Usage of the DateAndTime TC

["Robert Moore" <remoore@us.ibm.com>]

I have a general question about how people are using the
DateAndTime TC.  The question is more general than just
this TC, though - it's even more general than SMI.  I've
gone down this path because essentially the same question
has come up in connection with the Core Policy LDAP schema.

Here's the DateAndTime TC from RFC 2579:

DateAndTime ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
    STATUS       current
    DESCRIPTION
            "A date-time specification.

            field  octets  contents                  range
            -----  ------  --------                  -----
              1      1-2   year*                     0..65536
              2       3    month                     1..12
              3       4    day                       1..31
              4       5    hour                      0..23
              5       6    minutes                   0..59
              6       7    seconds                   0..60
                           (use 60 for leap-second)
              7       8    deci-seconds              0..9
              8       9    direction from UTC        '+' / '-'
              9      10    hours from UTC*           0..13
             10      11    minutes from UTC          0..59

            * Notes:
            - the value of year is in network-byte order
            - daylight saving time in New Zealand is +13

            For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
            displayed as:

                             1992-5-26,13:30:15.0,-4:0

            Note that if only local time is known, then timezone
            information (fields 8-10) is not present."
    SYNTAX       OCTET STRING (SIZE (8 | 11))


Now here's a typical example of how this TC has been used,
from RFC 2591, the Schedule MIB:

schedLastFailed OBJECT-TYPE
        SYNTAX      DateAndTime
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The date and time when the most recent failure occured. The
             value '0000000000000000'H is returned if no failure occured
             since the last re-initialization of the scheduler."
        DEFVAL { '0000000000000000'H }
        ::= { schedEntry 18 }

There are a number of other examples where this TC is used
in this same way.  My question is, why has everybody been
OK with a MIB object like this adding a new value
'0000000000000000'H to the range of the TC, when this value
is plainly ruled out by the definition of the TC?  This
value has the correct number of octets, but that's all -
the TC, for example, does not allow a 0 value in octets
3 and 4.

Note that once you start down this path, it may be hard to
stop.  What would the Area MIB reviewers make of an object
like this, for example:

myLastFailed OBJECT-TYPE
        SYNTAX      DateAndTime
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "The date and time when the most recent failure occured.

             The value '0000000000000000'H is returned if no failure
             occured since the last re-initialization of my resource.

             The value'0000000000000001'H is returned if a failure
             occurred, but the agent was for some reason unable to
             generate a time stamp.

             The value '0000000000000002'H is returned if a failure
             occurred, but the time of the failure is considered
             sensitive information that will not be surfaced in this
             MIB object."
        DEFVAL { '0000000000000000'H }
        ::= { myEntry 18 }

Pretty ridiculous.  But the point is, this definition doesn't
violate the DateAndTime TC any more than that of schedLastFailed
does.

So here's the real question: Did we just make a mistake in
approving the definition of schedLastFailed?  (If so, we're
continuing to make this same mistake in a number of other MIBs
as well.)  Or is the only binding part of the DateAndTime TC
the "SYNTAX   OCTET STRING (SIZE (8 | 11))", with the
internal format of the strings just being sort of a strong
recommendation?

It's certainly not my intent here to torpedo objects like
schedLastFailed, since I think they're useful.  I just need
us to articulate carefully exactly what it means in SMI to
specify an internal format for a string.

Thanks.

Regards,
Bob

Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com