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

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

I would be interested seeing best practices that have been learned by readers of this reflector contributed to the 04 version of the noted draft-ietf-ops-mib-review-guidelines-03.txt. In particular, as an expansion upon the advise against using experimental for anything that would see field deployment (as is the case for all IPCDN drafts and the like) the advice of the possibly cleaner direction of using enterprise space (e.g. CableLabs enterprise clabProj* of noted path being taken by IPCDN) with notes for the possible necessities of re-rooting.
 
 
4.3.  Naming Hierarchy
   Experience has shown that it is impractical to move objects from one
   subtree to another once those objects have seen large-scale use in an
   operational environment.  Hence any object that is targeted for
   deployment in an operational environment MUST NOT be registered under
   the experimental subtree, irrespective of the standardization status
   of that object.  The experimental subtree should be used only for
   objects that are intended for limited experimental deployment.  Such
   objects typically are defined in Experimental RFCs.
 
 
-----Original Message-----
From: Woundy, Richard [mailto:[e-mail]] 
Sent: Thursday, January 06, 2005 4:48 PM
To: '[e-mail]'; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; Fred Oko
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
 
Here is what the current MIB guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt <http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guidelines-03.txt> , section 4.5)have to say:
 
   - The value assigned to the MODULE-IDENTITY descriptor MUST be unique
     and (for IETF standards-track MIB modules) SHOULD reside under the
     mgmt subtree [RFC2578].  Most often it will be an IANA-assigned
     value directly under mib-2 [RFC2578], although for media-specific
     MIB modules that extend the IF-MIB [RFC2863] it is customary to use
     an IANA-assigned value under transmission [RFC2578].  In the past
     some IETF working groups have made their own assignments from
     subtrees delegated to them by IANA, but that practice has proven
     problematic and is NOT RECOMMENDED.
 
-- Rich
	-----Original Message-----
	From: [e-mail] [mailto:[e-mail]] On Behalf Of [e-mail]
	Sent: Thursday, January 06, 2005 4:14 PM
	To: [e-mail]
	Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
	Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
	Jean-Francois, 
	What are the attributes that a MIB has to have, in your opinion, for being added to the transmission OID under mib-2, as opposed to only be added to mib-2? I presented my opinion regarding this, which was that a MIB that would only be applicable to a certain type of interface would be better placed under the associated transmission type rather than being placed at the mib-2 level. I have not seen any justification for not doing this with the QoS MIB and BPI+ MIBs, other than the fact that the latest drafts of the BPI+ MIB is requesting them under mib-2, which is not a sufficient justification in my opinion.
	André 
	-----Original Message----- 
	From: Jean-Francois Mule [mailto:[e-mail]] 
	Sent: Thursday, January 06, 2005 3:54 PM 
	To: Wijnen, Bert (Bert); [e-mail]; [e-mail] 
	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, 
	  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:[e-mail]] 
	> Sent: Thursday, January 06, 2005 11:51 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 
	> 
	> 
	> 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 
	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