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

From: Eamonn McManus <[email-masked]>
Date: Fri, 13 Nov 1998 17:57:05 +0100

In connection with the smRunStartTime and smRunEndTime objects of the
Script MIB and what they should do on devices that don't have
real-time clocks, I wrote:

> 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".  

Juergen Schoenwaelder replied:
> 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.
[...]
> 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.)

This is an excellent idea, and I am very happy with it.  I don't think
it is worth adding separate sysUpTime-based objects given this.

Where would sysDateAndTime live in the SNMP namespace?  Would it be
under 1.3.6.1.2.1 alongside sysDescr, sysUpTime, and the rest?  Is
there a draft for the SNMPv3 equivalent of RFC1907?  I haven't been
following the SNMPv3 developments very closely.

Thanks,
,
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: Mon, 16 Nov 1998 17:18:40 +0100

>>>>> Eamonn McManus writes:

[snip]

Eamonn> This is an excellent idea, and I am very happy with it.  I
Eamonn> don't think it is worth adding separate sysUpTime-based
Eamonn> objects given this.

Good. We should probably bring this up on the SNMPv3 WG mailing list.

Eamonn> Where would sysDateAndTime live in the SNMP namespace?  Would
Eamonn> it be under 1.3.6.1.2.1 alongside sysDescr, sysUpTime, and the
Eamonn> rest?  Is there a draft for the SNMPv3 equivalent of RFC1907?
Eamonn> I haven't been following the SNMPv3 developments very closely.

I think that a sysDateAndTime object in the system (1.3.6.1.2.1.1)
group would make sense. Even for systems that have a real time clock
and which don't need to learn the DateAndTime from a manager, it would
be nice to have a standard way to read the clock in order to check how
much the clock differs from what one expects. Sure, some systems will
prefer to keep sysDateAndTime read-only, but this is no problem if we
define the object properly.

There was some talk about revising RFC1907 in Los Angeles but nothing
happened yet. Note, there are also procedural constraints since the
addition of an object conflicts with the current Draft status of
RFC1907. Anyway, we first need to find out if there is concensus for
such an addition. If we reach concensus, we can talk about the ways to
get it where we want it to be.

I will prepare an ID which defines this object and I will then ask the
SNMPv3 WG to discuss this ID in the December meeting. Perhaps we can
get away with all the nasty time stamp discussions by just adding one
more standard system object. We will see.
							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)