RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
"Jean-Francois Mule" <jf.mule@cablelabs.com> Thu, 06 January 2005 22:43 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02060 for <ipcdn-archive@ietf.org>; Thu, 6 Jan 2005 17:43:56 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgZA-0005yW-HU for ipcdn-archive@ietf.org; Thu, 06 Jan 2005 17:57:16 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgK7-0005AI-Sj; Thu, 06 Jan 2005 17:41:43 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CmgIn-0004MR-Ti for ipcdn@megatron.ietf.org; Thu, 06 Jan 2005 17:40:21 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01851 for <ipcdn@ietf.org>; Thu, 6 Jan 2005 17:40:19 -0500 (EST)
Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmgVf-0005rn-5W for ipcdn@ietf.org; Thu, 06 Jan 2005 17:53:39 -0500
Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id j06Mdf1e000422; Thu, 6 Jan 2005 15:39:42 -0700 (MST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
Date: Thu, 06 Jan 2005 15:39:41 -0700
Message-ID: <CD6CE349CFD30D40BF5E13B3E0D8480406A48E@srvxchg.cablelabs.com>
Thread-Topic: [ipcdn] RE: IETF IPCDN proposed standard drafts MIB Modules O ID assignmen ts: Assigning new RFCs under mib-2
Thread-Index: AcT0NNqC/WZWk+3LSrSzttC2xuJ8awABJBIw
From: Jean-Francois Mule <jf.mule@cablelabs.com>
To: andre.lejeune@Terayon.com
X-Approved: ondar
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2
Content-Transfer-Encoding: quoted-printable
Cc: Eduardo Cardona <e.cardona@cablelabs.com>, ipcdn@ietf.org, DOCSIS OSS Majordomo List <docsis-oss@cablelabs.com>, gnakanishi@motorola.com, bwijnen@lucent.com
X-BeenThere: ipcdn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP over Cable Data Network <ipcdn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipcdn@ietf.org>
List-Help: <mailto:ipcdn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipcdn>, <mailto:ipcdn-request@ietf.org?subject=subscribe>
Sender: ipcdn-bounces@ietf.org
Errors-To: ipcdn-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Content-Transfer-Encoding: quoted-printable
All right, back to good technical discussions. Andre wrote: > 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 believe some rough and vague guidelines can be found in the old MIB-II (RFC 1213 section 3.12) - now transmission is normatively defined by rfc2578 I think (SNMPv2-SMI). And that section 3.12 is the section I considered before I sent the email yesterday. Here is an outdated dump of the first assignments under the transmission branch: Prefix: iso.org.dod.internet.mgmt.mib-2.transmission (1.3.6.1.2.1.10) Decimal Name Description ------- ---- ----------- 5 x25 X.25 [RFC1382] 7 IEEE802.3 CSMACD--like Objects [RFC1650] 8 IEEE802.4 Token Bus-like Objects -- [RFC1230,RFC1239] 9 dot5 Token Ring-like Objects [RFC1743] 15 FDDI FDDI Objects [RFC1285,JDC20] 16 lapb LAP B [RFC1381] 18 ds1 T1 Carrier Objects [RFC1406] 19 e1 E1 Carrier Objects [RFC1406] 23 ppp Point-to-Point Protocol [RFC1471] 30 ds3 DS3/E3 Interface Objects [RFC1407] 31 sip SMDS Interface Objects [RFC1694] 32 frame-relay Frame Relay Objects [RFC1315,CXB] 33 RS-232 RS-232 Objects [RFC1659] 34 Parallel Parallel Printer Objects [RFC1660] 35 arcnet ARC network 36 arcnet-plus ARC network plus 37 atm ATM 38 MIOX25 MIOX25 [RFC1461] 39 sonetMIB SONET MIB [RFC1595] 44 frnetservMIB Frame Relay Service MIB for DCE [RFC1596] ... 127 docsIfMib DOCSIS RFI MIB [RFC2670] The DOCSIS RFI mib clearly defined a new type of transmission media (docsis mac layer which fits somewhat well within the above table). The key question is: why should the QoS MIB stay under transmission 127? One could argue that it defines interface extensions (the docsQosPktClassTable relies on ifIndex being an ifType of 127) - hence the justification. And this is fine by me: as my earlier post, I stated, we could document those kinds of motivations in a document (Bert added in an RFC3737-like document). My earlier email asked the question: do *we* in IPCDN see any real impact of changing the assignment of the IETF IPCDN *Internet-Draft* from *unassigned_by_IANA_under_docsIfMib* to *unassigned_by_IANA_under_mib-2*? There, I could not find any good reasons as I started in the email. That said, I would raise the following considerations: - because of the mal practices of assigning DOCSIS MIBs under docsIfMib (by CableLabs), I would argue that the best thing we can do is break the current OID given the syntactic and semantic MIB changes; that means either request that IANA assigns a random OID under docsIfMib that does *not* match the one that has been allocated, or, request that IANA assigned an OID under MIB-2; I think this is one of the points where I fundamentally disagree with your argumentation. Since the MIB module has changed so much, the best thing we can do to avoid OID namespace conflict and nightmares is to make sure the IETF IPCDN RFC root is different from the one used (or more correctly wrongfully used). - Mike Heard's MIB authoring guidelines (http://www.ietf.org/internet-drafts/draft-ietf-ops-mib-review-guideline s-03.txt) do state something about uniqueness of the OIDs, and this is a key point to me. Hence my earlier email: - if IANA were to assign this QoS MIB under a mib-2 root, I do not see any real implications. It is more a MIB tree management issue that the IETF ops area and mib doctors should worry about that I guess. I personally do not like the multiplication of branches (I tend to like more leaves rather than branches ;) - If IANA were to assign it under a docsIfMib root, there are no real implications from an IETF point of view but there might be some tough times in implementations and potential migrations --- if and when the CableLabs requirements change which again is an argument that does not belong here. I hope this answers your question. Let me add something you stated earlier which I strongly oppose: You wrote: > 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. No. Do you realize that the latest QoS MIB internet-drafts have changed some object syntax? DSCP for e.g. Do you want an OID to map to 2 different, imcompatible object definitions? Because that is what I think you end up with if you follow what you say. > 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. Dr. Richard Green, CableLabs CEO continue to say that CableLabs is not a standard body, period. We work with other SDOs to get our specifications to standardization level, like SCTE, ANSI, ETSI in Europe. Dr. Richard Green is also the chairman of ITU-T SG9 where DOCSIS is an international standard approved as an ITU-T recommendation. And this is just not the way we have worked within IETF to date: the IETF IPCDN mibs contain sometimes drastic changes to our original submission (see the use of the diffserv mib objects in the subs mgmt mib, section 3.3 of http://www.ipcdn.org/drafts/draft-ietf-ipcdn-subscriber-mib-16.txt). Our goal is to get those MIBs to stable RFC status with all the changes that were brought through this process. Jean-Francois. _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Wijnen, Bert (Bert)
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… andre.lejeune
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Wijnen, Bert (Bert)
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Jean-Francois Mule
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Jean-Francois Mule
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… andre.lejeune
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Woundy, Richard
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Jean-Francois Mule
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Fred Oko
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Woundy, Richard
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Wijnen, Bert (Bert)
- RE: [ipcdn] RE: IETF IPCDN proposed standard draf… Woundy, Richard