Subject: RE: re-review of Notify Log MIB

From: Randy Presuhn <[email-masked]>
Date: Mon, 20 Dec 1999 15:48:41 -0800 (PST)

Hi -

> Date: Mon, 20 Dec 1999 15:01:15 -0800
> To: "Sharon Chisholm" <[email-masked]>,
>         Randy Presuhn <[email-masked]>, [email-masked]
> From: Ramanathan Kavasseri <[email-masked]>
> Subject: RE: re-review of Notify Log MIB
...
> Ok. I didn't see that algorithm - it'll work for systems that support
> nlmLogdateAndTime...What about those that do not have date
> and time capability? 

See my previous message for the heuristic assuming that
systems with persistance logs are highly unlikely
to not support DateAndTime.

Even in that worst case of a box with persistant logs and no
working clock, there will be a large gap between the newest
and the oldest entries, unless this pathological box has
persistant storage for more that 2^31 log entries.

> Given the above algorithm, I'll be ok with dropping the "may flush
> existing entries" text, but we should revisit this after implementation
> experience...For systems that do not have date and time capability,
> should nlmLogTime's DESCRIPTION be changed so that all
> entries prior to the wrap have their nlmLogTime set to zero after the wrap?
...

This is already required by RFC 2579 near the top of page 18.
Yet another reason why I really hate TimeStamp objects. :-)
I guess a reminder wouldn't hurt; I leave this to the editor's
discretion.

 ------------------------------------------------------------------------
 Randy Presuhn           [email-masked]       http://www.bmc.com/
 Voice: +1 408 546-1006  BMC Software, Inc.  1-3141  2141 N. First Street
 Fax:   +1 408 965-0359  San Jose, California 95131  USA
 ------------------------------------------------------------------------
 Any relationship between my opinions and BMC's should be coincidental.
 ------------------------------------------------------------------------

---

From: Ramanathan Kavasseri <[email-masked]>
Date: Mon, 20 Dec 1999 16:50:28 -0800

I've snipped out the parts that I addressed in my prev mail - there's only one issue that needed addressing below...

>I guess a reminder wouldn't hurt; I leave this to the editor's

I'm still alittle in the dark. As I interpret it,
RFC2579 says that TimeStamp objects shouldn't be changed (reset to zero)
unless syspTime is reset due to a management (sub)system reset.
Thus resetting the TimeStamps to zero is not an option. However, if I
followed correctly, the text in RFC2579 page 18 says clearly that there
can be ambiguities in the value of the TimeStamp objects due to a
sysUpTime wrap, which is what (I think) you said could be added?

Note: I want to clarify that I followed what you meant, before I think about
adding any text...
:-)

Ram

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 21 Dec 1999 13:31:33 +0100

>>>>> Randy Presuhn writes:

Randy> See my previous message for the heuristic assuming that systems
Randy> with persistance logs are highly unlikely to not support
Randy> DateAndTime.

[...]

Randy> Yet another reason why I really hate TimeStamp objects. :-) I
Randy> guess a reminder wouldn't hurt; I leave this to the editor's
Randy> discretion.

Indeed, TimeStamp is problematic in many ways. The DISMAN-SCRIPT-MIB
therefore uses DateAndTime for time-stamping purposes. There are
implementations that do not have a wall-clock on board. However, there
are solutions for these systems as well, either implementing a time
protocol such as NTP or defining an object which can be used to set
the wall clock by a management application (which must of course be
done after every reboot). I actually wrote an ID on this topic which
is now expired. The issue was presented on one of the OPS meetings but
obviously no action was taken.

http://www.ibr.cs.tu-bs.de/~schoenw/draft-schoenw-snmpv2-mib-ext-00.txt.gz

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<[email-masked]>  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/>