From mailman-bounces@ietf.org Wed Dec 1 09:45:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04535 for ; Wed, 1 Dec 2004 09:45:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZSk1-0007vF-IH for hubmib-archive@lists.ietf.org; Wed, 01 Dec 2004 06:33:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: hubmib-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:53:42 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for hubmib-archive@lists.ietf.org: List Password // URL ---- -------- hubmib@ietf.org XUKx https://www1.ietf.org/mailman/options/hubmib/hubmib-archive%40lists.ietf.org From hubmib-bounces@ietf.org Wed Dec 1 13:33:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07008 for ; Wed, 1 Dec 2004 13:33:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZYIw-0004EG-OX; Wed, 01 Dec 2004 12:30:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZXRf-0005AR-4b for hubmib@megatron.ietf.org; Wed, 01 Dec 2004 11:35:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22925 for ; Wed, 1 Dec 2004 11:35:09 -0500 (EST) From: dromasca@avaya.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZXX0-00044H-2l for hubmib@ietf.org; Wed, 01 Dec 2004 11:40:43 -0500 Received: from 133.red-80-35-230.pooles.rima-tde.net ([80.35.230.133] helo=server2000) by mx2.foretec.com with smtp (Exim 4.24) id 1CZXRU-0003wh-6C for hubmib@ietf.org; Wed, 01 Dec 2004 11:35:01 -0500 Received: from M7 ([172.16.0.2]) by server2000; Wed, 12 Mar 2003 18:34:21 +0100 (Hora estándar romance) To: hubmib@ietf.org Date: Wed, 1 Dec 2004 16:34:36 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Message-Id: X-Spam-Score: 2.3 (++) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Type: text/plain; charset=unknown-8bit Subject: [Hubmib] Re: details X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Panda Antivirus has blocked the content of this message. Contact your administrator. http://www.pandasoftware.com _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Fri Dec 3 03:59:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13428 for ; Fri, 3 Dec 2004 03:59:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca7Qs-0007eH-SX; Fri, 03 Dec 2004 02:00:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ca6Ny-0002aS-LW for hubmib@megatron.ietf.org; Fri, 03 Dec 2004 00:53:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14129 for ; Fri, 3 Dec 2004 00:53:39 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ca6Te-0002R2-Kl for hubmib@ietf.org; Fri, 03 Dec 2004 00:59:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Dec 2004 00:53:10 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971402A3B854@mailserv.hatteras.com> Thread-Topic: comments on draft-ietf-hubmib-efm-cu-mib-02.txt Thread-Index: AcTY/F6HoKmCfE54Ra+xEubPTCJ26w== From: "Matt Squire" To: "Edward Beili (E-mail)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: hubmib@ietf.org Subject: [Hubmib] comments on draft-ietf-hubmib-efm-cu-mib-02.txt X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Ed -=20 Had some old and new comments on the EFM CU MIB draft. =20 First, some old ones. I submitted these against the -01 version and am = not sure what decision was made with respect to them and why. They = don't look to be addressed in the new draft but I might have missed = something. A couple were discussed at the August(?) meeting and were = supposed to go to the list, but nothing was ever discussed on the list. = - Matt P17, efmCuPAFDiscoveryCode. Why is this read-write? Seems like this = should be generated by the system rather than provisioned by management. = E.g. the system can select a unique code based on MAC addresses, OUIs, = etc. Setting this via management seems more problematic than = beneficial. Its probably nice as read-only for troubleshooting reasons, = but I don't get the r/w. P17, efmCuAdminProfile. Why do we say "current operating Subtype of the = PCS" instead of just "the subtype of the PCS"?. Can that subtype = change? Also, given we're having profiles on the EFMCu and PME level, = would it be better to have the PME level override the EFMCu level? If = we switched precedence order (PME wins over EFMCu), we don't lose any = management function, but we allow the manager to set a default for all = PMEs with the ability to override speicfic PMEs with something else. So = we get more function, and don't lose anything. =20 P8, 3.1.5. On ifAdminStatus for the PAF, we say setting it to "up" = re-initializes all PMEs associated with it. Does setting the = ifAdminStatus of the PCS to "down" take down all PMEs as well, or does = it just stop aggregation from occuring? Does the ifAdminStatus of the = PMEs automatically change with that of the EFMCu port? There's still = some more clarity needed here. I guess I don't really care which way it = ends up, but we need to say one way or the other. =20 P21, efmCuPeerPAFSupported. Seems like it might be worthwhile to have a = third value (unknown) given thats whats in 30.11.1.1.9. Makes the = mapping easier:) P29, PME Notifications. Many of the notifications (DeviceFault, = ConfigInitFailure, ProtocolInitFailure) seem like they could be handled = by one notification- e.g. there was a failure and a reason for the = failure. You're including the FltStatus anyway - do we need multiple = notifications? I know in some you include more info (for example, the = profile index), but does getting an integer index into a profile table = help the notification receiver to know what happened? Also, are there = any rules/guidelines on using these with the standard linkDown ifTable = notification? Can/should someone send both, one or the other, does it = matter, etc.? P39, efmCuPmeFltStatus. Should this be zero'd when the link is up or = initializing (there's no current faults in these oper states). Or is = this intended to hold the last fault? P44, EfmCu2BConfProfileEntry. The definitions here allow a completely = rate adaptive profile (set data rate to 0), but not a restricted data = rate profile (e.g. between 2 and 4 Mbps). Supporting min/max rates = would be good. Now for some new comments. General. There's a ton of Editors notes scattered throughout indicating = that certain parts aren't finished. I guess the draft isn't really = ready for last call? General. Should reference final EFM doc not D3.3. =20 P4, 3.1.1. What is the "configured bit-rate for a pre-activated modem"? = What is the ifSpeed of a PME when it is in a rate adaptive mode? =20 P4, 3.1.1. There are a couple definitions of the ifSpeed of the PCS a) ifSpeed is "rate across the MII" (in 3.1.5) b) ifSpeed is "sum of the current operating data rates of all modemsn = in the aggregation group without the 64/65B encapsulation overhead and = PAF overhead but accounting for the interframe gap" I'd prefer we just go with the first one consistently. If you want to = state somewhere what goes across the MII, thats fine, but it seems like = there are two definitions laying out there. P4, 3.1.1. On the examples ("the following configuration shall have no = frame loss..."), it would seem preferable to eliminate the "shall" as = we're not really dicating anything. Maybe more along the lines of: = "When using the stated definition of ifSpeed for the PCS, there would be = no packet loss in the following configurations..." P29-30, Notifications. Some of the defined notifications are events, = others are threshold crossing. For the threshold crossing, is the = notification to be generated when the threshold is crossed in each = direction, only when its exceeded, etc.? E.g. there are linkUp/linkDown = notifications defined in other MIBs for when things go up and down, its = not clear if the threshold notifications should be sent on clear as = well. I think they should be, but the text doesn't really indicate one = way or another. =20 P42, status table. In the efmCuPmeStatusTable, its not clear what should = be returned for some of the objects when the link is down or = initializing. Some of the objects have text (efmCuPmeOperProfile) while = others don't (efmCuPmeSnrMargin, etc.). Should probably consistently = say what to return when the PME is down. =20 Editorial P10 3.4: "most of the MAU characteristics is not" =3D> "are not" P38 efmCuPmeStatsuTable - description indicates its the configuration = not the status (cut & paste error) P44, efmCuPme2BConfProfileEntry (ditto for the 10P version) - Another = cut&paste error? Reads like the profile entry for the PCS not the PME. = _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Tue Dec 7 13:31:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03692 for ; Tue, 7 Dec 2004 13:31:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbjoA-00041X-8n; Tue, 07 Dec 2004 13:11:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbjjN-0002wl-Rs for hubmib@megatron.ietf.org; Tue, 07 Dec 2004 13:06:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01659 for ; Tue, 7 Dec 2004 13:06:30 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbjpz-00022q-Dn for hubmib@ietf.org; Tue, 07 Dec 2004 13:13:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 7 Dec 2004 13:06:01 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971402A3B85D@mailserv.hatteras.com> Thread-Topic: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQ From: "Matt Squire" To: "Chris Leak" X-Spam-Score: 0.3 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2066108355==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============2066108355== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC87.69449A04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DC87.69449A04 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Hi Chris -=20 =20 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. =20 =20 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). =20 =20 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.=20 =20 - Matt =20 =20 -----Original Message----- From: Chris Leak [mailto:ChrisLeak@metrobility.com] 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, =20 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? =20 Thanks, =20 Chris Leak Senior Software Engineer Metrobility Optical Systems chrisleak@metrobility.com (603) 589-0681 =20 ------_=_NextPart_001_01C4DC87.69449A04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi=20 Chris -
 
Your=20 question on what to do with timestamps for systems that don't have = date/time=20 hasn't been discussed in context of this MIB draft, so I'd like to see = what=20 others think.  It doesn't appear to be covered by the textual = conventions=20 doc, so I'm guessing that means its open to interpretation. =20
 
You=20 point out that there is some precedent for returning zeros, or returning = a=20 date/time approximation based on sysUpTime.  It seems that from a = utility=20 point of view the latter approach is better as relative times are = preserved, but=20 the first approach is certainly simpler and easier to document.  A = third=20 approach would be to change from DateAndTime to use sysUpTime instead = for the=20 timestamps.  Although this would solve the "what to do if you don't = know=20 the date/time" problem, it would create extra work on those systems that = do have=20 date/time (assuming most people want timestamps in the date/time =20 format). 
 
Maybe=20 some others can shed some light/opinions on the subject of how to handle = date/time when it is not available on the system.
 
-=20 Matt
 
 
-----Original Message-----
From: Chris Leak=20 [mailto:ChrisLeak@metrobility.com]
Sent: Monday, December = 06, 2004=20 5:56 PM
To: Matt Squire
Cc: Don Kate; Manu=20 Kaycee
Subject: EFM OAM MIB and the DateAndTime=20 TC

Matt,

 

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

 

Thanks,

 

Chris = Leak

Senior = Software=20 Engineer

Metrobility Optical=20 Systems

chrisleak@metrobility.com

(603) = 589-0681

 

------_=_NextPart_001_01C4DC87.69449A04-- --===============2066108355== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============2066108355==-- From hubmib-bounces@ietf.org Tue Dec 7 14:13:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07806 for ; Tue, 7 Dec 2004 14:13:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbkUy-00082h-OX; Tue, 07 Dec 2004 13:55:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbkRt-00072T-H4 for hubmib@megatron.ietf.org; Tue, 07 Dec 2004 13:52:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05830 for ; Tue, 7 Dec 2004 13:52:32 -0500 (EST) Received: from falcon.mrv.com ([66.43.110.200] helo=mailsrv.chats.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbkYV-00034S-DO for hubmib@ietf.org; Tue, 07 Dec 2004 13:59:24 -0500 Received: by mailsrv.chats.int.mrv.com with Internet Mail Service (5.5.2657.72) id ; Tue, 7 Dec 2004 10:52:27 -0800 Message-ID: <30C8EC18FA0B92458918317E864AABCE01CE204B@mailsrv.chats.int.mrv.com> From: Grant Schnebly To: "'hubmib@ietf.org'" Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Tue, 7 Dec 2004 10:51:04 -0800 Deferred-Delivery: Tue, 7 Dec 2004 10:52:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.6 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0522427651==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0522427651== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC8D.B3EEAF00" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4DC8D.B3EEAF00 Content-Type: text/plain; charset="iso-8859-1" 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:MSquire@HatterasNetworks.com] Sent: Tuesday, December 07, 2004 10:06 AM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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:ChrisLeak@metrobility.com] 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 chrisleak@metrobility.com (603) 589-0681 ------_=_NextPart_001_01C4DC8D.B3EEAF00 Content-Type: text/html; charset="iso-8859-1"
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:MSquire@HatterasNetworks.com]
Sent: Tuesday, December 07, 2004 10:06 AM
To: Chris Leak
Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org
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:ChrisLeak@metrobility.com]
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

chrisleak@metrobility.com

(603) 589-0681

 

