Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Mon, 13 Dec 2004 11:37:34 +0200

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-masked]]
> Sent: 13 December, 2004 8:53 AM
> To: 'Matt Squire'; Romascanu, Dan (Dan); [email-masked]; 
> 'Chris Leak'
> Cc: [email-masked]; [email-masked]
> 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-masked] 
> [mailto:[email-masked]] On Behalf
> Of Matt Squire
> Sent: Monday, December 13, 2004 4:00 AM
> To: Romascanu, Dan (Dan); [email-masked]; Chris Leak
> Cc: [email-masked]; [email-masked]
> 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-masked]]
> > Sent: Sunday, December 12, 2004 6:24 AM
> > To: Matt Squire; [email-masked]; Chris Leak
> > Cc: [email-masked]; [email-masked]
> > 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-masked]
> > > [mailto:[email-masked]]On Behalf Of Matt Squire
> > > Sent: 09 December, 2004 8:16 PM
> > > To: [email-masked]; Chris Leak
> > > Cc: [email-masked]; [email-masked]
> > > 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-masked]
> > > > IETF MIB Doctor
> > > > 
> > > 
> > > _______________________________________________
> > > Hubmib mailing list
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/hubmib
> > > 
> > 
> 
> _______________________________________________
> Hubmib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hubmib
> 
> 

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

---

From: "David B Harrington" <[email-masked]>
Date: Mon, 13 Dec 2004 09:02:07 -0500

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

> [mailto:[email-masked]] On Behalf Of Romascanu, Dan (Dan)
> Sent: Monday, December 13, 2004 4:38 AM
> To: Lior khermosh; Matt Squire; [email-masked]; Chris Leak
> 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
> 
> 
> 
> > To: 'Matt Squire'; Romascanu, Dan (Dan); 
> [email-masked]; 'Chris 
> > Leak'
> > [mailto:[email-masked]] On Behalf Of Matt Squire