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

From: "Fred Oko" <[email-masked]>
Date: Wed, 5 Jan 2005 22:26:03 -0500

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.

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)
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
	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

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
2) no re-roots have been implemented in any code -- they only exist in more recent drafts thus nullifying them is only on paper

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.

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.

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?

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, January 05, 2005 5:50 PM
To: [email-masked]
Cc: [email-masked]; Eduardo Cardona; DOCSIS OSS Majordomo List
Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

I concur with the comments made by Greg and Eduardo re: the fact that the IETF version of the mibs have somehow to be re-rooted. Thanks André for the rationale you provided.

Andre wrote:
> However, your original suggestion was to allow for "the OID 
> assignment of all the new IETF IPCDN DOCSIS RFCs under 
> mib-2". Purely based on taxonomy reasons, I don't think that 
> would be the right thing to do. Each MIB needs to be 
> considered separately. 
I would agree but this is more a question for the IETF mib police and how they would like to organize the IETF OID tree. From what we hear there, they do not necessarily like the multiplication of branches under mib2 for reasons I don't really know. Hence the question to the docsis oss team. The main point we wanted to understand from this thread is whether we had any specific reasons to have the OID assignment under docsIfMib(127).  Based on this dialog, we have no particular concerns with moving the mibs under a different root.

> What other experimental MIBs are about 
> to become RFC and therefore are being considered for this?
See all the IPCDN DOCSIS drafts at:
http://www.ipcdn.org/ipcdn-ids.html

2 OIDs are already assigned for rfc2669bis and rfc2670bis:
   - Cable device mib v2 ::= { mib-2 69 }
   - RF MIB v2    ::= { transmission 127 }

