Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

From: "Eduardo Cardona" <[email-masked]>
Date: Thu, 24 Jul 2003 18:59:36 -0600

See comments inline

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
Sent: Thursday, July 24, 2003 3:26 PM
To: Eduardo Cardona; Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn
(E-mail)
Cc: [email-masked]; Alexander Katsnelson; [email-masked]
Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10

Inline

> -----Original Message-----
> From: Eduardo Cardona [mailto:[email-masked]]
> Sent: donderdag 24 juli 2003 19:40
> To: Wijnen, Bert (Bert); Jean-Francois Mule; Ipcdn (E-mail)
> Cc: [email-masked]; Alexander Katsnelson; [email-masked]
> Subject: RE: [ipcdn] Changes made in draft-ietf-ipcdn-bpiplus-mib-10
> 
> 
> >In fact, looking at this, it seems a weird structure of the OID tree.

> >So you better decide what you want or how to clean it up if that is 
> >what you want. Maybe we discussed this 5 months ago and I forgot. 
> >Maybe it is indeed best to put this one under mib-2
> 
> Bert,
> We Would like to get your advise in this topic and I am extending some
> generalization:
> 
> The DOCSIS Interface suite of mibs were initialy visualized as :
> 
> Mib-2 branch Device mibs RFC 2669 ( eventually SubMgmt also)
> 
That seemed (and still seems) to make sense.

> Mib-2.transmission.docsIfMib(127) branch:  Extension of CATV Interface
> (ifType=127) for Phy/MAC layer requirements like bpi,
> bpiplus, docsQos, 
> 
So I can see that transmission.127 makes sense for the RFC2670 MIB.
Seems that BPI, BPIPLUS are also strongly related to a MAC interface, so
probably assigning them underneath docsIfMib is OK.

For the QOS MIB module I am not so sure. Seems to me that that should go
under mib-2, similar to how DIFFSERV-MIB went under mib-2.

<edo>
I have no strong position in that.
Only will point that Qos in DOCSIS is only in the RF transmission path
between CM and CMTS, 
At the higher level are the packet classifiers ( where Diff-serv is
analogous and complimentary -Filtering/classifying -  and will provide
at some point the bridge for end-to-end QOS)

My only concern is that DOCSIS QOS also handle service Flows information
which contains mac parameters: polling rates/types, burst size, etc.
kind of interface specific information. Not sure if that qualifies to
reside in the transmission branch.

Eventually in the future, Classifiers could be strip out to the mib-2 (
DIFF-Serv integration ) and the Service Flow information reside in the
transmission docsIfMib area, just thoughs.
 
</edo>   

> Is that still a valid approach for the submitted drafs or mib-2 branch

> will be the structure wise required tree?

See above... they need to go where we think they make sense logically.

What I possibly would have done is something aka:
  
  Mib-2.transmission.docsis(127)  -- generic OID branch for DOCSIS
interface
                                  -- objects
  docsis.docsIfMib(1)             -- docsIfMib
  docsIfMib.docsIfMibObjects(1)   -- OID branches within docsIfMib

  docsis.docsBpiMib(2)            -- docsBpiMib
  docsis.docsBpiPlusMib(3)        -- docsBpiPlusMib

In other words, I would have used one branch under which I would put the
MIB modules, and then within each MIB module I would have made anotehr
level for Objects, Notifications, Compliances etc. You have now
intermixed all that and that has made it a bit of a mess (at least in my
eyes). But we cannot fix that anymore. Or if we do, then it comes with a
lot of pain I suppose.

<edo>
Yes, very painfull, Docsis 1.0 started with RFC 2670 and only after a
while bpi was added and now bpiplus but not higher root was defined or
visualized at that time. 

</edo>   

