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

["Jean-Francois Mule" <[e-mail]>]

André et al.,

  Please let us stick to the engineering issues and technical questions at stake. I'm trying hard to keep this thread focused on technical issues and keep it under control, please help me...

  I will only respond to the technical points. See inline.

Jean-Francois 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: Thursday, January 06, 2005 10:24 AM
> To: [e-mail]; [e-mail]; Jean-Francois Mule
> Cc: [e-mail]; Eduardo Cardona; [e-mail]; 
> DOCSIS OSS Majordomo List
> Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts 
> MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
> 
> 
> Bert, 

> The main problem is that CableLabs require CM and CMTS 
> vendors to submit their equipment for 

[snip, stripped non technical comments, irrelevant to the thread]

> certification process using draft MIBs as pre-requisites into 
> these certification waves (CW) 

A clarification is required:
 - the comment on MIB requirements pointing to IETF ID is only applicable to DOCSIS. We have learned from it and if you take the PacketCable MIB requirements for example, the MIB modules are rooted under the CableLabs private OID branch.
 

[snip, stripped non technical comments, irrelevant to the thread]

< If these MIBs were not 
> required until they become RFC, then we would all be happy, 
  This is the case for CableLabs projects like PacketCable and Cablehome and it has been our approach since 2002 for any new MIB in any project (including DOCSIS, the eDOCSIS SLED mib is a good example of it).
  The precedent has been set for DOCSIS and there is not much we can do about it other than work towards completing the RFCs to then analyze the gap between what we have been requiring and using in the field for years, and what the standard-track RFCs require. This is the only rationale process I can recommend, otherwise, we keep arguing about drafts that are moving targets, making suppositions about what will be required by CableLabs - this wg is not the right place for that.

Ultimately, we are all servicing the same clients, our cable operators, the service providers that deploy these MIBs and manage the network elements with it.

> except for the fact that the Cable industry wants to move 
> faster than the time it takes to properly go through the RFC 
> approval processes, which is a valid desire. 

  Consider this: if we had put the original DOCSIS MIB modules under the CableLabs private tree to start with, this entire discussion would be moot. We would have private CableLabs MIBs and IETF RFCs. The migration path would still need to be analyzed and code changes made to support the RFCs. This is no different than what some vendors do with other wg MIB ID: they need mib objects to go to market with, put them under their private branch until the IETF is done, then make code and tool changes to move to the RFCs.


[snip, stripped non technical comments, irrelevant to the thread]
> I concur with Fred here on most of his points. 
> Re-rooting any of the MIBs is a very expensive process as it 
> costs 100s of thousands of dollars for every vendor as they 
> require to implement and test the change and go through 
> certification with the changes. 

I will only respond to the technical part of this comment.
Read my response to Fred's email. The re-rooting is actually not the hardest piece here, it is the actual syntax and semantic changes that went into those MIBs that would cause the bulk of the work, on both the CM/CMTS network elements and the mgmt applications that use those mibs.
This about how we had been using Counter32 objects for e.g. and how we have come along... Same goes for many technical changes.


[snip, stripped non technical comments, irrelevant to the thread]

> be re-rooted. I wish someone could find a way to avoid such 
> re-rooting in the future. 

  Tell me if what we have been doing since 2002 in other CableLabs projects helps. 
  The solution to date has been: the private CableLabs MIBs should be defined under the CableLabs private OID.
  You, vendors with requirements from operators contribute to design MIB modules in the CableLabs project. We define them under the CableLabs private OID branches to go to market with. As we go through the standard process, we make some changes (look at the many PacketCable Engineering Changes that were introduced in our private MIBs based on the learning we went through due to the IETF process - simple things like changing ipAddress to the RFC 3291 textual conventions to just correcting plain wrong SMI syntax issues). We also submit the original MIB and changes to the IETF process when it is appropriate. Once we reach RFC status, an analysis of the gaps between the RFC and what is being implemented by vendors can be done with all kinds of considerations (costs, benefits, etc.). Ultimately, the cable operators make those important decisions on the product requirements.

> The draft docsBpi2MIB was placed by someone under 
> mib-2 transmission docsIfMIB and that was the right place for 
> it. 

  No.
  The IETF IPCDN ID for the DOCSIS BPI+ MIB, defining the docsBpi2MIB module, ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipcdn-bpiplus-mib-15.txt, is requesting an assignment under mib-2.

> It is a MIB that needs to be maintained per interface, 
> similarly to other MIBs found under the transmission tree. 
> That person assigned the ID 6 to it, assuming it would be the 
> next one to be adopted. 
/wg chair hat on
  This assignment was WRONG, and should NEVER have been done. Let's not use the bad examples of the past to justify what we should do now!!!
  We should have moved this set of MIB requirements under the CableLabs branch before it even became an ID, freeze those requiremetns as we like, then pursue the IETF standardization process as we have.
wg chair hat off/

> It would not serve anyone if it was 
> placed anywhere else. 

  See above, I disagree.
  The OID assignment in that branch is the sole authoritative responsibility of IANA and noone else should make any assignment in the IANA controlled namespace. 


> The draft Event Notification MIB was 
> placed by someone under mib-2 docsDev and assigned the ID 2 
> to it. 
Same comment as above.


> I also think this was an appropriate place for such 
  I disagree, see above.


> MIB and don't see a need to move it anywhere else. The draft 
> Qos MIB was placed under mib-2 transmission docsIfMIB and I 
> also think that was an appropriate place for it, as it also 
> needs to be maintained per interface. The person assigned ID 
> 7 to it as it was the next available ID. We hope that this 
> assignment will continue to be used for the RFC. Maybe the 
> solution to all this is to let the the IANA assign the 
> numbers to wherever they want, but define requirements in the 
> DOCSIS OSSI spec to re-root each of these RFCs to where they 
> were first allocated. This is ugly in terms of documentation, 
> but it matches the reality of having two standard bodies 
> trying to define the same things, each with their own valid 
> reasons. André 


Jean-François

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