The other Ids in the queue to become RFC are:
   - Bpi+ (the IETF ID already asks for OID ::= { mib-2 yy } 
   - Event notif ::= { mib-2 xxx }
   - QoS MIB (subject of this discussion, we will request a change to mib-2 xxx)
   - subs mgmt (already approved for IETF publicaiton ::= { mib-2 xx } )

Others are PacketCable MIBs for which mib-2 is ok.

Jean-François 

> -----Original Message-----
> From: Eduardo Cardona 
> Sent: Wednesday, January 05, 2005 12:45 PM
> To: [email-masked]; [email-masked]; 
> DOCSIS OSS Majordomo List
> Cc: Jean-Francois Mule
> Subject: RE: IETF IPCDN proposed standard drafts MIB Modules 
> OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Andre, 
> 
> We have done same analysis as you did, 
> moreover in your case of subscriber MIB, the original 
> intention of the MIB was to simulate the CPE control 
> available in the CM but centralized ( MAX CPE and Filters) CM 
> Filters are in DocsDev so would be also appropriate to have 
> that mib in mib-2(1) docsDev(69) ?
> 
> By the way IETF normalized the filtering mechanism to follow 
> the classification mechanism available in diffServ 
> (mib-2)  diffServMib(97) 
> 
> mib-2 ?
> diffServMib?
> docsDevMib?
> docsIfMib?
> 
> Then your conclusion of setting that in mib-2 is more evident here,
> 
> For interface specific MIBs ( Cable MAC interface ) we 
> recognize that as a point to consider, and we appreciate you 
> pointed out  to that. that's the purpose of this quick 
> survey: Confronting IETF recommendations with Cable Industry 
> perception. 
> 
> Any other cons pros, vendors and DOCSIS community may think of?
> 
> Thanks
> 
> Eduardo
> 
> 
> 
> 
> 
> 
> 
> 
>  -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, January 05, 2005 11:08 AM
> To: Eduardo Cardona; [email-masked]; DOCSIS OSS 
> Majordomo List
> Cc: Jean-Francois Mule
> Subject: RE: IETF IPCDN proposed standard drafts MIB Modules 
> OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> OK. This is more like a taxonomy question then.
> 
> The question then becomes: are these MIBs related to a type 
> of interface or not. For example, docsIfMib was assigned 
> number 127, which corresponds to ifType 
> docsCableMaclayer(127). MIBs found under the docsIfMib would 
> therefore be related to the DOCSIS Cable MAC Layer 
> interfaces. This is why most of the MIBs found under the 
> transmission group are indexed by ifIndex (with, 
> unfortunately I guess, a few exceptions). A system with 
> multiple interfaces of the same type would have multiple 
> entries under the transmission tree to provide independent control.
> 
> Taking the subscriber management MIB, it seems to be a mixed 
> answer. The docsSubMgtCpeIpEntry is indexed by 
> docsIfCmtsCmStatusIndex and docsSubMgtCpeIpIndex. As such, it 
> looks like an extension to the docsIfCmtsCmStatusTable, 
> located under transmission, but not indexed by ifIndex. So I 
> guess we created a precedent already where we require 
> docsIfCmtsCmStatusIndex to be unique per CMTS, and not per 
> interface, even though it was placed under "transmission". 
> The subscriber management MIB also contains filter group 
> entries, which appear to be unique per CMTS and not really 
> related to the interface. So given these 2 considerations, it 
> seems acceptable to place this MIB under MIB-2, although one 
> could have argued that the docsIfCmtsCmStatusTable should 
> have been indexed by ifIndex in the first place, in which 
> case splitting the subscriber management MIB would have been 
> a possibility.
> 
> However, your original suggestion was to allow for "the OID 
> assignment of all the new IETF IPCDN DOCSIS RFCs under 
> mib-2". Purely based on taxonomy reasons, I don't think that 
> would be the right thing to do. Each MIB needs to be 
> considered separately. What other experimental MIBs are about 
> to become RFC and therefore are being considered for this?
> 
> Thanks,
> André
> 
> -----Original Message-----
> From: Eduardo Cardona [mailto:[email-masked]]
> Sent: Wednesday, January 05, 2005 11:56 AM
> To: Nakanishi Greg-MGI8179; [email-masked]; DOCSIS 
> OSS Majordomo List
> Cc: Jean-Francois Mule
> Subject: RE: IETF IPCDN proposed standard drafts MIB Modules 
> OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Correct, 
> 
> we are not looking in avoiding the root change, just to find 
> out if DOCSIS community have issues on moving the upcoming  
> brand new RFCs from docsIfMib (current spec drafts 
> requirement) to mib-2  (as a clarification, RFI MIB is not in 
> this category since it is an update of RFC 2670)
> 
> Thanks
> 
> Eduardo
> -----Original Message-----
> From: Nakanishi Greg-MGI8179 [mailto:[email-masked]] 
> Sent: Wednesday, January 05, 2005 9:46 AM
> To: [email-masked]'; Eduardo Cardona; DOCSIS OSS 
> Majordomo List
> Cc: Jean-Francois Mule
> Subject: RE: IETF IPCDN proposed standard drafts MIB Modules 
> OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Note that the currently required Subscriber Mgmt MIB (-02) is 
> rooted in the experimental branch.  When the MIB gets 
> standardized by the IETF it will move under the mib-2 branch. 
>  Regardless of whether it is located directly under mib-2 or 
> under mib-2.transmission.docsIfMib, the root is going to 
> change from the current experimental branch.  I don't see 
> anyway to avoid this.
> 
> greg
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Wednesday, January 05, 2005 8:15 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: IETF IPCDN proposed standard drafts MIB Modules 
> OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Eduardo,
> 
> You are probably familiar with the backwards compatibility 
> issues that occurred with the relocation of the docDev MIB 
> from experimental to its final location in RFC2669. In this 
> case, the problem was exacerbated by the fact that docsDev 
> MIB object entries often appear in configuration files. I 
> believe configuration files rarely contain entries from any 
> other MIB, with probably the exception of enterprise MIBs. If 
> this is true, then configuration files would not be an issue. 
> However, there are probably a lot of Support Systems out 
> there that make extensive use of these MIBs. So backwards 
> compatibility would probably be a requirement.
> 
> So my question is simple... Would we be required to support 
> these MIBs at both the old and new locations from the SNMP 
> agent interface? From the configuration file? If backwards 
> compatibility is required, I am afraid we would have to 
> oppose such change and request that the MIBs be left where 
> they are currently located.
> 
> André
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Eduardo Cardona
> Sent: Wednesday, January 05, 2005 10:55 AM
> To: DOCSIS OSS Majordomo List
> Cc: Jean-Francois Mule; Eduardo Cardona
> Subject: IETF IPCDN proposed standard drafts MIB Modules OID 
> assignments: Assigning new RFCs under mib-2
> 
> 
> 
> All,
> As you know, the IETF IPCDN wg is finalizing a number of 
> DOCSIS mibs. The subs mgmt MIB is done and will become an RFC 
> in the near future. In the final IETF reviews, it was 
> requested that we consider changing some of the OID 
> assignments from  ..mib-2(1) transmission(10) docsIfMib(127) 
> to just ..mib-2(1) (some draft DOCSIS MIBs including the QoS 
> MIB Internet-Drafts 
> http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-1
0.txt still request that the OID be assigned under mib-2..docsIfMib).

After some considerations, Jean-Francois and I do not see any real implications of this proposed change: the OID assignment of all the new IETF IPCDN DOCSIS RFCs under mib-2 seems ok since the MIB definitions of the published RFCs will be different and we would not gain much in retaining existing docsIfMIB OID values.

Can anyone see any issues with the change of assignments under mib-2? is there any pros & cons you would like to point out? Please get back to us by Thursday January 6.

Thanks

Jean-Francois, Eduardo

NOTICE: This communication contains information which may be proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you have received this communication in error, please do not print, copy,retransmit, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in error and delete the copy you received. Thank you.
NOTICE: This communication contains information which may be proprietary, privileged or confidential. If you are not the intended recipient (or authorized to receive for the intended recipient), or believe that you have received this communication in error, please do not print, copy,retransmit, disseminate, disclose or otherwise use the information. Also, please indicate to the sender that you have received this communication in error and delete the copy you received. Thank you.

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Jan 2005 11:27:08 -0700

Fred,
  
  Let me be direct: your email is totally inappropriate, and actually, misplaced.

  First, you responded to an email sent by Eduardo Cardona to the sole DOCSIS OSS reflector and copy the public IETF IPCDN reflector: you are effectively breaking the IPR policy your company signed. Worse, you included comments sent by André, comments that were solely sent in response to the DOCSIS OSS email Eduardo had sent). This is inappropriate.  Note that Eduardo and I wanted to ping the CableLabs DOCSIS OSS vendor team first by respect of the work those vendors have done for the MIBs and continue to do by bringing implementations to market - most of those vendors have implemented the DOCSIS MIBs we are talking about and not all unfortunately are watching the IPCDN traffic.

  Second, you missed the point of my email, the email I sent to the IETF IPCDN reflector. Note that in total transparence for the IETF process, we (Eduardo and myself) did communicate the same points to both the CableLabs DOCSIS OSS and IETF IPCDN reflectors. We asked internally the DOCSIS OSS team first as the MIB module in question was designed and evolved thanks to all the original contributions of the individuals and vendors part of the DOCSIS OSS team. But in the end (and that is the purpose on my email), the IETF IPCDN wg prevails and the IETF wg consensus is the one that matters.

