RE: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

inline

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]] 
> Sent: Thursday, January 06, 2005 4:42 AM
> To: Fred Oko; Jean-Francois Mule; [email protected]
> Cc: [email protected]; Eduardo Cardona; [email protected]; 
> DOCSIS OSS Majordomo List
> Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts 
> MIB Modules OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Inline
> 
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]]On Behalf Of
> > Fred Oko
> > Sent: Thursday, January 06, 2005 04:26
> > To: Jean-Francois Mule; [email protected]
> > Cc: [email protected]; Eduardo Cardona; [email protected]; 
> >     DOCSIS OSS Majordomo List
> > Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts 
> MIB Modules OID
> > assignmen ts: Assigning new RFCs under mib-2
> > 
> > 
> > I would agree that a MIB for which the author had the
> > foresight to root in the experimental(3) branch would be 
> > expected (both by MIB consumers and IETF) to be re-rooted for 
> > RFC transition. However, this only applies to the 
> > subscriber-mgmt MIB. I would argue that there is no value, 
> > only negative operational implications, and no impervious 
> > mandate for re-rooting any other MIB that has already seen 
> > widespread implementation and consumption. I would argue this 
> > not only for the QOS MIB, but for any draft MIB for which 
> > originally had a sub-docsIfMib or enterprise root that was 
> > mandated to be supported in any already passed CableLabs 
> > certification wave. The reasoning is that since these objects 
> > were implemented by CM/CMTS vendor and qualified, they have 
> > most certainly been also implemented against by existing OSS 
> > software, wherein lies definite operational impact of such a 
> > major change.
> > 
> I think the above shows where we have a BASIC problem (and we 
> discussed this in the past as well). 

  We are all aware of the problem as it exists and will continue to
exist: we have implementations of Internet-Drafts. This basic problem
exists in many places and companies deal with it.
  As a co-author of the SIP MIB, I can tell you that back in 2000, 2
companies had implementations of the SIP MIB draft 01. We are now almost
done, and the to-be-published sip mib draft09 has incompatibility
changes with draft 2...


> When trying to standardize a MIB document in the IETF, then 
> there should be NO assumptions on where the module gets 
> rooted. That will ONLY be known 
> once the document has been approved by the IESG. After that 
> approval, it is 
> IANA who assigns the OID. 
> 
> And that is exactly one of the reasons why we do not like 
> that WGs start assigning MIB modules underneath some OID 
> branch for that WG/technology.

  And we have not in the IETF IPCDN wg.
  More importantly, CableLabs has learned from this: DOCSIS is what it
is, we cannot change it but for other projects like PacketCable and
CableHome, the MIBs we originated with the help of vendors and our
service operator members like the MTA MIB have been routed under the
CableLabs private OID.

> The reason for not wanting such early assignments (other than 
> experimental) is that the MIB module may change (dramatically 
> even) during the process in the IETF WG, IETF Last Call, MIB 
> Doctor review, IESG review. And so if anyone implemented the 
> MIB module based on some random revision of an Internte-Draft 
> then that module (with assigned OID) might be completely 
> different than the one that finally gets approved (same OID 
> if you followed your logic). And so that WILL result in 
> INTEROPERABILITY problems in the market place.

  I agree and our goal in IPCDN has been to follow the IETF process.

> See also draft-ietf-ops-mib-review-guidelines-03.txt sections 
> 4.3 and 4.5
> 
> 
> > Impact points of any re-root:
> > 1) common to any change: CMTS and CM vendor must change code,
> > CL must update ATP etc for qualifications, vendors must 
> > re-qualify code, and MSO's must deploy new code (granted 
> > required just for other MIB updates if not re-root)
> 
> While a MIB is under development in the IETF, no one should 
> be assuming that such a MIB module is final and so no-one 
> should be using a pre-assigned OID for the MIB module. If 
> anything, one could use experimental (need to request an 
> assignment though; also see warnings about that in mib review 
> guidleines) or your own (vendor specific OID tree. Make sure 
> you UNDERSTAND that the names (OIDs) should not 
> conflict with any future final OID for the MIB once approved.


> 
> > 2) a decision must be made whether a CMTS or CM is
> > backward-compatible (either as mandated by CL or discretion 
> > of vendor as advised by MSOs) and supporting two instance of 
> > a MIB has implications -- and regardless the decision of 
> > backward-compatibility on a single device, any OSS that 
> > monitors across a non-homogeneous field will of course have 
> > chance to run into new and old instances
> 
> If one follows MIB guidelines/rules (and you MUST follow 
> those to get a 
> MIB module or an update to a MIB module approved in IETF), 
> then these guidelines/rules (and associated MIB doctor review 
> in IETF) will guarantee backward compatibility. If such needs 
> to be compromised, then it would only happen with serious and 
> explicit agreement of the WG and otehr IETF review (for 
> example when everyone agrees that there was a BUG in an 
> earlier module)
> 
> > 	a) multiple OIDs for same subidentifiers must be known
> > by clients which may have preference to use non-fully-qualified
> > 	b) if back-compat, collection must limit itself to one 
> > of the two instances to avoid double collection thus 
> > requiring conditional logic based on probing
> > 	c) I would expect any MSO with utilities that are 
> > broken by such a re-root will demand this "bug" be fixed by 
> > the vendor thus forcing effective back-compat
> > 	d) it may be difficult for some SNMP agent 
> > implementations to support efficient backward-compatability 
> > (i.e. two OIDs mapping to same in-memory data) as such 
> > efficiency would be a must for some of the expensive MIB tables
> > 3) Since CL CW have continued to require very old drafts we 
> > know that implementation against the "old"/only OIDs have 
> > been in use for a while
> > 
> Not sure I understand all points a-b. 
> What is an MSO?
  Multi Service Operator a.k.a. cable operator