> Is there any other OID holder based on functionality schema?
> ( security/Qos ) ? 
> The intention of that was corroborated ( I presume that ) with the
> assignemt of bpi mib RFC 3083 under docsIfMib 5 
> 
> We definitely will do what IETF and IANA wanted to keep organized the 
> OID trees, but a better understanding of IETF desire will be really 
> valuable. And the drafts could be the places to keep those trends 
> requirements among IETF, IPCDN and IANA.
> 
Within One MIB module, people can assign in the DRAFT docs itself. You
normally have something aka:

  someModuleMib MODULE-IDENTITY
     ...
  ::= { root-oid xx } -- xx to be assigned by IANA

  Within root-oid.xx you can then assign your own structure

This will help in the sense that you only get xx assigned once the ID
gets published as an RFC. And that is the time that people can actually
use the OID that gets assigned, not anytime earlier while you are still
developing the draft.

> A look of your oid mapping:
> 
>  docsIfMib 1   - RFC2670 mib objects
>  docsIfMib 2   - RFC2670 notifications
>  docsIfMib 3   - RFC2670 conformance 
>  docsIfMib 5   - RFC3083 bpi objects/notifications/conformance
> 
> The current drafts (implemented in the field showed in parantesis): ->

> prior to InetAddress RFC 2851/3291
>  docsIfMib 6   - bpiplus (draft 05) objects/notifications/conformance
>  docsIfMib 7   - docsQos (draft 04) objects/notifications/conformance
> 
This is REALLY BAD. Peopl should NOT and NEVER implement I-Ds and then
use OIDs from the IANA maintained/controlled OID space) for the MIB 
modules that are not yet published as RFC.
Vendors could have put them under their enterprise OID tree, or maybe
under some experimental OID tree if you had asked for one.

<edo>
That's our fault is good that IETF is doing a tremendous effort in
manteining the IANA trees integrity. Still we have all this legacy
problems.
</edo>

> Keeping the legacy structure: (legacy "weird structure") new proposed 
> drafts for RFC
>  docsIfMib 8   - IETF bpiplus RFC objects/notifications/conformance
>  docsIfMib 9   - IETF docsQos RFC objects/notifications/conformance 
> 
So if we do this, then the customers may end up with the same objects
but under two different OID trees? That sounds like BAD for the
customers, does it not?

What a mess!
<edo>
 :-| better say this rigth here than having the IESG in a bottleneck
situation
 </edo>

> 
> Thinking in IETF-MODULE styles
> 
> 
> What would be the organized structure?
> Mib-2 or transmission Hierachy related ifmib, bpiplus docsqos? How 
> IETF really wants to organize the trees? If Mib-2 for bpiplus and qos,