Jean-Francois.

> From: Fred Oko [mailto:[email-masked]] 
> Sent: Wednesday, January 05, 2005 8:26 PM
> To: Jean-Francois Mule; [email-masked]
> Cc: [email-masked]; Eduardo Cardona; DOCSIS OSS 
> Majordomo List; [email-masked]
> 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.
> 
> 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)
> 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
> 	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
> 
> 1) current OID assignments, while not actually assigned by 
> IANA are guaranteed to be non-conflicting
> 2) no re-roots have been implemented in any code -- they only 
> exist in more recent drafts thus nullifying them is only on paper
> 
> 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.
> 
> 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.
> 
> 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?

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Jan 2005 12:04:26 -0700

See inline for the technical response.

> RFC transition. 

Per my email, there is one MIB module to be discussed here: 
http://www.ietf.org/internet-drafts/draft-ietf-ipcdn-qos-mib-10.txt

I do not see the rooting to the experimental branch in the above
referenced document.

> However, this only applies to the 
> subscriber-mgmt MIB. 
The IETF IPCDN subs mgmt MIB will be routed under ..mib-2.

> I would argue that there is no value, 
> widespread implementation and consumption. 
The point of this IETF email discussion is not to discuss what the
product requirements should be moving forward for CableLabs once the RFC
is published (this is totally inappropriate). The point is to get the
MIB to a stable RFC status and your technical input was requested just
for that.

