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

From: Grant Schnebly <[email-masked]>
Date: Tue, 7 Dec 2004 10:51:04 -0800

Matt,
 
Your "third approach" is best - it's not much work for a Manager to crudely
match the Agent's sysUpTime with its own clock, and so derive a reasonable
approximation of the Agent's DateAndTime.
 
If the Agent does know the DateAndTime, it should use that whenever it
internally logs events in persistent memory.  Otherwise, between reboots the
Agent loses track of the time of old events.
 
 > [sysUpTime] would create extra work on those systems that do have
date/time
 
If there is any extra work, it's negligible, and limited to the Manager
side.
 
-Grant

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Tuesday, December 07, 2004 10:06 AM
To: Chris Leak
Cc: [email-masked]; [email-masked]
Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Hi Chris - 
 
Your question on what to do with timestamps for systems that don't have
date/time hasn't been discussed in context of this MIB draft, so I'd like to
see what others think.  It doesn't appear to be covered by the textual
conventions doc, so I'm guessing that means its open to interpretation.  
 
You point out that there is some precedent for returning zeros, or returning
a date/time approximation based on sysUpTime.  It seems that from a utility
point of view the latter approach is better as relative times are preserved,
but the first approach is certainly simpler and easier to document.  A third
approach would be to change from DateAndTime to use sysUpTime instead for
the timestamps.  Although this would solve the "what to do if you don't know
the date/time" problem, it would create extra work on those systems that do
have date/time (assuming most people want timestamps in the date/time
format).  
 
Maybe some others can shed some light/opinions on the subject of how to
handle date/time when it is not available on the system. 
 
- Matt

-----Original Message-----
From: Chris Leak [mailto:[email-masked]]
Sent: Monday, December 06, 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; Manu Kaycee
Subject: EFM OAM MIB and the DateAndTime TC

Matt,

Has there been any discussion regarding the implementation of the
dot3OamEventLogTimestamp object on systems where the date and time are not
available? I've seen examples of some MIBs on the standards track where the
value '0000000000000000'H is recommended in this case and one example where
sysUpTime was converted into a date and time. So far, this seems to be an
issue that's being addressed on a case by case basis. Any suggestions?

Thanks,

Chris Leak

Senior Software Engineer

Metrobility Optical Systems

[email-masked] <mailto:[email-masked]> 

(603) 589-0681

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

---

From: "Matt Squire" <[email-masked]>
Date: Wed, 8 Dec 2004 10:30:44 -0500

The timestamp is intended to be reference to the local clock - when the event was detected locally (for locally generated events) or when the event indication was received locally (for remotely generated events).  I'll enhance the description to bring that out.  
 
There is no corresponding reference in .3ah.  
 
Thanks.  
 
- Matt

-----Original Message-----
From: David B Harrington [mailto:[email-masked]]
Sent: Tuesday, December 07, 2004 4:11 PM
To: Matt Squire; 'Grant Schnebly'; [email-masked]
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Is the timestamp relative to the local clock or the remote clock when the event is remotely detected and reported via Erthernet OAM? 
 
The description should specify which clock is used or REFERENCE the EFM clause that specifies the orign of the timestamp.
 
David Harrington
[email-masked]

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Squire
Sent: Tuesday, December 07, 2004 3:09 PM
To: Grant Schnebly; [email-masked]
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Great.  Thanks for the input.  Unless there's objection raised, I'll plan on changing the type of the timestamp in the next revision.  
 
- Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Grant Schnebly
Sent: Tuesday, December 07, 2004 1:51 PM
To: [email-masked]'
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Matt,
 
Your "third approach" is best - it's not much work for a Manager to crudely match the Agent's sysUpTime with its own clock, and so derive a reasonable approximation of the Agent's DateAndTime.
 
If the Agent does know the DateAndTime, it should use that whenever it internally logs events in persistent memory.  Otherwise, between reboots the Agent loses track of the time of old events.
 
 > [sysUpTime] would create extra work on those systems that do have date/time
 
If there is any extra work, it's negligible, and limited to the Manager side.
 
-Grant

-----Original Message-----
From: Matt Squire [mailto:[email-masked]]
Sent: Tuesday, December 07, 2004 10:06 AM
To: Chris Leak
Cc: [email-masked]; [email-masked]
Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Hi Chris - 
 
Your question on what to do with timestamps for systems that don't have date/time hasn't been discussed in context of this MIB draft, so I'd like to see what others think.  It doesn't appear to be covered by the textual conventions doc, so I'm guessing that means its open to interpretation.  
 
You point out that there is some precedent for returning zeros, or returning a date/time approximation based on sysUpTime.  It seems that from a utility point of view the latter approach is better as relative times are preserved, but the first approach is certainly simpler and easier to document.  A third approach would be to change from DateAndTime to use sysUpTime instead for the timestamps.  Although this would solve the "what to do if you don't know the date/time" problem, it would create extra work on those systems that do have date/time (assuming most people want timestamps in the date/time  format).  
 
Maybe some others can shed some light/opinions on the subject of how to handle date/time when it is not available on the system. 
 
- Matt

-----Original Message-----
From: Chris Leak [mailto:[email-masked]]
Sent: Monday, December 06, 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; Manu Kaycee
Subject: EFM OAM MIB and the DateAndTime TC

Matt,

Has there been any discussion regarding the implementation of the dot3OamEventLogTimestamp object on systems where the date and time are not available? I've seen examples of some MIBs on the standards track where the value '0000000000000000'H is recommended in this case and one example where sysUpTime was converted into a date and time. So far, this seems to be an issue that's being addressed on a case by case basis. Any suggestions?

