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

See inline for the technical response.

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

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, 
> only negative operational implications, and no impervious 
> mandate for re-rooting any other MIB that has already seen 
> 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 
> 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.
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.

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

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

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

> 2) no re-roots have been implemented in any code -- they only 
> 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.


> 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. 
  I see no technical comment in the above paragraph.

> 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 
               ^^^^ 
  no.
> 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, 
                              ^^
  what CableLabs has done is done. 

> 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 
         ^^^^^^^^^^^^^^^^^^^
Not in IETF IPCDN

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