Re: OID Registration -- Rules versus BCP

[Michael Kirkham <mikek@muonics.com>]

I will adjust my validation rules accordingly.  A couple comments below,
though..

On Mon, 13 Jan 2003, C. M. Heard wrote:

> >>>>> On Thu, 9 Jan 2003, David T. Perkins wrote:
> > I believe that the descriptions in section 7.10 refer only to
> > OID values used for object types.
>
> That's clearly correct, contrary to what I said in my earlier message.
> After all, the title of Section 7.10 is "Mapping of the OBJECT-TYPE value,"
> and the context of the bullet quoted above is this (emphasis added):
>
>    When an OBJECT IDENTIFIER is assigned to an object:
>                              ------------------------
> [ ... ]
>
> (3)  Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
>      object may be assigned.

The confusion arises because the wording is somewhat in conflict with its
self.  The opening statment ("When an OBJECT IDENTIFIER is assigned to an
object") is worded so-as to focus on the OID assigned to the object, but
the subsequent paragraphs (1-3) are worded as if to focus on what is below
(subordinante to) that object.  I suggest that alternate wording might be
clearer/more appropriate (with my edits in [brackets]):

   When an OBJECT IDENTIFIER is assigned to an object:

(1)  If the object corresponds to a conceptual [column], then only a single
     assignment, that for a conceptual row, is present immediately
     [above] that object.  [The administratively assigned name for
     the column is derived by appending a unique, positive sub-identifier
     to the administratively assigned name for the conceptual row
     [above].]

(2)  If the object corresponds to a conceptual row, [only a single
     assignment, that for a conceptual table] is present [immediately
     above] that object.  [The administratively assigned name for the
     conceptual row object is derived by appending a sub-identifier of
     "1" to the administratively assigned name for the conceptual table
     [immediately above the row]].

(3)  Otherwise, no other OBJECT IDENTIFIERs which are subordinate to
     [any other OBJECT-TYPE] may be assigned [to the object].

> As the example above demonstrates, there is sometimes reason to use
> an OID assignment in the sense of RFC 2578 3.6(2) (or even to use the
> OBJECT-IDENTITY construct) to create a descriptor that refers to an
> instance of an object, or to a subtree of objects.  It would be
> totally unreasonable to ban such usage.

No disagreement.  I don't believe that they should be forbidden either (at
least, not simple ASN.1-style object identifier value assignments, or
otherwise various macros if they are assigned so-as not to conflict with
any instance of the object), just that the current wording (which appears
to be the same as it appeared in RFC 1442) could easily be taken to mean
otherwise (the reason, I hope, is clear from the above rewording).

The example seems perfectly reasonable to me, though being allowed to call
sysDescr.0 a NOTIFICATION-TYPE (for example) does not.  sysDescr.1 as a
NOTIFICATION-TYPE should be ok (through really poor style).

--
Michael Kirkham
www.muonics.com