> I would argue this 
A couple of points:
  - the IETF process follows its course and not only will the OID root
change but the MIB modules themselves - the one being worked on in IPCDN
have changed. And changed drastically sometimes (QoS mib in particular),
based on the expert advice from MIB doctors and the IETF community. They
have mostly changed for the better: for e.g., we are not mucking anymore
with the ECN bits when touching the DSCP code fields - I see those kinds
of changes as very important to improve the quality of our specs.
  - the requirements imposed by CableLabs for product qualification are
decided by its cable operator members as you are aware - this is not the
place to discuss this, sorry.

> Impact points of any re-root:
This is not a discussion for the IETF ID. This *potential* impact is
actually to be analyzed by the cable operators and CableLabs when the
time comes that we have all the DOCSIS MIBs to RFC status. My first goal
is to get those RFCs.

> implementations to support efficient backward-compatability 
                                       ^^^^^^^^^^^^^^^^^^^^^^^
   Have you followed the work of IPCDN? 
   this backward compatibility question has been raised and bottom line,
it is not possible. Some MIB modules have changed in a way that is
totally incompatible: renumbering of object OID entries in some tables
for e.g., change of object syntax that is incompatible on the wire, etc.

   But more importantly, backward compatibility is not our focus: the
IETF IPCDN wg and the IETF in general is not a rubber stamping
organization. If something needs to be changed in an Internet-Draft, it
is changed.

   More importantly, this is not specific to IPCDN or MIBs. Some vendors
implement internet drafts and have to change their implementations when
the RFCs are published. And we have yet to mandate any change since
there are no RFCs.

> IANA are guaranteed to be non-conflicting

/wg chair hat on
  I totally disagree. Read the mib drafts and analyze the syntax and
semantic changes in the MIB modules.
Wg chair hat off/

> exist in more recent drafts thus nullifying them is only on paper
  
  you are missing the point: code/implementation changes go far beyond
OID re-root if you want to take this path. 
  "thus nullifying them is only on paper" 
        ^^^^^^^^^^ I won't go there... And stop here.

> road that has been traveled. 
  I see no technical comment in the above paragraph.

> If we were forced to re-root I 
               ^^^^ 
  no.
> conventions across the many CL-related MIBs (docsIf, 
                              ^^
  what CableLabs has done is done. 

> to the author's discretion which one might tend to agree has 
         ^^^^^^^^^^^^^^^^^^^
Not in IETF IPCDN

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 6 Jan 2005 12:36:48 -0700

inline

> From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
> Sent: Thursday, January 06, 2005 4:42 AM
> To: Fred Oko; Jean-Francois Mule; [email-masked]
> Cc: [email-masked]; Eduardo Cardona; [email-masked]; 
> Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts 
> MIB Modules OID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Inline
> 
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Fred Oko
> > Sent: Thursday, January 06, 2005 04:26
> > Cc: [email-masked]; Eduardo Cardona; [email-masked]; 
> > Subject: [ipcdn] RE: IETF IPCDN proposed standard drafts 
> MIB Modules OID
> > assignmen ts: Assigning new RFCs under mib-2
> > 
> > 
> 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
> 
> 
> 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.

> 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)
> 
> 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

> 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.

> 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.
> 
> 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...

> 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.

> > 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.
> > 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?

> 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
> 
>

---

From: "Fred Oko" <[email-masked]>
Date: Fri, 7 Jan 2005 03:04:30 -0500

