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