------_=_NextPart_001_01C4DC8D.B3EEAF00-- --===============0522427651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0522427651==-- From hubmib-bounces@ietf.org Tue Dec 7 15:21:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15980 for ; Tue, 7 Dec 2004 15:21:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cblnf-0002iJ-Ay; Tue, 07 Dec 2004 15:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbleP-0005xx-Vg for hubmib@megatron.ietf.org; Tue, 07 Dec 2004 15:09:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14506 for ; Tue, 7 Dec 2004 15:09:32 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbll2-00053e-Tu for hubmib@ietf.org; Tue, 07 Dec 2004 15:16:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Tue, 7 Dec 2004 15:09:01 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971403098FC0@mailserv.hatteras.com> Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTckNZbINl7pFecQjGpwg3IBxJKpAAB5sxQ From: "Matt Squire" To: "Grant Schnebly" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0295207930==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0295207930== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC98.9825A604" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DC98.9825A604 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great. Thanks for the input. Unless there's objection raised, I'll = plan on changing the type of the timestamp in the next revision. =20 =20 - Matt -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf = Of Grant Schnebly Sent: Tuesday, December 07, 2004 1:51 PM To: 'hubmib@ietf.org' Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Matt, =20 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. =20 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. =20 > [sysUpTime] would create extra work on those systems that do have = date/time =20 If there is any extra work, it's negligible, and limited to the Manager = side. =20 -Grant =20 -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Tuesday, December 07, 2004 10:06 AM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC =20 Hi Chris -=20 =20 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. =20 =20 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). =20 =20 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.=20 =20 - Matt =20 =20 -----Original Message----- From: Chris Leak [mailto:ChrisLeak@metrobility.com] 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, =20 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? =20 Thanks, =20 Chris Leak Senior Software Engineer Metrobility Optical Systems chrisleak@metrobility.com (603) 589-0681 =20 ------_=_NextPart_001_01C4DC98.9825A604 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Great.  Thanks for the input.  Unless there's = objection raised,=20 I'll plan on changing the type of the timestamp in the next = revision. =20
 
-=20 Matt
-----Original Message-----
From: = hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org]On Behalf Of Grant=20 Schnebly
Sent: Tuesday, December 07, 2004 1:51 = PM
To:=20 'hubmib@ietf.org'
Subject: RE: [Hubmib] RE: EFM OAM MIB and = the=20 DateAndTime TC

Matt,
 
Your=20 "third approach" is best - it's not much work for a Manager to=20 crudely match the Agent's sysUpTime with its own clock, and = so=20 derive a reasonable approximation of the Agent's=20 DateAndTime.
 
If=20 the Agent does know the DateAndTime, it should use that whenever it = internally=20 logs events in persistent memory.  Otherwise, between reboots the = Agent=20 loses track of the time of old events.
 
 > [sysUpTime] would create = extra work=20 on those systems that do have date/time
 
If=20 there is any extra work, it's negligible, and limited to the Manager=20 side.
 
-Grant
 
-----Original Message-----
From: Matt Squire=20 [mailto:MSquire@HatterasNetworks.com]
Sent: Tuesday, = December 07,=20 2004 10:06 AM
To: Chris Leak
Cc:=20 owner-stds-802-3-efm@listserv.ieee.org; = hubmib@ietf.org
Subject:=20 [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

 
Hi=20 Chris -
 
Your question on what to do with timestamps for systems = that don't=20 have date/time hasn't been discussed in context of this MIB draft, = so I'd=20 like to see what others think.  It doesn't appear to be covered = by the=20 textual conventions doc, so I'm guessing that means its open to=20 interpretation. 
 
You point out that there is some precedent for returning = zeros, or=20 returning a date/time approximation based on sysUpTime.  It = seems that=20 from a utility point of view the latter approach is better as = relative times=20 are preserved, but the first approach is certainly simpler and = easier to=20 document.  A third approach would be to change from DateAndTime = to use=20 sysUpTime instead for the timestamps.  Although this would = solve the=20 "what to do if you don't know the date/time" problem, it would = create extra=20 work on those systems that do have date/time (assuming most people = want=20 timestamps in the date/time  format).  =
 
Maybe some others can shed some light/opinions on the = subject of how=20 to handle date/time when it is not available on the system.=20
 
-=20 Matt
 
 
-----Original Message-----
From: Chris Leak=20 [mailto:ChrisLeak@metrobility.com]
Sent: Monday, = December 06,=20 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; = Manu=20 Kaycee
Subject: EFM OAM MIB and the DateAndTime=20 TC

Matt,

 

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

 

Thanks,

 

Chris = Leak

Senior = Software=20 Engineer

Metrobility Optical=20 Systems

chrisleak@metrobility.com

(603)=20 589-0681

 

------_=_NextPart_001_01C4DC98.9825A604-- --===============0295207930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0295207930==-- From hubmib-bounces@ietf.org Tue Dec 7 17:04:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04749 for ; Tue, 7 Dec 2004 17:04:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnK4-00023s-1j; Tue, 07 Dec 2004 16:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbmcm-0003n6-Ft for hubmib@megatron.ietf.org; Tue, 07 Dec 2004 16:11:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21566 for ; Tue, 7 Dec 2004 16:11:54 -0500 (EST) Message-Id: <200412072111.QAA21566@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbmjP-0006eK-9j for hubmib@ietf.org; Tue, 07 Dec 2004 16:18:48 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2004120721111001300dr76ee>; Tue, 7 Dec 2004 21:11:10 +0000 From: "David B Harrington" To: "'Matt Squire'" , "'Grant Schnebly'" , Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Tue, 7 Dec 2004 16:11:06 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTckNZbINl7pFecQjGpwg3IBxJKpAAB5sxQAAHlhJA= In-Reply-To: <8052E2EA753D144EB906B7A7AA39971403098FC0@mailserv.hatteras.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0208429148==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0208429148== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C4DC77.5C0336F0" This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C4DC77.5C0336F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 dbharrington@comcast.net _____ From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire Sent: Tuesday, December 07, 2004 3:09 PM To: Grant Schnebly; hubmib@ietf.org 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: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Grant Schnebly Sent: Tuesday, December 07, 2004 1:51 PM To: 'hubmib@ietf.org' 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:MSquire@HatterasNetworks.com] Sent: Tuesday, December 07, 2004 10:06 AM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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:ChrisLeak@metrobility.com] 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 chrisleak@metrobility.com (603) 589-0681 ------=_NextPart_000_0029_01C4DC77.5C0336F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Is the timestamp relative = to the local=20 clock or the remote clock when the event is remotely detected and = reported via=20 Erthernet OAM?
 
The = description should specify=20 which clock is used or REFERENCE the EFM clause that specifies the orign = of the=20 timestamp.
 
David Harrington
dbharrington@comcast.net

 

From: hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt = Squire
Sent:=20 Tuesday, December 07, 2004 3:09 PM
To: Grant Schnebly;=20 hubmib@ietf.org
Subject: RE: [Hubmib] RE: EFM OAM MIB and the=20 DateAndTime TC

Great.  Thanks for the input.  Unless there's = objection=20 raised, I'll plan on changing the type of the timestamp in the next=20 revision. 
 
-=20 Matt
-----Original Message-----
From: = hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org]On Behalf Of Grant=20 Schnebly
Sent: Tuesday, December 07, 2004 1:51 = PM
To:=20 'hubmib@ietf.org'
Subject: RE: [Hubmib] RE: EFM OAM MIB = and the=20 DateAndTime TC

Matt,
 
Your "third approach" is best - it's not = much work=20 for a Manager to crudely match the Agent's sysUpTime with its=20 own clock, and so derive a reasonable approximation of the = Agent's=20 DateAndTime.
 
If=20 the Agent does know the DateAndTime, it should use that whenever it=20 internally logs events in persistent memory.  Otherwise, = between=20 reboots the Agent loses track of the time of old = events.
 
 > [sysUpTime] would create = extra work=20 on those systems that do have date/time
 
If=20 there is any extra work, it's negligible, and limited to the Manager = side.
 
-Grant
 
-----Original Message-----
From: Matt Squire=20 [mailto:MSquire@HatterasNetworks.com]
Sent: Tuesday, = December=20 07, 2004 10:06 AM
To: Chris Leak
Cc:=20 owner-stds-802-3-efm@listserv.ieee.org; = hubmib@ietf.org
Subject:=20 [Hubmib] RE: EFM OAM MIB and the DateAndTime = TC

 
Hi Chris -
 
Your question on what to do with timestamps for systems = that don't=20 have date/time hasn't been discussed in context of this MIB draft, = so I'd=20 like to see what others think.  It doesn't appear to be = covered by=20 the textual conventions doc, so I'm guessing that means its open = to=20 interpretation. 
 
You point out that there is some precedent for returning = zeros, or=20 returning a date/time approximation based on sysUpTime.  It = seems=20 that from a utility point of view the latter approach is better as = relative times are preserved, but the first approach is certainly = simpler=20 and easier to document.  A third approach would be to change = from=20 DateAndTime to use sysUpTime instead for the timestamps.  = Although=20 this would solve the "what to do if you don't know the date/time" = problem,=20 it would create extra work on those systems that do have date/time = (assuming most people want timestamps in the date/time =20 format). 
 
Maybe some others can shed some light/opinions on the = subject of=20 how to handle date/time when it is not available on the system.=20
 
- Matt
 
 
-----Original Message-----
From: Chris Leak=20 [mailto:ChrisLeak@metrobility.com]
Sent: Monday, = December 06,=20 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; = Manu=20 Kaycee
Subject: EFM OAM MIB and the DateAndTime=20 TC

Matt,

 

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

 

Thanks,

 

Chris = Leak

Senior = Software=20 Engineer

Metrobility = Optical=20 Systems

chrisleak@metrobility.com

(603)=20 589-0681

 

------=_NextPart_000_0029_01C4DC77.5C0336F0-- --===============0208429148== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0208429148==-- From hubmib-bounces@ietf.org Tue Dec 7 17:16:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05938 for ; Tue, 7 Dec 2004 17:16:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbnOz-0005po-GR; Tue, 07 Dec 2004 17:01:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbn3Q-00036i-Er for hubmib@megatron.ietf.org; Tue, 07 Dec 2004 16:39:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28686 for ; Tue, 7 Dec 2004 16:39:25 -0500 (EST) Message-Id: <200412072139.QAA28686@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbnA3-00007H-J9 for hubmib@ietf.org; Tue, 07 Dec 2004 16:46:20 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004120721385201500i3ad1e>; Tue, 7 Dec 2004 21:38:53 +0000 From: "David B Harrington" To: "'Matt Squire'" , "'Chris Leak'" Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Tue, 7 Dec 2004 16:38:48 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQAAcFSLA= In-Reply-To: <8052E2EA753D144EB906B7A7AA39971402A3B85D@mailserv.hatteras.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1813547631==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1813547631== Content-Type: multipart/alternative; boundary="----=_NextPart_000_006C_01C4DC7B.3B0DBA20" This is a multi-part message in MIME format. ------=_NextPart_000_006C_01C4DC7B.3B0DBA20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The sysUpTime solution might avoid the DateAndTime problem for the agent, but you'll need to consider how an application should handle discontinuities in sysUpTime for the various systems it is monitoring. If the timestamp might be the timestamp for a remote system, it might be difficult for the application to convert that to an equivalent date and time in order to correlate the local and remote events properly. Maybe the importance of the application being able to correlate the date and time of events isn't that high, and a lack of correlation capability might be acceptable, but if so, then why return the timestamp object from any system? It might be better to keep the DateAndTime semantics for correlation purposes, and for systems that don't support clocks to simply not support the timestamp object, and return a noSuchObject exception. Any application should already have code to handle the noSuchObject possibility. In comparison, applications would need to add special code to handle the "000000H" case for this object dbh _____ From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire Sent: Tuesday, December 07, 2004 1:06 PM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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:ChrisLeak@metrobility.com] 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 chrisleak@metrobility.com (603) 589-0681 ------=_NextPart_000_006C_01C4DC7B.3B0DBA20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
The sysUpTime solution might avoid the = DateAndTime problem=20 for the agent, but you'll need to consider how an application should = handle=20 discontinuities in sysUpTime for the various systems it is monitoring. = If the=20 timestamp might be the timestamp for a remote system, it might be = difficult for=20 the application to convert that to an equivalent date and time in order = to=20 correlate the local and remote events properly. Maybe the importance of = the=20 application being able to correlate the date and time of events isn't = that high,=20 and a lack of correlation capability might be acceptable, but if so, = then why=20 return the timestamp object from any system?
 
It might be better to keep the DateAndTime = semantics for=20 correlation purposes, and for systems that don't support clocks to = simply not=20 support the timestamp object, and return a noSuchObject exception. Any=20 application should already have code to handle the noSuchObject=20 possibility. In comparison, applications would need to add special code = to=20 handle the "000000H" case for this object
 
dbh

From: hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt=20 Squire
Sent: Tuesday, December 07, 2004 1:06 = PM
To: Chris=20 Leak
Cc: owner-stds-802-3-efm@listserv.ieee.org;=20 hubmib@ietf.org
Subject: [Hubmib] RE: EFM OAM MIB and the=20 DateAndTime TC

 
Hi=20 Chris -
 
Your=20 question on what to do with timestamps for systems that don't have = date/time=20 hasn't been discussed in context of this MIB draft, so I'd like to see = what=20 others think.  It doesn't appear to be covered by the textual = conventions=20 doc, so I'm guessing that means its open to interpretation. =20
 