OK, sorry if I have transgressed. In part my cross-posting was something I questioned and took guidance from seeing some previous cross-posting (being the most efficient distribution) on the reflectors but will be careful to avoid such in the future. As a theme of this thread I embrace, we learn by doing.

In part I was under the impression that the draft period was a time not only for forward evolution but that time would also be given to examine the operational impact imposed upon MIB implementers and consumers so as to not run into a brick wall once the RFC is cast in stone/shipped -- we could later call it foresight. But as you say some of the drafts have taken directions that no longer support backward-compatibility and would in fact mandate a re-root to prevent OID<->object conflicts etc. As I was not tracking this at the time I can only assume that this was the only (/optimal by consensus) path and no longer open to review e.g.

    REVISION        "200302010000Z" -- February 1, 2003
    DESCRIPTION
        "Published as draft-ietf-ipcdn-qos-mib-07.txt.

        Changes from qos-mib-06 include:

        - Re-routed the docQosMib because of compilation errors.
        - Removed obsolete and deprecated objects.
        - Renumbered existing objects after removal of
          obsolete and deprecated objects.

and the subsequent renaming to DOCS-IETF-QOS-MIB from DOCS-QOS-MIB. 

But note that my original references to backward-compatibility were not referring to the desired intra-MIB backward-compatibility (to the version mandated to be implemented) we have lost but instead of the likely necessity of the CMTS to support (post-reroot) backward-compatability at the SNMP agent application layer by concurrently exposing both the already-implemented draft MIB in addition to the RFCed version (i.e. transition period). The only other field deployment precedent to such a case yet faced by CableLabs MIBs was the noted docsDev experimental and RFC versions at the CM level. But there the two versions were interchangeable but for OID root while here there could be a mandate to support two, as you note, quite different versions of what in some cases can be expensive MIBs to manage resource-wise.

I would think the experiences of the respondents on this thread would cry out for a better scheme for handling such version incompatibilities if this is truly such a common occurrence with internet drafts in industries that demand rapid deployment. I would expect this to be one trait to consider in evaluating possible technology replacements for SNMP in DOCSIS3.0 such that it is easier to support versioning through handshake or views.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Thursday, January 06, 2005 1:27 PM
To: Fred Oko; [email-masked]
Cc: [email-masked]; Eduardo Cardona; DOCSIS OSS Majordomo List; [email-masked]; Dan Rice
Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

Fred,

Jean-Francois.

---

From: "Eduardo Cardona" <[email-masked]>
Date: Fri, 7 Jan 2005 08:39:41 -0700

few comments inline

-----Original Message-----
From: Fred Oko [mailto:[email-masked]] 
Sent: Friday, January 07, 2005 1:05 AM
To: Jean-Francois Mule; [email-masked]
Cc: [email-masked]; Eduardo Cardona; DOCSIS OSS Majordomo List; [email-masked]; Dan Rice
Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

<Edo>
 
SNMP semantics is believed to be rich enough to have a solution for transitions, 
If in the past docsis required the dual implementation of CD MIB in experimental as well as RFC 2669, we always take take the exercise of evaluate those consiredations for backward compatible analysis as the specs evolve
Specially on those days (DOCSIS 1.0) it was a matter of one MIB module for CMs with reduced number of instances per MIB structures such tables. 
In the current case (anyway outside of the topic discussion) we are also covering CMTS which is a different situation
Thanks for pointing out those elements that certainly are critical in deciding where to shift the transition cost ( device or Management system).
 
- The history told us that DOCSIS 1.0 put the load in the CM, 
DOCSIS 1.1 removed that "dual" MIB requirement so we have 4 years of DOCSIS 1.1 requirements that hopefully are pusshing the NMS applications to the next level

In particular, as well as SNMPv3 stack normaly automatically does Engine ID discovery, I believe it is expected for the NMS to do Mib modules per device registeration by querying sysOrTable and dynamically swap MIB modules and or Management routines and scripts. (Agree reads simple but could be complex, but what application on todays days is dump simple?)

