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

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.