Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

From: "Matt Squire" <[email-masked]>
Date: Tue, 7 Dec 2004 15:09:01 -0500

Great.  Thanks for the input.  Unless there's objection raised, I'll plan on changing the type of the timestamp in the next revision.  
 
- Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Grant Schnebly
Sent: Tuesday, December 07, 2004 1:51 PM
To: [email-masked]'
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Matt,
 
Your "third approach" is best - it's not much work for a Manager to crudely match the Agent's sysUpTime with its own clock, and so derive a reasonable approximation of the Agent's DateAndTime.
 
If the Agent does know the DateAndTime, it should use that whenever it internally logs events in persistent memory.  Otherwise, between reboots the Agent loses track of the time of old events.
 
 > [sysUpTime] would create extra work on those systems that do have date/time
 
If there is any extra work, it's negligible, and limited to the Manager side.
 
-Grant

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Tuesday, December 07, 2004 10:06 AM
To: Chris Leak
Cc: [email-masked]; [email-masked]
Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Hi Chris - 
 
Your question on what to do with timestamps for systems that don't have date/time hasn't been discussed in context of this MIB draft, so I'd like to see what others think.  It doesn't appear to be covered by the textual conventions doc, so I'm guessing that means its open to interpretation.  
 
You point out that there is some precedent for returning zeros, or returning a date/time approximation based on sysUpTime.  It seems that from a utility point of view the latter approach is better as relative times are preserved, but the first approach is certainly simpler and easier to document.  A third approach would be to change from DateAndTime to use sysUpTime instead for the timestamps.  Although this would solve the "what to do if you don't know the date/time" problem, it would create extra work on those systems that do have date/time (assuming most people want timestamps in the date/time  format).  
 
Maybe some others can shed some light/opinions on the subject of how to handle date/time when it is not available on the system. 
 
- Matt

-----Original Message-----
From: Chris Leak [mailto:[email-masked]]
Sent: Monday, December 06, 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; Manu Kaycee
Subject: EFM OAM MIB and the DateAndTime TC

Matt,

Has there been any discussion regarding the implementation of the dot3OamEventLogTimestamp object on systems where the date and time are not available? I've seen examples of some MIBs on the standards track where the value '0000000000000000'H is recommended in this case and one example where sysUpTime was converted into a date and time. So far, this seems to be an issue that's being addressed on a case by case basis. Any suggestions?

Thanks,

Chris Leak

Senior Software Engineer

Metrobility Optical Systems

[email-masked]

(603) 589-0681

_______________________________________________
Hubmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 7 Dec 2004 16:11:06 -0500

Is the timestamp relative to the local clock or the remote clock when
the event is remotely detected and reported via Erthernet OAM? 
 
The description should specify which clock is used or REFERENCE the
EFM clause that specifies the orign of the timestamp.
 
David Harrington
[email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Matt Squire
Sent: Tuesday, December 07, 2004 3:09 PM
To: Grant Schnebly; [email-masked]
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Great.  Thanks for the input.  Unless there's objection raised, I'll
plan on changing the type of the timestamp in the next revision.  
 
- Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of Grant Schnebly
Sent: Tuesday, December 07, 2004 1:51 PM
To: [email-masked]'
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Matt,
 
Your "third approach" is best - it's not much work for a Manager to
crudely match the Agent's sysUpTime with its own clock, and so derive
a reasonable approximation of the Agent's DateAndTime.
 
If the Agent does know the DateAndTime, it should use that whenever it
internally logs events in persistent memory.  Otherwise, between
reboots the Agent loses track of the time of old events.
 
 > [sysUpTime] would create extra work on those systems that do have
date/time
 
If there is any extra work, it's negligible, and limited to the
Manager side.
 
-Grant

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Tuesday, December 07, 2004 10:06 AM
To: Chris Leak
Cc: [email-masked]; [email-masked]
Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Hi Chris - 
 
Your question on what to do with timestamps for systems that don't
have date/time hasn't been discussed in context of this MIB draft, so
I'd like to see what others think.  It doesn't appear to be covered by
the textual conventions doc, so I'm guessing that means its open to
interpretation.  
 
You point out that there is some precedent for returning zeros, or
returning a date/time approximation based on sysUpTime.  It seems that
from a utility point of view the latter approach is better as relative
times are preserved, but the first approach is certainly simpler and
easier to document.  A third approach would be to change from
DateAndTime to use sysUpTime instead for the timestamps.  Although
this would solve the "what to do if you don't know the date/time"
problem, it would create extra work on those systems that do have
date/time (assuming most people want timestamps in the date/time
format).  
 
Maybe some others can shed some light/opinions on the subject of how
to handle date/time when it is not available on the system. 
 
- Matt

-----Original Message-----
From: Chris Leak [mailto:[email-masked]]
Sent: Monday, December 06, 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; Manu Kaycee
Subject: EFM OAM MIB and the DateAndTime TC

Matt,

Has there been any discussion regarding the implementation of the
dot3OamEventLogTimestamp object on systems where the date and time are
not available? I've seen examples of some MIBs on the standards track
where the value '0000000000000000'H is recommended in this case and
one example where sysUpTime was converted into a date and time. So
far, this seems to be an issue that's being addressed on a case by
case basis. Any suggestions?

Thanks,

Chris Leak

Senior Software Engineer

(603) 589-0681