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

From: Eamonn McManus <[email-masked]>
Date: Sat, 07 Nov 1998 17:15:14 +0100

Juergen Schoenwaelder <[email-masked]> wrote:
> >>>>> 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.

Yes, my implementation of the Script MIB is intended to run on such
a device.  (It does not yet, because the hardware isn't ready, so I
haven't yet confronted the DateAndTime problem.)  In between toasters
and general-purpose computers there is a category of device that one
might call a specialised network commodity.  Examples of such devices
include CD-ROM towers and print spoolers.  It's not hard to imagine
that costs of individual hardware components are very important here
and a wall clock will be left out unless it is essential.  It's also
not hard to imagine that downloadable code could be of use in some
such devices.

One reason I was thinking of the "year < 1000" suggestion, which
I recognise is very ugly, is that one possible script that could be
downloaded into the device would be one that obtains wall-clock time using
NTP or the like.  So if the device has this script and access to an NTP
server, it will have the real wall-clock time, otherwise a fake wall-clock
time based at 0:00 in the (nonexistent) year 0.  This makes the fact of
having to break times up into the various DateAndTime fields less painful,
because you need to do that anyway with wall-clock time if you have it.

I can see two clean solutions to this problem in so far as it concerns the
Script MIB.  The first, which requires little editing and no changes to
existing implementations, is to change the smRunStartTime and smRunEndTime
descriptions which currently say:
    The value '0000000000000000'H is returned if the script has not
    started [respectively terminated] yet
so that they add "or if wall-clock time is unavailable".  But this is
unfortunate, because even if wall-clock time is not available, uptime
usually is, and could be used.

The second solution is to replace these fields by TimeTicks values
based on sysUpTime always.

Solutions based on fiddling with the semantics of DateAndTime are not
clean, but perhaps should not be dismissed out of hand.

,
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: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 8 Nov 1998 11:46:47 +0100

>>>>> Eamonn McManus writes:

Eamonn> Yes, my implementation of the Script MIB is intended to run on
Eamonn> such a device.  (It does not yet, because the hardware isn't
Eamonn> ready, so I haven't yet confronted the DateAndTime problem.)

OK. This makes me think more serious about the problem.

Eamonn> I can see two clean solutions to this problem in so far as it
Eamonn> concerns the Script MIB.  The first, which requires little
Eamonn> editing and no changes to existing implementations, is to
Eamonn> change the smRunStartTime and smRunEndTime descriptions which
Eamonn> currently say: The value '0000000000000000'H is returned if
Eamonn> the script has not started [respectively terminated] yet so
Eamonn> that they add "or if wall-clock time is unavailable".  

I discussed exactly this approach last Friday in the context of a
proprietary MIB. The solution to define that the value of the
DateAndTime object is zero if the wall-clock time is not known works
nicely if there is a way to set the wall-clock time. In the
proprietary MIB, there is an SNMP object to actually set the
DateAndTime. (Sure, setting the time can also be realized by other
means such as NTP if available.) A manager who wants wall-clock time
stamps simply has to ensure that the agent is able to generate them.

Eamonn> But this is unfortunate, because even if wall-clock time is
Eamonn> not available, uptime usually is, and could be used.

Eamonn> The second solution is to replace these fields by TimeTicks
Eamonn> values based on sysUpTime always.

I think there is also a third option: Report the time relative to
sysUpTime and as a wall-clock time in different objects. Sure, this
doubles the number of time stamp objects, but it avoids to play ugly
games with the semantics of DateAndTime.

Eamonn> Solutions based on fiddling with the semantics of DateAndTime
Eamonn> are not clean, but perhaps should not be dismissed out of
Eamonn> hand.

I prefer to not play ugly games with DateAndTime. It really makes the
life of the manager harder - the desire to have as few objects as
possible does not automatically mean that a manager can easily be
written.

What about the following proposal: We simply make sure that every
device can have wall-clock time! For example, having a sysDateAndTime
variable which is read-write would allow to set the wall-clock via
SNMP if that is needed. Systems without a wall-clock or time protocols
such as NTP would report '0..0'H to indicate that they don't have a
notion of the wall-clock yet. DateAndTime objects such as
smRunStartTime will report '0..0'H until the wall-clock is known by
the device, which may be achieved by manually setting sysDateAndTime
if the agent is not capable to get the wall-clock time from another
source. This would make a whole bunch of problems go away. (Given the
amount of remote configuration we have in SNMPv3, it does not seem to
be an unrealistic burdon to allow the configuration of the wall-clock
time via SNMP as well.)
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)