That's not such difference on already products ready to switch from IP MIB RFC 2011 to the upcoming RFC 2011 updates for IPv6. as an example:
ipNetToPhysicalTable replaces ipNetToMedia
 - Changes of Object names
 - Changes of Index structure ( INETAddress requirements)
It means total applications rewrite

In our case "in the eventuality of updates" to new RFCs
- Majority of the objects keep the same name ( different MODULE name)
- A discovery process as indicated above will do most of the work
- Potentially Apps can stay quite the same, just the OID engine need to be smarter

Again, not saying that is easy, cost implications etc. other forums or discussions will decide that.

In summary, The Cable transition from one root to another, Is necessary, not an isolated case, (not exclusive for "rapid deployment" industries).  All IETF faces those paradigms, and the solutions for backward compatibility, and old devices support should (wish) come from all IETF parties. 

Your DOCSIS 3.0 comments
Based on your inertia of cross-pointing lists, please note that there is also a DOCSIS 3.0  Majordomo list, which I verified you are already subscribed.
 
</Edo> 

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Thursday, January 06, 2005 1:27 PM
To: Fred Oko; [email-masked]
Cc: [email-masked]; Eduardo Cardona; DOCSIS OSS Majordomo List; [email-masked]; Dan Rice
Subject: RE: IETF IPCDN proposed standard drafts MIB Modules OID assignmen ts: Assigning new RFCs under mib-2

Fred,

Jean-Francois.

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 7 Jan 2005 12:38:10 -0700

Fred Oko wrote:
> OK, sorry if I have transgressed. In part my cross-posting 
> was something I questioned and took guidance from seeing some 
> previous cross-posting (being the most efficient 
> distribution) on the reflectors but will be careful to avoid 
> such in the future. As a theme of this thread I embrace, we 
> learn by doing.

No problem. Sorry if my email response was perceived as harsh, it was not intended.

[snip]

Fred Oko wrote:
> But as you say some of the drafts have 
> taken directions that no longer support 
> backward-compatibility and would in fact mandate a re-root to 
> prevent OID<->object conflicts etc. 

So does this mean you are ok with the IETF IPCDN QoS MIB Internet-Draft 10 being changed to request an OID assignment under ..mib-2(1)?  I would like to get wg consensus on this: we have to move this draft along to get it on the IESG agenda asap.

> As I was not tracking 
> this at the time I can only assume that this was the only 
> (/optimal by consensus) path and no longer open to review e.g.
> 
  Yes. For reference, this is well documented.
  On 2/13/03, during the interim IPCDN wg meeting held at CableLabs chaired by Rich Woundy and myself, Bert Wijnen had strongly recommended this approach when reviewing the BPI+ mib draft 06. We as a wg approved to re-route the DOCSIS BPI+ then under mib-2, and we also agreed to change all IPCDN MIB module identity names.
  See http://www.ipcdn.org/meetings.html, Feb 13 2003 meeting,
  and the notes recorded in the IETF proceedings at:
  http://www.ietf.org/proceedings/03mar/slides/ipcdn-1/index.html

> But note that my original references to 
> backward-compatibility were not referring to the desired 
> intra-MIB backward-compatibility (to the version mandated to 
> be implemented) we have lost but instead of the likely 
> necessity of the CMTS to support (post-reroot) 
> backward-compatability at the SNMP agent application layer by 
> concurrently exposing both the already-implemented draft MIB 
> in addition to the RFCed version (i.e. transition period). 
  Ok. The latter is always what I meant. Note that, as I pointed out, the decision to mandate the "likely necessity of the CMTS to support" is something that will be done by cable operators. Be assured that we will deal with this extremely carefully and communicate with the vendors as part of the CableLabs process (this is btw not a topic for discussion in IETF).

> I would think the experiences of the respondents on this 
> thread would cry out for a better scheme for handling such 
> version incompatibilities if this is truly such a common 
> occurrence with internet drafts in industries that demand 
> rapid deployment. 
  Isnt' the way we have dealt with those issues in the CableLabs PacketCable and Cablehome projects answering your request for a better scheme?

Jean-François