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

From: "Matt Squire" <[email-masked]>
Date: Wed, 8 Dec 2004 13:03:14 -0500

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-masked]]
Sent: Tuesday, December 07, 2004 4:39 PM
To: Matt Squire; 'Chris Leak'
Cc: [email-masked]; [email-masked]
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-masked] [mailto:[email-masked]] On Behalf Of Matt Squire
Sent: Tuesday, December 07, 2004 1:06 PM
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: Thu, 9 Dec 2004 12:21:02 -0500

Hi,

1) I did not suggest returning an error code; I suggested returning an
exception. Returning a noSuchObject exception does not invalidate the
response, only the specific varbind. Exceptions were added to SNMP to
mitigate the problem of invalidating complete responses, a problem
which existed in SNMPv1. The problem you cite only exists if you use
error codes. You are limited to using error codes only if you use
SNMPv1.

2) I read the security considerations section to determine whether the
sensitivity of the information counter-indicated the use of SNMPv1.
The security considerations section says that the information is
sensitive, and that security is important for this mib module. It goes
into great detail about ensuring that the non-secure L2 OAM protocol
is secured, and goes on to say that SNMPv1 is not recommended because
it is not secure. Since the use of SNMPv1 is not recommended, and
later versions of SNMP support exceptions, the problem you cite should
not be an issue.

3) The application receiving a timestamp of zeroes has no more
information than if it had received an exception. In both cases, it
knows that the device that had the event does not support the
date/time capability, and the event occurred sometime prior to the
application receiving it. So it makes little difference when getting
the object from a device that doesn't support a clock. It makes a big
difference when getting the object from a device that does support a
clock.

4) If knowing WHEN an event occurred is important, then I would think
it would make more sense to know when it occurred at the remote device
that had the event rather than when it was received by the local
agent. 

5) sysUpTime is relative to the last restart of the management system,
and if the application doesn't know quite when that was, relative to
clock-time, all it can do is ESTIMATE when the event occurred. The
estimate will be muddied by any network latency. Given the inaccuracy
already introduced by timestamping a remote event with the agent-local
time, and adding to that the imprecision of roughly estimating when an
event ocuured based on sysUpTime, it strikes me that the precision is
getting very poor. If this object lacks precision, is it still really
useful?

6) Assuming an agent's clock is consistent with other agents' clocks,
an application receiving a date/time timestamped event report has more
useful information than one receiving a sysUpTime timestamp. With a
date/time timestamp, the application can do a much better job of
correlating events across multiple devices, which can be important for
troubleshooting. Correlating events properly can be important for
troubleshooting problems such as worms, viruses, routing/switching
updates, performance bottlenecks, etc. 

7) Lack of accuracy in correlating the times of multiple events could
lead operators to incorrectly dismiss some paths of investigation, and
waste time pursuing other paths, because the timestamped event
information is so inaccurate. 

I question the wisdom of using a sysUpTime timestamp rather than a
date/time timestamp in this table.

David Harrington
[email-masked]
IETF MIB Doctor

________________________________

	From: Matt Squire [mailto:[email-masked]] 
	Sent: Wednesday, December 08, 2004 1:03 PM
	To: [email-masked]; Chris Leak
	Cc: [email-masked]; [email-masked]
	Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

	Hi David - 

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