You=20 point out that there is some precedent for returning zeros, or = returning a=20 date/time approximation based on sysUpTime.  It seems that from a = utility=20 point of view the latter approach is better as relative times are = preserved,=20 but the first approach is certainly simpler and easier to = document.  A=20 third approach would be to change from DateAndTime to use sysUpTime = instead=20 for the timestamps.  Although this would solve the "what to do if = you=20 don't know the date/time" problem, it would create extra work on those = systems=20 that do have date/time (assuming most people want timestamps in the=20 date/time  format). 
 
Maybe some others can shed some light/opinions on the subject = of how to=20 handle date/time when it is not available on the system. =
 
-=20 Matt
 
 
-----Original Message-----
From: Chris Leak=20 [mailto:ChrisLeak@metrobility.com]
Sent: Monday, December = 06, 2004=20 5:56 PM
To: Matt Squire
Cc: Don Kate; Manu=20 Kaycee
Subject: EFM OAM MIB and the DateAndTime=20 TC

Matt,

 

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

 

Thanks,

 

Chris = Leak

Senior = Software=20 Engineer

Metrobility Optical=20 Systems

chrisleak@metrobility.com

(603) = 589-0681

 

------=_NextPart_000_006C_01C4DC7B.3B0DBA20-- --===============1813547631== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1813547631==-- From hubmib-bounces@ietf.org Wed Dec 8 10:42:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06730 for ; Wed, 8 Dec 2004 10:42:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc3qn-0007so-HT; Wed, 08 Dec 2004 10:35:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc3mh-0006yh-0I for hubmib@megatron.ietf.org; Wed, 08 Dec 2004 10:31:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05717 for ; Wed, 8 Dec 2004 10:31:16 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc3tT-0008L4-Sg for hubmib@ietf.org; Wed, 08 Dec 2004 10:38:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Wed, 8 Dec 2004 10:30:44 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971403098FC8@mailserv.hatteras.com> Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTckNZbINl7pFecQjGpwg3IBxJKpAAB5sxQAAHlhJAAJqAdQA== From: "Matt Squire" To: , "Grant Schnebly" , X-Spam-Score: 0.6 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0551189538==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0551189538== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD3A.E1E3A5D8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DD3A.E1E3A5D8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. =20 =20 There is no corresponding reference in .3ah. =20 =20 Thanks. =20 =20 - Matt -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net] Sent: Tuesday, December 07, 2004 4:11 PM To: Matt Squire; 'Grant Schnebly'; hubmib@ietf.org 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?=20 =20 The description should specify which clock is used or REFERENCE the EFM = clause that specifies the orign of the timestamp. =20 David Harrington dbharrington@comcast.net =20 _____ =20 From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf = Of Matt Squire Sent: Tuesday, December 07, 2004 3:09 PM To: Grant Schnebly; hubmib@ietf.org 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. =20 =20 - Matt -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf = Of Grant Schnebly Sent: Tuesday, December 07, 2004 1:51 PM To: 'hubmib@ietf.org' Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Matt, =20 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. =20 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. =20 > [sysUpTime] would create extra work on those systems that do have = date/time =20 If there is any extra work, it's negligible, and limited to the Manager = side. =20 -Grant =20 -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Tuesday, December 07, 2004 10:06 AM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC =20 Hi Chris -=20 =20 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. =20 =20 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). =20 =20 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.=20 =20 - Matt =20 =20 -----Original Message----- From: Chris Leak [mailto:ChrisLeak@metrobility.com] 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, =20 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? =20 Thanks, =20 Chris Leak Senior Software Engineer Metrobility Optical Systems chrisleak@metrobility.com (603) 589-0681 =20 ------_=_NextPart_001_01C4DD3A.E1E3A5D8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 timestamp is intended to be reference to the local clock - when the = event was=20 detected locally (for locally generated events) or when the event = indication was=20 received locally (for remotely generated events).  = I'll enhance the=20 description to bring that out. 
 
There=20 is no corresponding reference in .3ah. 
 
Thanks. 
 
-=20 Matt
-----Original Message-----
From: David B Harrington = [mailto:ietfdbh@comcast.net]
Sent: Tuesday, December 07, = 2004 4:11=20 PM
To: Matt Squire; 'Grant Schnebly';=20 hubmib@ietf.org
Subject: RE: [Hubmib] RE: EFM OAM MIB and = the=20 DateAndTime TC

Is the timestamp = relative to the local=20 clock or the remote clock when the event is remotely detected and = reported via=20 Erthernet OAM?
 
The = description should specify=20 which clock is used or REFERENCE the EFM clause that specifies the = orign of=20 the timestamp.
 
David Harrington
dbharrington@comcast.net

 =20

From: hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt=20 Squire
Sent: Tuesday, December 07, 2004 3:09 = PM
To: Grant=20 Schnebly; hubmib@ietf.org
Subject: RE: [Hubmib] RE: EFM OAM = MIB and=20 the DateAndTime TC

Great.  Thanks for the input.  Unless there's = objection=20 raised, I'll plan on changing the type of the timestamp in the next=20 revision. 
 
-=20 Matt
-----Original Message-----
From: = hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org]On Behalf Of Grant=20 Schnebly
Sent: Tuesday, December 07, 2004 1:51 = PM
To:=20 'hubmib@ietf.org'
Subject: RE: [Hubmib] RE: EFM OAM MIB = and the=20 DateAndTime TC

Matt,
 
Your "third approach" is best - it's = not much=20 work for a Manager to crudely match the Agent's sysUpTime = with its=20 own clock, and so derive a reasonable approximation of the = Agent's=20 DateAndTime.
 
If the Agent does know the DateAndTime, = it should=20 use that whenever it internally logs events in persistent = memory. =20 Otherwise, between reboots the Agent loses track of the time of = old=20 events.
 
 > [sysUpTime] would = create extra=20 work on those systems that do have date/time
 
If there is any extra work, it's = negligible, and=20 limited to the Manager side.
 
-Grant
 
-----Original Message-----
From: Matt Squire=20 [mailto:MSquire@HatterasNetworks.com]
Sent: Tuesday, = December=20 07, 2004 10:06 AM
To: Chris Leak
Cc:=20 owner-stds-802-3-efm@listserv.ieee.org;=20 hubmib@ietf.org
Subject: [Hubmib] RE: EFM OAM MIB and = the=20 DateAndTime TC

 
Hi Chris -
 
Your question on what to do with timestamps for systems = that=20 don't have date/time hasn't been discussed in context of this = MIB draft,=20 so I'd like to see what others think.  It doesn't appear to = be=20 covered by the textual conventions doc, so I'm guessing that = means its=20 open to interpretation. 
 
You point out that there is some precedent for = returning zeros,=20 or returning a date/time approximation based on sysUpTime.  = It=20 seems that from a utility point of view the latter approach is = better as=20 relative times are preserved, but the first approach is = certainly=20 simpler and easier to document.  A third approach would be = to=20 change from DateAndTime to use sysUpTime instead for the=20 timestamps.  Although this would solve the "what to do if = you don't=20 know the date/time" problem, it would create extra work on those = systems=20 that do have date/time (assuming most people want timestamps in = the=20 date/time  format). 
 
Maybe some others can shed some light/opinions on the = subject of=20 how to handle date/time when it is not available on the system.=20
 
- Matt
 
 
-----Original Message-----
From: Chris Leak = [mailto:ChrisLeak@metrobility.com]
Sent: Monday, = December=20 06, 2004 5:56 PM
To: Matt Squire
Cc: Don = Kate;=20 Manu Kaycee
Subject: EFM OAM MIB and the DateAndTime = TC

Matt,

 

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

 

Thanks,

 

Chris=20 Leak

Senior = Software=20 Engineer

Metrobility = Optical=20 Systems

chrisleak@metrobility.com

(603)=20 589-0681

 

=

= ------_=_NextPart_001_01C4DD3A.E1E3A5D8-- --===============0551189538== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0551189538==-- From hubmib-bounces@ietf.org Wed Dec 8 13:22:49 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21341 for ; Wed, 8 Dec 2004 13:22:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc6Hh-0004qN-GY; Wed, 08 Dec 2004 13:11:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc6AI-0003fZ-D1 for hubmib@megatron.ietf.org; Wed, 08 Dec 2004 13:03:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20400 for ; Wed, 8 Dec 2004 13:03:47 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc6H3-0003yn-UU for hubmib@ietf.org; Wed, 08 Dec 2004 13:10:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Wed, 8 Dec 2004 13:03:14 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971402A3B85F@mailserv.hatteras.com> Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQAAcFSLAAJmhuEA== From: "Matt Squire" To: , "Chris Leak" X-Spam-Score: 0.6 (/) X-Scan-Signature: 4a96669441ad70ecf6aebb4b47b971cd Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0670253092==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============0670253092== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD50.2FE213B0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DD50.2FE213B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi David -=20 =20 Here's some responses to your concerns/comments: =20 =20 - we should try to find a way to maintain time information across as = many systems as possible - the best path to that appears to be using = sysUpTime as it is universal where date/time is not - returning an error = code completely eliminates the possibility of knowing when something = happend, and that seems especially bad for an event log that is trying = to capture WHAT happened WHEN - knowing WHAT happened is only part of = the problem =20 - the timestamp is always relative to the sysUpTime of the local system = (e.g. when the event was generated or was received locally) [also = discussed in a respone to one of your previous emails] =20 - a management application can convert sysUpTime to date/time if desired = - the relative spacing of events within that system would be maintained =20 - the log entries should be transient (not survive re-starts), so the = table should never contain discontinuities within it (though = discontinuities may exist to an application monitoring the event log = over time) - those discontinuities could be handled by having the = application convert to date/time when it reads the sysUpTime timestamp = of a log entry =20 - returning an SNMP error code has the adverse effect of causing an = error at the SNMP PDU level, which can invalidate the response not just = that particular object, so if we were to go down the path of returning = an error code, it seems that returning all zeros is less problematic = then returning the SNMP error =20 After reading the emails, I've been moved to the opinion that = timestamping with a sysUpTime stamp is a more useful mechanism then with = a date/time for this particular application. I'm planning on moving the = text in that direction, so shout if thats a problem. =20 =20 - Matt -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net] Sent: Tuesday, December 07, 2004 4:39 PM To: Matt Squire; 'Chris Leak' Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Hi, =20 The sysUpTime solution might avoid the DateAndTime problem for the = agent, but you'll need to consider how an application should handle = discontinuities in sysUpTime for the various systems it is monitoring. = If the timestamp might be the timestamp for a remote system, it might be = difficult for the application to convert that to an equivalent date and = time in order to correlate the local and remote events properly. Maybe = the importance of the application being able to correlate the date and = time of events isn't that high, and a lack of correlation capability = might be acceptable, but if so, then why return the timestamp object = from any system? =20 It might be better to keep the DateAndTime semantics for correlation = purposes, and for systems that don't support clocks to simply not = support the timestamp object, and return a noSuchObject exception. Any = application should already have code to handle the noSuchObject = possibility. In comparison, applications would need to add special code = to handle the "000000H" case for this object =20 dbh _____ =20 From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf = Of Matt Squire Sent: Tuesday, December 07, 2004 1:06 PM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org Subject: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC =20 Hi Chris -=20 =20 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. =20 =20 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). =20 =20 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.=20 =20 - Matt =20 =20 -----Original Message----- From: Chris Leak [mailto:ChrisLeak@metrobility.com] 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, =20 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? =20 Thanks, =20 Chris Leak Senior Software Engineer Metrobility Optical Systems chrisleak@metrobility.com (603) 589-0681 =20 ------_=_NextPart_001_01C4DD50.2FE213B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 David -
 
Here's=20 some responses to your concerns/comments: 
 
- we=20 should try to find a way to maintain time information across as many = systems as=20 possible - the best path to that appears to be using sysUpTime as it is=20 universal where date/time is not - returning an error code completely = eliminates=20 the possibility of knowing when something happend, and that seems = especially bad=20 for an event log that is trying to capture WHAT happened WHEN - knowing = WHAT=20 happened is only part of the problem
 
=
- the=20 timestamp is always relative to the sysUpTime of the local system (e.g. = when the=20 event was generated or was received locally)  [also discussed in a = respone=20 to one of your previous emails]
 
- a=20 management application can convert sysUpTime to date/time = if desired - the=20 relative spacing of events within that system would be=20 maintained
 
- the=20 log entries should be transient (not survive re-starts), so the = table=20 should never contain discontinuities within it (though discontinuities = may exist=20 to an application monitoring the event log over time) - those = discontinuities=20 could be handled by having the application convert to date/time when it = reads=20 the sysUpTime timestamp of a log entry
 
