RE: RE: EFM OAM MIB and the DateAndTime TC

To make it clear again - this was a contributor and not a chair proposal. To be frank, I personally do not feel one hundred percent comfortable with redundant objects, which is a minus. If anybody feels stronger against this, please speak loudly. In the absence of vocal comments, we will go ahead with this method. 

Regards,

Dan



> -----Original Message-----
> From: Lior khermosh [mailto:[email protected]]
> Sent: 13 December, 2004 8:53 AM
> To: 'Matt Squire'; Romascanu, Dan (Dan); [email protected]; 
> 'Chris Leak'
> Cc: [email protected]; [email protected]
> Subject: RE: [Hubmib] 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
> 
>