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

Bert,

  We have discussed this set of issues for DOCSIS with Thomas Narten, yourself and Rich many times since 2002. Since then, I do not believe we have a mismatch. What was done was done, there is not much we CableLabs, the vendors or anyone can do about it.

  Let me be clear that we have worked hard to change the way we do things with MIBs and other IETF Internet-Drafts for that matter. My earlier emails on what we have done in PacketCable should provide detailed examples. Let me give you another example: in the SIP/SIPPING working groups, with the help of several vendors, we initiated the SIP DCS proxy-to-proxy draft and we worked with the wg chairs and Allison to get the draft to RFC. We then changed our SIP-based spec (PacketCable CMSS) to reference this RFC. Same for RFC 3495 on DHCP option 122 (which replaced an experimental DHCP option 177 assignment and that transition has gone well in the specs and in the field).

 See inline for additional comments.

Jean-François

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]] 
> Sent: Thursday, January 06, 2005 11:51 AM
> To: [email protected]; [email protected]; Jean-Francois Mule
> Cc: [email protected]; Eduardo Cardona; [email protected]; 
> 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
> 
> 
> Andre,
> 
> It sounds like we have a SERIOUS MISMATCH between CL and 
> IETF. 
  As I said above, I don't think we have any serious mismatch.  

> If CL wants to define their own stuff and mandate 
> implementations BEFORE IETF approves a MIB document, then 
> that is fine... 
> but then one should not come to IETF and try 
> to get IETF approval. It just does not work that way.

  With the time some of us put in the IETF work in various working groups, and my wg chair stance on IPCDN MIB issues when folks invoked "existing implementation" reasons in order not to address the comment, I hope you believe that we bring some contributions in the full spirit of IETF and that we benefit from expert advice and simple good engineering practices.


> And even if you do these sort of things just within CL, even 
> then I do see that you guys can easily run into 
> interoperability problems. 
  You bet.

> We are not doing this just for the 
> fun of it, but because there are serious risks for 
> inetroperability problems!
> 
> AGAIN, as I said before. if you want to root under docsIfMIb, 
> fine. Write a doc similar to 
> RFC3737 and we can do it. Not that we (IETF MIB Doctors) 
> prefer it that way, but we/you (IPCDN WG) can do it that way.


  Back to the original question, I have yet to see any good reason for not changing the OID assignment to mib-2 for the IETF IPCDN DOCSIS QoS MIB. Did I miss anything?

 
> It would still mean that you can only get the branch assigned 
> underneath docsIfMib AFTER IESG approval. That comes back to 
> possible interoperability issues if you assign it earlier.
> 
> Bert