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

Re: OID Registration -- Rules versus BCP


I thought this issue had already been resolved. 

That is, the rules for OID values specified in section 7.10
apply only to the values used for object types.

Note that when you read the SMI documents, that the term "object"
is used in many places as a short cut for "object type".

At 01:37 AM 1/13/2003 -0800, 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
>    MAX-ACCESS  read-write
>    STATUS      current
>        "The OBJECT IDENTIFIER (OID) of a TimeTicks, TimeStamp, or
>        DateAndTime object that indicates a discontinuity in the value
>        at mteTriggerValueID.
>        The OID may be for a leaf object (e.g. sysUpTime.0) or may
>        be wildcarded to match mteTriggerValueID.
>        This object supports normal checking for a discontinuity in a
>        counter.  Note that if this object does not point to sysUpTime
>        discontinuity checking MUST still check sysUpTime for an overall
>        discontinuity.
>        If the object identified is not accessible the sample attempt
>        is in error, with the error code as from an SNMP request.
>        Bad object identifiers or a mismatch between truncating the
>        identifier and the value of mteDeltaDiscontinuityIDWildcard
>        result in operation as one would expect when providing the
>        wrong identifier to a Get operation.  The Get will fail or get
>        the wrong object.  If the value syntax of those objects is not
>        usable, that results in an error that terminates the sample
>        with a 'badType' error code."
>    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.
>Michael Kirkham
/david t. perkins