RE: 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: [email protected] [mailto:[email protected]]
On Behalf Of [email protected]
Sent: Thursday, January 06, 2005 4:14 PM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
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:[email protected]
<mailto:[email protected]> ] 
Sent: Thursday, January 06, 2005 3:54 PM 
To: Wijnen, Bert (Bert); [email protected]; [email protected] 
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 


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]
<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 
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
[email protected]
https://www1.ietf.org/mailman/listinfo/ipcdn