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

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.

  

> -----Original Message-----
> From: Fred Oko [mailto:[email protected]] 
> Sent: Wednesday, January 05, 2005 8:26 PM
> To: Jean-Francois Mule; [email protected]
> Cc: [email protected]; Eduardo Cardona; DOCSIS OSS 
> Majordomo List; [email protected]
> Subject: 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.
> 
> 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?