RE: FW: [802.1] P802.1b/D0

["C. M. Heard" <heard@pobox.com>]

On Mon, 23 Dec 2002, Harrington, David wrote:
> I could be wrong, but I was of the impression that you could not use the
> same registered descriptors, such as sampleMIB, and assign them new
> OIDs.
> 
> From RFC2578, section 3.6 (from Mike's mail below) "the descriptor can
> not be changed nor associated with any other registration."

My reading of this -- which I admit is open to debate -- is that the
requirement applies to a descriptor within the context in which it is
required to be unique.

A descriptor is always required to be unique within a module, and all
descriptors in all "standard" MIB modules are required to be unique
(RFC 2578, Section 3.1).  However, a descriptor that's in a "standard"
module may duplicate a descriptor in some module that is not a
"standard" module.  It has to be that way, because the IETF does not
control what may be defined in MIB modules defined by other organizations.

If we were to apply the rule unconditionally, then it could be
interpreted to mean that an IETF MIB module could not use a descriptor
that had already appeared in any MIB module whatsoever, including those
that are controlled and maintained by other organizations.  In other
words, descriptors would have to be globally unique.  But that's
not workable, since there is no global authority for handing out
descriptors.  Fortunately, the SMI recognizes this and does not require
that descriptors be globally unique.  That's what the module.reference
notation is for.

So, I think it's legal to re-use a descriptor (including associating
it with different OBJECT IDENTIFIER value) if and only if:

(a) the descriptor was originally used in a definition in another
MIB module and the new definition does not appear in a "standard"
MIB module

OR

(b) the descriptor was originally used in a definition in another
MIB module, the new definition does appear in a "standard" MIB
module, but there is no other use of that descriptor in any
other "standard" module.

> And I would think that would be true for migrating a mib from
> experimental to mib-2; wouldn't the registered descriptors AND the OIDs
> in the migrated mib need to be changed?

Well, if you accept my argument that the rule is to be applied only within
the context in which a descriptor is required to be unique, then it boils
down to what one means for a module to be a "standard" module.  The
following paragraphs of RFC 2578, Section 4, are the closest the document
comes to providing a definition:

   The mgmt(2) subtree is used to identify "standard" objects.

   The experimental(3) subtree is used to identify objects being
   designed by working groups of the IETF.  If an information module
   produced by a working group becomes a "standard" information module,
   then at the very beginning of its entry onto the Internet standards
   track, the objects are moved under the mgmt(2) subtree.

In other words, a working definition is this:  a MIB module is a
"standard" MIB module if it is now or has ever been on the standards
track, and in that case all definitions within it (including the
MODULE-IDENTITY value) should be registered under the mgmt subtree
(for instance, one of the branches under mib-2) and not under
the experimental (or any other) subtree.  (Note that we can and
probably should apply the rules for "standard" modules to IETF MIBs
that appear in Informational RFCs.)

> Or is this another instance of a restriction being relaxed to become a
> Consistency Language Rule to be overridden when convenient? ;-)

I don't think so.  I'm inclined to agree with this:

On Mon, 23 Dec 2002, David T. Perkins wrote:
> As I previously mentioned, there is a fine line. The definitions that
> are in an experimental branch will most likely have their status changed
> from "current" to "obsolete". The definitions under mib-2 will
> have their definitions "current". And most likely there will
> probably not be "no changes" during the move. The result is
> different definitions using the same intrumentation.
> 
> Please note that if the definitions were under experimental and
> widely deployed, then there was either:
> 1) a break down in the standards process,
> 2) a vendor (or vendors) abusing the standards process, or
> 3) a little of both.

I think that (3) is what happened in the case of RFC 2786.

//cmh