Subject: Re: review of draft-ietf-disman-notif-log-mib-04.txt

From: Eamonn McManus <[email-masked]>
Date: Fri, 06 Nov 1998 17:26:38 +0100

Bob Stewart writes, about the NOTIFICATION-LOG-MIB:
> At 12:31 PM 10/19/98 +0200, Juergen Schoenwaelder wrote:
> >21) The nlmLogTime object raises an interesting question. For every
> >    notification, it is essential to know where it occured and when
> >    the notification was raised. Lets assume the log is used to log
> >    notifications received from other systems. The time-stamp of the
> >    notification is shipped in the varbind list, but it is based on
> >    sysUpTime of the sending engine. The nlmLogTime adds a time-stamp
> >    when the log entry is generated. However, since both are based on
> >    sysUpTime, there is no reliable way to get the date and time when
> >    the event really happened. (The time stamp in the recorded varbind
> >    list can be ambiguous at the time the value is read from the log.)
> >    Changing nlmLogTime to use DateAndTime would help quite a bit to
> >    find the real point in time a notification was issued.
> 
> Yuk.  I hate problems I can't just wave away.
> 
> I'm not happy depending on DateAndTime, since there are still plenty of
> systems that don't have that information.
> 
> I really don't want to get in the business of interpretation of
> sysUpTime-based timestamps in this MIB.  I want it to be usable in a
> reasonably low-end system.  My inclination is to push this problem off to
> timely use of the logs by higher level applications.
> 
> I'm also willing to consider the idea of replacing our sysUpTime-based time
> stamps with a variation on DateAndTime that has a clear definition for what
> it means on a system that doesn't know the date and time.  In otherwords a
> DateAndTime where the well-defined, recognizable degenerate case is a
> sysUpTime-based time stamp.  This could be the right way to push all time
> stamps and (heh heh) stamp out this debate for all time.

It's worth noting that the DISMAN-SCRIPT-MIB has the same problem.
Script-run start and end times are DateAndTime objects, and it is not
defined what their values should be on systems that don't have access
to the wallclock time.  A convention for DateAndTime values that are
based on sysUpTime rather than real time would be useful to both MIBs.
It could even be something as simple (albeit hacky) as saying that
dates before the year 1000 are actually sysUpTime-based offsets.

,
Eamonn
--
The Open Group Research Institute, 2 ave de Vignate, 38610 Gieres, France.
Phone +33 476.63.48.82.  Fax +33 476.51.05.32.  http://www.gr.osf.org/~emcmanus

---

From: Bob Stewart <[email-masked]>
Date: Fri, 06 Nov 1998 11:43:57 -0500

>dates before the year 1000 are actually sysUpTime-based offsets.

Practical, non-ivory-tower, non-purist that I am (hack, cough), unless
someone can offer a truly compelling reason why not (Keith?), I'd
officially change the DateAndTime textual convention to say what Eamonn
suggests, that a date before some particular year is actually a
representation of sysUpTime.

I know that's a bit traumatic to the rule about not changing semantics, but
we'd be using a space in the textual convention that is unlikely to have
been used in the past and we wouldn't have to invent another and get people
to switch to it.

So now I start designing on the fly.

Hmmmm.  Perhaps the way to do it is to say that a year less than 100 is a
sysUpTime representation.  That would make the high-order byte zero.  Say
that for a sysUpTime representation the month is not meaningful and is thus
set to zero, which makes this an invalid representation of a real date and
time.  What I was aiming for was a representation of days, hours, minutes,
seconds, and centiseconds, fitting nicely in the existing fields.

The catch is that there's only one byte for days, limiting this to a
sysUpTime of 255 days unless we do something funky to use some of the
higher order bytes.  If I calculated correctly, sysUpTime wraps at around
497 days.  I'd be willing to stipulate that all sysUpTime years are 365
days and use the low byte of the year to count years, but that still
doesn't quite fit in the fields we have.  I hate to stipulate a fixed
number of days in a sysUpTime month...

OK.  I constructed a straw scarecrow.  Somebody else have a go at this.

	Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Nov 1998 23:01:53 +0100

>>>>> Eamonn McManus writes:

Eamonn> It's worth noting that the DISMAN-SCRIPT-MIB has the same
Eamonn> problem.  Script-run start and end times are DateAndTime
Eamonn> objects, and it is not defined what their values should be on
Eamonn> systems that don't have access to the wallclock time.

Does your implementation of the Script MIB run on a system that does
not have a wall clock? I mean, the script MIB is a powerful control
interface for a mib-level manager. I do not expect that people
implement it in toaster devices. But I am willing to change my mind if
someone shows real examples where people could not implement this MIB
because it requires a wall clock.

(Note, I am arguing about the script MIB here. The notification
logging MIB is IMHO much more likely to be implemented in toaster
devices and the mileage may vary here.)
							Juergen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Nov 1998 23:14:03 +0100

>>>>> Bob Stewart writes:

Bob> Practical, non-ivory-tower, non-purist that I am (hack, cough),
Bob> unless someone can offer a truly compelling reason why not
Bob> (Keith?), I'd officially change the DateAndTime textual
Bob> convention to say what Eamonn suggests, that a date before some
Bob> particular year is actually a representation of sysUpTime.

Uh. Oah. Brrr. - How much beer do I have to offer in order to stop
you?
							Juergen