RE: RE: EFM OAM MIB and the DateAndTime TC

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 protected]
IETF MIB Doctor

________________________________

	From: Matt Squire [mailto:[email protected]] 
	Sent: Wednesday, December 08, 2004 1:03 PM
	To: [email protected]; Chris Leak
	Cc: [email protected]; [email protected]
	Subject: RE: [Hubmib] 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