Re: DEFVAL for DateAndTimes

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

[Please send any followups only to <mibs@ops.ietf.org> since this is
 really a cross WG issue.]

>>>>> Randy Presuhn writes:

Randy> A conversation with Dave Perkins in an Australian airport
Randy> uncovered a possible problem with RFCs 2592, 2591, and 2564.

Randy> RFC 2579's description of DateAndTime says:

[...]

Randy> These other documents have DEFVALs for DateAndTime of
Randy> '0000000000000000'H.  These values would be technically
Randy> illegal, and should probably be replaced with
Randy> '0000010100000000'H when these documents are revised.

The TN3270E-MIB (RFC 2561), TN3270E-RT-MIB (RFC 2562) and WWW-MIB (RFC
2594) also use this not strictly legal default value. I could not find
a single MIB which uses '0000010100000000'H.

Randy> (Alternatively, we could just recognize the existing, though
Randy> technically illegal, practice and get on with more interesting
Randy> problems.  :-)

I think that recognizing the existing, though technically illegal,
practice is the right thing to do. I will take care that the SMIng
definition of DateAndTime fixes this problem by explicitely allowing
the value '0000000000000000'H to indicate an unknown date and time
value. ;-)

Randy> A related annoying question: if the time has an offset of 00:00
Randy> from UTC, would the preferred value for byte 9 be a '+' or a
Randy> '-'?

I think both are valid and semantically identical. Not sure we need to
agree on a preferred value for byte 9 (although I would choose '+').

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>