RE: RE: EFM OAM MIB and the DateAndTime TC

Speaking as WG chair, I just want to observe that SNMPv1 is a historical version of the SNMP protocol, and has nothing to do with this discussion. 

Regards,

Dan



> -----Original Message-----
> From: John Messenger [mailto:[email protected]]
> Sent: 13 December, 2004 7:27 PM
> To: Romascanu, Dan (Dan); [email protected]; Lior khermosh; 
> Matt Squire; Chris Leak
> Cc: [email protected]; [email protected]
> Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC
> 
> 
> Hi,
> 
> As a vendor, I can say that most of our 802.3ah units will 
> not (initially, anyhow) have a time-of-day clock.  This has 
> not proven an issue with the (few) users with whom I have 
> discussed it.  SNMPv1 has not gone away yet.  Therefore, I 
> don't believe we should standardise a solution which makes 
> managing such a unit impossible.
> 	-- John
>  
> 
> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf
> Of Romascanu, Dan (Dan)
> Sent: 13 December 2004 14:11
> To: [email protected]; Lior khermosh; Matt Squire; Chris Leak
> Cc: [email protected]; [email protected]
> Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC
> 
> 
> David has expressed in detail the feeling of dis-comfort that 
> I feel with respect to my own proposal of defining two 
> different objects. The issue is that the WG did not reach up 
> to this point a consensus whether we prefer the 'good enough' 
> or the 'better but hard to implement' object. 
> 
> Let me try it the other way. Vendors representatives seem to 
> prefer the 'good enough' object with a SYNTAX of TimeStamp. 
> Do we know if customers will be happy with it? 
> 
> Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: David B Harrington [mailto:[email protected]]
> > Sent: 13 December, 2004 4:02 PM
> > To: Romascanu, Dan (Dan); 'Lior khermosh'; 'Matt Squire'; 
> 'Chris Leak'
> > Cc: [email protected]; [email protected]
> > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC
> > 
> > 
> > I would rather see one object, whether DateAndTime or sysUpTime
> > syntax. 
> > 
> > The harder we make it for applications to use the 
> informaton, the less
> > likely applications will use the information. A major 
> purpose of SNMP
> > is to standardize information so that it can be programmatically
> > compared across devices. Requiring applications to support two
> > different mechanisms is harder than just supporting one; having two
> > different mechanisms makes it harder to compare values 
> across devices;
> > and having to calculate the timestamp monitoring an epoch 
> start point
> > and applying a delta, with the possibility of decreased 
> accuracy makes
> > it harder to trust the data. I think this makes it more likely
> > applicatiosn will not use the data.
> > 
> > Using sysUpTime makes it easier for vendors to produce products that
> > comply with the standard; it doesn't make a better standard. Even
> > though I typically represent the views of a vendor, I do not believe
> > that standards should be "dumbed down" to accommodate the cheapest
> > devices; the cheapest devices are likely to simply not 
> support SNMP or
> > to suuport so few mib modules, the device is effectively 
> unmanageable.
> > Given the convergence of voice and data networking, it 
> seems likely to
> > me that EFM will be implemented in devices that will require clocks
> > for other reasons, and we should focus on producing the 
> best standard
> > rather than a standard designed for the least capable 
> devices. If most
> > vendors of EFM devices agree that they will not implement 
> clocks, then
> > I will gladly yield on this point.
> > 
> > dbh
> > 
> > > -----Original Message-----
> > > From: [email protected] 
> > > [mailto:[email protected]] On Behalf Of Romascanu, Dan (Dan)
> > > Sent: Monday, December 13, 2004 4:38 AM
> > > To: Lior khermosh; Matt Squire; [email protected]; Chris Leak
> > > Cc: [email protected]; [email protected]
> > > Subject: RE: [Hubmib] 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
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > Hubmib mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/hubmib
> > > 
> > 
> > 
> > 
> 
> _______________________________________________
> Hubmib mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/hubmib
>