[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OID Registration -- Rules versus BCP



>>>>> On Mon, 13 Jan 2003, Michael Kirkham wrote:
> I'm not sure there's been sufficient discussion to reach an agreement on
> this issue, but I happened upon this interesting tidbit from RFC 2981
> while running my archive of MIB modules through my validation routines to
> test my implementation of various DEFVAL sanity checks:
> 
> sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 }
> 
> mteTriggerDeltaDiscontinuityID OBJECT-TYPE
>     SYNTAX      OBJECT IDENTIFIER
>     MAX-ACCESS  read-write
>     STATUS      current
>     DESCRIPTION
[ ... ]
>     DEFVAL { sysUpTimeInstance }
>     ::= { mteTriggerDeltaEntry 1 }
> 
> SMIv2 requires DEFVALs for OID types to be referenced by a single
> identifier, so DEFVAL { { sysUpTime 0 } } wouldn't be valid.  But it is
> interesting to note that there are actually cases (or at least, a case)
> where a label has been given to a particular instance of an object.  My
> (current) implementation has flagged this as an error.

The problem is that this appears to conflict with the following
provision of RFC 2578 Section 7.10:

(3)  Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
     object may be assigned.

The solution to this dilemma was stated by Dave Perkins:

>>>>> 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.

It is clear from this context that the restriction in bullet (3) applies
only to assignments of OID to object types.

Now, I think there is good reason for saying that one SHOULD NOT create
registrations via MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
NOTIFICATION-GROUP, MODULE-COMPLIANCE, and AGENT-CAPABILITIES that are
subordinate to an OBJECT-TYPE:  the OID value associated with one of
these constructs should be an authoritative identification for a module,
a notification, etc., and if it is subordinate to an OBJECT-TYPE then
its uniqueness might be compromised (an instance (or subordinate row or
column) of the OBJECT-TYPE might have the same OID as the registered
item).  Aside from that, it's a bad module organization practice.  So I
could see a reason for issing a warning.  But Section 7.10 does not ban
these practices.

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.

Mike