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

["Woundy, Richard" <[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.
 
OK, if you would like to make comments on these MIB guidelines, you should
bring those comments to the proper forum in the IETF. The draft itself does
point out the best forum for these comments:
 
   Comments on this memo should be submitted to the
   <[e-mail]> mailing list.  To subscribe to this mailing
   list send an e-mail message to <[e-mail]> with
   the word "subscribe" in the message body.
 
-- Rich
-----Original Message-----
From: Fred Oko [mailto:[e-mail]] 
Sent: Friday, January 07, 2005 3:05 AM
To: Woundy, Richard; [e-mail]; [e-mail]
Cc: [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


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