Re: Usage of the DateAndTime TC

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Robert Moore writes:

Robert> Here's the DateAndTime TC from RFC 2579:

[...]

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

Correct. Dave Perkins also made this same observation some time ago.

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

In the past, we often failed to provide suitable "NULL" values for new
TCs such as DateAndTime. If we were doing DateAndTime again from
scratch, we probably would define it as (SIZE (0 | 8 | 11)).  Anyway,
this is irrelevant today for things like DateAndTime which are used
quite a bit.

Someone started to use '0000000000000000'H as a "NULL" value (perhaps
not really noticing that this breaks the TC definition) and people
copied this into many other MIB modules. This is also how it ended up
in the DISMAN-SCHEDULE-MIB. This evolutin makes this violation of the
DateAndTime TC a kind of de-facto standard standard violation. One
reason why this problem was not discussed much more in the past is
probably the fact that MIB compilers can't flag this kind of error
without hard-coding special TC semantics.

Anyway, we are now in a situation where we can:

(a) Fix all MIB modules and their implementations which violate the
    DateAndTime TC to use '0000010100000000'H. This has its costs.
(b) Clarify the DateAndTime TC that '0000000000000000'H is indeed a
    special legal value. This legalizes current practice and fielded
    implementation and this is the approach taken in
    <draft-ietf-sming-modules-02.txt>.
(c) Silently keep things as they are and rely on book authors to
    explain the folklore. ;-)

In this particular case, I believe that (b) is the cheapest way to
move ahead for existing MIBs. This does of course not answer whether
new MIBs should use '0000010100000000'H or '0000000000000000'H as a
"NULL" value. ('0000000000000000'H has some slight advantages from a
purist point of view since you can never confuse it with a legal point
in time. But it is a de-facto standard standard violation.)

[Note that this issue was not raised during the SMIv2 revision to
 Standard. This would have been a good opportunity to discuss it and
 perhaps get (b) into place.]

/js