RE: RE: EFM OAM MIB and the DateAndTime TC

Hi David - 
 
Here's some responses to your concerns/comments:  
 
- we should try to find a way to maintain time information across as many systems as possible - the best path to that appears to be using sysUpTime as it is universal where date/time is not - returning an error code completely eliminates the possibility of knowing when something happend, and that seems especially bad for an event log that is trying to capture WHAT happened WHEN - knowing WHAT happened is only part of the problem
 
- the timestamp is always relative to the sysUpTime of the local system (e.g. when the event was generated or was received locally)  [also discussed in a respone to one of your previous emails]
 
- a management application can convert sysUpTime to date/time if desired - the relative spacing of events within that system would be maintained
 
- the log entries should be transient (not survive re-starts), so the table should never contain discontinuities within it (though discontinuities may exist to an application monitoring the event log over time) - those discontinuities could be handled by having the application convert to date/time when it reads the sysUpTime timestamp of a log entry
 
- returning an SNMP error code has the adverse effect of causing an error at the SNMP PDU level, which can invalidate the response not just that particular object, so if we were to go down the path of returning an error code, it seems that returning all zeros is less problematic then returning the SNMP error
 
After reading the emails, I've been moved to the opinion that timestamping with a sysUpTime stamp is a more useful mechanism then with a date/time for this particular application.  I'm planning on moving the text in that direction, so shout if thats a problem.  
 
- Matt

-----Original Message-----
From: David B Harrington [mailto:[email protected]]
Sent: Tuesday, December 07, 2004 4:39 PM
To: Matt Squire; 'Chris Leak'
Cc: [email protected]; [email protected]
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC


Hi,
 
The sysUpTime solution might avoid the DateAndTime problem for the agent, but you'll need to consider how an application should handle discontinuities in sysUpTime for the various systems it is monitoring. If the timestamp might be the timestamp for a remote system, it might be difficult for the application to convert that to an equivalent date and time in order to correlate the local and remote events properly. Maybe the importance of the application being able to correlate the date and time of events isn't that high, and a lack of correlation capability might be acceptable, but if so, then why return the timestamp object from any system?
 
It might be better to keep the DateAndTime semantics for correlation purposes, and for systems that don't support clocks to simply not support the timestamp object, and return a noSuchObject exception. Any application should already have code to handle the noSuchObject possibility. In comparison, applications would need to add special code to handle the "000000H" case for this object
 
dbh


  _____  

From: [email protected] [mailto:[email protected]] On Behalf Of Matt Squire
Sent: Tuesday, December 07, 2004 1:06 PM
To: Chris Leak
Cc: [email protected]; [email protected]
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 protected]]
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 protected]

(603) 589-0681

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