RE: RE: EFM OAM MIB and the DateAndTime TC

Sounds like a reasonable thing to me.  

- Matt

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]
> Sent: Sunday, December 12, 2004 6:24 AM
> To: Matt Squire; [email protected]; Chris Leak
> Cc: [email protected]; [email protected]
> Subject: RE: [Hubmib] 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
> > 
>