Re: OID Registration -- Rules versus BCP

[Michael Kirkham <mikek@muonics.com>]

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
        "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
www.muonics.com