Thanks,

Chris Leak

Senior Software Engineer

[email-masked]

(603) 589-0681

---

From: "Matt Squire" <[email-masked]>
Date: Thu, 9 Dec 2004 13:16:27 -0500

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
>

---

From: Brian Arnold <[email-masked]>
Date: Thu, 09 Dec 2004 16:14:42 -0500

Matt asked for opinions.  Here's one from the cheap seats:

I agree wholeheartedly on the value of having accurate timestamps that can be correlated to other system events.  However, without a clear idea of the time/date capabilities of the range of devices for which .3ah OAM may be desired, I'd have to say, make the information universally "ok" for everybody, rather than "good" just for the folks with time/date capabilities.  Some thoughts and questions:

- If zeroes are returned for timestamps on systems where date/time isn't available, then useful information (not "perfect information") maintained in the OAM sublayer is being purposefully ignored and concealed.  That doesn't help anybody solve problems.

- Mandating date/time-or-nothing might place additional burden on some .3ah device designs that wish to support timestamps, when it's too early to tell what kinds of devices could benefit from .3ah OAM.  I don't have an application which would benefit one way or the other, but I'm just guessing.

- Not every network device with date/time functionality has the date and time configured, or configured properly.  Have seen more than a few switches and routers with files in flash with the date March 1 1993.  I know, this is a configuration problem and the gear shouldn't be operated that way, but sometimes they are.

- OAM sublayer timestamps are at 100msec granularity.  Time/date can't be any more precise than that (for OAM timestamps).  Is sysUpTime any worse from an accuracy standpoint?

I don't feel that strongly about this and David made some very good points below, but I just recall that one of the intents of the 100msec timestamps in .3ah OAM was that any device capable of implementing the OAM sublayer would be able to generate these timestamps.  Somehow seems wrong to suppress useful capabilities in the MIB for some .3ah OAM devices in favor of enhanced capabilities in other .3ah OAM devices.

Thanks,

Brian

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 12 Dec 2004 13:23:46 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Matt Squire
> Sent: 09 December, 2004 8:16 PM
> To: [email-masked]; Chris Leak
> 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
> 
> 
> 
> 
> >

---

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

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

> Sent: 13 December, 2004 4:02 PM
> To: Romascanu, Dan (Dan); 'Lior khermosh'; 'Matt Squire'; 'Chris Leak'
> 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
> > 
> > 
> > 
> > > From: Lior khermosh [mailto:[email-masked]]
> > > Sent: 13 December, 2004 8:53 AM
> > > To: 'Matt Squire'; Romascanu, Dan (Dan); 
> > [email-masked]; 'Chris 
> > > Leak'
> > > I will practice the same for the EPON DateAndTime objects.
> > > 
> > > 
> > > [mailto:[email-masked]] On Behalf Of Matt Squire
> > > Sent: Monday, December 13, 2004 4:00 AM
> > > To: Romascanu, Dan (Dan); [email-masked]; Chris Leak
> > > Sounds like a reasonable thing to me.  
> > > 
> > > - Matt
> > > 
> > > > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > > > Sent: Sunday, December 12, 2004 6:24 AM
> > > > To: Matt Squire; [email-masked]; Chris Leak
> > > > 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
> > > > 
> > > > > [email-masked] https://www1.ietf.org/mailman/listinfo/hubmib
> > > > > 
> > > > 
> > >

---

From: "John Messenger" <[email-masked]>
Date: Mon, 13 Dec 2004 17:26:30 -0000

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-masked] [mailto:[email-masked]]On Behalf
Of Romascanu, Dan (Dan)
Sent: 13 December 2004 14:11
To: [email-masked]; Lior khermosh; Matt Squire; Chris Leak
Cc: [email-masked]; [email-masked]
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Regards,

Dan

---

From: Grant Schnebly <[email-masked]>
Date: Mon, 13 Dec 2004 10:47:52 -0800

Folks,

This issue should only be about universality.  Requiring support for the
DateAndTime type will not influence clock accuracy.

No matter how much money you spend making your Rolex, somebody still has to
set the time, or its just jewelry.  And if you instantaneously checked every
Rolex out in the field, do you think they'd all display the same time?

Some wonderfully expensive and sophisticated agent may be installed where it
has no access to a time server.  The DateAndTime syntax will not magically
tell the Agent the correct time to report.  Even if somebody does set the
time, that time will not be in sync with every Manager that talks to it and
every other Agent those Managers talk to.

In the messy internet world of unsynchronized clocks, sysUpTime is the great
uniter.  Every Agent supports it, regardless of whether they can reach a
time server or somebody set their clock.  Every Manager understands the
sysUpTime of each Agent it manages, to a greater precision than we set our
wristwatches.  Everybody is happy, regardless of how much they spent on
their clock, and regardless of whether somebody is around to tell them a
DateAndTime.

Please keep it universal.

-Grant

-----Original Message-----
From: David B Harrington [mailto:[email-masked]]
Sent: Monday, December 13, 2004 6:02 AM
To: 'Romascanu, Dan (Dan)'; 'Lior khermosh'; 'Matt Squire'; 'Chris Leak'
Cc: [email-masked]; [email-masked]
Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

dbh

---

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

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

> From: John Messenger [mailto:[email-masked]]
> Sent: 13 December, 2004 7:27 PM
> To: Romascanu, Dan (Dan); [email-masked]; Lior khermosh; 
> Matt Squire; Chris Leak
> 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
>  
> 
> [mailto:[email-masked]]On Behalf
> Of Romascanu, Dan (Dan)
> 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
> 
> 
>