-=20 returning an SNMP error code has the adverse effect of causing an error = at the=20 SNMP PDU level, which can invalidate the response not just that = particular=20 object, so if we were to go down the path of returning an error code, it = seems=20 that returning all zeros is less problematic then returning the SNMP=20 error
 
After=20 reading the emails, I've been moved to the opinion that timestamping = with a=20 sysUpTime stamp is a more useful mechanism then with a date/time for = this=20 particular application.  I'm planning on moving the text in that = direction,=20 so shout if thats a problem. 
 
-=20 Matt
-----Original Message-----
From: David B Harrington = [mailto:ietfdbh@comcast.net]
Sent: Tuesday, December 07, = 2004 4:39=20 PM
To: Matt Squire; 'Chris Leak'
Cc:=20 owner-stds-802-3-efm@listserv.ieee.org; = hubmib@ietf.org
Subject: RE:=20 [Hubmib] RE: EFM OAM MIB and the DateAndTime TC

Hi,
 
The sysUpTime solution might avoid the = DateAndTime=20 problem for the agent, but you'll need to consider how an application = should=20 handle discontinuities in sysUpTime for the various systems it is = monitoring.=20 If the timestamp might be the timestamp for a remote system, it might = be=20 difficult for the application to convert that to an equivalent date = and time=20 in order to correlate the local and remote events properly. Maybe the=20 importance of the application being able to correlate the date and = time of=20 events isn't that high, and a lack of correlation capability might be=20 acceptable, but if so, then why return the timestamp object from any=20 system?
 
It might be better to keep the DateAndTime = semantics for=20 correlation purposes, and for systems that don't support clocks to = simply not=20 support the timestamp object, and return a noSuchObject exception. Any = application should already have code to handle the noSuchObject=20 possibility. In comparison, applications would need to add special = code to=20 handle the "000000H" case for this = object
 
dbh

