RE: RE: EFM OAM MIB and the DateAndTime TC

Speaking as a contributor. 

I believe that David brings some valid points. I understand however the other arguments about the possible lack of support form DateAndTime in some implementations. I suggest the following:

- add a TimeStamp object 
- keep the current object, but change the SYNTAX to DateAndTimeOrZero, so that it returns zero if the managed entity does not have a clock capability

Later, when some implementation experience will be achieved, we can deprecate one of the objects. 

Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of Matt Squire
> Sent: 09 December, 2004 8:16 PM
> To: [email protected]; Chris Leak
> Cc: [email protected]; [email protected]
> Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC
> 
> 
> 
> Hi David - 
> 
> I don't really argue with most of the arguments you give 
> below - date/time is better if you have it.  I guess the big 
> question is whether its more important for this application 
> to take steps to make things better when you have date/time, 
> or to make things better when you don't have date/time.  
> Either approach sacrifices something for the other guy.   On 
> the one hand, we can take an approach that gives "ok" 
> information for everybody, or an approach that gives better 
> information when you have date/time and no information when 
> you don't.  All of the other stuff (return 0s, excpetions, 
> errors, etc.) seems like noise.  
> 
> If the market was clear and there were a bunch of volume 
> shipments then we could probably just look at the existing 
> market and make a determination.  At this point, its just 
> guessing what kind of capabilities will exist in products 
> that implement 802.3ah OAM functionality.  
> 
> There were at least a couple of people that mentioned to me 
> that date/time would be a problem for them, so I leaned in 
> the direction of supporting their application better.  I'm 
> hoping to get some more opinions.  
> 
> - Matt
> 
> 
> 
> 
> > 
> > 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
> > 
> 
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>