> any particular subtrees of mib-2
> 
> Or transmission sub-tree:
> 
> How does IETF docsIfMib play  as an umbrella for bpiplus and
> docsQos or
> any DOCSIS related interface mib
> 
> Will that define a path requiring  IETF docsIfMib to be IESG approved 
> before  bpiplus/docsQos ? Supposed in transmission branch 
> transmission... (128 is also a docsis ifType not as good option as 127

> but that one is already covered by rfc2670
> 
>  One option:
> 
> Transmission 128 - docsIfIETF ? ( to say any number? ) docsIfIETF 1 
> docsIfMib new RFC (objects/notifications/conformance)
> docsIfIETF 2 bpiplus new RFC (objects/notifications/conformance)
> docsIfIETF 3 docsQos new RFC (objects/notifications/conformance)
> 
Will you also rename your object descriptors?
How are people going to know the difference between
current docsIfDownstreamChannelTable and the
docsIfDownstreamChannelTable once it gets re-rooted under docsIfIETF ??

See... what is biting you here is the rules of how you can change and
update non-published (I-Ds) and existing published (as RFCs)  
MIB modules. You may want to read about that in the RFC2578/79/80 RFCs.

Hope this helps. I need to think about a solution. Maybe we need to chat
about that some more. Bert

<edo>
I have the same question and probably something I did not understood
completely and I named the MODULE-IDENTITY scope.
Or at least As I understood your proposal of DOCS-IETF-IF-MIB vs
DOCS-IF-MIB
Which in the application side translate into :
DOCS-IETF-IF-MIB-docsIfDownstreamChannelTable vs
DOCS-IF-MIB-docsIfDownstreamChannelTable that I believe are different.

</edo>

> Thanks
> Eduardo

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "C. M. Heard" <[email-masked]>
Date: Fri, 25 Jul 2003 12:31:49 -0700 (PDT)

IPCDN folks,

Bert Wijnen brought this thread to my attention and invited me to
comment on it from a MIB doctor perspective.  I do have a few
questions and suggestions that I hope will simplify things.  It's
possible that some of this will go over old ground, and if it
does I apologize in advance.

...
> > Bert,
> > We Would like to get your advise in this topic and I am
> > extending some generalization:
> > 
> > The DOCSIS Interface suite of mibs were initialy visualized as:
> > 

One general comment:  most of the IETF MIB modules I have seen
(either as a WG participant, or as a MIB reviewer) seem to be
registered directly under mib-2 (or, for media-specific extensions
to the IF-MIB, transmission), and either follow the preferred
structure that is going to be RECOMMENDED in the next version of
the MIB review guidelines document, i.e.,

xyzMIB (typically mib-2.x or transmission.x)
|
+-- xyzNotifications(0)
+-- xyzObjects(1)
+-- xyzConformance(2)
    |
    +-- xyzCompliances(1)
    +-- xyzGoups(2)

or else the older (and somewhat less efficient and
no longer recommended) variant

xyzMIB (typically mib-2.x or transmission.x)
|
+-- xyzObjects(1)
+-- xyzConformance(2)
|   |
|   +-- xyzCompliances(1)
|   +-- xyzGoups(2)
|
+-- xyzNotifications(3)
    |
    +-- xyzNotificationsPrefix(0)

With certain exceptions -- the RMON WG is one -- most WGs just
get a new node from the IANA each time they create a new MIB
module.  The RMON WG has historically assigned stuff under
the rmon node, and it looks like IPCDN has started down this
path, too.

I think that was a BIG MISTAKE and want to suggest that IPCDN
consider doing what most of the rest of the IETF WGs do for
all new MIB modules that it creates.  I'm not saying this in
an attempt to be critical of anyone ... I just think we ought
to recognize when we make mistakes and learn from them rather
than repeat them.

A little bit of history:  in the -00 version of the MIB review
guidelines document the following language appeared in
Section 4.5:

     It is also acceptable for a working group
     to make its own assignments from a subtree
     delegated to it by IANA, provided that adequate
     controls are in place to ensure that such
     assignments are unique.

This was put in to -00 largely on the basis of the fact that
the RMON WG had been doing it.  Bert challenged this, and so
we asked Andy Bierman to comment on the RMON WG experience.
I've attached his reply.  Based on what he said, the consensus
of the MIB doctors was to take this language out ... you will
not see it in <draft-ietf-ops-mib-review-guidelines-01.txt>.
I believe that you will see in Andy's messane an echo of some
of the problems that have arisen here.  Please, let's learn
from these experiences.

Let's consider the advantages of the standard procedure of
getting a new node under mib-2 (or some other existing
IANA-managed subtree) when a new MIB module is developed:

- The procedure is well-known.  IANA and the RFC Editor know
exactly what to do, and they don't even require that an IANA
Considerations section appear in the RFC-to-be to request
the assignment (see http://www.ietf.org/ID-nits.html).

- It does not require that a WG attempt to manage an OID
subtree (a bad idea, since WGs haven't done a good job of
it historically), nor does it require that the WG ask the
IANA to manage a subtree for it (which would require writing
a complete IANA considerations section and publishing it in
an RFC, and would add to the IANA's already heavy workload).

- Since provisional assignments appear in Internet-Drafts in
the form { mib-2 xxx } or the like, it requires that vendors
who want to do early implementations use their own enterprise
trees or get an experimental number.  Traditionally, when a
WG assigns the number out of a delegated subtree, it assigns
the number right away, but since the document is still a
draft, it is subject to arbtrary changes.  This has been
known to cause problems when vendors implement the spec prior
to its approval as an RFC.  Witness bpiplus and docsQos.

There are some disadvantages, too:

- The OID tree does not necessarily reflect the hierarchical
relationships between objects in different MIB modules.

- There is often a long delay between the time the IESG
approves a spec and the publication of the RFC with the
IANA-assigned number.

In my opinion (and, I think, in the opinion of most of the
MIB doctors) the advantages far outweigh the disadvantages.

So, I recommend that all future MIB modules that are
produces in this WG be assigned nodes directly under mib-2
(or transmission, if that is appropriate) and follow the
RECOMMENDED OID assignment plan illustrated above.

For existing MIB modules there are two cases:

(a) if it's already been published as an RFC then it MUST
be left alone.  Under no circumstances may the existing
OID assignments be changed.  Attempting to "tidy up" messy
assignments in deployed MIBs is a "cure" that is much worse
than the "disease".

(b) for stuff that has appeared only in an I-D, but has
already appeared in fielded implementations:  if the stuff
works and is publishable as is, leave it alone.  If there
are objects that are flawed but have been fielded, the WG
may wish to consider having them appear with a status of
deprecated (or obsolete) in the initial version of the MIB
module.  That would require some explaining, but it is
probably defensible if it comes with a promise that "this
won't happen again".  At least, that's the position I'd
advise the IESG to take.

Now to comment on certain specifics ...

> probably assigning them underneath docsIfMib is OK.

Unless they are already implemented (which SHOULD NOT be the case
if they are only I-Ds), I'd advise a direct assignment under
transmission, per the advice in the long diatribe above.

> transmission docsIfMib area, just thoughs.

My VERY STRONG RECOMMENDATION is NOT to use the OID tree to try to
express relationships between objects in diferent MIB modules.  I
would strongly suggest assignments under mib-2.

> eyes). But we cannot fix that anymore. Or if we do, then it comes with a

I would not even go that far, as it means that there is a tree that
needs to be managed.  WGs have historically not done a good job of
this, and so it would need to be delegated to the IANA.  But that
creates a lot of work for no real advantage, IMHO.

> use the OID that gets assigned, not anytime earlier while you are still

Exactly.  Once again, I strongly advise the WG to do this, and I
further advise that root-oid should be an existing IANA-maintained
branch (like mib-2 or transmission).

> manteining the IANA trees integrity. Still we have all this legacy

This is where my suggestion above might prove to be a good idea:
if there are fielded implementations of objects that need to be
changed (e.g., pre-InetAddress objects) then consider keeping
those objects in the drafts, with the same descriptors and OIDs,
but giving them deprecated or even obsolete status.  It's unusual
to do that for an object that has not appeared in a published RFC,
but there is no SMIv2 rule that forbids it.  Then, define
replacement objects (e.g., that use the InetAddress TC) with new
descriptors and OIDs.  The same thing should happen with conformance
groups.  This would make the MIB module look like one that was
initially published with the flawed objects, and then was revised
via ordinary maintenance.  It wouldn't be the best looking MIB
module known to man, but it would work, I think.

> but under two different OID trees? That sounds like BAD for the

Yes.  I say this is a very bad idea, and urge the WG not to do it.

[ ... snipped downto: ... ]

> MIB modules. You may want to read about that in the RFC2578/79/80 RFCs.

Do that, and also look at Section 4.9 of the review guidelines draft
<draft-ietf-ops-mib-review-guidelines-01.txt>.

> about that some more. Bert

I hope my suggestion of having objects that are "born" with a
status of deprecated or obsolete can help clean up the
immediate problem with bpiplus and docsQos.

Mike