> What is CL CW?
  CableLabs Certification Wave
  This has nothing to do with this discussion BTW


> > No real impact points of not re-rooting anything -- simplest path:
> > 1) current OID assignments, while not actually assigned by
> > IANA are guaranteed to be non-conflicting
> 
> that is good.
> But, since they only exists in Internet-Drafts, they have not 
> really been assigned!!!! That is the thing to understand!!! PLEASE!

   Exactly.

 
> > 2) no re-roots have been implemented in any code -- they only
> > exist in more recent drafts thus nullifying them is only on paper
> > 
> As explained above, they SHOULD NOT exist in running code!!! 
> This is a real basic approach of how we do Iinternet-Drafts 
> and how and why we assign OIDs AFTER an Internet-Draft has 
> gone through the whole IETF developement and review process 
> and has been APPROVED 
> by the IESG.
> 
> > Additionally I personally see little value in the any
> > re-roots beyond philosophical cleanliness. I do agree that 
> > all MIBs may not be semantically perfect below docsIf, but I 
> > take it as the best hierarchical umbrella we have on that 
> > road that has been traveled. If we were forced to re-root I 
> > would advocate at least leveraging hierarchy by contextually 
> > group all CL/IPCDN related objects together instead of having 
> > them assigned loosely and likely non-contiguously into the 
> > mib-2 free space. E.g. in that sense I was a fan of the 
> > enterprise clab root.
> > 
> 
> I have explained to teh chairs, that a reroot is not MANDATORY.

  And if you read my post from yesterday, I stated:
> The alternative is that we document the 
> motivations and rationale for continuing to assign MIBs under 
> ..mib-2(1) transmission(10)
> docsIfMib(127)) - I am willing to do this if the wg feels 
> strongly about it.


> But IF you want to continue to allocate (or keep the current
> allocations) under docIfMib, then I would URGE you to create
> a document similar to RFC3737.

  I think we are on the same page. But since we (as individual
contributors) did not see much impact for the IETF IPCDN mibs given the
technical changes of the mib modules anyway, we decided to poll the
interested folks to see if we could put it under mib-2.

 
> And in the future, you would NOT let an Internet-Draft have any
> pre-assigned value, but instead have something aka:
> 
>    ::= { docsIfMib xx } -- xx to be assigned by IANA as per
>                         -- procedures outlined in 
> <your-rfc3737-equivalent>
> 
> So you (the WG) has basically been mis-using the fact that you
> had a docIfMib branch and were pre-assigning values against the
> normal process, and with the risk of having incomp-atible versions
> of MIB modules in implementations!

  Point taken. Trying to correct it...

 > > The very nature of so many representative MIB-rooting 
> > conventions across the many CL-related MIBs (docsIf, 
> > experimental, mib-2-pending, clab) suggests if this is not 
> > exactly a contentious issue, it is definitely one still open 
> > to the author's discretion which one might tend to agree has 
> > been non-optimal. I also see a variable modification time of 
> > these drafts at some middle revision to change OID roots 
> > which indicates it was not guided by a single firm guiding 
> > consensus (but perhaps MIB doctor advice trickle effect?). I 
> > would advocate that a firm future-guiding decision be made 
> > that would apply to all as-of-yet unwritten MIBs.
> > 
> Totally agree. And having 4 or 5 potential places to root a
> new MIB mdoule aka
>   docsIf, experimental, mib-2-pending, clab
> seems REALLY REALLY bad to me.

   Let me respectfully disagree with Fred's comment you quote but agree
with you when you say:
> And having 4 or 5 potential places to root a
> new MIB mdoule aka
>   docsIf, experimental, mib-2-pending, clab
> seems REALLY REALLY bad to me.


Here is why I disagree with Fred's comment. Fred wrote:
> > these drafts at some middle revision to change OID roots 
     Internet-drafts are not assigned any roots per Bert's earlier
comment. So the point is moot.
> > which indicates it was not guided by a single firm guiding 
> > consensus (but perhaps MIB doctor advice trickle effect?). 
     Who has raised this OID rooting issue in the past in the wg before
the draft went to mib doctor or AD reviews? I am willing to accept those
kinds of comments about "single firm guiding consensus". 
     We learn as we go, all together, no single point. We guide when we
know. Note that this area of MIB authoring is so complex to comprehend
and do well that we go to "mib doctors" and have to follow the MIB
authoring guidelines. We all learn by doing it, right?

> > Though were these proposed re-roots to make their way 
> > unimpeded into continued-draft/RFC/ECR/cert-wave would a good 
> > time estimate to seeing such in the field be late 2006?
> > 
> 
> Bert Wijnen,
> speaking as co-AD for the IETF OPS area.
> open to a good discussion on this topic and to try and document 
> the correct and agreed way for new and furture MIB dvelopement
> in this space.
> 
> Bert
> 
>