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

["Fred Oko" <[e-mail]>]

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:[e-mail]] 
Sent: Wednesday, January 05, 2005 5:50 PM
To: [e-mail]
Cc: [e-mail]; 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: [e-mail]; [e-mail]; 
> 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: [e-mail] [mailto:[e-mail]] 
> Sent: Wednesday, January 05, 2005 11:08 AM
> To: Eduardo Cardona; [e-mail]; 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:[e-mail]]
> Sent: Wednesday, January 05, 2005 11:56 AM
> To: Nakanishi Greg-MGI8179; [e-mail]; 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:[e-mail]] 
> Sent: Wednesday, January 05, 2005 9:46 AM
> To: '[e-mail]'; 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: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, January 05, 2005 8:15 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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: [e-mail] 
> [mailto:[e-mail]]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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn