RE: RE: EFM OAM MIB and the DateAndTime TC

I will practice the same for the EPON DateAndTime objects.


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Matt Squire
Sent: Monday, December 13, 2004 4:00 AM
To: Romascanu, Dan (Dan); [email protected]; Chris Leak
Cc: [email protected]; [email protected]
Subject: RE: [Hubmib] 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
> > 
> 

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