From: hubmib-bounces@ietf.org=20 [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt=20 Squire
Sent: Tuesday, December 07, 2004 1:06 = PM
To:=20 Chris Leak
Cc: owner-stds-802-3-efm@listserv.ieee.org;=20 hubmib@ietf.org
Subject: [Hubmib] RE: EFM OAM MIB and the=20 DateAndTime TC

 
Hi=20 Chris -
 
Your question on what to do with timestamps for systems = that don't=20 have date/time hasn't been discussed in context of this MIB draft, = so I'd=20 like to see what others think.  It doesn't appear to be covered = by the=20 textual conventions doc, so I'm guessing that means its open to=20 interpretation. 
 
You point out that there is some precedent for returning = zeros, or=20 returning a date/time approximation based on sysUpTime.  It = seems that=20 from a utility point of view the latter approach is better as = relative times=20 are preserved, but the first approach is certainly simpler and = easier to=20 document.  A third approach would be to change from DateAndTime = to use=20 sysUpTime instead for the timestamps.  Although this would = solve the=20 "what to do if you don't know the date/time" problem, it would = create extra=20 work on those systems that do have date/time (assuming most people = want=20 timestamps in the date/time  format).  =
 
Maybe some others can shed some light/opinions on the = subject of how=20 to handle date/time when it is not available on the system.=20
 
-=20 Matt
 
 
-----Original Message-----
From: Chris Leak=20 [mailto:ChrisLeak@metrobility.com]
Sent: Monday, = December 06,=20 2004 5:56 PM
To: Matt Squire
Cc: Don Kate; = Manu=20 Kaycee
Subject: EFM OAM MIB and the DateAndTime=20 TC

Matt,

 

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

 

Thanks,

 

Chris = Leak

Senior = Software=20 Engineer

Metrobility Optical=20 Systems

chrisleak@metrobility.com

(603)=20 589-0681

 

------_=_NextPart_001_01C4DD50.2FE213B0-- --===============0670253092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============0670253092==-- From hubmib-bounces@ietf.org Thu Dec 9 12:44:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14323 for ; Thu, 9 Dec 2004 12:44:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcS2a-0004Sh-FE; Thu, 09 Dec 2004 12:25:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRz2-00038g-Ek for hubmib@megatron.ietf.org; Thu, 09 Dec 2004 12:21:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11999 for ; Thu, 9 Dec 2004 12:21:38 -0500 (EST) Message-Id: <200412091721.MAA11999@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcS63-0001pF-HO for hubmib@ietf.org; Thu, 09 Dec 2004 12:28:56 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004120917210701500e3v25e>; Thu, 9 Dec 2004 17:21:08 +0000 From: "David B Harrington" To: "'Matt Squire'" , "'Chris Leak'" Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Thu, 9 Dec 2004 12:21:02 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQAAcFSLAAJmhuEAAGFmIg In-Reply-To: <8052E2EA753D144EB906B7A7AA39971402A3B85F@mailserv.hatteras.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Content-Transfer-Encoding: 7bit Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi, 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 dbharrington@comcast.net IETF MIB Doctor ________________________________ From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Wednesday, December 08, 2004 1:03 PM To: ietfdbh@comcast.net; Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Hi David - Here's some responses to your concerns/comments: - we should try to find a way to maintain time information across as many systems as possible - the best path to that appears to be using sysUpTime as it is universal where date/time is not - returning an error code completely eliminates the possibility of knowing when something happend, and that seems especially bad for an event log that is trying to capture WHAT happened WHEN - knowing WHAT happened is only part of the problem - the timestamp is always relative to the sysUpTime of the local system (e.g. when the event was generated or was received locally) [also discussed in a respone to one of your previous emails] - a management application can convert sysUpTime to date/time if desired - the relative spacing of events within that system would be maintained - the log entries should be transient (not survive re-starts), so the table should never contain discontinuities within it (though discontinuities may exist to an application monitoring the event log over time) - those discontinuities could be handled by having the application convert to date/time when it reads the sysUpTime timestamp of a log entry - returning an SNMP error code has the adverse effect of causing an error at the SNMP PDU level, which can invalidate the response not just that particular object, so if we were to go down the path of returning an error code, it seems that returning all zeros is less problematic then returning the SNMP error After reading the emails, I've been moved to the opinion that timestamping with a sysUpTime stamp is a more useful mechanism then with a date/time for this particular application. I'm planning on moving the text in that direction, so shout if thats a problem. - Matt -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net] Sent: Tuesday, December 07, 2004 4:39 PM To: Matt Squire; 'Chris Leak' Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Hi, The sysUpTime solution might avoid the DateAndTime problem for the agent, but you'll need to consider how an application should handle discontinuities in sysUpTime for the various systems it is monitoring. If the timestamp might be the timestamp for a remote system, it might be difficult for the application to convert that to an equivalent date and time in order to correlate the local and remote events properly. Maybe the importance of the application being able to correlate the date and time of events isn't that high, and a lack of correlation capability might be acceptable, but if so, then why return the timestamp object from any system? It might be better to keep the DateAndTime semantics for correlation purposes, and for systems that don't support clocks to simply not support the timestamp object, and return a noSuchObject exception. Any application should already have code to handle the noSuchObject possibility. In comparison, applications would need to add special code to handle the "000000H" case for this object dbh ________________________________ From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire Sent: Tuesday, December 07, 2004 1:06 PM To: Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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:ChrisLeak@metrobility.com] 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 chrisleak@metrobility.com (603) 589-0681 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu Dec 9 13:36:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19504 for ; Thu, 9 Dec 2004 13:36:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSsJ-0000dd-Bd; Thu, 09 Dec 2004 13:18:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcSqZ-0008Q8-9e for hubmib@megatron.ietf.org; Thu, 09 Dec 2004 13:16:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17716 for ; Thu, 9 Dec 2004 13:16:56 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcSxb-00037f-0T for hubmib@ietf.org; Thu, 09 Dec 2004 13:24:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Thu, 9 Dec 2004 13:16:27 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971402A3B866@mailserv.hatteras.com> Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQAAcFSLAAJmhuEAAGFmIgADFgoDA= From: "Matt Squire" To: , "Chris Leak" X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi David -=20 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. =20 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. =20 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. =20 - Matt >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > 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? >=20 > 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.=20 >=20 > 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.=20 >=20 > I question the wisdom of using a sysUpTime timestamp rather than a > date/time timestamp in this table. >=20 >=20 > David Harrington > dbharrington@comcast.net > IETF MIB Doctor >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Thu Dec 9 17:00:04 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16312 for ; Thu, 9 Dec 2004 17:00:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcW8r-0002cI-SR; Thu, 09 Dec 2004 16:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVdA-00067h-K2 for hubmib@megatron.ietf.org; Thu, 09 Dec 2004 16:15:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05103 for ; Thu, 9 Dec 2004 16:15:18 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcVkD-0007L4-Ks for hubmib@ietf.org; Thu, 09 Dec 2004 16:22:38 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Dec 2004 16:21:40 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from arnoldb-w2k02.cisco.com ([64.101.203.239]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iB9LEi9F006735; Thu, 9 Dec 2004 16:14:45 -0500 (EST) Message-Id: <4.3.2.7.2.20041209151602.03a7a7d0@mira-sjc5-d.cisco.com> X-Sender: arnoldb@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Dec 2004 16:14:42 -0500 To: "Matt Squire" From: Brian Arnold Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC In-Reply-To: <8052E2EA753D144EB906B7A7AA39971402A3B866@mailserv.hatteras .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-PMX-Version: 4.7.0.111621 X-from-outside-Cisco: [64.101.203.239] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org, ietfdbh@comcast.net X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org 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 At 01:16 PM 12/9/2004 -0500, Matt Squire wrote: >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 >> dbharrington@comcast.net >> IETF MIB Doctor >> > >_______________________________________________ >Hubmib mailing list >Hubmib@ietf.org >https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Sun Dec 12 06:26:14 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19666 for ; Sun, 12 Dec 2004 06:26:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdRr1-0002X1-Vb; Sun, 12 Dec 2004 06:25:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdRpO-0002Ii-Gr for hubmib@megatron.ietf.org; Sun, 12 Dec 2004 06:23:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19577 for ; Sun, 12 Dec 2004 06:23:48 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdRwz-0004ki-6a for hubmib@ietf.org; Sun, 12 Dec 2004 06:31:41 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBCBLpo4024694 for ; Sun, 12 Dec 2004 06:21:51 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBCBLno4024682 for ; Sun, 12 Dec 2004 06:21:50 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Sun, 12 Dec 2004 13:23:46 +0200 Message-ID: Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQAAcFSLAAJmhuEAAGFmIgADFgoDAAiNyWcA== From: "Romascanu, Dan \(Dan\)" To: "Matt Squire" , , "Chris Leak" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Speaking as a contributor.=20 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=20 - 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.=20 Regards, Dan > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > Sent: 09 December, 2004 8:16 PM > To: ietfdbh@comcast.net; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 >=20 > Hi David -=20 >=20 > I don't really argue with most of the arguments you give=20 > below - date/time is better if you have it. I guess the big=20 > question is whether its more important for this application=20 > to take steps to make things better when you have date/time,=20 > or to make things better when you don't have date/time. =20 > Either approach sacrifices something for the other guy. On=20 > the one hand, we can take an approach that gives "ok"=20 > information for everybody, or an approach that gives better=20 > information when you have date/time and no information when=20 > you don't. All of the other stuff (return 0s, excpetions,=20 > errors, etc.) seems like noise. =20 >=20 > If the market was clear and there were a bunch of volume=20 > shipments then we could probably just look at the existing=20 > market and make a determination. At this point, its just=20 > guessing what kind of capabilities will exist in products=20 > that implement 802.3ah OAM functionality. =20 >=20 > There were at least a couple of people that mentioned to me=20 > that date/time would be a problem for them, so I leaned in=20 > the direction of supporting their application better. I'm=20 > hoping to get some more opinions. =20 >=20 > - Matt >=20 >=20 >=20 >=20 > >=20 > > 1) I did not suggest returning an error code; I suggested=20 > returning an > > exception. Returning a noSuchObject exception does not=20 > invalidate the > > response, only the specific varbind. Exceptions were added=20 > 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. > >=20 > > 2) I read the security considerations section to determine=20 > 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=20 > 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=20 > recommended because > > it is not secure. Since the use of SNMPv1 is not recommended, and > > later versions of SNMP support exceptions, the problem you=20 > cite should > > not be an issue. > >=20 > > 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=20 > makes a big > > difference when getting the object from a device that does support a > > clock. > >=20 > > 4) If knowing WHEN an event occurred is important, then I=20 > would think > > it would make more sense to know when it occurred at the=20 > remote device > > that had the event rather than when it was received by the local > > agent.=20 > >=20 > > 5) sysUpTime is relative to the last restart of the=20 > 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=20 > inaccuracy > > already introduced by timestamping a remote event with the=20 > agent-local > > time, and adding to that the imprecision of roughly=20 > estimating when an > > event ocuured based on sysUpTime, it strikes me that the=20 > precision is > > getting very poor. If this object lacks precision, is it=20 > still really > > useful? > >=20 > > 6) Assuming an agent's clock is consistent with other=20 > agents' clocks, > > an application receiving a date/time timestamped event=20 > 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=20 > important for > > troubleshooting. Correlating events properly can be important for > > troubleshooting problems such as worms, viruses, routing/switching > > updates, performance bottlenecks, etc.=20 > >=20 > > 7) Lack of accuracy in correlating the times of multiple=20 > events could > > lead operators to incorrectly dismiss some paths of=20 > investigation, and > > waste time pursuing other paths, because the timestamped event > > information is so inaccurate.=20 > >=20 > > I question the wisdom of using a sysUpTime timestamp rather than a > > date/time timestamp in this table. > >=20 > >=20 > > David Harrington > > dbharrington@comcast.net > > IETF MIB Doctor > >=20 >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Sun Dec 12 21:20:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28752 for ; Sun, 12 Dec 2004 21:20:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdfd6-00069S-OK; Sun, 12 Dec 2004 21:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdfVv-00048N-2T for hubmib@megatron.ietf.org; Sun, 12 Dec 2004 21:00:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26931 for ; Sun, 12 Dec 2004 21:00:37 -0500 (EST) Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdfdd-0006jZ-GJ for hubmib@ietf.org; Sun, 12 Dec 2004 21:08:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Sun, 12 Dec 2004 21:00:01 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA39971403098FFF@mailserv.hatteras.com> Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTb5scSR9hyaNaqRyKGSkBRbAVhzgAnnxaQAAcFSLAAJmhuEAAGFmIgADFgoDAAiNyWcAAex2bA From: "Matt Squire" To: "Romascanu, Dan (Dan)" , , "Chris Leak" X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Sounds like a reasonable thing to me. =20 - Matt > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Sunday, December 12, 2004 6:24 AM > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > Speaking as a contributor.=20 >=20 > I believe that David brings some valid points. I understand=20 > however the other arguments about the possible lack of=20 > support form DateAndTime in some implementations. I suggest=20 > the following: >=20 > - add a TimeStamp object=20 > - keep the current object, but change the SYNTAX to=20 > DateAndTimeOrZero, so that it returns zero if the managed=20 > entity does not have a clock capability >=20 > Later, when some implementation experience will be achieved,=20 > we can deprecate one of the objects.=20 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: hubmib-bounces@ietf.org=20 > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > Sent: 09 December, 2004 8:16 PM > > To: ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > >=20 > >=20 > >=20 > > Hi David -=20 > >=20 > > I don't really argue with most of the arguments you give=20 > > below - date/time is better if you have it. I guess the big=20 > > question is whether its more important for this application=20 > > to take steps to make things better when you have date/time,=20 > > or to make things better when you don't have date/time. =20 > > Either approach sacrifices something for the other guy. On=20 > > the one hand, we can take an approach that gives "ok"=20 > > information for everybody, or an approach that gives better=20 > > information when you have date/time and no information when=20 > > you don't. All of the other stuff (return 0s, excpetions,=20 > > errors, etc.) seems like noise. =20 > >=20 > > If the market was clear and there were a bunch of volume=20 > > shipments then we could probably just look at the existing=20 > > market and make a determination. At this point, its just=20 > > guessing what kind of capabilities will exist in products=20 > > that implement 802.3ah OAM functionality. =20 > >=20 > > There were at least a couple of people that mentioned to me=20 > > that date/time would be a problem for them, so I leaned in=20 > > the direction of supporting their application better. I'm=20 > > hoping to get some more opinions. =20 > >=20 > > - Matt > >=20 > >=20 > >=20 > >=20 > > >=20 > > > 1) I did not suggest returning an error code; I suggested=20 > > returning an > > > exception. Returning a noSuchObject exception does not=20 > > invalidate the > > > response, only the specific varbind. Exceptions were added=20 > > to SNMP to > > > mitigate the problem of invalidating complete responses, a problem > > > which existed in SNMPv1. The problem you cite only exists=20 > if you use > > > error codes. You are limited to using error codes only if you use > > > SNMPv1. > > >=20 > > > 2) I read the security considerations section to determine=20 > > whether the > > > sensitivity of the information counter-indicated the use=20 > of SNMPv1. > > > The security considerations section says that the information is > > > sensitive, and that security is important for this mib=20 > > module. It goes > > > into great detail about ensuring that the non-secure L2=20 > OAM protocol > > > is secured, and goes on to say that SNMPv1 is not=20 > > recommended because > > > it is not secure. Since the use of SNMPv1 is not recommended, and > > > later versions of SNMP support exceptions, the problem you=20 > > cite should > > > not be an issue. > > >=20 > > > 3) The application receiving a timestamp of zeroes has no more > > > information than if it had received an exception. In both=20 > 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=20 > when getting > > > the object from a device that doesn't support a clock. It=20 > > makes a big > > > difference when getting the object from a device that=20 > does support a > > > clock. > > >=20 > > > 4) If knowing WHEN an event occurred is important, then I=20 > > would think > > > it would make more sense to know when it occurred at the=20 > > remote device > > > that had the event rather than when it was received by the local > > > agent.=20 > > >=20 > > > 5) sysUpTime is relative to the last restart of the=20 > > management system, > > > and if the application doesn't know quite when that was,=20 > 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=20 > > inaccuracy > > > already introduced by timestamping a remote event with the=20 > > agent-local > > > time, and adding to that the imprecision of roughly=20 > > estimating when an > > > event ocuured based on sysUpTime, it strikes me that the=20 > > precision is > > > getting very poor. If this object lacks precision, is it=20 > > still really > > > useful? > > >=20 > > > 6) Assuming an agent's clock is consistent with other=20 > > agents' clocks, > > > an application receiving a date/time timestamped event=20 > > report has more > > > useful information than one receiving a sysUpTime=20 > timestamp. With a > > > date/time timestamp, the application can do a much better job of > > > correlating events across multiple devices, which can be=20 > > important for > > > troubleshooting. Correlating events properly can be important for > > > troubleshooting problems such as worms, viruses, routing/switching > > > updates, performance bottlenecks, etc.=20 > > >=20 > > > 7) Lack of accuracy in correlating the times of multiple=20 > > events could > > > lead operators to incorrectly dismiss some paths of=20 > > investigation, and > > > waste time pursuing other paths, because the timestamped event > > > information is so inaccurate.=20 > > >=20 > > > I question the wisdom of using a sysUpTime timestamp rather than a > > > date/time timestamp in this table. > > >=20 > > >=20 > > > David Harrington > > > dbharrington@comcast.net > > > IETF MIB Doctor > > >=20 > >=20 > > _______________________________________________ > > Hubmib mailing list > > Hubmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/hubmib > >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 02:05:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24233 for ; Mon, 13 Dec 2004 02:05:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdk8x-0007MH-1E; Mon, 13 Dec 2004 01:57:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdk5p-0006Iq-4V for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 01:54:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17696 for ; Mon, 13 Dec 2004 01:53:59 -0500 (EST) Received: from mail14b.g14.rapidsite.net ([128.121.64.164]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CdkDY-0004cp-Md for hubmib@ietf.org; Mon, 13 Dec 2004 02:02:01 -0500 Received: from mxw1400.sanjose14-verio.com (128.121.143.19) by mail14b.g14.rapidsite.net (RS ver 1.0.95vs) with SMTP id 4-079384829; Mon, 13 Dec 2004 01:53:55 -0500 (EST) From: "Lior khermosh" To: "'Matt Squire'" , "'Romascanu, Dan \(Dan\)'" , , "'Chris Leak'" Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 08:52:42 +0200 Message-ID: <01c901c4e0e0$5bbe70c0$2b0b0b0b@passave.co.il> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <8052E2EA753D144EB906B7A7AA39971403098FFF@mailserv.hatteras.com> X-Loop-Detect: 1 X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Content-Transfer-Encoding: 7bit Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: 7bit I will practice the same for the EPON DateAndTime objects. -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire Sent: Monday, December 13, 2004 4:00 AM To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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:dromasca@avaya.com] > Sent: Sunday, December 12, 2004 6:24 AM > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > 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: hubmib-bounces@ietf.org > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > Sent: 09 December, 2004 8:16 PM > > To: ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > 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 > > > dbharrington@comcast.net > > > IETF MIB Doctor > > > > > > > _______________________________________________ > > Hubmib mailing list > > Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib > > > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 05:03:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17517 for ; Mon, 13 Dec 2004 05:03:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdmwe-0004n7-Nx; Mon, 13 Dec 2004 04:56:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmeJ-0000Uh-Jl for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 04:37:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15833 for ; Mon, 13 Dec 2004 04:37:45 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdmm5-00005x-UU for hubmib@ietf.org; Mon, 13 Dec 2004 04:45:50 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBD9Zio4021028 for ; Mon, 13 Dec 2004 04:35:44 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBD9Zfo4020960 for ; Mon, 13 Dec 2004 04:35:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 11:37:34 +0200 Message-ID: Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTg4Ieydm51NyonQe2pIsqop/KjsQAFkjow From: "Romascanu, Dan \(Dan\)" To: "Lior khermosh" , "Matt Squire" , , "Chris Leak" X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable 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.=20 Regards, Dan > -----Original Message----- > From: Lior khermosh [mailto:lior.khermosh@passave.com] > Sent: 13 December, 2004 8:53 AM > To: 'Matt Squire'; Romascanu, Dan (Dan); ietfdbh@comcast.net;=20 > 'Chris Leak' > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > I will practice the same for the EPON DateAndTime objects. >=20 >=20 > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org] On Behalf > Of Matt Squire > Sent: Monday, December 13, 2004 4:00 AM > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > Sounds like a reasonable thing to me. =20 >=20 > - Matt >=20 > > -----Original Message----- > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > Sent: Sunday, December 12, 2004 6:24 AM > > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > >=20 > >=20 > > Speaking as a contributor. > >=20 > > I believe that David brings some valid points. I understand > > however the other arguments about the possible lack of=20 > > support form DateAndTime in some implementations. I suggest=20 > > the following: > >=20 > > - add a TimeStamp object > > - keep the current object, but change the SYNTAX to=20 > > DateAndTimeOrZero, so that it returns zero if the managed=20 > > entity does not have a clock capability > >=20 > > Later, when some implementation experience will be achieved, > > we can deprecate one of the objects.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: hubmib-bounces@ietf.org > > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > > Sent: 09 December, 2004 8:16 PM > > > To: ietfdbh@comcast.net; Chris Leak > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > >=20 > > >=20 > > >=20 > > > Hi David - > > >=20 > > > 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=20 > > > question is whether its more important for this application=20 > > > to take steps to make things better when you have date/time,=20 > > > or to make things better when you don't have date/time. =20 > > > Either approach sacrifices something for the other guy. On=20 > > > the one hand, we can take an approach that gives "ok"=20 > > > information for everybody, or an approach that gives better=20 > > > information when you have date/time and no information when=20 > > > you don't. All of the other stuff (return 0s, excpetions,=20 > > > errors, etc.) seems like noise. =20 > > >=20 > > > If the market was clear and there were a bunch of volume > > > shipments then we could probably just look at the existing=20 > > > market and make a determination. At this point, its just=20 > > > guessing what kind of capabilities will exist in products=20 > > > that implement 802.3ah OAM functionality. =20 > > >=20 > > > 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=20 > > > the direction of supporting their application better. I'm=20 > > > hoping to get some more opinions. =20 > > >=20 > > > - Matt > > >=20 > > >=20 > > >=20 > > >=20 > > > >=20 > > > > 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=20 > responses, a problem >=20 > > > > which existed in SNMPv1. The problem you cite only exists > > if you use > > > > error codes. You are limited to using error codes only=20 > if you use=20 > > > > SNMPv1. > > > >=20 > > > > 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=20 > information is=20 > > > > 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=20 > recommended, and=20 > > > > later versions of SNMP support exceptions, the problem you > > > cite should > > > > not be an issue. > > > >=20 > > > > 3) The application receiving a timestamp of zeroes has no more=20 > > > > information than if it had received an exception. In both > > cases, it > > > > knows that the device that had the event does not support the=20 > > > > date/time capability, and the event occurred sometime=20 > prior to the >=20 > > > > 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. > > > >=20 > > > > 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=20 > the local=20 > > > > agent. > > > >=20 > > > > 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=20 > occurred. The >=20 > > > > 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? > > > >=20 > > > > 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=20 > better job of=20 > > > > correlating events across multiple devices, which can be > > > important for > > > > troubleshooting. Correlating events properly can be=20 > important for=20 > > > > troubleshooting problems such as worms, viruses,=20 > routing/switching >=20 > > > > updates, performance bottlenecks, etc. > > > >=20 > > > > 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=20 > > > > information is so inaccurate. > > > >=20 > > > > I question the wisdom of using a sysUpTime timestamp=20 > rather than a >=20 > > > > date/time timestamp in this table. > > > >=20 > > > >=20 > > > > David Harrington > > > > dbharrington@comcast.net > > > > IETF MIB Doctor > > > >=20 > > >=20 > > > _______________________________________________ > > > Hubmib mailing list > > > Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib > > >=20 > >=20 >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 09:31:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13581 for ; Mon, 13 Dec 2004 09:31:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdr87-0004or-CX; Mon, 13 Dec 2004 09:24:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdqml-0005uk-VF for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 09:02:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10563 for ; Mon, 13 Dec 2004 09:02:46 -0500 (EST) Message-Id: <200412131402.JAA10563@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdqua-0006fF-Ly for hubmib@ietf.org; Mon, 13 Dec 2004 09:10:53 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2004121314021401500s0tche>; Mon, 13 Dec 2004 14:02:15 +0000 From: "David B Harrington" To: "'Romascanu, Dan \(Dan\)'" , "'Lior khermosh'" , "'Matt Squire'" , "'Chris Leak'" Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 09:02:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcTg4Ieydm51NyonQe2pIsqop/KjsQAFkjowAAjPehA= In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: 7bit Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: 7bit 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: hubmib-bounces@ietf.org > [mailto:hubmib-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Monday, December 13, 2004 4:38 AM > To: Lior khermosh; Matt Squire; ietfdbh@comcast.net; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > 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:lior.khermosh@passave.com] > > Sent: 13 December, 2004 8:53 AM > > To: 'Matt Squire'; Romascanu, Dan (Dan); > ietfdbh@comcast.net; 'Chris > > Leak' > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > > > > I will practice the same for the EPON DateAndTime objects. > > > > > > -----Original Message----- > > From: hubmib-bounces@ietf.org > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire > > Sent: Monday, December 13, 2004 4:00 AM > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > 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:dromasca@avaya.com] > > > Sent: Sunday, December 12, 2004 6:24 AM > > > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > 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: hubmib-bounces@ietf.org > > > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > > > Sent: 09 December, 2004 8:16 PM > > > > To: ietfdbh@comcast.net; Chris Leak > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > 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 > > > > > dbharrington@comcast.net > > > > > IETF MIB Doctor > > > > > > > > > > > > > _______________________________________________ > > > > Hubmib mailing list > > > > Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib > > > > > > > > > > > _______________________________________________ > > Hubmib mailing list > > Hubmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/hubmib > > > > > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 09:35:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14446 for ; Mon, 13 Dec 2004 09:35:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdr9V-0005LM-VE; Mon, 13 Dec 2004 09:26:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdqvE-0007mV-BV for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 09:11:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11333 for ; Mon, 13 Dec 2004 09:11:31 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdr33-0006sz-6m for hubmib@ietf.org; Mon, 13 Dec 2004 09:19:37 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBDE9So4029201 for ; Mon, 13 Dec 2004 09:09:28 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBDE9Qo4029160 for ; Mon, 13 Dec 2004 09:09:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 16:11:23 +0200 Message-ID: Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTg4Ieydm51NyonQe2pIsqop/KjsQAFkjowAAjPehAAAKz2YA== From: "Romascanu, Dan \(Dan\)" To: , "Lior khermosh" , "Matt Squire" , "Chris Leak" X-Spam-Score: 0.0 (/) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable 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.=20 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?=20 Regards, Dan > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: 13 December, 2004 4:02 PM > To: Romascanu, Dan (Dan); 'Lior khermosh'; 'Matt Squire'; 'Chris Leak' > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > I would rather see one object, whether DateAndTime or sysUpTime > syntax.=20 >=20 > 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. >=20 > 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. >=20 > dbh >=20 > > -----Original Message----- > > From: hubmib-bounces@ietf.org=20 > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Monday, December 13, 2004 4:38 AM > > To: Lior khermosh; Matt Squire; ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > >=20 > > To make it clear again - this was a contributor and not a=20 > > chair proposal. To be frank, I personally do not feel one=20 > > hundred percent comfortable with redundant objects, which is=20 > > a minus. If anybody feels stronger against this, please speak=20 > > loudly. In the absence of vocal comments, we will go ahead=20 > > with this method.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Lior khermosh [mailto:lior.khermosh@passave.com] > > > Sent: 13 December, 2004 8:53 AM > > > To: 'Matt Squire'; Romascanu, Dan (Dan);=20 > > ietfdbh@comcast.net; 'Chris=20 > > > Leak' > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > >=20 > > >=20 > > > I will practice the same for the EPON DateAndTime objects. > > >=20 > > >=20 > > > -----Original Message----- > > > From: hubmib-bounces@ietf.org > > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire > > > Sent: Monday, December 13, 2004 4:00 AM > > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > >=20 > > >=20 > > > Sounds like a reasonable thing to me. =20 > > >=20 > > > - Matt > > >=20 > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Sunday, December 12, 2004 6:24 AM > > > > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > >=20 > > > >=20 > > > > Speaking as a contributor. > > > >=20 > > > > I believe that David brings some valid points. I understand > > > > however the other arguments about the possible lack of=20 > > > > support form DateAndTime in some implementations. I suggest=20 > > > > the following: > > > >=20 > > > > - add a TimeStamp object > > > > - keep the current object, but change the SYNTAX to=20 > > > > DateAndTimeOrZero, so that it returns zero if the managed=20 > > > > entity does not have a clock capability > > > >=20 > > > > Later, when some implementation experience will be achieved, > > > > we can deprecate one of the objects.=20 > > > >=20 > > > > Regards, > > > >=20 > > > > Dan > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: hubmib-bounces@ietf.org > > > > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > > > > Sent: 09 December, 2004 8:16 PM > > > > > To: ietfdbh@comcast.net; Chris Leak > > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Hi David - > > > > >=20 > > > > > 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=20 > > > > > question is whether its more important for this application=20 > > > > > to take steps to make things better when you have date/time,=20 > > > > > or to make things better when you don't have date/time. =20 > > > > > Either approach sacrifices something for the other guy. On=20 > > > > > the one hand, we can take an approach that gives "ok"=20 > > > > > information for everybody, or an approach that gives better=20 > > > > > information when you have date/time and no information when=20 > > > > > you don't. All of the other stuff (return 0s, excpetions,=20 > > > > > errors, etc.) seems like noise. =20 > > > > >=20 > > > > > If the market was clear and there were a bunch of volume > > > > > shipments then we could probably just look at the existing=20 > > > > > market and make a determination. At this point, its just=20 > > > > > guessing what kind of capabilities will exist in products=20 > > > > > that implement 802.3ah OAM functionality. =20 > > > > >=20 > > > > > 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=20 > > > > > the direction of supporting their application better. I'm=20 > > > > > hoping to get some more opinions. =20 > > > > >=20 > > > > > - Matt > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > 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=20 > > > responses, a problem > > >=20 > > > > > > which existed in SNMPv1. The problem you cite only exists > > > > if you use > > > > > > error codes. You are limited to using error codes only=20 > > > if you use=20 > > > > > > SNMPv1. > > > > > >=20 > > > > > > 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=20 > > > information is=20 > > > > > > 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=20 > > > recommended, and=20 > > > > > > later versions of SNMP support exceptions, the problem you > > > > > cite should > > > > > > not be an issue. > > > > > >=20 > > > > > > 3) The application receiving a timestamp of zeroes=20 > > has no more=20 > > > > > > information than if it had received an exception. In both > > > > cases, it > > > > > > knows that the device that had the event does not support > the=20 > > > > > > date/time capability, and the event occurred sometime=20 > > > prior to the > > >=20 > > > > > > 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. > > > > > >=20 > > > > > > 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=20 > > > the local=20 > > > > > > agent. > > > > > >=20 > > > > > > 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=20 > > > occurred. The > > >=20 > > > > > > 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? > > > > > >=20 > > > > > > 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=20 > > > better job of=20 > > > > > > correlating events across multiple devices, which can be > > > > > important for > > > > > > troubleshooting. Correlating events properly can be=20 > > > important for=20 > > > > > > troubleshooting problems such as worms, viruses,=20 > > > routing/switching > > >=20 > > > > > > updates, performance bottlenecks, etc. > > > > > >=20 > > > > > > 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=20 > > timestamped event=20 > > > > > > information is so inaccurate. > > > > > >=20 > > > > > > I question the wisdom of using a sysUpTime timestamp=20 > > > rather than a > > >=20 > > > > > > date/time timestamp in this table. > > > > > >=20 > > > > > >=20 > > > > > > David Harrington > > > > > > dbharrington@comcast.net > > > > > > IETF MIB Doctor > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Hubmib mailing list > > > > > Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib > > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > Hubmib mailing list > > > Hubmib@ietf.org > > > https://www1.ietf.org/mailman/listinfo/hubmib > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Hubmib mailing list > > Hubmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/hubmib > >=20 >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 12:46:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02081 for ; Mon, 13 Dec 2004 12:46:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdu79-0005aE-4R; Mon, 13 Dec 2004 12:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdtyC-0002r0-Sf for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 12:26:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00578 for ; Mon, 13 Dec 2004 12:26:46 -0500 (EST) Received: from [213.70.90.131] (helo=mail.advaoptical.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdu5s-0003y1-RG for hubmib@ietf.org; Mon, 13 Dec 2004 12:34:55 -0500 Received: from muc-srv-mail2.advaoptical.com (unverified) by mail.advaoptical.de (Content Technologies SMTPRS 4.3.1) with ESMTP id ; Mon, 13 Dec 2004 18:24:36 +0100 Received: from muc-srv-mail.advaoptical.com ([172.20.1.46]) by muc-srv-mail2.advaoptical.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Dec 2004 18:26:32 +0100 Received: from yrk-srv-mail.yrk.advaoptical.com ([172.22.21.13]) by muc-srv-mail.advaoptical.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Dec 2004 18:26:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 17:26:30 -0000 Message-ID: <149127BC7EEE5A48B1F550A57086C1EB045A71@yrk-srv-mail.yrk.advaoptical.com> Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC thread-index: AcTg4Ieydm51NyonQe2pIsqop/KjsQAFkjowAAjPehAAAKz2YAAG1uSQ From: "John Messenger" To: "Romascanu, Dan \(Dan\)" , , "Lior khermosh" , "Matt Squire" , "Chris Leak" X-OriginalArrivalTime: 13 Dec 2004 17:26:31.0692 (UTC) FILETIME=[E30D14C0:01C4E138] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable 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 =20 -----Original Message----- From: hubmib-bounces@ietf.org [mailto:hubmib-bounces@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 13 December 2004 14:11 To: ietfdbh@comcast.net; Lior khermosh; Matt Squire; Chris Leak Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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.=20 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?=20 Regards, Dan > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: 13 December, 2004 4:02 PM > To: Romascanu, Dan (Dan); 'Lior khermosh'; 'Matt Squire'; 'Chris Leak' > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > I would rather see one object, whether DateAndTime or sysUpTime > syntax.=20 >=20 > 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. >=20 > 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. >=20 > dbh >=20 > > -----Original Message----- > > From: hubmib-bounces@ietf.org=20 > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > Sent: Monday, December 13, 2004 4:38 AM > > To: Lior khermosh; Matt Squire; ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > >=20 > > To make it clear again - this was a contributor and not a=20 > > chair proposal. To be frank, I personally do not feel one=20 > > hundred percent comfortable with redundant objects, which is=20 > > a minus. If anybody feels stronger against this, please speak=20 > > loudly. In the absence of vocal comments, we will go ahead=20 > > with this method.=20 > >=20 > > Regards, > >=20 > > Dan > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Lior khermosh [mailto:lior.khermosh@passave.com] > > > Sent: 13 December, 2004 8:53 AM > > > To: 'Matt Squire'; Romascanu, Dan (Dan);=20 > > ietfdbh@comcast.net; 'Chris=20 > > > Leak' > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > >=20 > > >=20 > > > I will practice the same for the EPON DateAndTime objects. > > >=20 > > >=20 > > > -----Original Message----- > > > From: hubmib-bounces@ietf.org > > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire > > > Sent: Monday, December 13, 2004 4:00 AM > > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > >=20 > > >=20 > > > Sounds like a reasonable thing to me. =20 > > >=20 > > > - Matt > > >=20 > > > > -----Original Message----- > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > Sent: Sunday, December 12, 2004 6:24 AM > > > > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > >=20 > > > >=20 > > > > Speaking as a contributor. > > > >=20 > > > > I believe that David brings some valid points. I understand > > > > however the other arguments about the possible lack of=20 > > > > support form DateAndTime in some implementations. I suggest=20 > > > > the following: > > > >=20 > > > > - add a TimeStamp object > > > > - keep the current object, but change the SYNTAX to=20 > > > > DateAndTimeOrZero, so that it returns zero if the managed=20 > > > > entity does not have a clock capability > > > >=20 > > > > Later, when some implementation experience will be achieved, > > > > we can deprecate one of the objects.=20 > > > >=20 > > > > Regards, > > > >=20 > > > > Dan > > > >=20 > > > >=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: hubmib-bounces@ietf.org > > > > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > > > > Sent: 09 December, 2004 8:16 PM > > > > > To: ietfdbh@comcast.net; Chris Leak > > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > > >=20 > > > > >=20 > > > > >=20 > > > > > Hi David - > > > > >=20 > > > > > 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=20 > > > > > question is whether its more important for this application=20 > > > > > to take steps to make things better when you have date/time,=20 > > > > > or to make things better when you don't have date/time. =20 > > > > > Either approach sacrifices something for the other guy. On=20 > > > > > the one hand, we can take an approach that gives "ok"=20 > > > > > information for everybody, or an approach that gives better=20 > > > > > information when you have date/time and no information when=20 > > > > > you don't. All of the other stuff (return 0s, excpetions,=20 > > > > > errors, etc.) seems like noise. =20 > > > > >=20 > > > > > If the market was clear and there were a bunch of volume > > > > > shipments then we could probably just look at the existing=20 > > > > > market and make a determination. At this point, its just=20 > > > > > guessing what kind of capabilities will exist in products=20 > > > > > that implement 802.3ah OAM functionality. =20 > > > > >=20 > > > > > 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=20 > > > > > the direction of supporting their application better. I'm=20 > > > > > hoping to get some more opinions. =20 > > > > >=20 > > > > > - Matt > > > > >=20 > > > > >=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > > 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=20 > > > responses, a problem > > >=20 > > > > > > which existed in SNMPv1. The problem you cite only exists > > > > if you use > > > > > > error codes. You are limited to using error codes only=20 > > > if you use=20 > > > > > > SNMPv1. > > > > > >=20 > > > > > > 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=20 > > > information is=20 > > > > > > 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=20 > > > recommended, and=20 > > > > > > later versions of SNMP support exceptions, the problem you > > > > > cite should > > > > > > not be an issue. > > > > > >=20 > > > > > > 3) The application receiving a timestamp of zeroes=20 > > has no more=20 > > > > > > information than if it had received an exception. In both > > > > cases, it > > > > > > knows that the device that had the event does not support > the=20 > > > > > > date/time capability, and the event occurred sometime=20 > > > prior to the > > >=20 > > > > > > 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. > > > > > >=20 > > > > > > 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=20 > > > the local=20 > > > > > > agent. > > > > > >=20 > > > > > > 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=20 > > > occurred. The > > >=20 > > > > > > 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? > > > > > >=20 > > > > > > 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=20 > > > better job of=20 > > > > > > correlating events across multiple devices, which can be > > > > > important for > > > > > > troubleshooting. Correlating events properly can be=20 > > > important for=20 > > > > > > troubleshooting problems such as worms, viruses,=20 > > > routing/switching > > >=20 > > > > > > updates, performance bottlenecks, etc. > > > > > >=20 > > > > > > 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=20 > > timestamped event=20 > > > > > > information is so inaccurate. > > > > > >=20 > > > > > > I question the wisdom of using a sysUpTime timestamp=20 > > > rather than a > > >=20 > > > > > > date/time timestamp in this table. > > > > > >=20 > > > > > >=20 > > > > > > David Harrington > > > > > > dbharrington@comcast.net > > > > > > IETF MIB Doctor > > > > > >=20 > > > > >=20 > > > > > _______________________________________________ > > > > > Hubmib mailing list > > > > > Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib > > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > Hubmib mailing list > > > Hubmib@ietf.org > > > https://www1.ietf.org/mailman/listinfo/hubmib > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Hubmib mailing list > > Hubmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/hubmib > >=20 >=20 >=20 >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 14:04:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09287 for ; Mon, 13 Dec 2004 14:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdvJA-0004zx-10; Mon, 13 Dec 2004 13:52:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdvG5-00045H-Kr for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 13:49:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08110 for ; Mon, 13 Dec 2004 13:49:20 -0500 (EST) Received: from falcon.mrv.com ([66.43.110.200] helo=mailsrv.chats.int.mrv.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdvNw-00067t-OA for hubmib@ietf.org; Mon, 13 Dec 2004 13:57:29 -0500 Received: by mailsrv.chats.int.mrv.com with Internet Mail Service (5.5.2657.72) id ; Mon, 13 Dec 2004 10:49:01 -0800 Message-ID: <30C8EC18FA0B92458918317E864AABCE01CE2060@mailsrv.chats.int.mrv.com> From: Grant Schnebly To: "'ietfdbh@comcast.net'" , "'Romascanu, Dan (Dan)'" , "'Lior khermosh'" , "'Matt Squire'" , "'Chris Leak'" Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 10:47:52 -0800 Deferred-Delivery: Mon, 13 Dec 2004 10:49:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bb0e9e1ca9d18125bc841b2d8d77e24 Cc: hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org 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:ietfdbh@comcast.net] Sent: Monday, December 13, 2004 6:02 AM To: 'Romascanu, Dan (Dan)'; 'Lior khermosh'; 'Matt Squire'; 'Chris Leak' Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org 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: hubmib-bounces@ietf.org > [mailto:hubmib-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > Sent: Monday, December 13, 2004 4:38 AM > To: Lior khermosh; Matt Squire; ietfdbh@comcast.net; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > 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:lior.khermosh@passave.com] > > Sent: 13 December, 2004 8:53 AM > > To: 'Matt Squire'; Romascanu, Dan (Dan); > ietfdbh@comcast.net; 'Chris > > Leak' > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > > > > I will practice the same for the EPON DateAndTime objects. > > > > > > -----Original Message----- > > From: hubmib-bounces@ietf.org > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire > > Sent: Monday, December 13, 2004 4:00 AM > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > 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:dromasca@avaya.com] > > > Sent: Sunday, December 12, 2004 6:24 AM > > > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > 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: hubmib-bounces@ietf.org > > > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > > > Sent: 09 December, 2004 8:16 PM > > > > To: ietfdbh@comcast.net; Chris Leak > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > 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 > > > > > dbharrington@comcast.net > > > > > IETF MIB Doctor > > > > > > > > > > > > > _______________________________________________ > > > > Hubmib mailing list > > > > Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib > > > > > > > > > > > _______________________________________________ > > Hubmib mailing list > > Hubmib@ietf.org > > https://www1.ietf.org/mailman/listinfo/hubmib > > > > > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Mon Dec 13 14:44:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11447 for ; Mon, 13 Dec 2004 14:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cdw0E-0006av-5h; Mon, 13 Dec 2004 14:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdvxW-0005Kx-Jc for hubmib@megatron.ietf.org; Mon, 13 Dec 2004 14:34:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10867 for ; Mon, 13 Dec 2004 14:34:13 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cdw5O-00070b-4Z for hubmib@ietf.org; Mon, 13 Dec 2004 14:42:22 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBDJPOfX028090 for ; Mon, 13 Dec 2004 14:25:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBDJPGfX027928 for ; Mon, 13 Dec 2004 14:25:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Date: Mon, 13 Dec 2004 21:34:02 +0200 Message-ID: Thread-Topic: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC Thread-Index: AcTg4Ieydm51NyonQe2pIsqop/KjsQAFkjowAAjPehAAAKz2YAAG1uSQAAR9iUA= From: "Romascanu, Dan \(Dan\)" To: "John Messenger" , , "Lior khermosh" , "Matt Squire" , "Chris Leak" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Content-Transfer-Encoding: quoted-printable Cc: owner-stds-802-3-efm@listserv.ieee.org, hubmib@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable 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.=20 Regards, Dan > -----Original Message----- > From: John Messenger [mailto:jmessenger@advaoptical.com] > Sent: 13 December, 2004 7:27 PM > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Lior khermosh;=20 > Matt Squire; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > Hi, >=20 > As a vendor, I can say that most of our 802.3ah units will=20 > not (initially, anyhow) have a time-of-day clock. This has=20 > not proven an issue with the (few) users with whom I have=20 > discussed it. SNMPv1 has not gone away yet. Therefore, I=20 > don't believe we should standardise a solution which makes=20 > managing such a unit impossible. > -- John > =20 >=20 > -----Original Message----- > From: hubmib-bounces@ietf.org=20 > [mailto:hubmib-bounces@ietf.org]On Behalf > Of Romascanu, Dan (Dan) > Sent: 13 December 2004 14:11 > To: ietfdbh@comcast.net; Lior khermosh; Matt Squire; Chris Leak > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC >=20 >=20 > David has expressed in detail the feeling of dis-comfort that=20 > I feel with respect to my own proposal of defining two=20 > different objects. The issue is that the WG did not reach up=20 > to this point a consensus whether we prefer the 'good enough'=20 > or the 'better but hard to implement' object.=20 >=20 > Let me try it the other way. Vendors representatives seem to=20 > prefer the 'good enough' object with a SYNTAX of TimeStamp.=20 > Do we know if customers will be happy with it?=20 >=20 > Regards, >=20 > Dan >=20 >=20 >=20 > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: 13 December, 2004 4:02 PM > > To: Romascanu, Dan (Dan); 'Lior khermosh'; 'Matt Squire';=20 > 'Chris Leak' > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > >=20 > >=20 > > I would rather see one object, whether DateAndTime or sysUpTime > > syntax.=20 > >=20 > > The harder we make it for applications to use the=20 > informaton, the less > > likely applications will use the information. A major=20 > 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=20 > across devices; > > and having to calculate the timestamp monitoring an epoch=20 > start point > > and applying a delta, with the possibility of decreased=20 > accuracy makes > > it harder to trust the data. I think this makes it more likely > > applicatiosn will not use the data. > >=20 > > 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=20 > support SNMP or > > to suuport so few mib modules, the device is effectively=20 > unmanageable. > > Given the convergence of voice and data networking, it=20 > 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=20 > best standard > > rather than a standard designed for the least capable=20 > devices. If most > > vendors of EFM devices agree that they will not implement=20 > clocks, then > > I will gladly yield on this point. > >=20 > > dbh > >=20 > > > -----Original Message----- > > > From: hubmib-bounces@ietf.org=20 > > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) > > > Sent: Monday, December 13, 2004 4:38 AM > > > To: Lior khermosh; Matt Squire; ietfdbh@comcast.net; Chris Leak > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > >=20 > > > To make it clear again - this was a contributor and not a=20 > > > chair proposal. To be frank, I personally do not feel one=20 > > > hundred percent comfortable with redundant objects, which is=20 > > > a minus. If anybody feels stronger against this, please speak=20 > > > loudly. In the absence of vocal comments, we will go ahead=20 > > > with this method.=20 > > >=20 > > > Regards, > > >=20 > > > Dan > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Lior khermosh [mailto:lior.khermosh@passave.com] > > > > Sent: 13 December, 2004 8:53 AM > > > > To: 'Matt Squire'; Romascanu, Dan (Dan);=20 > > > ietfdbh@comcast.net; 'Chris=20 > > > > Leak' > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > >=20 > > > >=20 > > > > I will practice the same for the EPON DateAndTime objects. > > > >=20 > > > >=20 > > > > -----Original Message----- > > > > From: hubmib-bounces@ietf.org > > > > [mailto:hubmib-bounces@ietf.org] On Behalf Of Matt Squire > > > > Sent: Monday, December 13, 2004 4:00 AM > > > > To: Romascanu, Dan (Dan); ietfdbh@comcast.net; Chris Leak > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > >=20 > > > >=20 > > > > Sounds like a reasonable thing to me. =20 > > > >=20 > > > > - Matt > > > >=20 > > > > > -----Original Message----- > > > > > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > > > > > Sent: Sunday, December 12, 2004 6:24 AM > > > > > To: Matt Squire; ietfdbh@comcast.net; Chris Leak > > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > > >=20 > > > > >=20 > > > > > Speaking as a contributor. > > > > >=20 > > > > > I believe that David brings some valid points. I understand > > > > > however the other arguments about the possible lack of=20 > > > > > support form DateAndTime in some implementations. I suggest=20 > > > > > the following: > > > > >=20 > > > > > - add a TimeStamp object > > > > > - keep the current object, but change the SYNTAX to=20 > > > > > DateAndTimeOrZero, so that it returns zero if the managed=20 > > > > > entity does not have a clock capability > > > > >=20 > > > > > Later, when some implementation experience will be achieved, > > > > > we can deprecate one of the objects.=20 > > > > >=20 > > > > > Regards, > > > > >=20 > > > > > Dan > > > > >=20 > > > > >=20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: hubmib-bounces@ietf.org > > > > > > [mailto:hubmib-bounces@ietf.org]On Behalf Of Matt Squire > > > > > > Sent: 09 December, 2004 8:16 PM > > > > > > To: ietfdbh@comcast.net; Chris Leak > > > > > > Cc: owner-stds-802-3-efm@listserv.ieee.org; hubmib@ietf.org > > > > > > Subject: RE: [Hubmib] RE: EFM OAM MIB and the DateAndTime TC > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > Hi David - > > > > > >=20 > > > > > > I don't really argue with most of the arguments you give > > > > > > below - date/time is better if you have it. I=20 > guess the big=20 > > > > > > question is whether its more important for this application=20 > > > > > > to take steps to make things better when you have=20 > date/time,=20 > > > > > > or to make things better when you don't have date/time. =20 > > > > > > Either approach sacrifices something for the other=20 > guy. On=20 > > > > > > the one hand, we can take an approach that gives "ok"=20 > > > > > > information for everybody, or an approach that gives better=20 > > > > > > information when you have date/time and no information when=20 > > > > > > you don't. All of the other stuff (return 0s, excpetions,=20 > > > > > > errors, etc.) seems like noise. =20 > > > > > >=20 > > > > > > If the market was clear and there were a bunch of volume > > > > > > shipments then we could probably just look at the existing=20 > > > > > > market and make a determination. At this point, its just=20 > > > > > > guessing what kind of capabilities will exist in products=20 > > > > > > that implement 802.3ah OAM functionality. =20 > > > > > >=20 > > > > > > 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=20 > > > > > > the direction of supporting their application better. I'm=20 > > > > > > hoping to get some more opinions. =20 > > > > > >=20 > > > > > > - Matt > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > > 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=20 > > > > responses, a problem > > > >=20 > > > > > > > which existed in SNMPv1. The problem you cite only exists > > > > > if you use > > > > > > > error codes. You are limited to using error codes only=20 > > > > if you use=20 > > > > > > > SNMPv1. > > > > > > >=20 > > > > > > > 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=20 > > > > information is=20 > > > > > > > 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=20 > > > > recommended, and=20 > > > > > > > later versions of SNMP support exceptions, the problem you > > > > > > cite should > > > > > > > not be an issue. > > > > > > >=20 > > > > > > > 3) The application receiving a timestamp of zeroes=20 > > > has no more=20 > > > > > > > information than if it had received an exception. In both > > > > > cases, it > > > > > > > knows that the device that had the event does not support > > the=20 > > > > > > > date/time capability, and the event occurred sometime=20 > > > > prior to the > > > >=20 > > > > > > > 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. > > > > > > >=20 > > > > > > > 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=20 > > > > the local=20 > > > > > > > agent. > > > > > > >=20 > > > > > > > 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=20 > > > > occurred. The > > > >=20 > > > > > > > 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? > > > > > > >=20 > > > > > > > 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=20 > > > > better job of=20 > > > > > > > correlating events across multiple devices, which can be > > > > > > important for > > > > > > > troubleshooting. Correlating events properly can be=20 > > > > important for=20 > > > > > > > troubleshooting problems such as worms, viruses,=20 > > > > routing/switching > > > >=20 > > > > > > > updates, performance bottlenecks, etc. > > > > > > >=20 > > > > > > > 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=20 > > > timestamped event=20 > > > > > > > information is so inaccurate. > > > > > > >=20 > > > > > > > I question the wisdom of using a sysUpTime timestamp=20 > > > > rather than a > > > >=20 > > > > > > > date/time timestamp in this table. > > > > > > >=20 > > > > > > >=20 > > > > > > > David Harrington > > > > > > > dbharrington@comcast.net > > > > > > > IETF MIB Doctor > > > > > > >=20 > > > > > >=20 > > > > > > _______________________________________________ > > > > > > Hubmib mailing list > > > > > > Hubmib@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/hubmib > > > > > >=20 > > > > >=20 > > > >=20 > > > > _______________________________________________ > > > > Hubmib mailing list > > > > Hubmib@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/hubmib > > > >=20 > > > >=20 > > >=20 > > > _______________________________________________ > > > Hubmib mailing list > > > Hubmib@ietf.org > > > https://www1.ietf.org/mailman/listinfo/hubmib > > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib >=20 _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Sun Dec 19 09:25:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04052 for ; Sun, 19 Dec 2004 09:25:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg1xV-0007M3-4a; Sun, 19 Dec 2004 09:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cg1wg-0007En-CK for hubmib@megatron.ietf.org; Sun, 19 Dec 2004 09:22:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03782 for ; Sun, 19 Dec 2004 09:22:00 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cg25k-0002U1-5c for hubmib@ietf.org; Sun, 19 Dec 2004 09:31:24 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBJED3ja017926 for ; Sun, 19 Dec 2004 09:13:04 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBJED1ja017911 for ; Sun, 19 Dec 2004 09:13:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 19 Dec 2004 16:21:55 +0200 Message-ID: Thread-Topic: EPON MIB comments Thread-Index: AcTjqFC0IycPXHi+QGG7xAtwn/7d0gCLZB0Q From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: Glen Kramer Subject: [Hubmib] FW: EPON MIB comments X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Although these comments from one of the 802.3ae contributors came in = after the WG Last Call deadline, I suggest that we enter them as Last = Call comments and address them accordingly.=20 Regards, Dan -----Original Message----- From: Glen Kramer [mailto:glen.kramer@teknovus.com] Sent: 16 December, 2004 9:49 PM To: Romascanu, Dan (Dan) Subject: EPON MIB comments Dan, I finally read the EPON MIB document. Below are my comments. I am not = sure if it is too late to make use of these, or not. Plsease, feel free to = post these on the reflector. Regards, Glen =20 1. In tables in section 7, object names that are split across lines lost = a letter. 2. dot3MpcpMode object should be read-only as is its counterpart in = 802.3ah (aMPCPMode attribute). 3. dot3MpcpRoundTripTime should be defined for the OLT only, similarly = to its counterpart in 802.3ah (aMPCPRoundTripTime attribute). The ONUs are = not aware of the round-trip times to the OLT. 4. dot3MpcpOnTime and dot3MpcpOffTime. It is not clear from the = description that these objects refer to laser_on and laser_off times. Also, = according to the 802.3ah, these times are constant and fixed at 32 TQ. These objects = are not necessary. Correspondingly, 802.3ah did not find it necessary to specify such attributes in clause 30. =20 5. dot3MpcpRxNotSupportedMpcp. The description of this object does not = make sense. If a frame is not supported, it is not an MPCP frame. Conversely, there exist no unsupported MPCP frames. There is no matching attribute = in clause 30 in 802.3ah and this object should be removed from this draft = as well. 6. Not clear why dot3OmpEmulationSLDErrors is mandatory at the OLT but optional at the ONU. It is not optional per 802.3ah and is relevant for = both devices. (For comparison, the dot3OmpEmulationCRC8Errors is mandatory in = the OLT and ONUs). 7. dot3OmpEmulationBroadcastLLIDPlusOnuId. It is not clear what the = phrase "broadcast LLID plus ONU's LLID (frame reflected)" means. Should it = simply say "broadcast or unicast LLID"? Also, there is no relevant attribute = in clause 30 in 802.3ah. 8. dot3OmpEmulationNotBroadcastLLIDNotOnuId. This object is redundant, = as the dot3OmpEmulationBadLLID will count the same frames. I recommend = removing dot3OmpEmulationNotBroadcastLLIDNotOnuId from this draft. 9. The access to eponDeviceObjectReset object should be write-only. If device is being reset, it cannot generate "reset" response. When the = device can generate the response, it will be running already. Thus, the only possible response is "running". 10. The object eponDeviceObjectOamMode is not necessary. To get the OAM mode, the management agent would access OAM MIB. No need to duplicate objects in different MIBs. 11. eponDeviceObjectDeviceReadyMode object should be read-only. = Modifying device mode through the management may have unpredictable results (like taking down entire EPON). 12. eponDeviceObjectPowerDown - "Setting this variable to True(1) will = cause Device to be entered into Power down mode where no registration is allowed and only receiving data from the link.". This object does not = make sense. Setting it to True will cause the device lose the link (because = no transmission is allowed leading to MPCP timeout) and never register = again (because registration is not allowed). 13. eponDeviceObjectReportThreshold. The 802.3ah standard does not limit number of thresholds to be used. This object will only return the first threshold for each queue. What about the rest of thresholds? How to = read/set them? 14. eponDeviceRemoteMACAddressLLIDControl - "Indicates and controls the resetting of the LLID MAC address log. Setting this object to none(1) = has no action resetLog(2) empties the LLID MAC address log. All data is = deleted. Setting it to useDefaultReporting(3) returns all entries priorities to = their factory-default reporting. Reading this object always returns useDefaultReporting(3)." The description of this object seems to match some proprietary EPON = device. In the 802.3ah standard, there is no provision of whether to keep LLID = MAC address log. It is not clear, what does it mean "returns all entries priorities to their factory-default reporting", since there is no specification for either "entries" or "factory-default reporting". This object should be removed. 15. Objects eponDeviceStatTxFramesQueue[0-7], eponDeviceStatRxFramesQueue[0-7], and = eponDeviceStatDroppedFramesQueue[0-7] are not specific to EPON. These objects exist for other devices, such as bridge ports. There is no need to duplicate these objects here. Besides, neither 802.3ah nor 802.1D standards require exactly 8 queues to be implemented. I recommend removing these objects. 16. The following objects represent non-EPON-specific events and should = be moved to OAM MIB. =20 eponDeviceSampleMinimum=20 eponDeviceDyingGaspAlarmState eponDeviceDyingGaspAlarmEnabled eponDeviceCriticalEventState eponDeviceCriticalEventEnabled eponDeviceLocalLinkFaultAlarmState eponDeviceLocalLinkFaultAlarmEnabled eponDeviceTemperatureEventIndicationState eponDeviceTemperatureEventIndicationEnabled eponDevicePowerVoltageEventIndicationState eponDevicePowerVoltageEventIndicationEnabled eponDeviceGlobalEventState eponDeviceGlobalEventEnabled eponDeviceErroredSymbolPeriodEventState eponDeviceErroredSymbolPeriodEventEnabled eponDeviceErroredFrameEventState eponDeviceErroredFrameEventEnabled eponDeviceErroredFramePeriodEventState eponDeviceErroredFramePeriodEventEnabled eponDeviceErroredFrameSecondsSummaryEventState eponDeviceErroredFrameSecondsSummaryEventEnabled eponDeviceOrganizationSpecificEventState eponDeviceOrganizationSpecificEventEnabled eponDeviceEventControl _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-bounces@ietf.org Sat Dec 25 10:44:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29545 for ; Sat, 25 Dec 2004 10:44:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiE0D-00079n-An; Sat, 25 Dec 2004 10:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CiDpG-0005p6-VM for hubmib@megatron.ietf.org; Sat, 25 Dec 2004 10:27:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28652 for ; Sat, 25 Dec 2004 10:27:25 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CiDzZ-0004ig-KI for hubmib@ietf.org; Sat, 25 Dec 2004 10:38:06 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBPFIOja015688 for ; Sat, 25 Dec 2004 10:18:24 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id iBPFIMja015619 for ; Sat, 25 Dec 2004 10:18:22 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 25 Dec 2004 17:27:21 +0200 Message-ID: Thread-Topic: Re: Delivery Protection Thread-Index: AcTqljn0tZlnq+fIQT6434LLrG+NLgAAAAHh From: "Romascanu, Dan \(Dan\)" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Hubmib] Out of Office AutoReply: Re: Delivery Protection X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ethernet Interfaces an Hub MIB WG List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1834859052==" Sender: hubmib-bounces@ietf.org Errors-To: hubmib-bounces@ietf.org This is a multi-part message in MIME format. --===============1834859052== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4EA96.39FBF6EE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4EA96.39FBF6EE Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I am on vacation and will be back to the office on January 3rd, 2005. My = e-mail access will be very sparce until that date. For urgent issues you = may try to reach me at +972-54-5581118. Regards, Dan ------_=_NextPart_001_01C4EA96.39FBF6EE Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Out of Office AutoReply: <Possible SPAM> Re: Delivery = Protection

I am on vacation and will be back to the office on = January 3rd, 2005. My e-mail access will be very sparce until that date. = For urgent issues you may try to reach me at +972-54-5581118.

Regards,

Dan

------_=_NextPart_001_01C4EA96.39FBF6EE-- --===============1834859052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib --===============1834859052==--