From mailman-admin@ietf.org Sun Feb 1 09:18:38 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14701 for ; Sun, 1 Feb 2004 09:18:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnIQN-0002zo-7C for hubmib-archive@lists.ietf.org; Sun, 01 Feb 2004 09:18:11 -0500 Date: Sun, 01 Feb 2004 09:18:11 -0500 Message-ID: <20040201141811.1364.82675.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: hubmib-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk 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, hubmib-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 All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.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-admin@ietf.org Mon Feb 2 06:49:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05248 for ; Mon, 2 Feb 2004 06:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncZY-0007E5-7w; Mon, 02 Feb 2004 06:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncZ5-0007DH-9b for hubmib@optimus.ietf.org; Mon, 02 Feb 2004 06:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05219 for ; Mon, 2 Feb 2004 06:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AncZ1-0002nw-00 for hubmib@ietf.org; Mon, 02 Feb 2004 06:48:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AncY6-0002ix-00 for hubmib@ietf.org; Mon, 02 Feb 2004 06:47:31 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AncXN-0002eG-00 for hubmib@ietf.org; Mon, 02 Feb 2004 06:46:45 -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 i12Bh6fi014980 for ; Mon, 2 Feb 2004 06:43:06 -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 i12Bh3fi014955 for ; Mon, 2 Feb 2004 06:43:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E982.37676E66" Date: Mon, 2 Feb 2004 13:46:38 +0200 Message-ID: Thread-Topic: Agenda for the Seoul meeting Thread-Index: AcPpgjd5P2zuRWhuSZybaVJ1C0+KXQ== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Agenda for the Seoul meeting Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E982.37676E66 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The Ethernet Interfaces and Hub MIB WG will be meeting in Seoul. The = main items on the agenda will be the three Internet-Drafts for EFM: - Generic EFM MIB - = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-m= ib-00.txt (just submitted by Matt Squire, wait for one day or two until = it shows up on the repository) - EPON MIB - = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-e= pon-mib-00.txt - EFM Copper MIB - = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-mib-00.txt Each of the MIB document editors will have roughly 30 minutes allocated = to present and discuss the issues related to his document. Comments are = required to be sent on the WG e-mail list from now until the meeting = date in Seoul. Are there other work items that need to be discussed? One that comes to = my mind is related to the MAU MIB revision, required by the EFM work. = Anything else? Please share with me and the WG list any other agenda = items you think are worth being discussed. Regards, Dan ------_=_NextPart_001_01C3E982.37676E66 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Agenda for the Seoul meeting

The Ethernet Interfaces and = Hub MIB WG will be meeting in Seoul. The main items on the agenda will = be the three Internet-Drafts for EFM:

- Generic EFM MIB - http://www.ietf.cnri.reston.va.us/internet-drafts/draf= t-ietf-hubmib-efm-mib-00.txt (just submitted by Matt Squire, wait = for one day or two until it shows up on the repository)

- EPON MIB - http://www.ietf.cnri.reston.va.us/internet-drafts= /draft-ietf-hubmib-efm-epon-mib-00.txt

- EFM Copper MIB - http://www.ietf.cnri.reston.va.us/internet-drafts/d= raft-ietf-hubmib-efm-cu-mib-00.txt

Each of the MIB document = editors will have roughly 30 minutes allocated to present and discuss = the issues related to his document. Comments are required to be sent on = the WG e-mail list from now until the meeting date in Seoul.

Are there other work items = that need to be discussed? One that comes to my mind is related to the = MAU MIB revision, required by the EFM work. Anything else? Please share = with me and the WG list any other agenda items you think are worth being = discussed.

Regards,

Dan

------_=_NextPart_001_01C3E982.37676E66-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 2 07:36:40 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05250 for ; Mon, 2 Feb 2004 06:49:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncZY-0007ET-Ui for hubmib-archive@odin.ietf.org; Mon, 02 Feb 2004 06:49:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Bn0B0027798 for hubmib-archive@odin.ietf.org; Mon, 2 Feb 2004 06:49:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncZY-0007E5-7w; Mon, 02 Feb 2004 06:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AncZ5-0007DH-9b for hubmib@optimus.ietf.org; Mon, 02 Feb 2004 06:48:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05219 for ; Mon, 2 Feb 2004 06:48:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AncZ1-0002nw-00 for hubmib@ietf.org; Mon, 02 Feb 2004 06:48:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AncY6-0002ix-00 for hubmib@ietf.org; Mon, 02 Feb 2004 06:47:31 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AncXN-0002eG-00 for hubmib@ietf.org; Mon, 02 Feb 2004 06:46:45 -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 i12Bh6fi014980 for ; Mon, 2 Feb 2004 06:43:06 -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 i12Bh3fi014955 for ; Mon, 2 Feb 2004 06:43:04 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3E982.37676E66" Date: Mon, 2 Feb 2004 13:46:38 +0200 Message-ID: Thread-Topic: Agenda for the Seoul meeting Thread-Index: AcPpgjd5P2zuRWhuSZybaVJ1C0+KXQ== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Agenda for the Seoul meeting Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3E982.37676E66 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable The Ethernet Interfaces and Hub MIB WG will be meeting in Seoul. The = main items on the agenda will be the three Internet-Drafts for EFM: - Generic EFM MIB - = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-m= ib-00.txt (just submitted by Matt Squire, wait for one day or two until = it shows up on the repository) - EPON MIB - = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-e= pon-mib-00.txt - EFM Copper MIB - = http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-hubmib-efm-c= u-mib-00.txt Each of the MIB document editors will have roughly 30 minutes allocated = to present and discuss the issues related to his document. Comments are = required to be sent on the WG e-mail list from now until the meeting = date in Seoul. Are there other work items that need to be discussed? One that comes to = my mind is related to the MAU MIB revision, required by the EFM work. = Anything else? Please share with me and the WG list any other agenda = items you think are worth being discussed. Regards, Dan ------_=_NextPart_001_01C3E982.37676E66 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Agenda for the Seoul meeting

The Ethernet Interfaces and = Hub MIB WG will be meeting in Seoul. The main items on the agenda will = be the three Internet-Drafts for EFM:

- Generic EFM MIB - http://www.ietf.cnri.reston.va.us/internet-drafts/draf= t-ietf-hubmib-efm-mib-00.txt (just submitted by Matt Squire, wait = for one day or two until it shows up on the repository)

- EPON MIB - http://www.ietf.cnri.reston.va.us/internet-drafts= /draft-ietf-hubmib-efm-epon-mib-00.txt

- EFM Copper MIB - http://www.ietf.cnri.reston.va.us/internet-drafts/d= raft-ietf-hubmib-efm-cu-mib-00.txt

Each of the MIB document = editors will have roughly 30 minutes allocated to present and discuss = the issues related to his document. Comments are required to be sent on = the WG e-mail list from now until the meeting date in Seoul.

Are there other work items = that need to be discussed? One that comes to my mind is related to the = MAU MIB revision, required by the EFM work. Anything else? Please share = with me and the WG list any other agenda items you think are worth being = discussed.

Regards,

Dan

------_=_NextPart_001_01C3E982.37676E66-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 2 15:57:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08803 for ; Mon, 2 Feb 2004 15:57:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl7t-0006th-Eo; Mon, 02 Feb 2004 15:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl6z-0006bW-39 for hubmib@optimus.ietf.org; Mon, 02 Feb 2004 15:56:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08532; Mon, 2 Feb 2004 15:56:02 -0500 (EST) Message-Id: <200402022056.PAA08532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: hubmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 02 Feb 2004 15:56:02 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-efm-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ethernet Interfaces and Hub MIB Working Group of the IETF. Title : Ethernet in the First Mile (EFM) Common MIB Author(s) : M. Squire Filename : draft-ietf-hubmib-efm-mib-00.txt Pages : 28 Date : 2004-2-2 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB for the capability to manage Ethernet-in-the-First-Mile (EFM) devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-efm-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-efm-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-2150202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-efm-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-efm-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 2 15:57:32 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08804 for ; Mon, 2 Feb 2004 15:57:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl7x-0006vd-06 for hubmib-archive@odin.ietf.org; Mon, 02 Feb 2004 15:57:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Kv4ep026619 for hubmib-archive@odin.ietf.org; Mon, 2 Feb 2004 15:57:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl7t-0006th-Eo; Mon, 02 Feb 2004 15:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anl6z-0006bW-39 for hubmib@optimus.ietf.org; Mon, 02 Feb 2004 15:56:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08532; Mon, 2 Feb 2004 15:56:02 -0500 (EST) Message-Id: <200402022056.PAA08532@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: hubmib@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 02 Feb 2004 15:56:02 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-efm-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ethernet Interfaces and Hub MIB Working Group of the IETF. Title : Ethernet in the First Mile (EFM) Common MIB Author(s) : M. Squire Filename : draft-ietf-hubmib-efm-mib-00.txt Pages : 28 Date : 2004-2-2 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This document proposes an extension to the Ethernet-like Interfaces MIB for the capability to manage Ethernet-in-the-First-Mile (EFM) devices. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-efm-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-hubmib-efm-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-hubmib-efm-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-2150202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-efm-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-efm-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-2150202.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 9 12:42:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00086 for ; Mon, 9 Feb 2004 12:42:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFPz-0001ob-Qq; Mon, 09 Feb 2004 12:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFHU-0000gM-QN for hubmib@optimus.ietf.org; Mon, 09 Feb 2004 12:33:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29648 for ; Mon, 9 Feb 2004 12:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFHT-0004eJ-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFGY-0004Zo-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:32:14 -0500 Received: from ns.cnri.reston.va.us ([132.151.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFFy-0004VX-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:31:38 -0500 Received: from cnri-7-43.cnri.reston.va.us ([132.151.7.43] helo=marcia.cnri.reston.va.us) by ns.cnri.reston.va.us with esmtp (Exim 4.20) id 1AqFFq-0004vS-Jl; Mon, 09 Feb 2004 12:31:31 -0500 Message-Id: <5.1.0.14.2.20040209122944.01fe99f0@odin> X-Sender: mbeaulie@odin X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Feb 2004 12:31:24 -0500 To: "Romascanu, Dan (Dan)" From: Marcia Beaulieu Cc: , , david.kessens@nokia.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Hubmib] 59th IETF - HUBMIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is to confirm that HUBMIB is currently scheduled on Wednesday, March 3 at 0900-1130 Other groups scheduled at that time are: lemonade, icar, eap, multi6, enum, mmusic =================================================================== If you have not already done so, please submit the agenda for your working group meeting by Tuesday, February 24 at 12:00noon ET to agenda@ietf.org. You will find the blue sheet (roster) and white sheet (Proceedings Submission Form) in a file folder on the head table in the room your working group will meet. Please pass the blue sheet around the room at the beginning of the session (a clipboard and pen will be provided for your convenience) to record attendance. Please turn the blue sheet and completed white sheet in at the IETF Registration desk following the conclusion of your working group session. The deadline for submission of minutes and presentation slides for inclusion in the proceedings of the 59th IETF Meeting is Friday, April 2, 2004 at 17:00 ET. Please send all materials to proceedings@ietf.org by that time. Any materials received after that time will not be included. Please note that submission of minutes is mandatory, while submission of presentation slides is optional. Minutes may be submitted in plain text (Unix/Mac/Dos) or in simple HTML with no style sheets. Minutes submitted in plain text will be reformatted by the Secretariat. Therefore, if you are concerned about preserving the formatting of your minutes, then please submit them in HTML. Presentation slides may be submitted in any of the following formats: .TXT Plain text (Unix/Mac/Dos) .DOC MS Word Document (v95 - 2000) .PDF Adobe Portable Document Format (Acrobat 3, 4, 5, 6) .PPT MS PowerPoint (v95 - 2000) When submitting slides for multiple presentations, please indicate the order that the presentations should appear in the proceedings. Input to the proceedings, which has been processed to conform with established proceedings standards (as described above), will be posted within 48 hours after receipt at: www.ietf.org/proceedings/04mar/index.html . Please review your materials on line and send any corrections to: proceedings@ietf.org . The deadline for submitting corrections is Friday, April 16, 2004 at 17:00 ET. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 9 12:42:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00134 for ; Mon, 9 Feb 2004 12:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFQ0-0001ol-2j; Mon, 09 Feb 2004 12:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFPa-0001oE-Ie for hubmib@optimus.ietf.org; Mon, 09 Feb 2004 12:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00057 for ; Mon, 9 Feb 2004 12:41:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFPY-0005TC-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:41:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFOe-0005Lw-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:40:36 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AqFNr-0005FX-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:39:47 -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 i19Ha4fi019186 for ; Mon, 9 Feb 2004 12:36:05 -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 i19HZxfi019003 for ; Mon, 9 Feb 2004 12:36:01 -0500 (EST) 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: Mon, 9 Feb 2004 19:39:40 +0200 Message-ID: Thread-Topic: 59th IETF - HUBMIB Thread-Index: AcPvMqHHh6jK2VcpThy6wPPXbQoHDwAAIlGg From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: 59th IETF - HUBMIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Proposed Agenda - Please comment 1. Agenda bashing, minutes, taker, etc. (Dan) - 5 minutes 2. WG status (Dan) - 10 minutes 3. Generic EFM MIB Issues (Matt) - 30 minutes 4. EPON MIB Issues (Lior) - 30 minutes 5. EFM Cu Issues (Eduard) - 30 minutes 6. Open Discussion (or early lunch) - 45 minutes If there are other items for the agenda, please contact me. Regards, Dan -----Original Message----- From: Marcia Beaulieu [mailto:mbeaulie@foretec.com] Sent: 09 February, 2004 7:31 PM To: Romascanu, Dan (Dan) Cc: bwijnen@lucent.com; hubmib@ietf.org; david.kessens@nokia.com Subject: 59th IETF - HUBMIB This is to confirm that HUBMIB is currently scheduled on Wednesday, = March 3 at 0900-1130 Other groups scheduled at that time are: lemonade, icar, eap, multi6, enum, mmusic =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If you have not already done so, please submit the agenda for your = working=20 group meeting by Tuesday, February 24 at 12:00noon ET to = agenda@ietf.org. You will find the blue sheet (roster) and white sheet (Proceedings=20 Submission Form) in a file folder on the head table in the room your=20 working group will meet. Please pass the blue sheet around the room at = the=20 beginning of the session (a clipboard and pen will be provided for your=20 convenience) to record attendance. Please turn the blue sheet and=20 completed white sheet in at the IETF Registration desk following the=20 conclusion of your working group session. The deadline for submission of minutes and presentation slides for=20 inclusion in the proceedings of the 59th IETF Meeting is Friday, April = 2,=20 2004 at 17:00 ET. Please send all materials to proceedings@ietf.org by = that=20 time. Any materials received after that time will not be included. = Please=20 note that submission of minutes is mandatory, while submission of=20 presentation slides is optional. Minutes may be submitted in plain text (Unix/Mac/Dos) or in simple HTML=20 with no style sheets. Minutes submitted in plain text will be = reformatted=20 by the Secretariat. Therefore, if you are concerned about preserving the = formatting of your minutes, then please submit them in HTML. Presentation slides may be submitted in any of the following formats: .TXT Plain text (Unix/Mac/Dos) .DOC MS Word Document (v95 - 2000) .PDF Adobe Portable Document Format (Acrobat 3, 4, 5, 6) .PPT MS PowerPoint (v95 - 2000) When submitting slides for multiple presentations, please indicate the=20 order that the presentations should appear in the proceedings. Input to the proceedings, which has been processed to conform with=20 established proceedings standards (as described above), will be posted=20 within 48 hours after receipt at: = www.ietf.org/proceedings/04mar/index.html=20 . Please review your materials on line and send any corrections to:=20 proceedings@ietf.org . The deadline for submitting corrections is = Friday,=20 April 16, 2004 at 17:00 ET. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 9 13:27:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00091 for ; Mon, 9 Feb 2004 12:42:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFQ0-0001pX-Ad for hubmib-archive@odin.ietf.org; Mon, 09 Feb 2004 12:42:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Hg0Yf007002 for hubmib-archive@odin.ietf.org; Mon, 9 Feb 2004 12:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFPz-0001ob-Qq; Mon, 09 Feb 2004 12:41:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFHU-0000gM-QN for hubmib@optimus.ietf.org; Mon, 09 Feb 2004 12:33:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29648 for ; Mon, 9 Feb 2004 12:33:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFHT-0004eJ-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:33:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFGY-0004Zo-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:32:14 -0500 Received: from ns.cnri.reston.va.us ([132.151.1.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFFy-0004VX-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:31:38 -0500 Received: from cnri-7-43.cnri.reston.va.us ([132.151.7.43] helo=marcia.cnri.reston.va.us) by ns.cnri.reston.va.us with esmtp (Exim 4.20) id 1AqFFq-0004vS-Jl; Mon, 09 Feb 2004 12:31:31 -0500 Message-Id: <5.1.0.14.2.20040209122944.01fe99f0@odin> X-Sender: mbeaulie@odin X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 09 Feb 2004 12:31:24 -0500 To: "Romascanu, Dan (Dan)" From: Marcia Beaulieu Cc: , , david.kessens@nokia.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Hubmib] 59th IETF - HUBMIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is to confirm that HUBMIB is currently scheduled on Wednesday, March 3 at 0900-1130 Other groups scheduled at that time are: lemonade, icar, eap, multi6, enum, mmusic =================================================================== If you have not already done so, please submit the agenda for your working group meeting by Tuesday, February 24 at 12:00noon ET to agenda@ietf.org. You will find the blue sheet (roster) and white sheet (Proceedings Submission Form) in a file folder on the head table in the room your working group will meet. Please pass the blue sheet around the room at the beginning of the session (a clipboard and pen will be provided for your convenience) to record attendance. Please turn the blue sheet and completed white sheet in at the IETF Registration desk following the conclusion of your working group session. The deadline for submission of minutes and presentation slides for inclusion in the proceedings of the 59th IETF Meeting is Friday, April 2, 2004 at 17:00 ET. Please send all materials to proceedings@ietf.org by that time. Any materials received after that time will not be included. Please note that submission of minutes is mandatory, while submission of presentation slides is optional. Minutes may be submitted in plain text (Unix/Mac/Dos) or in simple HTML with no style sheets. Minutes submitted in plain text will be reformatted by the Secretariat. Therefore, if you are concerned about preserving the formatting of your minutes, then please submit them in HTML. Presentation slides may be submitted in any of the following formats: .TXT Plain text (Unix/Mac/Dos) .DOC MS Word Document (v95 - 2000) .PDF Adobe Portable Document Format (Acrobat 3, 4, 5, 6) .PPT MS PowerPoint (v95 - 2000) When submitting slides for multiple presentations, please indicate the order that the presentations should appear in the proceedings. Input to the proceedings, which has been processed to conform with established proceedings standards (as described above), will be posted within 48 hours after receipt at: www.ietf.org/proceedings/04mar/index.html . Please review your materials on line and send any corrections to: proceedings@ietf.org . The deadline for submitting corrections is Friday, April 16, 2004 at 17:00 ET. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 9 13:27:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00088 for ; Mon, 9 Feb 2004 12:42:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFQ0-0001pW-AR for hubmib-archive@odin.ietf.org; Mon, 09 Feb 2004 12:42:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Hg0L0007000 for hubmib-archive@odin.ietf.org; Mon, 9 Feb 2004 12:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFQ0-0001ol-2j; Mon, 09 Feb 2004 12:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqFPa-0001oE-Ie for hubmib@optimus.ietf.org; Mon, 09 Feb 2004 12:41:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00057 for ; Mon, 9 Feb 2004 12:41:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqFPY-0005TC-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:41:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqFOe-0005Lw-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:40:36 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AqFNr-0005FX-00 for hubmib@ietf.org; Mon, 09 Feb 2004 12:39:47 -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 i19Ha4fi019186 for ; Mon, 9 Feb 2004 12:36:05 -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 i19HZxfi019003 for ; Mon, 9 Feb 2004 12:36:01 -0500 (EST) 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: Mon, 9 Feb 2004 19:39:40 +0200 Message-ID: Thread-Topic: 59th IETF - HUBMIB Thread-Index: AcPvMqHHh6jK2VcpThy6wPPXbQoHDwAAIlGg From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: 59th IETF - HUBMIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Proposed Agenda - Please comment 1. Agenda bashing, minutes, taker, etc. (Dan) - 5 minutes 2. WG status (Dan) - 10 minutes 3. Generic EFM MIB Issues (Matt) - 30 minutes 4. EPON MIB Issues (Lior) - 30 minutes 5. EFM Cu Issues (Eduard) - 30 minutes 6. Open Discussion (or early lunch) - 45 minutes If there are other items for the agenda, please contact me. Regards, Dan -----Original Message----- From: Marcia Beaulieu [mailto:mbeaulie@foretec.com] Sent: 09 February, 2004 7:31 PM To: Romascanu, Dan (Dan) Cc: bwijnen@lucent.com; hubmib@ietf.org; david.kessens@nokia.com Subject: 59th IETF - HUBMIB This is to confirm that HUBMIB is currently scheduled on Wednesday, = March 3 at 0900-1130 Other groups scheduled at that time are: lemonade, icar, eap, multi6, enum, mmusic =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D If you have not already done so, please submit the agenda for your = working=20 group meeting by Tuesday, February 24 at 12:00noon ET to = agenda@ietf.org. You will find the blue sheet (roster) and white sheet (Proceedings=20 Submission Form) in a file folder on the head table in the room your=20 working group will meet. Please pass the blue sheet around the room at = the=20 beginning of the session (a clipboard and pen will be provided for your=20 convenience) to record attendance. Please turn the blue sheet and=20 completed white sheet in at the IETF Registration desk following the=20 conclusion of your working group session. The deadline for submission of minutes and presentation slides for=20 inclusion in the proceedings of the 59th IETF Meeting is Friday, April = 2,=20 2004 at 17:00 ET. Please send all materials to proceedings@ietf.org by = that=20 time. Any materials received after that time will not be included. = Please=20 note that submission of minutes is mandatory, while submission of=20 presentation slides is optional. Minutes may be submitted in plain text (Unix/Mac/Dos) or in simple HTML=20 with no style sheets. Minutes submitted in plain text will be = reformatted=20 by the Secretariat. Therefore, if you are concerned about preserving the = formatting of your minutes, then please submit them in HTML. Presentation slides may be submitted in any of the following formats: .TXT Plain text (Unix/Mac/Dos) .DOC MS Word Document (v95 - 2000) .PDF Adobe Portable Document Format (Acrobat 3, 4, 5, 6) .PPT MS PowerPoint (v95 - 2000) When submitting slides for multiple presentations, please indicate the=20 order that the presentations should appear in the proceedings. Input to the proceedings, which has been processed to conform with=20 established proceedings standards (as described above), will be posted=20 within 48 hours after receipt at: = www.ietf.org/proceedings/04mar/index.html=20 . Please review your materials on line and send any corrections to:=20 proceedings@ietf.org . The deadline for submitting corrections is = Friday,=20 April 16, 2004 at 17:00 ET. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Fri Feb 13 10:39:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15381 for ; Fri, 13 Feb 2004 10:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfPB-0005He-JL for hubmib-archive@odin.ietf.org; Fri, 13 Feb 2004 10:39:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFd1Dl020295 for hubmib-archive@odin.ietf.org; Fri, 13 Feb 2004 10:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfPA-0005H7-Oh; Fri, 13 Feb 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfOR-0005CS-DI for hubmib@optimus.ietf.org; Fri, 13 Feb 2004 10:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15353 for ; Fri, 13 Feb 2004 10:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfOO-0003Pq-00 for hubmib@ietf.org; Fri, 13 Feb 2004 10:38:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfNl-0003L3-00 for hubmib@ietf.org; Fri, 13 Feb 2004 10:37:34 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ArfMk-0003Dx-00 for hubmib@ietf.org; Fri, 13 Feb 2004 10:36:30 -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 i1DFZcdZ022310 for ; Fri, 13 Feb 2004 10:35:38 -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 i1DFZZdZ022255 for ; Fri, 13 Feb 2004 10:35:36 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F247.24DCE52E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 13 Feb 2004 17:36:27 +0200 Message-ID: Thread-Topic: Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1g== From: "Romascanu, Dan (Dan)" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Canceling the WG Meeting in Seoul? Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F247.24DCE52E Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F247.24DCE52E Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?

I received in the last couple = of days notifications from the editors of two of the three documents = (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for = the WG meeting. As it looks like they cannot get somebody else to = properly represent their work in the meeting, I am inclined to suggest = that our meeting in Seoul be cancelled. This is not yet a final = announcement, please respond whether you agree or not with canceling the = meeting. If you think that we should meet, please let me know how you = suggest to cover the agenda items.

I frankly am concerned with = the low level of technical traffic on the list lately. With the first = round of WG drafts submitted, I was expecting more feedback and public = review. I know that the IEEE drafts are stabilizing as result of the = sponsor ballot comments, and I know that there are quite a lot of = consistent changes the management sections, specifically in Clause 30 = affecting this work. The discussions on MIB-related issues must be = conducted on the hubmib WG list. Please remember that in the IETF work = the WG list is the main media for work and communication, ensuring the = fair and accessible change of views specific to the IETF process. FYI, = if you have concerns about spam traffic - this list is manually = administered, and as far as I know no spam traffic made it to the list = in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F247.24DCE52E-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Feb 13 11:28:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15379 for ; Fri, 13 Feb 2004 10:39:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfPA-0005H7-Oh; Fri, 13 Feb 2004 10:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfOR-0005CS-DI for hubmib@optimus.ietf.org; Fri, 13 Feb 2004 10:38:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15353 for ; Fri, 13 Feb 2004 10:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfOO-0003Pq-00 for hubmib@ietf.org; Fri, 13 Feb 2004 10:38:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfNl-0003L3-00 for hubmib@ietf.org; Fri, 13 Feb 2004 10:37:34 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1ArfMk-0003Dx-00 for hubmib@ietf.org; Fri, 13 Feb 2004 10:36:30 -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 i1DFZcdZ022310 for ; Fri, 13 Feb 2004 10:35:38 -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 i1DFZZdZ022255 for ; Fri, 13 Feb 2004 10:35:36 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F247.24DCE52E" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Fri, 13 Feb 2004 17:36:27 +0200 Message-ID: Thread-Topic: Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1g== From: "Romascanu, Dan (Dan)" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Canceling the WG Meeting in Seoul? Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F247.24DCE52E Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F247.24DCE52E Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?

I received in the last couple = of days notifications from the editors of two of the three documents = (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for = the WG meeting. As it looks like they cannot get somebody else to = properly represent their work in the meeting, I am inclined to suggest = that our meeting in Seoul be cancelled. This is not yet a final = announcement, please respond whether you agree or not with canceling the = meeting. If you think that we should meet, please let me know how you = suggest to cover the agenda items.

I frankly am concerned with = the low level of technical traffic on the list lately. With the first = round of WG drafts submitted, I was expecting more feedback and public = review. I know that the IEEE drafts are stabilizing as result of the = sponsor ballot comments, and I know that there are quite a lot of = consistent changes the management sections, specifically in Clause 30 = affecting this work. The discussions on MIB-related issues must be = conducted on the hubmib WG list. Please remember that in the IETF work = the WG list is the main media for work and communication, ensuring the = fair and accessible change of views specific to the IETF process. FYI, = if you have concerns about spam traffic - this list is manually = administered, and as far as I know no spam traffic made it to the list = in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F247.24DCE52E-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Feb 13 14:48:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28640 for ; Fri, 13 Feb 2004 14:48:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjI8-0003Mn-5j; Fri, 13 Feb 2004 14:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjHK-00039F-IU for hubmib@optimus.ietf.org; Fri, 13 Feb 2004 14:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28609 for ; Fri, 13 Feb 2004 14:47:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjHH-00035u-00 for hubmib@ietf.org; Fri, 13 Feb 2004 14:47:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjGK-00031j-00 for hubmib@ietf.org; Fri, 13 Feb 2004 14:46:09 -0500 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1ArjFS-0002yN-00 for hubmib@ietf.org; Fri, 13 Feb 2004 14:45:14 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i1DJBKaj029498 for ; Fri, 13 Feb 2004 14:11:20 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 13 Feb 2004 14:45:13 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 13 Feb 2004 14:45:13 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 14:45:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F269.E5149343" Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Date: Fri, 13 Feb 2004 14:45:12 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA015FF160@NHROCMBX1.ets.enterasys.com> Thread-Topic: [Hubmib] Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gAIebVQ From: "Harrington, David" To: "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 13 Feb 2004 19:45:12.0999 (UTC) FILETIME=[E55BC370:01C3F269] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:64.8790 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F269.E5149343 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, =20 Just a comment. At the hubmib interim meeting coresident at the Vancouver IEEE meeting, you seemed pretty insistent that the discussion be brought into the IETF meeting, and not just done by the editors at interim meetings coexistent with IEEE meetings. If the session will be cancelled in Seoul, how will you proceed regarding future interim meetings? =20 if you are getting more involvement from IEEE personnel than IETF personnel, maybe the mib work should be moved into the IEEE and the Hubmib WG closed? As you know, that is the emerging approach being taken for the Bridgemib WG mibs. =20 Just a thought, dbh _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? =09 =09 I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years. Regards, Dan =09 =09 ------_=_NextPart_001_01C3F269.E5149343 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at the = Vancouver=20 IEEE meeting, you seemed pretty insistent that the discussion be brought = into=20 the IETF meeting, and not just done by the editors at interim meetings=20 coexistent with IEEE meetings. If the session will be cancelled in = Seoul, how=20 will you proceed regarding future interim meetings?
 
if you are getting more involvement from IEEE personnel than = IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG=20 closed? As you know, that is the emerging approach being taken for = the=20 Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, 2004 = 10:36=20 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last couple = of days=20 notifications from the editors of two of the three documents (generic = EFM MIB,=20 and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. = As it=20 looks like they cannot get somebody else to properly represent their = work in=20 the meeting, I am inclined to suggest that our meeting in Seoul be = cancelled.=20 This is not yet a final announcement, please respond whether you agree = or not=20 with canceling the meeting. If you think that we should meet, please = let me=20 know how you suggest to cover the agenda items.

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot comments, = and I=20 know that there are quite a lot of consistent changes the management = sections,=20 specifically in Clause 30 affecting this work. The discussions on = MIB-related=20 issues must be conducted on the hubmib WG list. Please remember that = in the=20 IETF work the WG list is the main media for work and communication, = ensuring=20 the fair and accessible change of views specific to the IETF process. = FYI, if=20 you have concerns about spam traffic - this list is manually = administered, and=20 as far as I know no spam traffic made it to the list in the last few=20 years.

Regards,

Dan

------_=_NextPart_001_01C3F269.E5149343-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Fri Feb 13 15:33:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28641 for ; Fri, 13 Feb 2004 14:48:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjI8-0003NH-FL for hubmib-archive@odin.ietf.org; Fri, 13 Feb 2004 14:48:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DJm0vF012952 for hubmib-archive@odin.ietf.org; Fri, 13 Feb 2004 14:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjI8-0003Mn-5j; Fri, 13 Feb 2004 14:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArjHK-00039F-IU for hubmib@optimus.ietf.org; Fri, 13 Feb 2004 14:47:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28609 for ; Fri, 13 Feb 2004 14:47:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArjHH-00035u-00 for hubmib@ietf.org; Fri, 13 Feb 2004 14:47:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArjGK-00031j-00 for hubmib@ietf.org; Fri, 13 Feb 2004 14:46:09 -0500 Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx with esmtp (Exim 4.12) id 1ArjFS-0002yN-00 for hubmib@ietf.org; Fri, 13 Feb 2004 14:45:14 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id i1DJBKaj029498 for ; Fri, 13 Feb 2004 14:11:20 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 13 Feb 2004 14:45:13 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 13 Feb 2004 14:45:13 -0500 Received: from nhrocmbx1 ([134.141.79.104]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 13 Feb 2004 14:45:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F269.E5149343" Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Date: Fri, 13 Feb 2004 14:45:12 -0500 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA015FF160@NHROCMBX1.ets.enterasys.com> Thread-Topic: [Hubmib] Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gAIebVQ From: "Harrington, David" To: "Romascanu, Dan (Dan)" , X-OriginalArrivalTime: 13 Feb 2004 19:45:12.0999 (UTC) FILETIME=[E55BC370:01C3F269] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:83.3688 M:99.5542 P:95.9108 R:95.9108 S:64.8790 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F269.E5149343 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dan, =20 Just a comment. At the hubmib interim meeting coresident at the Vancouver IEEE meeting, you seemed pretty insistent that the discussion be brought into the IETF meeting, and not just done by the editors at interim meetings coexistent with IEEE meetings. If the session will be cancelled in Seoul, how will you proceed regarding future interim meetings? =20 if you are getting more involvement from IEEE personnel than IETF personnel, maybe the mib work should be moved into the IEEE and the Hubmib WG closed? As you know, that is the emerging approach being taken for the Bridgemib WG mibs. =20 Just a thought, dbh _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? =09 =09 I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years. Regards, Dan =09 =09 ------_=_NextPart_001_01C3F269.E5149343 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at the = Vancouver=20 IEEE meeting, you seemed pretty insistent that the discussion be brought = into=20 the IETF meeting, and not just done by the editors at interim meetings=20 coexistent with IEEE meetings. If the session will be cancelled in = Seoul, how=20 will you proceed regarding future interim meetings?
 
if you are getting more involvement from IEEE personnel than = IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG=20 closed? As you know, that is the emerging approach being taken for = the=20 Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, 2004 = 10:36=20 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last couple = of days=20 notifications from the editors of two of the three documents (generic = EFM MIB,=20 and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. = As it=20 looks like they cannot get somebody else to properly represent their = work in=20 the meeting, I am inclined to suggest that our meeting in Seoul be = cancelled.=20 This is not yet a final announcement, please respond whether you agree = or not=20 with canceling the meeting. If you think that we should meet, please = let me=20 know how you suggest to cover the agenda items.

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot comments, = and I=20 know that there are quite a lot of consistent changes the management = sections,=20 specifically in Clause 30 affecting this work. The discussions on = MIB-related=20 issues must be conducted on the hubmib WG list. Please remember that = in the=20 IETF work the WG list is the main media for work and communication, = ensuring=20 the fair and accessible change of views specific to the IETF process. = FYI, if=20 you have concerns about spam traffic - this list is manually = administered, and=20 as far as I know no spam traffic made it to the list in the last few=20 years.

Regards,

Dan

------_=_NextPart_001_01C3F269.E5149343-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Feb 15 02:14:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26015 for ; Sun, 15 Feb 2004 02:14:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGTc-00051p-Ds; Sun, 15 Feb 2004 02:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGSu-0004n9-3q for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 02:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24856 for ; Sun, 15 Feb 2004 02:13:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGSq-0005my-00 for hubmib@ietf.org; Sun, 15 Feb 2004 02:13:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGRy-0005kL-00 for hubmib@ietf.org; Sun, 15 Feb 2004 02:12:23 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsGRG-0005h3-00 for hubmib@ietf.org; Sun, 15 Feb 2004 02:11:38 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 3-0295329063; Sun, 15 Feb 2004 02:11:05 -0500 (EST) From: "Lior Khermosh" To: "Harrington, David" , "Romascanu, Dan \(Dan\)" , Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Date: Sun, 15 Feb 2004 09:14:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C3F3A4.1C66EF80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <6D745637A7E0F94DA070743C55CDA9BA015FF160@NHROCMBX1.ets.enterasys.com> X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C3F3A4.1C66EF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Canceling the WG Meeting in Seoul?Hi David, Just a comment on your comment. Without referring to the question where the MIBs should be I would just like to note, as the editor of the EPON MIB, that I have been receiving in the last few weeks comments about the documents. Obviously the trigger for that is the coming Plenary meeting. However I do accept Dan's comment regarding to reflector's traffic. I will try to bounce any such activity in the future in the reflector since probably one comment can be an opening for a lot of questions from other people. I can not force people to CC the reflector but I will ask them to do so and bounce the comment changes in a note. Lior Khermosh -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Harrington, David Sent: Friday, February 13, 2004 9:45 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi Dan, Just a comment. At the hubmib interim meeting coresident at the Vancouver IEEE meeting, you seemed pretty insistent that the discussion be brought into the IETF meeting, and not just done by the editors at interim meetings coexistent with IEEE meetings. If the session will be cancelled in Seoul, how will you proceed regarding future interim meetings? if you are getting more involvement from IEEE personnel than IETF personnel, maybe the mib work should be moved into the IEEE and the Hubmib WG closed? As you know, that is the emerging approach being taken for the Bridgemib WG mibs. Just a thought, dbh ---------------------------------------------------------------------------- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items. I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years. Regards, Dan ------=_NextPart_000_000C_01C3F3A4.1C66EF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Hi=20 David,
Just a=20 comment on your comment. Without referring to the question where = the MIBs=20 should be I would just like to note, as the editor of the = EPON MIB,=20 that I have been receiving in the last few weeks comments about the = documents.=20 Obviously the trigger for that is the coming Plenary = meeting. However=20 I do accept Dan's comment regarding to reflector's traffic. I will try = to bounce=20 any such activity in the future in the reflector since probably one = comment can=20 be an opening for a lot of questions from other people. I can not force = people=20 to CC the reflector but I will ask them to do so and bounce the comment = changes=20 in a note.
 
Lior=20 Khermosh
 
 
-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Harrington,=20 David
Sent: Friday, February 13, 2004 9:45 PM
To:=20 Romascanu, Dan (Dan); hubmib@ietf.org
Subject: RE: [Hubmib]=20 Canceling the WG Meeting in Seoul?

Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at = the=20 Vancouver IEEE meeting, you seemed pretty insistent that the = discussion be=20 brought into the IETF meeting, and not just done by the editors at = interim=20 meetings coexistent with IEEE meetings. If the session will be = cancelled in=20 Seoul, how will you proceed regarding future interim=20 meetings?
 
if you are getting more involvement from IEEE personnel than = IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG=20 closed? As you know, that is the emerging approach being taken = for the=20 Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, = 2004 10:36=20 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last = couple of days=20 notifications from the editors of two of the three documents = (generic EFM=20 MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG = meeting.=20 As it looks like they cannot get somebody else to properly represent = their=20 work in the meeting, I am inclined to suggest that our meeting in = Seoul be=20 cancelled. This is not yet a final announcement, please respond = whether you=20 agree or not with canceling the meeting. If you think that we should = meet,=20 please let me know how you suggest to cover the agenda items. =

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot = comments, and I=20 know that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The = discussions on=20 MIB-related issues must be conducted on the hubmib WG list. Please = remember=20 that in the IETF work the WG list is the main media for work and=20 communication, ensuring the fair and accessible change of views = specific to=20 the IETF process. FYI, if you have concerns about spam traffic - = this list=20 is manually administered, and as far as I know no spam traffic made = it to=20 the list in the last few years.

Regards,

Dan

------=_NextPart_000_000C_01C3F3A4.1C66EF80-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Feb 15 03:03:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26019 for ; Sun, 15 Feb 2004 02:14:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGTi-00053p-N0 for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 02:14:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F7EA3e019369 for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 02:14:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGTc-00051p-Ds; Sun, 15 Feb 2004 02:14:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsGSu-0004n9-3q for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 02:13:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24856 for ; Sun, 15 Feb 2004 02:13:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsGSq-0005my-00 for hubmib@ietf.org; Sun, 15 Feb 2004 02:13:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsGRy-0005kL-00 for hubmib@ietf.org; Sun, 15 Feb 2004 02:12:23 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsGRG-0005h3-00 for hubmib@ietf.org; Sun, 15 Feb 2004 02:11:38 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 3-0295329063; Sun, 15 Feb 2004 02:11:05 -0500 (EST) From: "Lior Khermosh" To: "Harrington, David" , "Romascanu, Dan \(Dan\)" , Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Date: Sun, 15 Feb 2004 09:14:27 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C3F3A4.1C66EF80" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-reply-to: <6D745637A7E0F94DA070743C55CDA9BA015FF160@NHROCMBX1.ets.enterasys.com> X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C3F3A4.1C66EF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Canceling the WG Meeting in Seoul?Hi David, Just a comment on your comment. Without referring to the question where the MIBs should be I would just like to note, as the editor of the EPON MIB, that I have been receiving in the last few weeks comments about the documents. Obviously the trigger for that is the coming Plenary meeting. However I do accept Dan's comment regarding to reflector's traffic. I will try to bounce any such activity in the future in the reflector since probably one comment can be an opening for a lot of questions from other people. I can not force people to CC the reflector but I will ask them to do so and bounce the comment changes in a note. Lior Khermosh -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Harrington, David Sent: Friday, February 13, 2004 9:45 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi Dan, Just a comment. At the hubmib interim meeting coresident at the Vancouver IEEE meeting, you seemed pretty insistent that the discussion be brought into the IETF meeting, and not just done by the editors at interim meetings coexistent with IEEE meetings. If the session will be cancelled in Seoul, how will you proceed regarding future interim meetings? if you are getting more involvement from IEEE personnel than IETF personnel, maybe the mib work should be moved into the IEEE and the Hubmib WG closed? As you know, that is the emerging approach being taken for the Bridgemib WG mibs. Just a thought, dbh ---------------------------------------------------------------------------- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items. I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years. Regards, Dan ------=_NextPart_000_000C_01C3F3A4.1C66EF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Hi=20 David,
Just a=20 comment on your comment. Without referring to the question where = the MIBs=20 should be I would just like to note, as the editor of the = EPON MIB,=20 that I have been receiving in the last few weeks comments about the = documents.=20 Obviously the trigger for that is the coming Plenary = meeting. However=20 I do accept Dan's comment regarding to reflector's traffic. I will try = to bounce=20 any such activity in the future in the reflector since probably one = comment can=20 be an opening for a lot of questions from other people. I can not force = people=20 to CC the reflector but I will ask them to do so and bounce the comment = changes=20 in a note.
 
Lior=20 Khermosh
 
 
-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Harrington,=20 David
Sent: Friday, February 13, 2004 9:45 PM
To:=20 Romascanu, Dan (Dan); hubmib@ietf.org
Subject: RE: [Hubmib]=20 Canceling the WG Meeting in Seoul?

Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at = the=20 Vancouver IEEE meeting, you seemed pretty insistent that the = discussion be=20 brought into the IETF meeting, and not just done by the editors at = interim=20 meetings coexistent with IEEE meetings. If the session will be = cancelled in=20 Seoul, how will you proceed regarding future interim=20 meetings?
 
if you are getting more involvement from IEEE personnel than = IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG=20 closed? As you know, that is the emerging approach being taken = for the=20 Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, = 2004 10:36=20 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last = couple of days=20 notifications from the editors of two of the three documents = (generic EFM=20 MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG = meeting.=20 As it looks like they cannot get somebody else to properly represent = their=20 work in the meeting, I am inclined to suggest that our meeting in = Seoul be=20 cancelled. This is not yet a final announcement, please respond = whether you=20 agree or not with canceling the meeting. If you think that we should = meet,=20 please let me know how you suggest to cover the agenda items. =

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot = comments, and I=20 know that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The = discussions on=20 MIB-related issues must be conducted on the hubmib WG list. Please = remember=20 that in the IETF work the WG list is the main media for work and=20 communication, ensuring the fair and accessible change of views = specific to=20 the IETF process. FYI, if you have concerns about spam traffic - = this list=20 is manually administered, and as far as I know no spam traffic made = it to=20 the list in the last few years.

Regards,

Dan

------=_NextPart_000_000C_01C3F3A4.1C66EF80-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Feb 15 04:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02589 for ; Sun, 15 Feb 2004 04:18:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIPb-000181-P5 for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 04:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F9I3Dx004337 for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 04:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIPa-00017o-5y; Sun, 15 Feb 2004 04:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIOw-00017C-2n for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 04:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02577 for ; Sun, 15 Feb 2004 04:17:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsIOt-0005T8-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:17:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsINw-0005Qv-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:16:21 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsINo-0005OR-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:16:12 -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 i1F9FKdZ001240 for ; Sun, 15 Feb 2004 04:15:20 -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 i1F9FIdZ001209 for ; Sun, 15 Feb 2004 04:15:19 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3A4.597B6130" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 15 Feb 2004 11:16:09 +0200 Message-ID: Thread-Topic: [Hubmib] Canceling the WG Meeting in Seoul? Thread-Index: AcPzkweHTmVICxXlR6OUejLGqaVDEwAEPSlQ From: "Romascanu, Dan (Dan)" To: "Lior Khermosh" , "Harrington, David" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3A4.597B6130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lior, =20 As long as this is an IETF work item, discussions need to be conducted = on the IETF list.=20 =20 Regards, Dan -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: 15 February, 2004 9:14 AM To: Harrington, David; Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi David, Just a comment on your comment. Without referring to the question where = the MIBs should be I would just like to note, as the editor of the EPON = MIB, that I have been receiving in the last few weeks comments about the = documents. Obviously the trigger for that is the coming Plenary meeting. = However I do accept Dan's comment regarding to reflector's traffic. I = will try to bounce any such activity in the future in the reflector = since probably one comment can be an opening for a lot of questions from = other people. I can not force people to CC the reflector but I will ask = them to do so and bounce the comment changes in a note. =20 Lior Khermosh =20 =20 -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Harrington, David Sent: Friday, February 13, 2004 9:45 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi Dan, =20 Just a comment. At the hubmib interim meeting coresident at the = Vancouver IEEE meeting, you seemed pretty insistent that the discussion = be brought into the IETF meeting, and not just done by the editors at = interim meetings coexistent with IEEE meetings. If the session will be = cancelled in Seoul, how will you proceed regarding future interim = meetings? =20 if you are getting more involvement from IEEE personnel than IETF = personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG closed? As you know, that is the emerging approach being taken = for the Bridgemib WG mibs. =20 Just a thought, dbh _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F3A4.597B6130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Lior,
 
As long as this is an IETF work item, discussions need to be = conducted on=20 the IETF list.
 
Regards,

Dan

-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: 15 February, 2004 = 9:14=20 AM
To: Harrington, David; Romascanu, Dan (Dan);=20 hubmib@ietf.org
Subject: RE: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

Hi=20 David,
Just=20 a comment on your comment. Without referring to the question = where the=20 MIBs should be I would just like to note, as the editor of the=20 EPON MIB, that I have been receiving in the last few weeks = comments about=20 the documents. Obviously the trigger for that is the coming = Plenary=20 meeting. However I do accept Dan's comment regarding to = reflector's=20 traffic. I will try to bounce any such activity in the future in the = reflector=20 since probably one comment can be an opening for a lot of questions = from other=20 people. I can not force people to CC the reflector but I will ask them = to do=20 so and bounce the comment changes in a note.
 
Lior=20 Khermosh
 
 
-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Harrington,=20 David
Sent: Friday, February 13, 2004 9:45 = PM
To:=20 Romascanu, Dan (Dan); hubmib@ietf.org
Subject: RE: = [Hubmib]=20 Canceling the WG Meeting in Seoul?

Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at = the=20 Vancouver IEEE meeting, you seemed pretty insistent that the = discussion be=20 brought into the IETF meeting, and not just done by the editors at = interim=20 meetings coexistent with IEEE meetings. If the session will be = cancelled in=20 Seoul, how will you proceed regarding future interim=20 meetings?
 
if you are getting more involvement from IEEE personnel = than IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib=20 WG closed? As you know, that is the emerging approach being = taken for=20 the Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, = 2004=20 10:36 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last = couple of days=20 notifications from the editors of two of the three documents = (generic EFM=20 MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG = meeting.=20 As it looks like they cannot get somebody else to properly = represent their=20 work in the meeting, I am inclined to suggest that our meeting in = Seoul be=20 cancelled. This is not yet a final announcement, please respond = whether=20 you agree or not with canceling the meeting. If you think that we = should=20 meet, please let me know how you suggest to cover the agenda = items.=20

I frankly am concerned = with the low=20 level of technical traffic on the list lately. With the first = round of WG=20 drafts submitted, I was expecting more feedback and public review. = I know=20 that the IEEE drafts are stabilizing as result of the sponsor = ballot=20 comments, and I know that there are quite a lot of consistent = changes the=20 management sections, specifically in Clause 30 affecting this = work. The=20 discussions on MIB-related issues must be conducted on the hubmib = WG list.=20 Please remember that in the IETF work the WG list is the main = media for=20 work and communication, ensuring the fair and accessible change of = views=20 specific to the IETF process. FYI, if you have concerns about spam = traffic=20 - this list is manually administered, and as far as I know no spam = traffic=20 made it to the list in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F3A4.597B6130-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Feb 15 04:18:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02590 for ; Sun, 15 Feb 2004 04:18:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIPa-00017o-5y; Sun, 15 Feb 2004 04:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIOw-00017C-2n for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 04:17:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02577 for ; Sun, 15 Feb 2004 04:17:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsIOt-0005T8-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:17:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsINw-0005Qv-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:16:21 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsINo-0005OR-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:16:12 -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 i1F9FKdZ001240 for ; Sun, 15 Feb 2004 04:15:20 -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 i1F9FIdZ001209 for ; Sun, 15 Feb 2004 04:15:19 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3A4.597B6130" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 15 Feb 2004 11:16:09 +0200 Message-ID: Thread-Topic: [Hubmib] Canceling the WG Meeting in Seoul? Thread-Index: AcPzkweHTmVICxXlR6OUejLGqaVDEwAEPSlQ From: "Romascanu, Dan (Dan)" To: "Lior Khermosh" , "Harrington, David" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3A4.597B6130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Lior, =20 As long as this is an IETF work item, discussions need to be conducted = on the IETF list.=20 =20 Regards, Dan -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: 15 February, 2004 9:14 AM To: Harrington, David; Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi David, Just a comment on your comment. Without referring to the question where = the MIBs should be I would just like to note, as the editor of the EPON = MIB, that I have been receiving in the last few weeks comments about the = documents. Obviously the trigger for that is the coming Plenary meeting. = However I do accept Dan's comment regarding to reflector's traffic. I = will try to bounce any such activity in the future in the reflector = since probably one comment can be an opening for a lot of questions from = other people. I can not force people to CC the reflector but I will ask = them to do so and bounce the comment changes in a note. =20 Lior Khermosh =20 =20 -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Harrington, David Sent: Friday, February 13, 2004 9:45 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi Dan, =20 Just a comment. At the hubmib interim meeting coresident at the = Vancouver IEEE meeting, you seemed pretty insistent that the discussion = be brought into the IETF meeting, and not just done by the editors at = interim meetings coexistent with IEEE meetings. If the session will be = cancelled in Seoul, how will you proceed regarding future interim = meetings? =20 if you are getting more involvement from IEEE personnel than IETF = personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG closed? As you know, that is the emerging approach being taken = for the Bridgemib WG mibs. =20 Just a thought, dbh _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F3A4.597B6130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Lior,
 
As long as this is an IETF work item, discussions need to be = conducted on=20 the IETF list.
 
Regards,

Dan

-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: 15 February, 2004 = 9:14=20 AM
To: Harrington, David; Romascanu, Dan (Dan);=20 hubmib@ietf.org
Subject: RE: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

Hi=20 David,
Just=20 a comment on your comment. Without referring to the question = where the=20 MIBs should be I would just like to note, as the editor of the=20 EPON MIB, that I have been receiving in the last few weeks = comments about=20 the documents. Obviously the trigger for that is the coming = Plenary=20 meeting. However I do accept Dan's comment regarding to = reflector's=20 traffic. I will try to bounce any such activity in the future in the = reflector=20 since probably one comment can be an opening for a lot of questions = from other=20 people. I can not force people to CC the reflector but I will ask them = to do=20 so and bounce the comment changes in a note.
 
Lior=20 Khermosh
 
 
-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Harrington,=20 David
Sent: Friday, February 13, 2004 9:45 = PM
To:=20 Romascanu, Dan (Dan); hubmib@ietf.org
Subject: RE: = [Hubmib]=20 Canceling the WG Meeting in Seoul?

Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at = the=20 Vancouver IEEE meeting, you seemed pretty insistent that the = discussion be=20 brought into the IETF meeting, and not just done by the editors at = interim=20 meetings coexistent with IEEE meetings. If the session will be = cancelled in=20 Seoul, how will you proceed regarding future interim=20 meetings?
 
if you are getting more involvement from IEEE personnel = than IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib=20 WG closed? As you know, that is the emerging approach being = taken for=20 the Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, = 2004=20 10:36 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last = couple of days=20 notifications from the editors of two of the three documents = (generic EFM=20 MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG = meeting.=20 As it looks like they cannot get somebody else to properly = represent their=20 work in the meeting, I am inclined to suggest that our meeting in = Seoul be=20 cancelled. This is not yet a final announcement, please respond = whether=20 you agree or not with canceling the meeting. If you think that we = should=20 meet, please let me know how you suggest to cover the agenda = items.=20

I frankly am concerned = with the low=20 level of technical traffic on the list lately. With the first = round of WG=20 drafts submitted, I was expecting more feedback and public review. = I know=20 that the IEEE drafts are stabilizing as result of the sponsor = ballot=20 comments, and I know that there are quite a lot of consistent = changes the=20 management sections, specifically in Clause 30 affecting this = work. The=20 discussions on MIB-related issues must be conducted on the hubmib = WG list.=20 Please remember that in the IETF work the WG list is the main = media for=20 work and communication, ensuring the fair and accessible change of = views=20 specific to the IETF process. FYI, if you have concerns about spam = traffic=20 - this list is manually administered, and as far as I know no spam = traffic=20 made it to the list in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F3A4.597B6130-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Feb 15 04:32:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02831 for ; Sun, 15 Feb 2004 04:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsId6-0003ng-Ho; Sun, 15 Feb 2004 04:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIcT-0003nN-77 for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 04:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02813 for ; Sun, 15 Feb 2004 04:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsIcQ-0006E9-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:31:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsIbT-0006C0-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:30:21 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsIam-00069j-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:29:36 -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 i1F9Po2B024487 for ; Sun, 15 Feb 2004 04:25:50 -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 i1F9Pm2B024448 for ; Sun, 15 Feb 2004 04:25:49 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3A6.38BB323E" Date: Sun, 15 Feb 2004 11:29:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Hubmib] Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gAIebVQAE7avEA= From: "Romascanu, Dan (Dan)" To: "Harrington, David" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3A6.38BB323E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, =20 The Vancouver gathering was an editing session, and not an interim = meeting. We had tried to organize an official interim meeting, but this = failed for various reasons, most important being that we did not get = enough interest from people intending to participate in an interim = meeting.=20 =20 The Area Director made it clear that no interim meeting will be approved = by the IESG while the WG does not meet during the regular IETF session. = I think that this is fair, and in the spirit of the IETF process. An = IETF participant cannot be required to pay an extra participation fee to = the IEEE for a hubmib meeting, while the WG does not meet during the = regular IETF meetings.=20 =20 Personally, I do not have a special problem with the MIB work being = moved to the IEEE. I would note however, that the IEEE 802.3 WG seems to = prefer the current arrangement, and are less inclined than the 802.1 WG = to do SNMP MIB work. By the time when the current EFM work was = chartered, about 13 or 14 individuals expressed their support for the = work in the IETF, and their intention to particpate at different levels. Regards, Dan -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: 13 February, 2004 9:45 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi Dan, =20 Just a comment. At the hubmib interim meeting coresident at the = Vancouver IEEE meeting, you seemed pretty insistent that the discussion = be brought into the IETF meeting, and not just done by the editors at = interim meetings coexistent with IEEE meetings. If the session will be = cancelled in Seoul, how will you proceed regarding future interim = meetings? =20 if you are getting more involvement from IEEE personnel than IETF = personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG closed? As you know, that is the emerging approach being taken = for the Bridgemib WG mibs. =20 Just a thought, dbh _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F3A6.38BB323E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
David,
 
The Vancouver gathering was an editing session, and = not an=20 interim meeting. We had tried to organize an official interim meeting, = but this=20 failed for various reasons, most important being that we did not = get enough=20 interest from people intending to participate in an interim = meeting.=20
 
The Area Director made it clear that no interim meeting will be = approved=20 by the IESG while the WG does not meet during the regular IETF session. = I think=20 that this is fair, and in the spirit of the IETF process. An IETF = participant=20 cannot be required to pay an extra participation fee to the IEEE for a = hubmib=20 meeting, while the WG does not meet during the regular IETF = meetings.=20
 
Personally, I do not have a special problem with the MIB work = being moved=20 to the IEEE. I would note however, that the IEEE 802.3 WG seems to = prefer the=20 current arrangement, and are less inclined than the 802.1 WG to do SNMP = MIB=20 work. By the time when the current EFM work was chartered, about 13 or = 14=20 individuals expressed their support for the work in the IETF, and their=20 intention to particpate at different = levels.

Regards,

Dan

-----Original Message-----
From: Harrington, David=20 [mailto:dbh@enterasys.com]
Sent: 13 February, 2004 9:45=20 PM
To: Romascanu, Dan (Dan); = hubmib@ietf.org
Subject: RE:=20 [Hubmib] Canceling the WG Meeting in Seoul?

Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at = the=20 Vancouver IEEE meeting, you seemed pretty insistent that the = discussion be=20 brought into the IETF meeting, and not just done by the editors at = interim=20 meetings coexistent with IEEE meetings. If the session will be = cancelled in=20 Seoul, how will you proceed regarding future interim=20 meetings?
 
if you are getting more involvement from IEEE personnel than = IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG=20 closed? As you know, that is the emerging approach being taken = for the=20 Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, = 2004 10:36=20 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last = couple of days=20 notifications from the editors of two of the three documents = (generic EFM=20 MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG = meeting.=20 As it looks like they cannot get somebody else to properly represent = their=20 work in the meeting, I am inclined to suggest that our meeting in = Seoul be=20 cancelled. This is not yet a final announcement, please respond = whether you=20 agree or not with canceling the meeting. If you think that we should = meet,=20 please let me know how you suggest to cover the agenda items. =

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot = comments, and I=20 know that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The = discussions on=20 MIB-related issues must be conducted on the hubmib WG list. Please = remember=20 that in the IETF work the WG list is the main media for work and=20 communication, ensuring the fair and accessible change of views = specific to=20 the IETF process. FYI, if you have concerns about spam traffic - = this list=20 is manually administered, and as far as I know no spam traffic made = it to=20 the list in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F3A6.38BB323E-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Feb 15 04:32:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02842 for ; Sun, 15 Feb 2004 04:32:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIdB-0003oC-5e for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 04:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1F9W5Y8014624 for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 04:32:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsId6-0003ng-Ho; Sun, 15 Feb 2004 04:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsIcT-0003nN-77 for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 04:31:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02813 for ; Sun, 15 Feb 2004 04:31:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsIcQ-0006E9-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:31:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsIbT-0006C0-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:30:21 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsIam-00069j-00 for hubmib@ietf.org; Sun, 15 Feb 2004 04:29:36 -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 i1F9Po2B024487 for ; Sun, 15 Feb 2004 04:25:50 -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 i1F9Pm2B024448 for ; Sun, 15 Feb 2004 04:25:49 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3A6.38BB323E" Date: Sun, 15 Feb 2004 11:29:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Hubmib] Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gAIebVQAE7avEA= From: "Romascanu, Dan (Dan)" To: "Harrington, David" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3A6.38BB323E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David, =20 The Vancouver gathering was an editing session, and not an interim = meeting. We had tried to organize an official interim meeting, but this = failed for various reasons, most important being that we did not get = enough interest from people intending to participate in an interim = meeting.=20 =20 The Area Director made it clear that no interim meeting will be approved = by the IESG while the WG does not meet during the regular IETF session. = I think that this is fair, and in the spirit of the IETF process. An = IETF participant cannot be required to pay an extra participation fee to = the IEEE for a hubmib meeting, while the WG does not meet during the = regular IETF meetings.=20 =20 Personally, I do not have a special problem with the MIB work being = moved to the IEEE. I would note however, that the IEEE 802.3 WG seems to = prefer the current arrangement, and are less inclined than the 802.1 WG = to do SNMP MIB work. By the time when the current EFM work was = chartered, about 13 or 14 individuals expressed their support for the = work in the IETF, and their intention to particpate at different levels. Regards, Dan -----Original Message----- From: Harrington, David [mailto:dbh@enterasys.com] Sent: 13 February, 2004 9:45 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? Hi Dan, =20 Just a comment. At the hubmib interim meeting coresident at the = Vancouver IEEE meeting, you seemed pretty insistent that the discussion = be brought into the IETF meeting, and not just done by the editors at = interim meetings coexistent with IEEE meetings. If the session will be = cancelled in Seoul, how will you proceed regarding future interim = meetings? =20 if you are getting more involvement from IEEE personnel than IETF = personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG closed? As you know, that is the emerging approach being taken = for the Bridgemib WG mibs. =20 Just a thought, dbh _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Friday, February 13, 2004 10:36 AM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F3A6.38BB323E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
David,
 
The Vancouver gathering was an editing session, and = not an=20 interim meeting. We had tried to organize an official interim meeting, = but this=20 failed for various reasons, most important being that we did not = get enough=20 interest from people intending to participate in an interim = meeting.=20
 
The Area Director made it clear that no interim meeting will be = approved=20 by the IESG while the WG does not meet during the regular IETF session. = I think=20 that this is fair, and in the spirit of the IETF process. An IETF = participant=20 cannot be required to pay an extra participation fee to the IEEE for a = hubmib=20 meeting, while the WG does not meet during the regular IETF = meetings.=20
 
Personally, I do not have a special problem with the MIB work = being moved=20 to the IEEE. I would note however, that the IEEE 802.3 WG seems to = prefer the=20 current arrangement, and are less inclined than the 802.1 WG to do SNMP = MIB=20 work. By the time when the current EFM work was chartered, about 13 or = 14=20 individuals expressed their support for the work in the IETF, and their=20 intention to particpate at different = levels.

Regards,

Dan

-----Original Message-----
From: Harrington, David=20 [mailto:dbh@enterasys.com]
Sent: 13 February, 2004 9:45=20 PM
To: Romascanu, Dan (Dan); = hubmib@ietf.org
Subject: RE:=20 [Hubmib] Canceling the WG Meeting in Seoul?

Hi Dan,
 
Just a comment. At the hubmib interim meeting coresident at = the=20 Vancouver IEEE meeting, you seemed pretty insistent that the = discussion be=20 brought into the IETF meeting, and not just done by the editors at = interim=20 meetings coexistent with IEEE meetings. If the session will be = cancelled in=20 Seoul, how will you proceed regarding future interim=20 meetings?
 
if you are getting more involvement from IEEE personnel than = IETF=20 personnel, maybe the mib work should be moved into the IEEE and the = Hubmib WG=20 closed? As you know, that is the emerging approach being taken = for the=20 Bridgemib WG mibs.
 
Just a thought,
dbh

From: Romascanu, Dan (Dan)=20 [mailto:dromasca@avaya.com]
Sent: Friday, February 13, = 2004 10:36=20 AM
To: hubmib@ietf.org
Cc:=20 bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG = Meeting in=20 Seoul?

I received in the last = couple of days=20 notifications from the editors of two of the three documents = (generic EFM=20 MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG = meeting.=20 As it looks like they cannot get somebody else to properly represent = their=20 work in the meeting, I am inclined to suggest that our meeting in = Seoul be=20 cancelled. This is not yet a final announcement, please respond = whether you=20 agree or not with canceling the meeting. If you think that we should = meet,=20 please let me know how you suggest to cover the agenda items. =

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot = comments, and I=20 know that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The = discussions on=20 MIB-related issues must be conducted on the hubmib WG list. Please = remember=20 that in the IETF work the WG list is the main media for work and=20 communication, ensuring the fair and accessible change of views = specific to=20 the IETF process. FYI, if you have concerns about spam traffic - = this list=20 is manually administered, and as far as I know no spam traffic made = it to=20 the list in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F3A6.38BB323E-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Feb 15 07:59:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07270 for ; Sun, 15 Feb 2004 07:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLrR-0006h3-98; Sun, 15 Feb 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLr1-0006g4-TQ for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 07:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07224 for ; Sun, 15 Feb 2004 07:58:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsLr1-00028g-00 for hubmib@ietf.org; Sun, 15 Feb 2004 07:58:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsLq3-00023Q-00 for hubmib@ietf.org; Sun, 15 Feb 2004 07:57:36 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsLpM-0001ze-00 for hubmib@ietf.org; Sun, 15 Feb 2004 07:56:52 -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 i1FCr42B021016 for ; Sun, 15 Feb 2004 07:53: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 i1FCr22B021003 for ; Sun, 15 Feb 2004 07:53:03 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3C3.2C7113AA" Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 15 Feb 2004 14:56:48 +0200 Message-ID: Thread-Topic: Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gBe8P7w From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3C3.2C7113AA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable In order to help with the decision regarding the meeting in Seoul, can = everybody who is planning to be at the Seoul IETF and attend the hubmib = WG meeting send me an e-mail.=20 =20 Thanks and Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Romascanu, Dan (Dan) Sent: 13 February, 2004 5:36 PM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F3C3.2C7113AA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
In order to help with the decision regarding the = meeting in=20 Seoul, can everybody who is planning to be at the Seoul = IETF and=20 attend the hubmib WG meeting send me an e-mail.=20
 

Thanks and=20 Regards,

Dan

-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan=20 (Dan)
Sent: 13 February, 2004 5:36 PM
To:=20 hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: = [Hubmib]=20 Canceling the WG Meeting in Seoul?

I received in the last couple = of days=20 notifications from the editors of two of the three documents (generic = EFM MIB,=20 and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. = As it=20 looks like they cannot get somebody else to properly represent their = work in=20 the meeting, I am inclined to suggest that our meeting in Seoul be = cancelled.=20 This is not yet a final announcement, please respond whether you agree = or not=20 with canceling the meeting. If you think that we should meet, please = let me=20 know how you suggest to cover the agenda items.

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot comments, = and I=20 know that there are quite a lot of consistent changes the management = sections,=20 specifically in Clause 30 affecting this work. The discussions on = MIB-related=20 issues must be conducted on the hubmib WG list. Please remember that = in the=20 IETF work the WG list is the main media for work and communication, = ensuring=20 the fair and accessible change of views specific to the IETF process. = FYI, if=20 you have concerns about spam traffic - this list is manually = administered, and=20 as far as I know no spam traffic made it to the list in the last few=20 years.

Regards,

Dan

------_=_NextPart_001_01C3F3C3.2C7113AA-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Feb 15 08:48:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07272 for ; Sun, 15 Feb 2004 07:59:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLrR-0006hq-Qu for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 07:59:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1FCx1Oi025760 for hubmib-archive@odin.ietf.org; Sun, 15 Feb 2004 07:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLrR-0006h3-98; Sun, 15 Feb 2004 07:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsLr1-0006g4-TQ for hubmib@optimus.ietf.org; Sun, 15 Feb 2004 07:58:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07224 for ; Sun, 15 Feb 2004 07:58:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsLr1-00028g-00 for hubmib@ietf.org; Sun, 15 Feb 2004 07:58:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsLq3-00023Q-00 for hubmib@ietf.org; Sun, 15 Feb 2004 07:57:36 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AsLpM-0001ze-00 for hubmib@ietf.org; Sun, 15 Feb 2004 07:56:52 -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 i1FCr42B021016 for ; Sun, 15 Feb 2004 07:53: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 i1FCr22B021003 for ; Sun, 15 Feb 2004 07:53:03 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F3C3.2C7113AA" Subject: RE: [Hubmib] Canceling the WG Meeting in Seoul? X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 15 Feb 2004 14:56:48 +0200 Message-ID: Thread-Topic: Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gBe8P7w From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F3C3.2C7113AA Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable In order to help with the decision regarding the meeting in Seoul, can = everybody who is planning to be at the Seoul IETF and attend the hubmib = WG meeting send me an e-mail.=20 =20 Thanks and Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Romascanu, Dan (Dan) Sent: 13 February, 2004 5:36 PM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F3C3.2C7113AA Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
In order to help with the decision regarding the = meeting in=20 Seoul, can everybody who is planning to be at the Seoul = IETF and=20 attend the hubmib WG meeting send me an e-mail.=20
 

Thanks and=20 Regards,

Dan

-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan=20 (Dan)
Sent: 13 February, 2004 5:36 PM
To:=20 hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: = [Hubmib]=20 Canceling the WG Meeting in Seoul?

I received in the last couple = of days=20 notifications from the editors of two of the three documents (generic = EFM MIB,=20 and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. = As it=20 looks like they cannot get somebody else to properly represent their = work in=20 the meeting, I am inclined to suggest that our meeting in Seoul be = cancelled.=20 This is not yet a final announcement, please respond whether you agree = or not=20 with canceling the meeting. If you think that we should meet, please = let me=20 know how you suggest to cover the agenda items.

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot comments, = and I=20 know that there are quite a lot of consistent changes the management = sections,=20 specifically in Clause 30 affecting this work. The discussions on = MIB-related=20 issues must be conducted on the hubmib WG list. Please remember that = in the=20 IETF work the WG list is the main media for work and communication, = ensuring=20 the fair and accessible change of views specific to the IETF process. = FYI, if=20 you have concerns about spam traffic - this list is manually = administered, and=20 as far as I know no spam traffic made it to the list in the last few=20 years.

Regards,

Dan

------_=_NextPart_001_01C3F3C3.2C7113AA-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 16 07:23:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13754 for ; Mon, 16 Feb 2004 07:23:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashm8-0001QW-Mi; Mon, 16 Feb 2004 07:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshlN-0001OJ-7I for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 07:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13724 for ; Mon, 16 Feb 2004 07:22:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshlM-0007ay-00 for hubmib@ietf.org; Mon, 16 Feb 2004 07:22:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshkR-0007YK-00 for hubmib@ietf.org; Mon, 16 Feb 2004 07:21:18 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1Ashjm-0007Rq-00 for hubmib@ietf.org; Mon, 16 Feb 2004 07:20:34 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id DAE4218F21A; Mon, 16 Feb 2004 04:29:31 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Mon, 16 Feb 2004 04:19:06 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A1A@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'Lior Khermosh'" , "'hubmib@ietf.org'" Cc: "Hariprasad V. Nair" Date: Mon, 16 Feb 2004 04:19:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F487.1012AC68" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F487.1012AC68 Content-Type: text/plain Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------_=_NextPart_001_01C3F487.1012AC68 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello Mr. = Khermosh,

 

Thanks for your reply. I am = forwarding the earlier questions posted by me and your reply for that,  to the mailing = list.

 

Few more questions on your reply = :

 

=

1. Currently, as far as I know, =  the standard 802.3ah does not = suggest a de-asserting mechanism.

 

While standard specify a way to = report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the case for all the = Errored Events though an assertion and de-assertion is possible in this case = without deviating from the standard, I think.

However all the Global Events, = Temperature and Voltage specific events and the Vendor SpecificAlarm Events,  are not defined in the = standard. Can they be optional then?

 

2. One thing I missed to point out = in my previous mail : Attribute = eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState = attribute. Or are they different?  = Please clarify.

 

Thanks

Raj = Subramanian.

 

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Sunday, February 15, = 2004 12:34 PM
To: Rajagopalan = Subramanian
Subject: RE: = Clarifications in EPON Device MIB

 

Dear = Mr. Subramanian,

 

Thank you very = much for your comments. They are very helpful. I would like to ask the = permission to send the comments and replies to the hubmib reflector for the = interest of all people.

 

eponDeviceObjectOnuLoopba= ck – As defined now it is redundant and should be removed. =

 

From eponDeviceObjectDyingGaspAlarmState :

When the dyingGaspAlarm state is removed the dying gasp alarm is = reset.

I added it to the text.

 

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

 

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed so I = suggest to keep them. I will add a description.

 

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed. Iwill add = a description.

 

The difference in my = opinion is:

 

Alarm:=

When the value of the alarm input is above the threshold defined for the = alarm the alarm is asserted. When the condition is below that threshold the alarm = is de-asserted.

 

Event:=

When the indication of the event input occurs the event is asserted. When = the input is removed that event is de-asserted.

 

Event is more referring = to a system condition while alarm indicates a bad thing happening in the = system.

 

eponDeviceObjectPowerDown=

I think it is. An ONU = might have a battery back up and when the device is starting to get down it = indicates Power down. In my opinion it is a very important indication for the = carrier.

 

 

Best = regards,

Lior = Khermosh

 

 

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Wednesday, February 11, = 2004 6:51 AM
To: = 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications = in EPON Device MIB

Hello = Mr.Khermosh,

 <= /font>

I have few questions in = the Device MIB that you had proposed as part of the = draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you = can help me get it clarified.

 =

eponDeviceObjectOnuLoopba= ck = –

In what way is this = attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. = In an implementation should both of these be = supported?

 =

 =

From = eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry = 27) = –

The SYNTAX in the MIB = attribute says it’s a TruthValue and the description says that ‘this = bit should be asserted when we receive the corresponding event’. My = question is : The bit will be set when we receive an event but when will we = reset it ? It cannot be always ‘1’ whenever the user reads this = attribute, right?

 =

 =

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

The description says = ‘ this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause = 57.

But I could not locate = these attributes in the Draft2.0 version of the standard. Can you give me = pointers as to where I should be looking into?

 =

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The description for = these two attributes are Identical.  I could not a VendorAlarm and a = VendorEvent, separately in the clause 57. Can you give some info = please?

 =

eponDeviceObjectPowerDown=

Is setting the PowerDown = a valid scenario for the EPON?

 =

Thanks for your = time.

 

Regards,

Raj = Subramanian

Centillium = India,

Bangalore, INDIA=

+91 80 = 25523575

 

------_=_NextPart_001_01C3F487.1012AC68-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 16 07:23:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13767 for ; Mon, 16 Feb 2004 07:23:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashm9-0001R0-85 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 07:23:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GCN1te005500 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 07:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ashm8-0001QW-Mi; Mon, 16 Feb 2004 07:23:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AshlN-0001OJ-7I for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 07:22:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13724 for ; Mon, 16 Feb 2004 07:22:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AshlM-0007ay-00 for hubmib@ietf.org; Mon, 16 Feb 2004 07:22:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AshkR-0007YK-00 for hubmib@ietf.org; Mon, 16 Feb 2004 07:21:18 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1Ashjm-0007Rq-00 for hubmib@ietf.org; Mon, 16 Feb 2004 07:20:34 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id DAE4218F21A; Mon, 16 Feb 2004 04:29:31 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Mon, 16 Feb 2004 04:19:06 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A1A@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'Lior Khermosh'" , "'hubmib@ietf.org'" Cc: "Hariprasad V. Nair" Date: Mon, 16 Feb 2004 04:19:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F487.1012AC68" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F487.1012AC68 Content-Type: text/plain Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------_=_NextPart_001_01C3F487.1012AC68 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello Mr. = Khermosh,

 

Thanks for your reply. I am = forwarding the earlier questions posted by me and your reply for that,  to the mailing = list.

 

Few more questions on your reply = :

 

=

1. Currently, as far as I know, =  the standard 802.3ah does not = suggest a de-asserting mechanism.

 

While standard specify a way to = report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the case for all the = Errored Events though an assertion and de-assertion is possible in this case = without deviating from the standard, I think.

However all the Global Events, = Temperature and Voltage specific events and the Vendor SpecificAlarm Events,  are not defined in the = standard. Can they be optional then?

 

2. One thing I missed to point out = in my previous mail : Attribute = eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState = attribute. Or are they different?  = Please clarify.

 

Thanks

Raj = Subramanian.

 

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Sunday, February 15, = 2004 12:34 PM
To: Rajagopalan = Subramanian
Subject: RE: = Clarifications in EPON Device MIB

 

Dear = Mr. Subramanian,

 

Thank you very = much for your comments. They are very helpful. I would like to ask the = permission to send the comments and replies to the hubmib reflector for the = interest of all people.

 

eponDeviceObjectOnuLoopba= ck – As defined now it is redundant and should be removed. =

 

From eponDeviceObjectDyingGaspAlarmState :

When the dyingGaspAlarm state is removed the dying gasp alarm is = reset.

I added it to the text.

 

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

 

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed so I = suggest to keep them. I will add a description.

 

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed. Iwill add = a description.

 

The difference in my = opinion is:

 

Alarm:=

When the value of the alarm input is above the threshold defined for the = alarm the alarm is asserted. When the condition is below that threshold the alarm = is de-asserted.

 

Event:=

When the indication of the event input occurs the event is asserted. When = the input is removed that event is de-asserted.

 

Event is more referring = to a system condition while alarm indicates a bad thing happening in the = system.

 

eponDeviceObjectPowerDown=

I think it is. An ONU = might have a battery back up and when the device is starting to get down it = indicates Power down. In my opinion it is a very important indication for the = carrier.

 

 

Best = regards,

Lior = Khermosh

 

 

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Wednesday, February 11, = 2004 6:51 AM
To: = 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications = in EPON Device MIB

Hello = Mr.Khermosh,

 <= /font>

I have few questions in = the Device MIB that you had proposed as part of the = draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you = can help me get it clarified.

 =

eponDeviceObjectOnuLoopba= ck = –

In what way is this = attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. = In an implementation should both of these be = supported?

 =

 =

From = eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry = 27) = –

The SYNTAX in the MIB = attribute says it’s a TruthValue and the description says that ‘this = bit should be asserted when we receive the corresponding event’. My = question is : The bit will be set when we receive an event but when will we = reset it ? It cannot be always ‘1’ whenever the user reads this = attribute, right?

 =

 =

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

The description says = ‘ this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause = 57.

But I could not locate = these attributes in the Draft2.0 version of the standard. Can you give me = pointers as to where I should be looking into?

 =

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The description for = these two attributes are Identical.  I could not a VendorAlarm and a = VendorEvent, separately in the clause 57. Can you give some info = please?

 =

eponDeviceObjectPowerDown=

Is setting the PowerDown = a valid scenario for the EPON?

 =

Thanks for your = time.

 

Regards,

Raj = Subramanian

Centillium = India,

Bangalore, INDIA=

+91 80 = 25523575

 

------_=_NextPart_001_01C3F487.1012AC68-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 16 08:31:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16175 for ; Mon, 16 Feb 2004 08:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipw-0005Uo-T7; Mon, 16 Feb 2004 08:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipC-0005Te-12 for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 08:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16089 for ; Mon, 16 Feb 2004 08:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipA-0003MQ-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioB-0003HM-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:29:12 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsinD-0003Bg-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:28:12 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-04648057 for ; Mon, 16 Feb 2004 08:27:41 -0500 (EST) From: "Lior Khermosh" To: Date: Mon, 16 Feb 2004 15:31:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C3F4A1.E14AE600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,SUBJ_ALL_CAPS autolearn=no version=2.60 Subject: [Hubmib] FW: EPON-DEVICE-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C3F4A1.E14AE600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 08, 2004 10:13 AM To: jayaprakash.kulkarni@wipro.com Subject: RE: EPON-DEVICE-MIB Jayaprakash, Thank you for your comments. I agree that the device modes can not be configure through the MIB so it is indeed a read-only attribute. I think that as for OAM mode is is required to receive from a device a state mode of its OAM where 3 equal options exist - Server client and NoOAM. We can add the OAM disabling/enabling in addition to that. Regards, Lior -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Friday, February 06, 2004 6:21 AM To: lior.khermosh@passave.com Subject: EPON-DEVICE-MIB Hi Lior In the EPON-DEVICE-MIB, eponDeviceObjectModes is defined as read-write, should it be a read-only value instead? eponDeviceObjectOamMode is also defined as read-write. Will eponDeviceObjectModes suffice to identify if the device is a oamServer or oamClient? For enabling/disabling the oam we could have a truth value. regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------=_NextPart_000_006E_01C3F4A1.E14AE600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: Sunday, February 08, = 2004=20 10:13 AM
To: jayaprakash.kulkarni@wipro.com
Subject: = RE:=20 EPON-DEVICE-MIB

Jayaprakash,
Thank you for your = comments.
I agree that the device modes can not be = configure=20 through the MIB so it is indeed a read-only=20 attribute.
I think that as for OAM mode is is required = to receive=20 from a device a state mode of its OAM where 3 equal options exist - = Server=20 client and NoOAM. We can add the OAM disabling/enabling in addition to=20 that.
 
Regards,
Lior
 
 
 
-----Original Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Friday, = February 06,=20 2004 6:21 AM
To: = lior.khermosh@passave.com
Subject:=20 EPON-DEVICE-MIB

Hi=20 Lior
 
In = the=20 EPON-DEVICE-MIB,
 
eponDeviceObjectModes is = defined as=20 read-write, should it be a read-only value=20 instead? 
 
eponDeviceObjectOamMode is also defined as read-write.=20
Will=20 eponDeviceObjectModes suffice to identify if the device is a oamServer = or=20 oamClient? For enabling/disabling the oam we could have a truth=20 value.
 
regards
Jayaprakash
 
 
 
 
 
Confidentiality Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------=_NextPart_000_006E_01C3F4A1.E14AE600-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 16 08:31:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16193 for ; Mon, 16 Feb 2004 08:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipz-0005YL-5Q for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GDV3ds021325 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:31:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005Xr-VE; Mon, 16 Feb 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipE-0005Tv-5x for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 08:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16098 for ; Mon, 16 Feb 2004 08:30:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipD-0003Me-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioE-0003Hk-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:29:15 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsinE-0003Bi-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:28:12 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-24648057 for ; Mon, 16 Feb 2004 08:27:53 -0500 (EST) From: "Lior Khermosh" To: Date: Mon, 16 Feb 2004 15:31:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C3F4A1.E9047000" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Subject: [Hubmib] FW: eponDeviceObjectOnuRegisterStatus Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C3F4A1.E9047000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, January 25, 2004 8:45 AM To: jayaprakash.kulkarni@wipro.com Subject: RE: eponDeviceObjectOnuRegisterStatus Dear Jayaprakash, Thank you very much for the comment. I will replace that in a more clear device attribute - maybe something like device ready or ready to transmit/receive data or something like that. Best regards, Lior Khermosh Passave -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Thursday, January 22, 2004 2:32 PM To: lior.khermosh@passave.com Subject: eponDeviceObjectOnuRegisterStatus Hi Lior Further comments on draft-ietf-hubmib-efm-epon-mib-00.txt, Is there any speicifc reason that you have included eponDeviceObjectOnuRegisterStatus when dot3MpcpRegistrationState is available for obtaining the MPCP Registration State? regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------=_NextPart_000_0076_01C3F4A1.E9047000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: Sunday, January 25, = 2004 8:45=20 AM
To: jayaprakash.kulkarni@wipro.com
Subject: RE:=20 eponDeviceObjectOnuRegisterStatus

Dear=20 Jayaprakash,
Thank you very much for the=20 comment.
I will replace that in a more clear device = attribute -=20 maybe something like device ready or ready to transmit/receive data or = something=20 like that.
 
Best regards,
Lior Khermosh
Passave
 
-----Original Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Thursday, = January 22,=20 2004 2:32 PM
To: = lior.khermosh@passave.com
Subject:=20 eponDeviceObjectOnuRegisterStatus

Hi=20 Lior
 
Further comments on=20 draft-ietf-hubmib-efm-epon-mib-00.txt,
 
Is there any speicifc reason that you have = included=20 eponDeviceObjectOnuRegisterStatus when=20 dot3MpcpRegistrationState is available for obtaining the MPCP = Registration=20 State?
 
regards
Jayaprakash
 
 
Confidentiality =
Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------=_NextPart_000_0076_01C3F4A1.E9047000-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 16 08:31:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16181 for ; Mon, 16 Feb 2004 08:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005W2-Ep; Mon, 16 Feb 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipD-0005Tq-JS for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 08:30:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16095 for ; Mon, 16 Feb 2004 08:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipC-0003Ma-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioD-0003Hc-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:29:14 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsinE-0003Bh-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:28:12 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-14648057 for ; Mon, 16 Feb 2004 08:27:49 -0500 (EST) From: "Lior Khermosh" To: Date: Mon, 16 Feb 2004 15:31:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C3F4A1.E5D724E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Subject: [Hubmib] FW: Minor comments on draft-ietf-hubmib-efm-epon-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0072_01C3F4A1.E5D724E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, January 25, 2004 8:45 AM To: jayaprakash.kulkarni@wipro.com Subject: RE: Minor comments on draft-ietf-hubmib-efm-epon-mib-00.txt Dear Jayaprakash, Thank you very much for the comments. I accept them. Best regards, Lior Khermosh Passave -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Thursday, January 22, 2004 8:55 AM To: lior.khermosh@passave.com Subject: Minor comments on draft-ietf-hubmib-efm-epon-mib-00.txt Two minor comments on latest draft-ietf-hubmib-efm-epon-mib-00.txt >>EfmeponMIB MODULE-IDENTITY Should it be dot3EfmeponMIB ? >>eponDeviceObjects OBJECT IDENTIFIER ::= { eponDevice 1} eponDevice is not defined, this might be eponDeviceObjectMIB? regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------=_NextPart_000_0072_01C3F4A1.E5D724E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: Sunday, January 25, = 2004 8:45=20 AM
To: jayaprakash.kulkarni@wipro.com
Subject: RE: = Minor=20 comments on draft-ietf-hubmib-efm-epon-mib-00.txt

Dear Jayaprakash,
Thank you very much for the comments. I = accept=20 them.
 
 
Best regards,
Lior Khermosh
Passave
 
 
-----Original Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Thursday, = January 22,=20 2004 8:55 AM
To: = lior.khermosh@passave.com
Subject: Minor=20 comments on draft-ietf-hubmib-efm-epon-mib-00.txt

 
Two = minor=20 comments on latest = draft-ietf-hubmib-efm-epon-mib-00.txt
 
>>EfmeponMIB=20 MODULE-IDENTITY
 
Should it be=20 dot3EfmeponMIB ?
 
 
>>eponDeviceObjects OBJECT = IDENTIFIER=20 ::=3D { eponDevice = 1}
 
eponDevice is not=20 defined, this might be eponDeviceObjectMIB?

regards
Jayaprakash
Confidentiality Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------=_NextPart_000_0072_01C3F4A1.E5D724E0-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 16 09:19:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16191 for ; Mon, 16 Feb 2004 08:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005Xr-VE; Mon, 16 Feb 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipE-0005Tv-5x for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 08:30:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16098 for ; Mon, 16 Feb 2004 08:30:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipD-0003Me-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:30:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioE-0003Hk-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:29:15 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsinE-0003Bi-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:28:12 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-24648057 for ; Mon, 16 Feb 2004 08:27:53 -0500 (EST) From: "Lior Khermosh" To: Date: Mon, 16 Feb 2004 15:31:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0076_01C3F4A1.E9047000" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_40_50, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Subject: [Hubmib] FW: eponDeviceObjectOnuRegisterStatus Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0076_01C3F4A1.E9047000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, January 25, 2004 8:45 AM To: jayaprakash.kulkarni@wipro.com Subject: RE: eponDeviceObjectOnuRegisterStatus Dear Jayaprakash, Thank you very much for the comment. I will replace that in a more clear device attribute - maybe something like device ready or ready to transmit/receive data or something like that. Best regards, Lior Khermosh Passave -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Thursday, January 22, 2004 2:32 PM To: lior.khermosh@passave.com Subject: eponDeviceObjectOnuRegisterStatus Hi Lior Further comments on draft-ietf-hubmib-efm-epon-mib-00.txt, Is there any speicifc reason that you have included eponDeviceObjectOnuRegisterStatus when dot3MpcpRegistrationState is available for obtaining the MPCP Registration State? regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------=_NextPart_000_0076_01C3F4A1.E9047000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: Sunday, January 25, = 2004 8:45=20 AM
To: jayaprakash.kulkarni@wipro.com
Subject: RE:=20 eponDeviceObjectOnuRegisterStatus

Dear=20 Jayaprakash,
Thank you very much for the=20 comment.
I will replace that in a more clear device = attribute -=20 maybe something like device ready or ready to transmit/receive data or = something=20 like that.
 
Best regards,
Lior Khermosh
Passave
 
-----Original Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Thursday, = January 22,=20 2004 2:32 PM
To: = lior.khermosh@passave.com
Subject:=20 eponDeviceObjectOnuRegisterStatus

Hi=20 Lior
 
Further comments on=20 draft-ietf-hubmib-efm-epon-mib-00.txt,
 
Is there any speicifc reason that you have = included=20 eponDeviceObjectOnuRegisterStatus when=20 dot3MpcpRegistrationState is available for obtaining the MPCP = Registration=20 State?
 
regards
Jayaprakash
 
 
Confidentiality =
Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------=_NextPart_000_0076_01C3F4A1.E9047000-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 16 09:19:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16186 for ; Mon, 16 Feb 2004 08:31:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005X2-Nm for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GDV2Q2021212 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005W2-Ep; Mon, 16 Feb 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipD-0005Tq-JS for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 08:30:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16095 for ; Mon, 16 Feb 2004 08:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipC-0003Ma-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioD-0003Hc-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:29:14 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsinE-0003Bh-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:28:12 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-14648057 for ; Mon, 16 Feb 2004 08:27:49 -0500 (EST) From: "Lior Khermosh" To: Date: Mon, 16 Feb 2004 15:31:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0072_01C3F4A1.E5D724E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY autolearn=no version=2.60 Subject: [Hubmib] FW: Minor comments on draft-ietf-hubmib-efm-epon-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0072_01C3F4A1.E5D724E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, January 25, 2004 8:45 AM To: jayaprakash.kulkarni@wipro.com Subject: RE: Minor comments on draft-ietf-hubmib-efm-epon-mib-00.txt Dear Jayaprakash, Thank you very much for the comments. I accept them. Best regards, Lior Khermosh Passave -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Thursday, January 22, 2004 8:55 AM To: lior.khermosh@passave.com Subject: Minor comments on draft-ietf-hubmib-efm-epon-mib-00.txt Two minor comments on latest draft-ietf-hubmib-efm-epon-mib-00.txt >>EfmeponMIB MODULE-IDENTITY Should it be dot3EfmeponMIB ? >>eponDeviceObjects OBJECT IDENTIFIER ::= { eponDevice 1} eponDevice is not defined, this might be eponDeviceObjectMIB? regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------=_NextPart_000_0072_01C3F4A1.E5D724E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: Sunday, January 25, = 2004 8:45=20 AM
To: jayaprakash.kulkarni@wipro.com
Subject: RE: = Minor=20 comments on draft-ietf-hubmib-efm-epon-mib-00.txt

Dear Jayaprakash,
Thank you very much for the comments. I = accept=20 them.
 
 
Best regards,
Lior Khermosh
Passave
 
 
-----Original Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Thursday, = January 22,=20 2004 8:55 AM
To: = lior.khermosh@passave.com
Subject: Minor=20 comments on draft-ietf-hubmib-efm-epon-mib-00.txt

 
Two = minor=20 comments on latest = draft-ietf-hubmib-efm-epon-mib-00.txt
 
>>EfmeponMIB=20 MODULE-IDENTITY
 
Should it be=20 dot3EfmeponMIB ?
 
 
>>eponDeviceObjects OBJECT = IDENTIFIER=20 ::=3D { eponDevice = 1}
 
eponDevice is not=20 defined, this might be eponDeviceObjectMIB?

regards
Jayaprakash
Confidentiality Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------=_NextPart_000_0072_01C3F4A1.E5D724E0-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 16 09:19:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16177 for ; Mon, 16 Feb 2004 08:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipy-0005Vk-33 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:31:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GDV1d6021165 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 08:31:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asipw-0005Uo-T7; Mon, 16 Feb 2004 08:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsipC-0005Te-12 for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 08:30:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16089 for ; Mon, 16 Feb 2004 08:30:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsipA-0003MQ-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:30:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsioB-0003HM-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:29:12 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AsinD-0003Bg-00 for hubmib@ietf.org; Mon, 16 Feb 2004 08:28:12 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-04648057 for ; Mon, 16 Feb 2004 08:27:41 -0500 (EST) From: "Lior Khermosh" To: Date: Mon, 16 Feb 2004 15:31:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006E_01C3F4A1.E14AE600" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE,HTML_TAG_EXISTS_TBODY,SUBJ_ALL_CAPS autolearn=no version=2.60 Subject: [Hubmib] FW: EPON-DEVICE-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_006E_01C3F4A1.E14AE600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 08, 2004 10:13 AM To: jayaprakash.kulkarni@wipro.com Subject: RE: EPON-DEVICE-MIB Jayaprakash, Thank you for your comments. I agree that the device modes can not be configure through the MIB so it is indeed a read-only attribute. I think that as for OAM mode is is required to receive from a device a state mode of its OAM where 3 equal options exist - Server client and NoOAM. We can add the OAM disabling/enabling in addition to that. Regards, Lior -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Friday, February 06, 2004 6:21 AM To: lior.khermosh@passave.com Subject: EPON-DEVICE-MIB Hi Lior In the EPON-DEVICE-MIB, eponDeviceObjectModes is defined as read-write, should it be a read-only value instead? eponDeviceObjectOamMode is also defined as read-write. Will eponDeviceObjectModes suffice to identify if the device is a oamServer or oamClient? For enabling/disabling the oam we could have a truth value. regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------=_NextPart_000_006E_01C3F4A1.E14AE600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: Lior Khermosh=20 [mailto:lior.khermosh@passave.com]
Sent: Sunday, February 08, = 2004=20 10:13 AM
To: jayaprakash.kulkarni@wipro.com
Subject: = RE:=20 EPON-DEVICE-MIB

Jayaprakash,
Thank you for your = comments.
I agree that the device modes can not be = configure=20 through the MIB so it is indeed a read-only=20 attribute.
I think that as for OAM mode is is required = to receive=20 from a device a state mode of its OAM where 3 equal options exist - = Server=20 client and NoOAM. We can add the OAM disabling/enabling in addition to=20 that.
 
Regards,
Lior
 
 
 
-----Original Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Friday, = February 06,=20 2004 6:21 AM
To: = lior.khermosh@passave.com
Subject:=20 EPON-DEVICE-MIB

Hi=20 Lior
 
In = the=20 EPON-DEVICE-MIB,
 
eponDeviceObjectModes is = defined as=20 read-write, should it be a read-only value=20 instead? 
 
eponDeviceObjectOamMode is also defined as read-write.=20
Will=20 eponDeviceObjectModes suffice to identify if the device is a oamServer = or=20 oamClient? For enabling/disabling the oam we could have a truth=20 value.
 
regards
Jayaprakash
 
 
 
 
 
Confidentiality Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------=_NextPart_000_006E_01C3F4A1.E14AE600-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 16 11:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28311 for ; Mon, 16 Feb 2004 11:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslF0-0000iz-W3; Mon, 16 Feb 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslEs-0000iI-No for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 11:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28182 for ; Mon, 16 Feb 2004 11:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslEq-0000Qv-00 for hubmib@ietf.org; Mon, 16 Feb 2004 11:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslCi-0007lt-00 for hubmib@ietf.org; Mon, 16 Feb 2004 11:02:40 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AslAc-0007Ik-00 for hubmib@ietf.org; Mon, 16 Feb 2004 11:00:30 -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 i1GFxbdZ017295 for ; Mon, 16 Feb 2004 10:59:37 -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 i1GFxYdZ017221 for ; Mon, 16 Feb 2004 10:59:35 -0500 (EST) 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: Mon, 16 Feb 2004 18:00:25 +0200 Message-ID: Thread-Topic: 59th IETF - Registration Thread-Index: AcP0pch4YSevaNSRSm6xGHRFylFW/AAAC8bw From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: 59th IETF - Registration Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Regards, Dan -----Original Message----- From: owner-ietf-announce@ietf.org = [mailto:owner-ietf-announce@ietf.org]On Behalf Of Marcia Beaulieu Sent: 16 February, 2004 5:31 PM To: IETF-Announce; @ietf.org@rhe.post.avaya.com Subject: 59th IETF - Registration We are currently experiencing technical problems with registration and will need to close registration for the next few hours. Once the problems have been corrected, we will send out another=20 message letting you know registration has reopened. Due to these problems, registration will be extended until Tuesday, February 17 at 12:00noon ET. Sorry for any inconvenience this may cause. IETF Secretariat _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 16 11:05:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28316 for ; Mon, 16 Feb 2004 11:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslF1-0000ju-Q0 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 11:05:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GG53rQ002820 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 11:05:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslF0-0000iz-W3; Mon, 16 Feb 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslEs-0000iI-No for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 11:04:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28182 for ; Mon, 16 Feb 2004 11:04:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslEq-0000Qv-00 for hubmib@ietf.org; Mon, 16 Feb 2004 11:04:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AslCi-0007lt-00 for hubmib@ietf.org; Mon, 16 Feb 2004 11:02:40 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AslAc-0007Ik-00 for hubmib@ietf.org; Mon, 16 Feb 2004 11:00:30 -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 i1GFxbdZ017295 for ; Mon, 16 Feb 2004 10:59:37 -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 i1GFxYdZ017221 for ; Mon, 16 Feb 2004 10:59:35 -0500 (EST) 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: Mon, 16 Feb 2004 18:00:25 +0200 Message-ID: Thread-Topic: 59th IETF - Registration Thread-Index: AcP0pch4YSevaNSRSm6xGHRFylFW/AAAC8bw From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: 59th IETF - Registration Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Regards, Dan -----Original Message----- From: owner-ietf-announce@ietf.org = [mailto:owner-ietf-announce@ietf.org]On Behalf Of Marcia Beaulieu Sent: 16 February, 2004 5:31 PM To: IETF-Announce; @ietf.org@rhe.post.avaya.com Subject: 59th IETF - Registration We are currently experiencing technical problems with registration and will need to close registration for the next few hours. Once the problems have been corrected, we will send out another=20 message letting you know registration has reopened. Due to these problems, registration will be extended until Tuesday, February 17 at 12:00noon ET. Sorry for any inconvenience this may cause. IETF Secretariat _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 16 12:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07966 for ; Mon, 16 Feb 2004 12:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asmjv-0000We-Nm for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 12:41:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GHf3FH002005 for hubmib-archive@odin.ietf.org; Mon, 16 Feb 2004 12:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asmjt-0000Vr-WB; Mon, 16 Feb 2004 12:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmjM-0000Ue-6l for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 12:40:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07922 for ; Mon, 16 Feb 2004 12:40:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmjK-0004Hk-00 for hubmib@ietf.org; Mon, 16 Feb 2004 12:40:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmiR-0004CS-00 for hubmib@ietf.org; Mon, 16 Feb 2004 12:39:31 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Asmha-00046f-00 for hubmib@ietf.org; Mon, 16 Feb 2004 12:38:38 -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 i1GHbidZ014491 for ; Mon, 16 Feb 2004 12:37:45 -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 i1GHbgdZ014479 for ; Mon, 16 Feb 2004 12:37:43 -0500 (EST) 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: Mon, 16 Feb 2004 19:38:34 +0200 Message-ID: Thread-Topic: 59th IETF Registration - Reopend Thread-Index: AcP0shgoVNEeuAxfQeCx4p33Rfq4oAAAYxcw From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: 59th IETF Registration - Reopend Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Regards, Dan -----Original Message----- From: owner-ietf-announce@ietf.org = [mailto:owner-ietf-announce@ietf.org]On Behalf Of = ietf-registrar@ietf.org Sent: 16 February, 2004 6:30 PM To: IETF-Announce; @ietf.org@rhe.post.avaya.com Subject: 59th IETF Registration - Reopend The registration problems we were experiencing earlier have been=20 corrected and registration has been reopened. The pre-registration and pre-payment cutoff has been extended to=20 Tuesday, February 17 at 12:00noon ET. Sorry for any inconvenience this may have caused. IETF Secretariat _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 16 12:41:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07964 for ; Mon, 16 Feb 2004 12:41:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asmjt-0000Vr-WB; Mon, 16 Feb 2004 12:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsmjM-0000Ue-6l for hubmib@optimus.ietf.org; Mon, 16 Feb 2004 12:40:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07922 for ; Mon, 16 Feb 2004 12:40:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsmjK-0004Hk-00 for hubmib@ietf.org; Mon, 16 Feb 2004 12:40:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsmiR-0004CS-00 for hubmib@ietf.org; Mon, 16 Feb 2004 12:39:31 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Asmha-00046f-00 for hubmib@ietf.org; Mon, 16 Feb 2004 12:38:38 -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 i1GHbidZ014491 for ; Mon, 16 Feb 2004 12:37:45 -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 i1GHbgdZ014479 for ; Mon, 16 Feb 2004 12:37:43 -0500 (EST) 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: Mon, 16 Feb 2004 19:38:34 +0200 Message-ID: Thread-Topic: 59th IETF Registration - Reopend Thread-Index: AcP0shgoVNEeuAxfQeCx4p33Rfq4oAAAYxcw From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: 59th IETF Registration - Reopend Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Regards, Dan -----Original Message----- From: owner-ietf-announce@ietf.org = [mailto:owner-ietf-announce@ietf.org]On Behalf Of = ietf-registrar@ietf.org Sent: 16 February, 2004 6:30 PM To: IETF-Announce; @ietf.org@rhe.post.avaya.com Subject: 59th IETF Registration - Reopend The registration problems we were experiencing earlier have been=20 corrected and registration has been reopened. The pre-registration and pre-payment cutoff has been extended to=20 Tuesday, February 17 at 12:00noon ET. Sorry for any inconvenience this may have caused. IETF Secretariat _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Feb 17 08:21:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27111 for ; Tue, 17 Feb 2004 08:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At59q-0007Uq-Jp; Tue, 17 Feb 2004 08:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At58u-0007Mb-B7 for hubmib@optimus.ietf.org; Tue, 17 Feb 2004 08:20:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27091 for ; Tue, 17 Feb 2004 08:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At58t-000673-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:20:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At57y-00064M-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:19:07 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1At57N-00061h-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:18:29 -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 i1HDEeT0020362 for ; Tue, 17 Feb 2004 08:14:40 -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 i1HDEbT0020313 for ; Tue, 17 Feb 2004 08:14:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F558.8679A451" Subject: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?) Date: Tue, 17 Feb 2004 15:18:25 +0200 Message-ID: Thread-Topic: Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gDENgQQ From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F558.8679A451 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Following a few responses that I received from people already having = booked their trip to Seoul, and the advice received from the Area = Director, my recommendation is to stick to the schedule and hold the = meting as planned.=20 =20 Please note that:=20 =20 - we have only one of the 3 doc editors present in the meeting.=20 - I would require the missing editors to submit a list of issues they = want us to discuss and try to resolve - we may not be as productive as we had hoped, but we will do our best Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Romascanu, Dan (Dan) Sent: 13 February, 2004 5:36 PM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F558.8679A451 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Following a few responses that I received from = people already=20 having booked their trip to Seoul, and the advice received from the Area = Director, my recommendation is to stick to the schedule and hold the = meting as=20 planned.
 
Please note that:
 
- we have only one of the 3 doc editors present in the meeting.=20
- I would=20 require the missing editors to submit a list of issues they = want us=20 to discuss and
  try to = resolve
- we may not be as productive as we had = hoped, but we will do our=20 best

Regards,

Dan

-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan=20 (Dan)
Sent: 13 February, 2004 5:36 PM
To:=20 hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: = [Hubmib]=20 Canceling the WG Meeting in Seoul?

I received in the last couple = of days=20 notifications from the editors of two of the three documents (generic = EFM MIB,=20 and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. = As it=20 looks like they cannot get somebody else to properly represent their = work in=20 the meeting, I am inclined to suggest that our meeting in Seoul be = cancelled.=20 This is not yet a final announcement, please respond whether you agree = or not=20 with canceling the meeting. If you think that we should meet, please = let me=20 know how you suggest to cover the agenda items.

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot comments, = and I=20 know that there are quite a lot of consistent changes the management = sections,=20 specifically in Clause 30 affecting this work. The discussions on = MIB-related=20 issues must be conducted on the hubmib WG list. Please remember that = in the=20 IETF work the WG list is the main media for work and communication, = ensuring=20 the fair and accessible change of views specific to the IETF process. = FYI, if=20 you have concerns about spam traffic - this list is manually = administered, and=20 as far as I know no spam traffic made it to the list in the last few=20 years.

Regards,

Dan

------_=_NextPart_001_01C3F558.8679A451-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Tue Feb 17 08:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27315 for ; Tue, 17 Feb 2004 08:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5IX-0007zM-Cn; Tue, 17 Feb 2004 08:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5Hc-0007rI-CO for hubmib@optimus.ietf.org; Tue, 17 Feb 2004 08:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27294 for ; Tue, 17 Feb 2004 08:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5Hb-0006bM-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5Gh-0006ZB-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:28:08 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1At5Ft-0006TI-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:27:17 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Feb 2004 15:33:02 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742044@il-mail02.actelis.net> From: Edward Beili To: "'Romascanu, Dan (Dan)'" , hubmib@ietf.org Cc: bwijnen@lucent.com Subject: RE: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?) Date: Tue, 17 Feb 2004 15:32:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F55A.8F1D4DF0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F55A.8F1D4DF0 Content-Type: text/plain; charset="windows-1255" Dan, When is the deadline for the issues list submission? -E. -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, February 17, 2004 03:18 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Cc: bwijnen@lucent.com Subject: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?) Following a few responses that I received from people already having booked their trip to Seoul, and the advice received from the Area Director, my recommendation is to stick to the schedule and hold the meting as planned. Please note that: - we have only one of the 3 doc editors present in the meeting. - I would require the missing editors to submit a list of issues they want us to discuss and try to resolve - we may not be as productive as we had hoped, but we will do our best Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 13 February, 2004 5:36 PM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items. I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F55A.8F1D4DF0 Content-Type: text/html; charset="windows-1255" Canceling the WG Meeting in Seoul?
Dan,
 
When is the deadline for the issues list submission?
-E.
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, February 17, 2004 03:18 PM
To: Romascanu, Dan (Dan); hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?)

Following a few responses that I received from people already having booked their trip to Seoul, and the advice received from the Area Director, my recommendation is to stick to the schedule and hold the meting as planned.
 
Please note that:
 
- we have only one of the 3 doc editors present in the meeting.
- I would require the missing editors to submit a list of issues they want us to discuss and
  try to resolve
- we may not be as productive as we had hoped, but we will do our best

Regards,

Dan

-----Original Message-----
From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan (Dan)
Sent: 13 February, 2004 5:36 PM
To: hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG Meeting in Seoul?

I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items.

I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F55A.8F1D4DF0-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Feb 17 08:30:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27332 for ; Tue, 17 Feb 2004 08:30:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5IY-00080T-Tn for hubmib-archive@odin.ietf.org; Tue, 17 Feb 2004 08:30:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HDU2Sh030747 for hubmib-archive@odin.ietf.org; Tue, 17 Feb 2004 08:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5IX-0007zM-Cn; Tue, 17 Feb 2004 08:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At5Hc-0007rI-CO for hubmib@optimus.ietf.org; Tue, 17 Feb 2004 08:29:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27294 for ; Tue, 17 Feb 2004 08:29:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At5Hb-0006bM-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:29:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At5Gh-0006ZB-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:28:08 -0500 Received: from [192.116.151.125] (helo=il-mail02.actelis.net) by ietf-mx with esmtp (Exim 4.12) id 1At5Ft-0006TI-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:27:17 -0500 Received: by il-mail02.actelis.net with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Feb 2004 15:33:02 +0200 Message-ID: <36EB88BFB60BD711B29C00062939CDF2742044@il-mail02.actelis.net> From: Edward Beili To: "'Romascanu, Dan (Dan)'" , hubmib@ietf.org Cc: bwijnen@lucent.com Subject: RE: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?) Date: Tue, 17 Feb 2004 15:32:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F55A.8F1D4DF0" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F55A.8F1D4DF0 Content-Type: text/plain; charset="windows-1255" Dan, When is the deadline for the issues list submission? -E. -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: Tuesday, February 17, 2004 03:18 PM To: Romascanu, Dan (Dan); hubmib@ietf.org Cc: bwijnen@lucent.com Subject: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?) Following a few responses that I received from people already having booked their trip to Seoul, and the advice received from the Area Director, my recommendation is to stick to the schedule and hold the meting as planned. Please note that: - we have only one of the 3 doc editors present in the meeting. - I would require the missing editors to submit a list of issues they want us to discuss and try to resolve - we may not be as productive as we had hoped, but we will do our best Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan (Dan) Sent: 13 February, 2004 5:36 PM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items. I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F55A.8F1D4DF0 Content-Type: text/html; charset="windows-1255" Canceling the WG Meeting in Seoul?
Dan,
 
When is the deadline for the issues list submission?
-E.
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Tuesday, February 17, 2004 03:18 PM
To: Romascanu, Dan (Dan); hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?)

Following a few responses that I received from people already having booked their trip to Seoul, and the advice received from the Area Director, my recommendation is to stick to the schedule and hold the meting as planned.
 
Please note that:
 
- we have only one of the 3 doc editors present in the meeting.
- I would require the missing editors to submit a list of issues they want us to discuss and
  try to resolve
- we may not be as productive as we had hoped, but we will do our best

Regards,

Dan

-----Original Message-----
From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan (Dan)
Sent: 13 February, 2004 5:36 PM
To: hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: [Hubmib] Canceling the WG Meeting in Seoul?

I received in the last couple of days notifications from the editors of two of the three documents (generic EFM MIB, and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. As it looks like they cannot get somebody else to properly represent their work in the meeting, I am inclined to suggest that our meeting in Seoul be cancelled. This is not yet a final announcement, please respond whether you agree or not with canceling the meeting. If you think that we should meet, please let me know how you suggest to cover the agenda items.

I frankly am concerned with the low level of technical traffic on the list lately. With the first round of WG drafts submitted, I was expecting more feedback and public review. I know that the IEEE drafts are stabilizing as result of the sponsor ballot comments, and I know that there are quite a lot of consistent changes the management sections, specifically in Clause 30 affecting this work. The discussions on MIB-related issues must be conducted on the hubmib WG list. Please remember that in the IETF work the WG list is the main media for work and communication, ensuring the fair and accessible change of views specific to the IETF process. FYI, if you have concerns about spam traffic - this list is manually administered, and as far as I know no spam traffic made it to the list in the last few years.

Regards,

Dan

------_=_NextPart_001_01C3F55A.8F1D4DF0-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Tue Feb 17 09:09:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27113 for ; Tue, 17 Feb 2004 08:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At59r-0007VP-LQ for hubmib-archive@odin.ietf.org; Tue, 17 Feb 2004 08:21:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HDL3PX028851 for hubmib-archive@odin.ietf.org; Tue, 17 Feb 2004 08:21:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At59q-0007Uq-Jp; Tue, 17 Feb 2004 08:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At58u-0007Mb-B7 for hubmib@optimus.ietf.org; Tue, 17 Feb 2004 08:20:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27091 for ; Tue, 17 Feb 2004 08:20:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At58t-000673-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:20:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At57y-00064M-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:19:07 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1At57N-00061h-00 for hubmib@ietf.org; Tue, 17 Feb 2004 08:18:29 -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 i1HDEeT0020362 for ; Tue, 17 Feb 2004 08:14:40 -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 i1HDEbT0020313 for ; Tue, 17 Feb 2004 08:14:38 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F558.8679A451" Subject: Meeting in Seoul (Was: RE: [Hubmib] Canceling the WG Meeting in Seoul?) Date: Tue, 17 Feb 2004 15:18:25 +0200 Message-ID: Thread-Topic: Canceling the WG Meeting in Seoul? Thread-Index: AcPyRyTTNvrWoK80TGGizim4esZq1gDENgQQ From: "Romascanu, Dan (Dan)" To: "Romascanu, Dan (Dan)" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.6 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F558.8679A451 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Following a few responses that I received from people already having = booked their trip to Seoul, and the advice received from the Area = Director, my recommendation is to stick to the schedule and hold the = meting as planned.=20 =20 Please note that:=20 =20 - we have only one of the 3 doc editors present in the meeting.=20 - I would require the missing editors to submit a list of issues they = want us to discuss and try to resolve - we may not be as productive as we had hoped, but we will do our best Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Romascanu, Dan (Dan) Sent: 13 February, 2004 5:36 PM To: hubmib@ietf.org Cc: bwijnen@lucent.com Subject: [Hubmib] Canceling the WG Meeting in Seoul? I received in the last couple of days notifications from the editors of = two of the three documents (generic EFM MIB, and EFM Cu MIB) that they = cannot make it to Seoul for the WG meeting. As it looks like they cannot = get somebody else to properly represent their work in the meeting, I am = inclined to suggest that our meeting in Seoul be cancelled. This is not = yet a final announcement, please respond whether you agree or not with = canceling the meeting. If you think that we should meet, please let me = know how you suggest to cover the agenda items.=20 I frankly am concerned with the low level of technical traffic on the = list lately. With the first round of WG drafts submitted, I was = expecting more feedback and public review. I know that the IEEE drafts = are stabilizing as result of the sponsor ballot comments, and I know = that there are quite a lot of consistent changes the management = sections, specifically in Clause 30 affecting this work. The discussions = on MIB-related issues must be conducted on the hubmib WG list. Please = remember that in the IETF work the WG list is the main media for work = and communication, ensuring the fair and accessible change of views = specific to the IETF process. FYI, if you have concerns about spam = traffic - this list is manually administered, and as far as I know no = spam traffic made it to the list in the last few years. Regards, Dan ------_=_NextPart_001_01C3F558.8679A451 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Canceling the WG Meeting in Seoul?
Following a few responses that I received from = people already=20 having booked their trip to Seoul, and the advice received from the Area = Director, my recommendation is to stick to the schedule and hold the = meting as=20 planned.
 
Please note that:
 
- we have only one of the 3 doc editors present in the meeting.=20
- I would=20 require the missing editors to submit a list of issues they = want us=20 to discuss and
  try to = resolve
- we may not be as productive as we had = hoped, but we will do our=20 best

Regards,

Dan

-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Romascanu, Dan=20 (Dan)
Sent: 13 February, 2004 5:36 PM
To:=20 hubmib@ietf.org
Cc: bwijnen@lucent.com
Subject: = [Hubmib]=20 Canceling the WG Meeting in Seoul?

I received in the last couple = of days=20 notifications from the editors of two of the three documents (generic = EFM MIB,=20 and EFM Cu MIB) that they cannot make it to Seoul for the WG meeting. = As it=20 looks like they cannot get somebody else to properly represent their = work in=20 the meeting, I am inclined to suggest that our meeting in Seoul be = cancelled.=20 This is not yet a final announcement, please respond whether you agree = or not=20 with canceling the meeting. If you think that we should meet, please = let me=20 know how you suggest to cover the agenda items.

I frankly am concerned with = the low level=20 of technical traffic on the list lately. With the first round of WG = drafts=20 submitted, I was expecting more feedback and public review. I know = that the=20 IEEE drafts are stabilizing as result of the sponsor ballot comments, = and I=20 know that there are quite a lot of consistent changes the management = sections,=20 specifically in Clause 30 affecting this work. The discussions on = MIB-related=20 issues must be conducted on the hubmib WG list. Please remember that = in the=20 IETF work the WG list is the main media for work and communication, = ensuring=20 the fair and accessible change of views specific to the IETF process. = FYI, if=20 you have concerns about spam traffic - this list is manually = administered, and=20 as far as I know no spam traffic made it to the list in the last few=20 years.

Regards,

Dan

------_=_NextPart_001_01C3F558.8679A451-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Feb 19 01:51:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16972 for ; Thu, 19 Feb 2004 01:51:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati1W-0003QO-Fh; Thu, 19 Feb 2004 01:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati1R-0003Q4-Ip for hubmib@optimus.ietf.org; Thu, 19 Feb 2004 01:50:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16967 for ; Thu, 19 Feb 2004 01:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ati1O-00074O-00 for hubmib@ietf.org; Thu, 19 Feb 2004 01:50:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ati0O-00072m-00 for hubmib@ietf.org; Thu, 19 Feb 2004 01:49:53 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1Athzf-00070B-00 for hubmib@ietf.org; Thu, 19 Feb 2004 01:49:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Thu, 19 Feb 2004 01:48:38 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714E5FAA4@mailserv.hatteras.com> Thread-Topic: Dot3OamEntry in EFM-COMMON-MIB Thread-Index: AcPfR9zHn/qxjeKfQWm9dxCmXwkSoANGxtOwARC8IfABgphMkA== From: "Matt Squire" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jayaprakash -=20 Some responses in-line > (1) Its a good idea that dot3Oam events need to be sent as SNMP traps. > A SNMP trap can send all the attributes specified in the standard >=20 > But, I feel, running total fields would still need to be defined=20 > in some table. What do you say? Let me make sure I understand. The defined error events provide = thresholds for=20 a) frame errors b) symbol errors c) errored seconds We already have C30 counters and MIB variables for frame errors, so we = do have a "running total" for frame errors. But you're right in that I = don't think we have symbol errors or errored seconds reflected in C30 or = a MIB. =20 My guess is that it may be possible to get a counter for errored seconds = in the MIB. A symbol error has been discussed in the past, and my = recollection is that the majority of people were very against it as it = has such a high update rate that it would be hard to maintain accurately = across the management interfaces provided. So I don't know that getting = a symbol error counter into C30 would float, and if its not there, we're = not going to get a counter in the MIB. =20 > (2) A seperate issue regarding dot3OamEventConfigTable: >=20 > How do we set the peer values for entities defined in this table, > as I understand peer entities are not a part of the ifTable, will=20 > there be a dot3OamPeerEventConfigTable? In that case SNMP traps=20 > for dot3OamPeer events also needs to be defined. > > your thoughts? > Dot3 OAM had the self-imposed mandate for no "set" capability. If you = want to "set" parameters on a remote device, it could be done either = locally at that device (e.g. CLI), or via telnet/SNMP/whatever. But = .3ah OAM can't help configure a peer entity. =20 We've tried to pick defaults so that configuration, in most cases, isn't = required. =20 - Matt > regards > Jayaprakash _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Feb 19 01:51:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16974 for ; Thu, 19 Feb 2004 01:51:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati1X-0003Qt-6V for hubmib-archive@odin.ietf.org; Thu, 19 Feb 2004 01:51:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1J6p3kB013190 for hubmib-archive@odin.ietf.org; Thu, 19 Feb 2004 01:51:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati1W-0003QO-Fh; Thu, 19 Feb 2004 01:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ati1R-0003Q4-Ip for hubmib@optimus.ietf.org; Thu, 19 Feb 2004 01:50:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16967 for ; Thu, 19 Feb 2004 01:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ati1O-00074O-00 for hubmib@ietf.org; Thu, 19 Feb 2004 01:50:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ati0O-00072m-00 for hubmib@ietf.org; Thu, 19 Feb 2004 01:49:53 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1Athzf-00070B-00 for hubmib@ietf.org; Thu, 19 Feb 2004 01:49:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Thu, 19 Feb 2004 01:48:38 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714E5FAA4@mailserv.hatteras.com> Thread-Topic: Dot3OamEntry in EFM-COMMON-MIB Thread-Index: AcPfR9zHn/qxjeKfQWm9dxCmXwkSoANGxtOwARC8IfABgphMkA== From: "Matt Squire" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Jayaprakash -=20 Some responses in-line > (1) Its a good idea that dot3Oam events need to be sent as SNMP traps. > A SNMP trap can send all the attributes specified in the standard >=20 > But, I feel, running total fields would still need to be defined=20 > in some table. What do you say? Let me make sure I understand. The defined error events provide = thresholds for=20 a) frame errors b) symbol errors c) errored seconds We already have C30 counters and MIB variables for frame errors, so we = do have a "running total" for frame errors. But you're right in that I = don't think we have symbol errors or errored seconds reflected in C30 or = a MIB. =20 My guess is that it may be possible to get a counter for errored seconds = in the MIB. A symbol error has been discussed in the past, and my = recollection is that the majority of people were very against it as it = has such a high update rate that it would be hard to maintain accurately = across the management interfaces provided. So I don't know that getting = a symbol error counter into C30 would float, and if its not there, we're = not going to get a counter in the MIB. =20 > (2) A seperate issue regarding dot3OamEventConfigTable: >=20 > How do we set the peer values for entities defined in this table, > as I understand peer entities are not a part of the ifTable, will=20 > there be a dot3OamPeerEventConfigTable? In that case SNMP traps=20 > for dot3OamPeer events also needs to be defined. > > your thoughts? > Dot3 OAM had the self-imposed mandate for no "set" capability. If you = want to "set" parameters on a remote device, it could be done either = locally at that device (e.g. CLI), or via telnet/SNMP/whatever. But = .3ah OAM can't help configure a peer entity. =20 We've tried to pick defaults so that configuration, in most cases, isn't = required. =20 - Matt > regards > Jayaprakash _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Feb 19 06:34:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15001 for ; Thu, 19 Feb 2004 06:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmRM-0001pL-Rq; Thu, 19 Feb 2004 06:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmQV-0001gw-TC for hubmib@optimus.ietf.org; Thu, 19 Feb 2004 06:33:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14901 for ; Thu, 19 Feb 2004 06:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmQR-0007MF-00 for hubmib@ietf.org; Thu, 19 Feb 2004 06:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtmPX-0007JE-00 for hubmib@ietf.org; Thu, 19 Feb 2004 06:32:08 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AtmOi-0007Gw-00 for hubmib@ietf.org; Thu, 19 Feb 2004 06:31:16 -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 i1JBRRjG011423 for ; Thu, 19 Feb 2004 06:27:27 -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 i1JBROjG011398 for ; Thu, 19 Feb 2004 06:27:25 -0500 (EST) 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: Thu, 19 Feb 2004 13:31:14 +0200 Message-ID: Thread-Topic: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Thread-Index: AcP21GLrdmKlB3CsS+maFd8FnLgR1wABxp9Q From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I have 'borrowed' this message from another WG list. I think that the = information is relevant for the participants in the hubmib WG, as well = as for the whole IETF process participants. Please feel free to contact = me if there are questions. Regards, Dan -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus = Westerlund Sent: 19 February, 2004 12:32 PM To: IETF AVT WG Subject: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Hi, I would like to make all WG participants aware of that 3 RFC has been=20 published that updates your rights in submission to the IETF. I would=20 recommend that you look at them. Reasons why you should look at them = are: - RFC 3667 updates what an Internet draft needs to contain, thus it is=20 important that any document editor reads this. - RFC 3667 also regulates what rights you grant with any contribution to = the IETF. Please note that as contribution is also counted email to the=20 WG, speaking at the WG meeting. Please read the RFC for authoritative=20 text on this. - RFC 3668 describes what rules that apply for IPR disclosures, thus it=20 applies to any contributing to the IETF. - RFC 3669 contains guidelines for how to handle IPR in the WG. This can = be useful reading for people discussing, having or disclosing IPR. See document information, abstract and links below. Cheers Magnus BCP 78 RFC 3667 Title: IETF Rights in Contributions Author(s): S. Bradner Status: Best Current Practice Date: February 2004 Mailbox: sob@harvard.edu Pages: 18 Characters: 43297 SeeAlso: BCP 78 I-D Tag: draft-ietf-ipr-submission-rights-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3667.txt The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. BCP 79 RFC 3668 Title: Intellectual Property Rights in IETF Technology Author(s): S. Bradner Status: Best Current Practice Date: February 2004 Mailbox: sob@harvard.edu Pages: 17 Characters: 41365 SeeAlso: BCP 79 I-D Tag: draft-ietf-ipr-technology-rights-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3668.txt The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. RFC 3669 Title: Guidelines for Working Groups on Intellectual Property Issues Author(s): S. Brim Status: Informational Date: February 2004 Mailbox: sbrim@cisco.com Pages: 17 Characters: 40946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipr-wg-guidelines-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3669.txt This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Feb 19 06:34:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15017 for ; Thu, 19 Feb 2004 06:34:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmRN-0001q2-Hq for hubmib-archive@odin.ietf.org; Thu, 19 Feb 2004 06:34:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JBY1TT007061 for hubmib-archive@odin.ietf.org; Thu, 19 Feb 2004 06:34:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmRM-0001pL-Rq; Thu, 19 Feb 2004 06:34:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtmQV-0001gw-TC for hubmib@optimus.ietf.org; Thu, 19 Feb 2004 06:33:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14901 for ; Thu, 19 Feb 2004 06:33:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtmQR-0007MF-00 for hubmib@ietf.org; Thu, 19 Feb 2004 06:33:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtmPX-0007JE-00 for hubmib@ietf.org; Thu, 19 Feb 2004 06:32:08 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AtmOi-0007Gw-00 for hubmib@ietf.org; Thu, 19 Feb 2004 06:31:16 -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 i1JBRRjG011423 for ; Thu, 19 Feb 2004 06:27:27 -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 i1JBROjG011398 for ; Thu, 19 Feb 2004 06:27:25 -0500 (EST) 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: Thu, 19 Feb 2004 13:31:14 +0200 Message-ID: Thread-Topic: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Thread-Index: AcP21GLrdmKlB3CsS+maFd8FnLgR1wABxp9Q From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] FW: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I have 'borrowed' this message from another WG list. I think that the = information is relevant for the participants in the hubmib WG, as well = as for the whole IETF process participants. Please feel free to contact = me if there are questions. Regards, Dan -----Original Message----- From: avt-admin@ietf.org [mailto:avt-admin@ietf.org]On Behalf Of Magnus = Westerlund Sent: 19 February, 2004 12:32 PM To: IETF AVT WG Subject: [AVT] Updated RFCs on Copyright and IPR in relation to IETF Hi, I would like to make all WG participants aware of that 3 RFC has been=20 published that updates your rights in submission to the IETF. I would=20 recommend that you look at them. Reasons why you should look at them = are: - RFC 3667 updates what an Internet draft needs to contain, thus it is=20 important that any document editor reads this. - RFC 3667 also regulates what rights you grant with any contribution to = the IETF. Please note that as contribution is also counted email to the=20 WG, speaking at the WG meeting. Please read the RFC for authoritative=20 text on this. - RFC 3668 describes what rules that apply for IPR disclosures, thus it=20 applies to any contributing to the IETF. - RFC 3669 contains guidelines for how to handle IPR in the WG. This can = be useful reading for people discussing, having or disclosing IPR. See document information, abstract and links below. Cheers Magnus BCP 78 RFC 3667 Title: IETF Rights in Contributions Author(s): S. Bradner Status: Best Current Practice Date: February 2004 Mailbox: sob@harvard.edu Pages: 18 Characters: 43297 SeeAlso: BCP 78 I-D Tag: draft-ietf-ipr-submission-rights-08.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3667.txt The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026, and, with RFC 3668, replaces Section 10 of RFC 2026. BCP 79 RFC 3668 Title: Intellectual Property Rights in IETF Technology Author(s): S. Bradner Status: Best Current Practice Date: February 2004 Mailbox: sob@harvard.edu Pages: 17 Characters: 41365 SeeAlso: BCP 79 I-D Tag: draft-ietf-ipr-technology-rights-12.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3668.txt The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information about any IPR constraints on a technical proposal as possible. The policies are also intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This memo details the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This memo updates RFC 2026 and, with RFC 3667, replaces Section 10 of RFC 2026. This memo also updates paragraph 4 of Section 3.2 of RFC 2028, for all purposes, including reference [2] in RFC 2418. RFC 3669 Title: Guidelines for Working Groups on Intellectual Property Issues Author(s): S. Brim Status: Informational Date: February 2004 Mailbox: sbrim@cisco.com Pages: 17 Characters: 40946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipr-wg-guidelines-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3669.txt This memo lays out a conceptual framework and rules of thumb useful for working groups dealing with Intellectual Property Rights (IPR) issues. It documents specific examples of how IPR issues have been dealt with in the IETF. --=20 Magnus Westerlund Multimedia Technologies, Ericsson Research EAB/TVA/A ---------------------------------------------------------------------- Ericsson AB | Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com This communication is confidential and intended solely for the = addressee(s). Any unauthorized review, use, disclosure or distribution = is prohibited. If you believe this message has been sent to you in = error, please notify the sender by replying to this transmission and = delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, = interruption, unauthorized amendment, tampering and viruses, and we only = send and receive e-mails on the basis that we are not liable for any = such corruption, interception, amendment, tampering or viruses or any = consequences thereof. _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Feb 19 08:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18698 for ; Thu, 19 Feb 2004 08:54:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atocs-0003gA-2Z; Thu, 19 Feb 2004 08:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtocH-0003e9-QB for hubmib@optimus.ietf.org; Thu, 19 Feb 2004 08:53:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18632 for ; Thu, 19 Feb 2004 08:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtocG-0005Nk-00 for hubmib@ietf.org; Thu, 19 Feb 2004 08:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtobL-0005JD-00 for hubmib@ietf.org; Thu, 19 Feb 2004 08:52:30 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1AtoaM-0005Ai-00 for hubmib@ietf.org; Thu, 19 Feb 2004 08:51:26 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id 0AC6418F680; Thu, 19 Feb 2004 05:57:58 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Feb 2004 05:47:38 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A22@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'Lior Khermosh'" , "'hubmib@ietf.org'" Cc: "Hariprasad V. Nair" Date: Thu, 19 Feb 2004 05:47:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F6EE.EC5901D8" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F6EE.EC5901D8 Content-Type: text/plain Hello Mr.Khermosh, One more query in addition to the ones I sent few days back. 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We donot have any reference to these in the 802.3ah drafts. If I am not wrong, these two are replaced by the 'SyncTime' in the draft 1.414 itself. Should we reflect this in the MIB too? Or am I missing something?! Thanks Raj. -----Original Message----- From: Rajagopalan Subramanian Sent: Monday, February 16, 2004 5:49 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------_=_NextPart_001_01C3F6EE.EC5901D8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello = Mr.Khermosh,

 

One more query in addition to the = ones I sent few days back.

 

3.  In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverS= ettlingTime and  dot3MpcpCdrLockTi= me.

We donot have any reference to = these in the 802.3ah drafts.  If I am = not wrong, these two are replaced by the ‘SyncTime’ in the draft 1.414 itself. Should we reflect this in the MIB = too?

 

Or am I missing = something?!

 

Thanks =

Raj.

 

-----Original = Message-----
From: Rajagopalan = Subramanian
Sent: = Monday, February 16, = 2004 5:49 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: Hariprasad V. = Nair
Subject: RE: = Clarifications in EPON Device MIB

 

Hello Mr. = Khermosh,

 

Thanks for your = reply. I am forwarding the earlier questions posted by me and your reply for = that,  to the mailing = list.

 

Few more = questions on your reply :

 

=

1. Currently, as = far as I know,  the standard = 802.3ah does not suggest a de-asserting mechanism.

 

While standard = specify a way to report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the = case for all the Errored Events though an assertion and de-assertion is possible = in this case without deviating from the standard, I = think.

However all the = Global Events, Temperature and Voltage specific events and the Vendor = SpecificAlarm Events,  are not defined = in the standard. Can they be optional then?

 

2. One thing I = missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to = the eponDeviceObjectVendorSpecificEventState attribute. Or are they = different?  Please = clarify.

 

Thanks

Raj = Subramanian.

 

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Sunday, February 15, = 2004 12:34 PM
To: Rajagopalan = Subramanian
Subject: RE: = Clarifications in EPON Device MIB

 

Dear = Mr. Subramanian,

 

Thank you very = much for your comments. They are very helpful. I would like to ask the = permission to send the comments and replies to the hubmib reflector for the = interest of all people.

 

eponDeviceObjectOnuLoopba= ck – As defined now it is redundant and should be removed. =

 

From eponDeviceObjectDyingGaspAlarmState :

When the dyingGaspAlarm state is removed the dying gasp alarm is = reset.

I added it to the text.

 

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

 

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed so I suggest to = keep them. I will add a description.

 

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed. Iwill add = a description.

 

The difference in my = opinion is:

 

Alarm:=

When the value of the alarm input is above the threshold defined for the = alarm the alarm is asserted. When the condition is below that threshold the alarm = is de-asserted.

 

Event:=

When the indication of the event input occurs the event is asserted. When = the input is removed that event is de-asserted.

 

Event is more referring = to a system condition while alarm indicates a bad thing happening in the = system.

 

eponDeviceObjectPowerDown=

I think it is. An ONU = might have a battery back up and when the device is starting to get down it = indicates Power down. In my opinion it is a very important indication for the = carrier.

 

 

Best = regards,

Lior = Khermosh

 

 

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Wednesday, February 11, = 2004 6:51 AM
To: = 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications = in EPON Device MIB

Hello = Mr.Khermosh,

 <= /font>

I have few questions in = the Device MIB that you had proposed as part of the = draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you = can help me get it clarified.

 =

eponDeviceObjectOnuLoopba= ck = –

In what way is this = attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. = In an implementation should both of these be = supported?

 =

 =

From eponDeviceObjectDyingGaspAlarmState (Entry 8) to = eponDeviceObjectOrganizationSpecificEventState(Entry 27) –

The SYNTAX in the MIB = attribute says it’s a TruthValue and the description says that ‘this = bit should be asserted when we receive the corresponding event’. My = question is : The bit will be set when we receive an event but when will we = reset it ? It cannot be always ‘1’ whenever the user reads this = attribute, right?

 =

 =

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

The description says = ‘ this event defines the state of the *resp= ective* event of the OAM Alarm Indications as specified in the [802.3ah] clause = 57.

But I could not locate = these attributes in the Draft2.0 version of the standard. Can you give me = pointers as to where I should be looking into?

 =

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The description for = these two attributes are Identical.  I could not a VendorAlarm and a = VendorEvent, separately in the clause 57. Can you give some info = please?

 =

eponDeviceObjectPowerDown=

Is setting the PowerDown = a valid scenario for the EPON?

 =

Thanks for your = time.

 

Regards,

Raj = Subramanian

Centillium India,

Bangalore, INDIA=

+91 80 25523575

 

------_=_NextPart_001_01C3F6EE.EC5901D8-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Feb 19 08:54:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18706 for ; Thu, 19 Feb 2004 08:54:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atoct-0003h5-28 for hubmib-archive@odin.ietf.org; Thu, 19 Feb 2004 08:54:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JDs2P2014158 for hubmib-archive@odin.ietf.org; Thu, 19 Feb 2004 08:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atocs-0003gA-2Z; Thu, 19 Feb 2004 08:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtocH-0003e9-QB for hubmib@optimus.ietf.org; Thu, 19 Feb 2004 08:53:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18632 for ; Thu, 19 Feb 2004 08:53:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtocG-0005Nk-00 for hubmib@ietf.org; Thu, 19 Feb 2004 08:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtobL-0005JD-00 for hubmib@ietf.org; Thu, 19 Feb 2004 08:52:30 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1AtoaM-0005Ai-00 for hubmib@ietf.org; Thu, 19 Feb 2004 08:51:26 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id 0AC6418F680; Thu, 19 Feb 2004 05:57:58 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Feb 2004 05:47:38 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A22@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'Lior Khermosh'" , "'hubmib@ietf.org'" Cc: "Hariprasad V. Nair" Date: Thu, 19 Feb 2004 05:47:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F6EE.EC5901D8" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F6EE.EC5901D8 Content-Type: text/plain Hello Mr.Khermosh, One more query in addition to the ones I sent few days back. 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We donot have any reference to these in the 802.3ah drafts. If I am not wrong, these two are replaced by the 'SyncTime' in the draft 1.414 itself. Should we reflect this in the MIB too? Or am I missing something?! Thanks Raj. -----Original Message----- From: Rajagopalan Subramanian Sent: Monday, February 16, 2004 5:49 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------_=_NextPart_001_01C3F6EE.EC5901D8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hello = Mr.Khermosh,

 

One more query in addition to the = ones I sent few days back.

 

3.  In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverS= ettlingTime and  dot3MpcpCdrLockTi= me.

We donot have any reference to = these in the 802.3ah drafts.  If I am = not wrong, these two are replaced by the ‘SyncTime’ in the draft 1.414 itself. Should we reflect this in the MIB = too?

 

Or am I missing = something?!

 

Thanks =

Raj.

 

-----Original = Message-----
From: Rajagopalan = Subramanian
Sent: = Monday, February 16, = 2004 5:49 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: Hariprasad V. = Nair
Subject: RE: = Clarifications in EPON Device MIB

 

Hello Mr. = Khermosh,

 

Thanks for your = reply. I am forwarding the earlier questions posted by me and your reply for = that,  to the mailing = list.

 

Few more = questions on your reply :

 

=

1. Currently, as = far as I know,  the standard = 802.3ah does not suggest a de-asserting mechanism.

 

While standard = specify a way to report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the = case for all the Errored Events though an assertion and de-assertion is possible = in this case without deviating from the standard, I = think.

However all the = Global Events, Temperature and Voltage specific events and the Vendor = SpecificAlarm Events,  are not defined = in the standard. Can they be optional then?

 

2. One thing I = missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to = the eponDeviceObjectVendorSpecificEventState attribute. Or are they = different?  Please = clarify.

 

Thanks

Raj = Subramanian.

 

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Sunday, February 15, = 2004 12:34 PM
To: Rajagopalan = Subramanian
Subject: RE: = Clarifications in EPON Device MIB

 

Dear = Mr. Subramanian,

 

Thank you very = much for your comments. They are very helpful. I would like to ask the = permission to send the comments and replies to the hubmib reflector for the = interest of all people.

 

eponDeviceObjectOnuLoopba= ck – As defined now it is redundant and should be removed. =

 

From eponDeviceObjectDyingGaspAlarmState :

When the dyingGaspAlarm state is removed the dying gasp alarm is = reset.

I added it to the text.

 

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

 

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed so I suggest to = keep them. I will add a description.

 

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed. Iwill add = a description.

 

The difference in my = opinion is:

 

Alarm:=

When the value of the alarm input is above the threshold defined for the = alarm the alarm is asserted. When the condition is below that threshold the alarm = is de-asserted.

 

Event:=

When the indication of the event input occurs the event is asserted. When = the input is removed that event is de-asserted.

 

Event is more referring = to a system condition while alarm indicates a bad thing happening in the = system.

 

eponDeviceObjectPowerDown=

I think it is. An ONU = might have a battery back up and when the device is starting to get down it = indicates Power down. In my opinion it is a very important indication for the = carrier.

 

 

Best = regards,

Lior = Khermosh

 

 

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Wednesday, February 11, = 2004 6:51 AM
To: = 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications = in EPON Device MIB

Hello = Mr.Khermosh,

 <= /font>

I have few questions in = the Device MIB that you had proposed as part of the = draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you = can help me get it clarified.

 =

eponDeviceObjectOnuLoopba= ck = –

In what way is this = attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. = In an implementation should both of these be = supported?

 =

 =

From eponDeviceObjectDyingGaspAlarmState (Entry 8) to = eponDeviceObjectOrganizationSpecificEventState(Entry 27) –

The SYNTAX in the MIB = attribute says it’s a TruthValue and the description says that ‘this = bit should be asserted when we receive the corresponding event’. My = question is : The bit will be set when we receive an event but when will we = reset it ? It cannot be always ‘1’ whenever the user reads this = attribute, right?

 =

 =

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

The description says = ‘ this event defines the state of the *resp= ective* event of the OAM Alarm Indications as specified in the [802.3ah] clause = 57.

But I could not locate = these attributes in the Draft2.0 version of the standard. Can you give me = pointers as to where I should be looking into?

 =

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The description for = these two attributes are Identical.  I could not a VendorAlarm and a = VendorEvent, separately in the clause 57. Can you give some info = please?

 =

eponDeviceObjectPowerDown=

Is setting the PowerDown = a valid scenario for the EPON?

 =

Thanks for your = time.

 

Regards,

Raj = Subramanian

Centillium India,

Bangalore, INDIA=

+91 80 25523575

 

------_=_NextPart_001_01C3F6EE.EC5901D8-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Feb 20 01:01:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19387 for ; Fri, 20 Feb 2004 01:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3ie-0005xk-Ge; Fri, 20 Feb 2004 01:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3iK-0005sg-Cj for hubmib@optimus.ietf.org; Fri, 20 Feb 2004 01:00:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19362 for ; Fri, 20 Feb 2004 01:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3iH-00054a-00 for hubmib@ietf.org; Fri, 20 Feb 2004 01:00:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3hN-00052n-00 for hubmib@ietf.org; Fri, 20 Feb 2004 00:59:43 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1Au3go-0004xw-00 for hubmib@ietf.org; Fri, 20 Feb 2004 00:59:06 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id B1BC118F6BA; Thu, 19 Feb 2004 22:08:48 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Feb 2004 21:58:30 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A24@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'MSquire@HatterasNetworks.com'" Cc: "'hubmib@ietf.org'" Date: Thu, 19 Feb 2004 21:58:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F776.8D9CFC30" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F776.8D9CFC30 Content-Type: text/plain Hi Matt, Its good to have Traps to report whenever there is an OAM event. But according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as 'GET' attributes of am OAM object class. The definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 also implies that they should be updated as and when we receive or send an Event Notification. This made me believe that these events should also be maintained as SNMP (statistics) table attributes. Your thoughts please. Thanks Raj Subramanian -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Friday, February 06, 2004 9:14 AM Thats a good question. I'm still a little unsure of how to best map the event tables into MIB stuff. But we will almost definitly include the running totals into the event information, along with all of the other fields in the event TLVs. One possibility is to simply map each OAM event to a notification (SNMP trap), where we take all fields (including the running totals) into the trap. Thats the way I'm leaning presently, where we don't maintain any SNMP tables for the events, and instead just map them to SNMP traps. If you think thats good/bad, let me know. - Matt -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Tuesday, January 20, 2004 6:24 AM To: Matt Squire Subject: Dot3OamEntry in EFM-COMMON-MIB Hi Matt Got one more doubt while going through the draft-squire-hubmib-efm-mib-00.txt Are you planning to provide the following running-total counters in the Dot3OamEntry along with the dot3OamThreshold and Config objects? dot3OamErrSymRunningTotal dot3OamErrFrameSecsSummaryRunningTotal dot3OamErrFrameRunningTotal dot3OamErrFramePeriodRunningTotal regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------_=_NextPart_001_01C3F776.8D9CFC30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Hi = Matt,

Its good = to have Traps to report whenever there is an OAM event. =

 

But = according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed = as ‘GET’ attributes of am OAM object class.

The = definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 also implies that = they should be updated as and when we receive or send an Event = Notification.

This = made me believe that these events should also be maintained as SNMP = (statistics) table attributes.

 

Your = thoughts please.

 

Thanks

Raj = Subramanian

 

 

-----Original Message-----
From: Matt Squire [mailto:MSquire@HatterasNetworks.com]
Sent: = Friday, February 06, = 2004 9:14 AM

 

Thats a good question.  I'm still a little unsure of how to best map the event = tables into MIB stuff.  But we will almost definitly include the running totals into the event information, along = with all of the other fields in the event TLVs.  =

 

One possibility = is to simply map each OAM event to a notification (SNMP trap), where we take = all fields (including the running totals) into the trap.  Thats the = way I'm leaning presently, where we don't maintain any SNMP tables for the = events, and instead just map them to SNMP traps.  If you think thats good/bad, = let me know. 

 

- = Matt

-----Original Message-----
From: = jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Tuesday, January = 20, 2004 6:24 AM
To: Matt Squire
Subject: Dot3OamEntry in EFM-COMMON-MIB

Hi = Matt

 

Got one more doubt while = going through the = draft-squire-hubmib-efm-mib-00.txt

 

Are you planning to = provide the following running-total counters in the Dot3OamEntry along with the dot3OamThreshold and Config objects?

 

dot3OamErrSymRunningTotal<= /span>

dot3OamErrFrameSecsSummary= RunningTotal

dot3OamErrFrameRunningTota= l

dot3OamErrFramePeriodRunni= ngTotal

 

regards=

Jayaprakash<= o:p>

 

Confidentiality =
Notice
 
 
The information contained in this electronic message and =
any attachments to this message are =
intended
for the exclusive use of the addressee(s) and may =
contain confidential or privileged information. =
If
you are not the intended recipient, please notify the =
sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 

Confidentiality Notice


The information contained in this electronic message and any =
attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro =
or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------_=_NextPart_001_01C3F776.8D9CFC30-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Fri Feb 20 01:01:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19391 for ; Fri, 20 Feb 2004 01:01:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3if-0005yI-LB for hubmib-archive@odin.ietf.org; Fri, 20 Feb 2004 01:01:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K611rl022948 for hubmib-archive@odin.ietf.org; Fri, 20 Feb 2004 01:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3ie-0005xk-Ge; Fri, 20 Feb 2004 01:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au3iK-0005sg-Cj for hubmib@optimus.ietf.org; Fri, 20 Feb 2004 01:00:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19362 for ; Fri, 20 Feb 2004 01:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au3iH-00054a-00 for hubmib@ietf.org; Fri, 20 Feb 2004 01:00:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au3hN-00052n-00 for hubmib@ietf.org; Fri, 20 Feb 2004 00:59:43 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1Au3go-0004xw-00 for hubmib@ietf.org; Fri, 20 Feb 2004 00:59:06 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id B1BC118F6BA; Thu, 19 Feb 2004 22:08:48 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Thu, 19 Feb 2004 21:58:30 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A24@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'MSquire@HatterasNetworks.com'" Cc: "'hubmib@ietf.org'" Date: Thu, 19 Feb 2004 21:58:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F776.8D9CFC30" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F776.8D9CFC30 Content-Type: text/plain Hi Matt, Its good to have Traps to report whenever there is an OAM event. But according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as 'GET' attributes of am OAM object class. The definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 also implies that they should be updated as and when we receive or send an Event Notification. This made me believe that these events should also be maintained as SNMP (statistics) table attributes. Your thoughts please. Thanks Raj Subramanian -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com] Sent: Friday, February 06, 2004 9:14 AM Thats a good question. I'm still a little unsure of how to best map the event tables into MIB stuff. But we will almost definitly include the running totals into the event information, along with all of the other fields in the event TLVs. One possibility is to simply map each OAM event to a notification (SNMP trap), where we take all fields (including the running totals) into the trap. Thats the way I'm leaning presently, where we don't maintain any SNMP tables for the events, and instead just map them to SNMP traps. If you think thats good/bad, let me know. - Matt -----Original Message----- From: jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com] Sent: Tuesday, January 20, 2004 6:24 AM To: Matt Squire Subject: Dot3OamEntry in EFM-COMMON-MIB Hi Matt Got one more doubt while going through the draft-squire-hubmib-efm-mib-00.txt Are you planning to provide the following running-total counters in the Dot3OamEntry along with the dot3OamThreshold and Config objects? dot3OamErrSymRunningTotal dot3OamErrFrameSecsSummaryRunningTotal dot3OamErrFrameRunningTotal dot3OamErrFramePeriodRunningTotal regards Jayaprakash Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------_=_NextPart_001_01C3F776.8D9CFC30 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message

Hi = Matt,

Its good = to have Traps to report whenever there is an OAM event. =

 

But = according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed = as ‘GET’ attributes of am OAM object class.

The = definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 also implies that = they should be updated as and when we receive or send an Event = Notification.

This = made me believe that these events should also be maintained as SNMP = (statistics) table attributes.

 

Your = thoughts please.

 

Thanks

Raj = Subramanian

 

 

-----Original Message-----
From: Matt Squire [mailto:MSquire@HatterasNetworks.com]
Sent: = Friday, February 06, = 2004 9:14 AM

 

Thats a good question.  I'm still a little unsure of how to best map the event = tables into MIB stuff.  But we will almost definitly include the running totals into the event information, along = with all of the other fields in the event TLVs.  =

 

One possibility = is to simply map each OAM event to a notification (SNMP trap), where we take = all fields (including the running totals) into the trap.  Thats the = way I'm leaning presently, where we don't maintain any SNMP tables for the = events, and instead just map them to SNMP traps.  If you think thats good/bad, = let me know. 

 

- = Matt

-----Original Message-----
From: = jayaprakash.kulkarni@wipro.com [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Tuesday, January = 20, 2004 6:24 AM
To: Matt Squire
Subject: Dot3OamEntry in EFM-COMMON-MIB

Hi = Matt

 

Got one more doubt while = going through the = draft-squire-hubmib-efm-mib-00.txt

 

Are you planning to = provide the following running-total counters in the Dot3OamEntry along with the dot3OamThreshold and Config objects?

 

dot3OamErrSymRunningTotal<= /span>

dot3OamErrFrameSecsSummary= RunningTotal

dot3OamErrFrameRunningTota= l

dot3OamErrFramePeriodRunni= ngTotal

 

regards=

Jayaprakash<= o:p>

 

Confidentiality =
Notice
 
 
The information contained in this electronic message and =
any attachments to this message are =
intended
for the exclusive use of the addressee(s) and may =
contain confidential or privileged information. =
If
you are not the intended recipient, please notify the =
sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 

Confidentiality Notice


The information contained in this electronic message and any =
attachments to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro =
or Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------_=_NextPart_001_01C3F776.8D9CFC30-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Feb 20 11:59:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01738 for ; Fri, 20 Feb 2004 11:59:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDzR-0001Im-C7; Fri, 20 Feb 2004 11:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDyW-0001GS-6x for hubmib@optimus.ietf.org; Fri, 20 Feb 2004 11:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01707 for ; Fri, 20 Feb 2004 11:58:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDyU-0007XK-00 for hubmib@ietf.org; Fri, 20 Feb 2004 11:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDxa-0007Ue-00 for hubmib@ietf.org; Fri, 20 Feb 2004 11:57:08 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AuDxH-0007Rg-00 for hubmib@ietf.org; Fri, 20 Feb 2004 11:56:47 -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 i1KGtrXo025389 for ; Fri, 20 Feb 2004 11:55:53 -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 i1KGtnXo025343 for ; Fri, 20 Feb 2004 11:55:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F7D2.8419D753" Subject: RE: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Date: Fri, 20 Feb 2004 18:56:42 +0200 Message-ID: Thread-Topic: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Thread-Index: AcP3dvLyGXxh/LvrRT63lsy0pYmzxwAWr23Q From: "Romascanu, Dan (Dan)" To: "Rajagopalan Subramanian" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,TRACKER_ID autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F7D2.8419D753 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Raj, =20 There is no need to keep a strict relationship between the Clause 30 = definitions and the SNMP MIB. From a Hubmib Charter point of view, we = are looking at the IEEE 802.3 standard as a source and reference for the = IETF MIBs, but we are allowed to take different approaches when needed. = From a technical point of view Clause 30 describes the MAC level = management model, while the SNMP MIB, may take a different approach, = dictated by the operational requirements of management in an Internet = environment.=20 =20 On a different note, I would recommend to use the correct SNMP = terminology - i.e. Notifications, rather than Traps (which are a sub-set = of SNMPv3 Notifications). =20 Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Rajagopalan Subramanian Sent: 20 February, 2004 7:58 AM To: 'MSquire@HatterasNetworks.com' Cc: 'hubmib@ietf.org' Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Hi Matt, Its good to have Traps to report whenever there is an OAM event.=20 =20 But according to the 802.3ah Standard, in the section 30A.19, = aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = 'GET' attributes of am OAM object class. The definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also implies that they should be updated as and when we receive or send = an Event Notification. This made me believe that these events should also be maintained as SNMP = (statistics) table attributes. =20 Your thoughts please. =20 Thanks Raj Subramanian =20 =20 -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com]=20 Sent: Friday, February 06, 2004 9:14 AM =20 Thats a good question. I'm still a little unsure of how to best map the = event tables into MIB stuff. But we will almost definitly include the = running totals into the event information, along with all of the other = fields in the event TLVs. =20 =20 One possibility is to simply map each OAM event to a notification (SNMP = trap), where we take all fields (including the running totals) into the = trap. Thats the way I'm leaning presently, where we don't maintain any = SNMP tables for the events, and instead just map them to SNMP traps. If = you think thats good/bad, let me know. =20 =20 - Matt -----Original Message----- From: jayaprakash.kulkarni@wipro.com = [mailto:jayaprakash.kulkarni@wipro.com] Sent: Tuesday, January 20, 2004 6:24 AM To: Matt Squire Subject: Dot3OamEntry in EFM-COMMON-MIB Hi Matt =20 Got one more doubt while going through the = draft-squire-hubmib-efm-mib-00.txt =20 Are you planning to provide the following running-total counters in the = Dot3OamEntry along with the dot3OamThreshold and Config objects? =20 dot3OamErrSymRunningTotal dot3OamErrFrameSecsSummaryRunningTotal dot3OamErrFrameRunningTotal dot3OamErrFramePeriodRunningTotal =20 regards Jayaprakash =20 Confidentiality Notice =20 =20 The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. =20 Confidentiality Notice The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------_=_NextPart_001_01C3F7D2.8419D753 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Raj,
 
There is no need to keep a strict relationship between the = Clause 30=20 definitions and the SNMP MIB. From a Hubmib Charter point of view, we = are=20 looking at the IEEE 802.3 standard as a source and reference for the = IETF MIBs,=20 but we are allowed to take different approaches when needed. From a = technical=20 point of view Clause 30 describes the MAC level management = model,=20 while the SNMP MIB, may take a different approach, dictated by = the=20 operational requirements of management in an Internet environment.=20
 
On a different note, I would recommend to use the correct SNMP=20 terminology - i.e. Notifications, rather than Traps (which are a sub-set = of=20 SNMPv3 Notifications).
 

Regards,

Dan

-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Rajagopalan=20 Subramanian
Sent: 20 February, 2004 7:58 AM
To:=20 'MSquire@HatterasNetworks.com'
Cc:=20 'hubmib@ietf.org'
Subject: [Hubmib] RE: Dot3OamEntry in=20 EFM-COMMON-MIB

Hi=20 Matt,

Its = good to=20 have Traps to report whenever there is an OAM event.=20

 

But=20 according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = ‘GET’ attributes=20 of am OAM object class.

The=20 definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also=20 implies that they should be updated as and when we receive or send an = Event=20 Notification.

This made=20 me believe that these events should also be maintained as SNMP = (statistics)=20 table attributes.

 

Your=20 thoughts please.

 

Thanks

Raj=20 Subramanian

 

 

-----Original=20 Message-----
From: = Matt=20 Squire [mailto:MSquire@HatterasNetworks.com]
Sent: Friday, February 06,=20 2004 = 9:14=20 AM

 

Thats a good=20 question.  I'm still a little unsure of how to best map the event = tables=20 into MIB stuff. =20 But=20 we will almost definitly include the running totals into the event=20 information, along with all of the other fields in the event=20 TLVs. 

 

One=20 possibility is to simply map each OAM event to a notification (SNMP = trap),=20 where we take all fields (including the running totals) into the = trap. =20 Thats the way I'm leaning presently, where we don't maintain any SNMP = tables=20 for the events, and instead just map them to SNMP traps.  If you = think=20 thats good/bad, let me know. 

 

-=20 Matt

-----Original=20 Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Tuesday, January 20, = 2004 6:24=20 AM
To: Matt=20 Squire
Subject:=20 Dot3OamEntry in EFM-COMMON-MIB

Hi=20 Matt

 

Got one more doubt = while going=20 through the=20 = draft-squire-hubmib-efm-mib-00.txt

 

Are you planning to = provide the=20 following running-total counters in the Dot3OamEntry along with the=20 dot3OamThreshold and Config = objects?

 

dot3OamErrSymRunningTotal

dot3OamErrFrameSecsSummaryRunningTotal

dot3OamErrFrameRunningTotal

dot3OamErrFramePeriodRunningTotal

 

regards

Jayaprakash

 

Confidentiality =
Notice
 
 
The information contained in this electronic message and any =
attachments to this message are =
intended
for =
the exclusive use of the addressee(s) and may contain confidential or =
privileged information. If
you are not the intended recipient, please notify =
the sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 

Confidentiality =
Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------_=_NextPart_001_01C3F7D2.8419D753-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Fri Feb 20 11:59:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01755 for ; Fri, 20 Feb 2004 11:59:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDzS-0001JD-1H for hubmib-archive@odin.ietf.org; Fri, 20 Feb 2004 11:59:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KGx1Eu005021 for hubmib-archive@odin.ietf.org; Fri, 20 Feb 2004 11:59:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDzR-0001Im-C7; Fri, 20 Feb 2004 11:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuDyW-0001GS-6x for hubmib@optimus.ietf.org; Fri, 20 Feb 2004 11:58:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01707 for ; Fri, 20 Feb 2004 11:58:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuDyU-0007XK-00 for hubmib@ietf.org; Fri, 20 Feb 2004 11:58:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuDxa-0007Ue-00 for hubmib@ietf.org; Fri, 20 Feb 2004 11:57:08 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AuDxH-0007Rg-00 for hubmib@ietf.org; Fri, 20 Feb 2004 11:56:47 -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 i1KGtrXo025389 for ; Fri, 20 Feb 2004 11:55:53 -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 i1KGtnXo025343 for ; Fri, 20 Feb 2004 11:55:51 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F7D2.8419D753" Subject: RE: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Date: Fri, 20 Feb 2004 18:56:42 +0200 Message-ID: Thread-Topic: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Thread-Index: AcP3dvLyGXxh/LvrRT63lsy0pYmzxwAWr23Q From: "Romascanu, Dan (Dan)" To: "Rajagopalan Subramanian" , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.1 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,TRACKER_ID autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F7D2.8419D753 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Raj, =20 There is no need to keep a strict relationship between the Clause 30 = definitions and the SNMP MIB. From a Hubmib Charter point of view, we = are looking at the IEEE 802.3 standard as a source and reference for the = IETF MIBs, but we are allowed to take different approaches when needed. = From a technical point of view Clause 30 describes the MAC level = management model, while the SNMP MIB, may take a different approach, = dictated by the operational requirements of management in an Internet = environment.=20 =20 On a different note, I would recommend to use the correct SNMP = terminology - i.e. Notifications, rather than Traps (which are a sub-set = of SNMPv3 Notifications). =20 Regards, Dan -----Original Message----- From: hubmib-admin@ietf.org [mailto:hubmib-admin@ietf.org]On Behalf Of = Rajagopalan Subramanian Sent: 20 February, 2004 7:58 AM To: 'MSquire@HatterasNetworks.com' Cc: 'hubmib@ietf.org' Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Hi Matt, Its good to have Traps to report whenever there is an OAM event.=20 =20 But according to the 802.3ah Standard, in the section 30A.19, = aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = 'GET' attributes of am OAM object class. The definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also implies that they should be updated as and when we receive or send = an Event Notification. This made me believe that these events should also be maintained as SNMP = (statistics) table attributes. =20 Your thoughts please. =20 Thanks Raj Subramanian =20 =20 -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com]=20 Sent: Friday, February 06, 2004 9:14 AM =20 Thats a good question. I'm still a little unsure of how to best map the = event tables into MIB stuff. But we will almost definitly include the = running totals into the event information, along with all of the other = fields in the event TLVs. =20 =20 One possibility is to simply map each OAM event to a notification (SNMP = trap), where we take all fields (including the running totals) into the = trap. Thats the way I'm leaning presently, where we don't maintain any = SNMP tables for the events, and instead just map them to SNMP traps. If = you think thats good/bad, let me know. =20 =20 - Matt -----Original Message----- From: jayaprakash.kulkarni@wipro.com = [mailto:jayaprakash.kulkarni@wipro.com] Sent: Tuesday, January 20, 2004 6:24 AM To: Matt Squire Subject: Dot3OamEntry in EFM-COMMON-MIB Hi Matt =20 Got one more doubt while going through the = draft-squire-hubmib-efm-mib-00.txt =20 Are you planning to provide the following running-total counters in the = Dot3OamEntry along with the dot3OamThreshold and Config objects? =20 dot3OamErrSymRunningTotal dot3OamErrFrameSecsSummaryRunningTotal dot3OamErrFrameRunningTotal dot3OamErrFramePeriodRunningTotal =20 regards Jayaprakash =20 Confidentiality Notice =20 =20 The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. =20 Confidentiality Notice The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------_=_NextPart_001_01C3F7D2.8419D753 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Raj,
 
There is no need to keep a strict relationship between the = Clause 30=20 definitions and the SNMP MIB. From a Hubmib Charter point of view, we = are=20 looking at the IEEE 802.3 standard as a source and reference for the = IETF MIBs,=20 but we are allowed to take different approaches when needed. From a = technical=20 point of view Clause 30 describes the MAC level management = model,=20 while the SNMP MIB, may take a different approach, dictated by = the=20 operational requirements of management in an Internet environment.=20
 
On a different note, I would recommend to use the correct SNMP=20 terminology - i.e. Notifications, rather than Traps (which are a sub-set = of=20 SNMPv3 Notifications).
 

Regards,

Dan

-----Original Message-----
From: = hubmib-admin@ietf.org=20 [mailto:hubmib-admin@ietf.org]On Behalf Of Rajagopalan=20 Subramanian
Sent: 20 February, 2004 7:58 AM
To:=20 'MSquire@HatterasNetworks.com'
Cc:=20 'hubmib@ietf.org'
Subject: [Hubmib] RE: Dot3OamEntry in=20 EFM-COMMON-MIB

Hi=20 Matt,

Its = good to=20 have Traps to report whenever there is an OAM event.=20

 

But=20 according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = ‘GET’ attributes=20 of am OAM object class.

The=20 definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also=20 implies that they should be updated as and when we receive or send an = Event=20 Notification.

This made=20 me believe that these events should also be maintained as SNMP = (statistics)=20 table attributes.

 

Your=20 thoughts please.

 

Thanks

Raj=20 Subramanian

 

 

-----Original=20 Message-----
From: = Matt=20 Squire [mailto:MSquire@HatterasNetworks.com]
Sent: Friday, February 06,=20 2004 = 9:14=20 AM

 

Thats a good=20 question.  I'm still a little unsure of how to best map the event = tables=20 into MIB stuff. =20 But=20 we will almost definitly include the running totals into the event=20 information, along with all of the other fields in the event=20 TLVs. 

 

One=20 possibility is to simply map each OAM event to a notification (SNMP = trap),=20 where we take all fields (including the running totals) into the = trap. =20 Thats the way I'm leaning presently, where we don't maintain any SNMP = tables=20 for the events, and instead just map them to SNMP traps.  If you = think=20 thats good/bad, let me know. 

 

-=20 Matt

-----Original=20 Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Tuesday, January 20, = 2004 6:24=20 AM
To: Matt=20 Squire
Subject:=20 Dot3OamEntry in EFM-COMMON-MIB

Hi=20 Matt

 

Got one more doubt = while going=20 through the=20 = draft-squire-hubmib-efm-mib-00.txt

 

Are you planning to = provide the=20 following running-total counters in the Dot3OamEntry along with the=20 dot3OamThreshold and Config = objects?

 

dot3OamErrSymRunningTotal

dot3OamErrFrameSecsSummaryRunningTotal

dot3OamErrFrameRunningTotal

dot3OamErrFramePeriodRunningTotal

 

regards

Jayaprakash

 

Confidentiality =
Notice
 
 
The information contained in this electronic message and any =
attachments to this message are =
intended
for =
the exclusive use of the addressee(s) and may contain confidential or =
privileged information. If
you are not the intended recipient, please notify =
the sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 

Confidentiality =
Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------_=_NextPart_001_01C3F7D2.8419D753-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Feb 22 03:30:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20287 for ; Sun, 22 Feb 2004 03:30:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auozx-0007Wo-UP; Sun, 22 Feb 2004 03:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuS2s-0002Kq-H6 for hubmib@optimus.ietf.org; Sat, 21 Feb 2004 02:59:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20597 for ; Sat, 21 Feb 2004 02:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuS2o-0005zn-00 for hubmib@ietf.org; Sat, 21 Feb 2004 02:59:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuS1q-0005xf-00 for hubmib@ietf.org; Sat, 21 Feb 2004 02:58:29 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AuS1R-0005vo-00 for hubmib@ietf.org; Sat, 21 Feb 2004 02:58:01 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-045006267; Sat, 21 Feb 2004 02:57:50 -0500 (EST) From: "Lior Khermosh" To: "Rajagopalan Subramanian" , Cc: "Hariprasad V. Nair" Date: Sat, 21 Feb 2004 10:01:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C3F861.A3A324C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A22@apollo.centillium_nt.centillium.com> Importance: Normal X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C3F861.A3A324C0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA20598 Content-Transfer-Encoding: quoted-printable Raj, Indeed the MPCP is using sync time which is the addition of both. Without intervening with MPCP considerations the optical devices has separate agc and cdr times which from management perspective are very interesting to b= e exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to the= m as different parameters which only the added time is complying). In order= to comply to the MPCP I will add an attribute for sync time but my opinion i= s that agc and cdr time should also be maintained for management. Best regards, Lior -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Thursday, February 19, 2004 3:48 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr.Khermosh, One more query in addition to the ones I sent few days back. 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We donot have any reference to these in the 802.3ah drafts. If I am no= t wrong, these two are replaced by the =91SyncTime=92 in the draft 1.414 it= self. Should we reflect this in the MIB too? Or am I missing something?! Thanks Raj. -----Original Message----- From: Rajagopalan Subramanian Sent: Monday, February 16, 2004 5:49 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by = me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest = a de-asserting mechanism. While standard specify a way to report the Critical link event, link fa= ult and Dying Gasp events in the form of Flags field in the OAMPDU, it does = not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard= , I think. However all the Global Events, Temperature and Voltage specific events = and the Vendor SpecificAlarm Events, are not defined in the standard. Can th= ey be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to t= he eponDeviceObjectVendorSpecificEventState attribute. Or are they different= ? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would l= ike to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback =96 As defined now it is redundant and shou= ld be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State=85=85=85=85=85=85=85. eponDeviceObjectG= lobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for th= e alarm the alarm is asserted. When the condition is below that threshold t= he alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. Wh= en the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a b= ad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device = is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part = of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can hel= p me get it clarified. eponDeviceObjectOnuLoopback =96 In what way is this attribute different from the one defined in the E= FM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) =96 The SYNTAX in the MIB attribute says it=92s a TruthValue and the description says that =91this bit should be asserted when we receive the corresponding event=92. My question is : The bit will be set when we rece= ive an event but when will we reset it ? It cannot be always =911=92 whenever= the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State=85=85=85=85=85=85=85. eponDeviceObjectG= lobalEvent7State The description says =91 this event defines the state of the *respect= ive* event of the OAM Alarm Indications as specified in the [802.3ah] clause 5= 7. But I could not locate these attributes in the Draft2.0 version of th= e standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not = a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------=_NextPart_000_0035_01C3F861.A3A324C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Raj,
Indeed=20 the MPCP is using sync time which is the addition of both. Without = intervening=20 with MPCP considerations the optical devices has separate agc and cdr = times=20 which from management perspective are very interesting to be=20 exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to = them as=20 different parameters which only the added time is complying). In order = to comply=20 to the MPCP I will add an attribute for sync time but my opinion is that = agc and=20 cdr time should also be maintained for management.
 
 
Best=20 regards,
Lior
 
-----Original Message-----
From: Rajagopalan = Subramanian=20 [mailto:rajas@Centillium.com]
Sent: Thursday, February 19, = 2004 3:48=20 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: = Hariprasad=20 V. Nair
Subject: RE: Clarifications in EPON Device=20 MIB

Hello=20 Mr.Khermosh,

 

One more query = in=20 addition to the ones I sent few days = back.

 

3.  In the dot3MpcpEntry table : = there are=20 two fields dot3MpcpReceiverSettlingTime=20 and  dot3MpcpCdrLockTime.

We donot have = any=20 reference to these in the 802.3ah drafts.  If I am not wrong, these two = are=20 replaced by the ‘SyncTime’=20 in the draft 1.414 itself. Should we reflect this in the MIB=20 too?

 

Or am I = missing=20 something?!

 

Thanks=20

Raj.

 

-----Original=20 Message-----
From:=20 Rajagopalan Subramanian
Sent: Monday, February 16,=20 2004 = 5:49=20 PM
To: 'Lior Khermosh';=20 'hubmib@ietf.org'
Cc:=20 Hariprasad V. Nair
Subject:=20 RE: Clarifications in EPON Device MIB

 

Hello Mr.=20 Khermosh,

 

Thanks for=20 your reply. I am forwarding the earlier questions posted by me and = your reply=20 for that,  to the = mailing=20 list.

 

Few more=20 questions on your reply :

 

1.=20 Currently, as far as I know,  = the=20 standard 802.3ah does not suggest a de-asserting mechanism.=20

 

While=20 standard specify a way to report the Critical link event, link fault = and=20 Dying  Gasp events in = the form of=20 Flags field in the OAMPDU, it does not talk about resetting=20 them.

Similar is=20 the case for all the Errored Events though an assertion and = de-assertion is=20 possible in this case without deviating from the standard, I=20 think.

However all=20 the Global Events, Temperature and Voltage specific events and the = Vendor=20 SpecificAlarm Events,  = are not=20 defined in the standard. Can they be optional=20 then?

 

2. One=20 thing I missed to point out in my previous mail : Attribute=20 eponDeviceObjectOrganizationSpecificEventState seems to be identical = to the=20 eponDeviceObjectVendorSpecificEventState attribute. Or are they=20 different?  Please=20 clarify.

 

Thanks

Raj=20 Subramanian.

 

 

-----Original=20 Message-----
From: = Lior=20 Khermosh [mailto:lior.khermosh@passave.com]
Sent: Sunday, February 15,=20 2004 = 12:34=20 PM
To: Rajagopalan = Subramanian
Subject: RE: Clarifications in = EPON=20 Device MIB

 

Dear=20 Mr. = Subramanian,

 

Thank you=20 very much for your comments. They are very helpful. I would like to = ask the=20 permission to send the comments and replies to the hubmib = reflector for=20 the interest of all people.

 

eponDeviceObjectOnuLoopback – As=20 defined now it is redundant and should be removed.=20

 

From=20 eponDeviceObjectDyingGaspAlarmState = :

When=20 the dyingGaspAlarm state is removed the dying gasp alarm is=20 reset.

I=20 added it to the text.

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

 

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed so I = suggest to=20 keep them. I will add a description.

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed. Iwill = add a=20 description.

 

The difference in my = opinion=20 is:

 

Alarm:

When=20 the value of the alarm input is above the threshold defined for the = alarm the=20 alarm is asserted. When the condition is below that threshold the = alarm is=20 de-asserted.

 

Event:

When=20 the indication of the event input occurs the event is asserted. When = the input=20 is removed that event is de-asserted.

 

Event is more = referring to a=20 system condition while alarm indicates a bad thing happening in the=20 system.

 

eponDeviceObjectPowerDown=20

I think it is. An ONU = might have=20 a battery back up and when the device is starting to get down it = indicates=20 Power down. In my opinion it is a very important indication for the=20 carrier.

 

 

Best=20 regards,

Lior=20 Khermosh

 

 

 

-----Original=20 Message-----
From:=20 Rajagopalan Subramanian [mailto:rajas@Centillium.com]
Sent: Wednesday, February = 11,=20 2004 = 6:51=20 AM
To:=20 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications in = EPON Device=20 MIB

Hello=20 Mr.Khermosh,

 

I have few questions = in the=20 Device MIB that you had proposed as part of the=20 draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you can help me get it=20 clarified.

 

eponDeviceObjectOnuLoopback=20 –

In what way is this = attribute=20 different from the one defined in the EFM MIB, = dot3OamLoopbackCommand. In an=20 implementation should both of these be=20 supported?

 

 

From=20 eponDeviceObjectDyingGaspAlarmState (Entry 8) to=20 eponDeviceObjectOrganizationSpecificEventState(Entry=20 27)=20 –

The SYNTAX in the = MIB=20 attribute says it’s a TruthValue and the description says that = ‘this bit=20 should be asserted when we receive the corresponding event’. = My question is=20 : The bit will be set when we receive an event but when will we = reset it ?=20 It cannot be always ‘1’ whenever the user reads this = attribute,=20 right?

 

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

The description says = ‘ this=20 event defines the state of the *respective* event of the OAM = Alarm=20 Indications as specified in the [802.3ah] clause=20 57.

But I could not = locate these=20 attributes in the Draft2.0 version of the standard. Can you give me = pointers=20 as to where I should be looking into?

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The description for = these two=20 attributes are Identical.  I could not a VendorAlarm and a = VendorEvent,=20 separately in the clause 57. Can you give some info=20 please?

 

eponDeviceObjectPowerDown=20

Is setting the = PowerDown a=20 valid scenario for the EPON?

 

Thanks for your=20 time.

 

Regards,

Raj=20 Subramanian

Centillium=20 India,=20

Bangalore,=20 INDIA

+91=20 80 25523575

 

<= /BODY> ------=_NextPart_000_0035_01C3F861.A3A324C0-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Feb 22 03:30:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20305 for ; Sun, 22 Feb 2004 03:30:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auozz-0007X1-LD for hubmib-archive@odin.ietf.org; Sun, 22 Feb 2004 03:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1M8U3Hq028949 for hubmib-archive@odin.ietf.org; Sun, 22 Feb 2004 03:30:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auozx-0007Wo-UP; Sun, 22 Feb 2004 03:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuS2s-0002Kq-H6 for hubmib@optimus.ietf.org; Sat, 21 Feb 2004 02:59:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20597 for ; Sat, 21 Feb 2004 02:59:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuS2o-0005zn-00 for hubmib@ietf.org; Sat, 21 Feb 2004 02:59:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuS1q-0005xf-00 for hubmib@ietf.org; Sat, 21 Feb 2004 02:58:29 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AuS1R-0005vo-00 for hubmib@ietf.org; Sat, 21 Feb 2004 02:58:01 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.90vs) with SMTP id 2-045006267; Sat, 21 Feb 2004 02:57:50 -0500 (EST) From: "Lior Khermosh" To: "Rajagopalan Subramanian" , Cc: "Hariprasad V. Nair" Date: Sat, 21 Feb 2004 10:01:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01C3F861.A3A324C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A22@apollo.centillium_nt.centillium.com> Importance: Normal X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0035_01C3F861.A3A324C0 Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id CAA20598 Content-Transfer-Encoding: quoted-printable Raj, Indeed the MPCP is using sync time which is the addition of both. Without intervening with MPCP considerations the optical devices has separate agc and cdr times which from management perspective are very interesting to b= e exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to the= m as different parameters which only the added time is complying). In order= to comply to the MPCP I will add an attribute for sync time but my opinion i= s that agc and cdr time should also be maintained for management. Best regards, Lior -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Thursday, February 19, 2004 3:48 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr.Khermosh, One more query in addition to the ones I sent few days back. 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We donot have any reference to these in the 802.3ah drafts. If I am no= t wrong, these two are replaced by the =91SyncTime=92 in the draft 1.414 it= self. Should we reflect this in the MIB too? Or am I missing something?! Thanks Raj. -----Original Message----- From: Rajagopalan Subramanian Sent: Monday, February 16, 2004 5:49 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by = me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest = a de-asserting mechanism. While standard specify a way to report the Critical link event, link fa= ult and Dying Gasp events in the form of Flags field in the OAMPDU, it does = not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard= , I think. However all the Global Events, Temperature and Voltage specific events = and the Vendor SpecificAlarm Events, are not defined in the standard. Can th= ey be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to t= he eponDeviceObjectVendorSpecificEventState attribute. Or are they different= ? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would l= ike to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback =96 As defined now it is redundant and shou= ld be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State=85=85=85=85=85=85=85. eponDeviceObjectG= lobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for th= e alarm the alarm is asserted. When the condition is below that threshold t= he alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. Wh= en the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a b= ad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device = is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part = of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can hel= p me get it clarified. eponDeviceObjectOnuLoopback =96 In what way is this attribute different from the one defined in the E= FM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) =96 The SYNTAX in the MIB attribute says it=92s a TruthValue and the description says that =91this bit should be asserted when we receive the corresponding event=92. My question is : The bit will be set when we rece= ive an event but when will we reset it ? It cannot be always =911=92 whenever= the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State=85=85=85=85=85=85=85. eponDeviceObjectG= lobalEvent7State The description says =91 this event defines the state of the *respect= ive* event of the OAM Alarm Indications as specified in the [802.3ah] clause 5= 7. But I could not locate these attributes in the Draft2.0 version of th= e standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not = a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------=_NextPart_000_0035_01C3F861.A3A324C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Raj,
Indeed=20 the MPCP is using sync time which is the addition of both. Without = intervening=20 with MPCP considerations the optical devices has separate agc and cdr = times=20 which from management perspective are very interesting to be=20 exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to = them as=20 different parameters which only the added time is complying). In order = to comply=20 to the MPCP I will add an attribute for sync time but my opinion is that = agc and=20 cdr time should also be maintained for management.
 
 
Best=20 regards,
Lior
 
-----Original Message-----
From: Rajagopalan = Subramanian=20 [mailto:rajas@Centillium.com]
Sent: Thursday, February 19, = 2004 3:48=20 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: = Hariprasad=20 V. Nair
Subject: RE: Clarifications in EPON Device=20 MIB

Hello=20 Mr.Khermosh,

 

One more query = in=20 addition to the ones I sent few days = back.

 

3.  In the dot3MpcpEntry table : = there are=20 two fields dot3MpcpReceiverSettlingTime=20 and  dot3MpcpCdrLockTime.

We donot have = any=20 reference to these in the 802.3ah drafts.  If I am not wrong, these two = are=20 replaced by the ‘SyncTime’=20 in the draft 1.414 itself. Should we reflect this in the MIB=20 too?

 

Or am I = missing=20 something?!

 

Thanks=20

Raj.

 

-----Original=20 Message-----
From:=20 Rajagopalan Subramanian
Sent: Monday, February 16,=20 2004 = 5:49=20 PM
To: 'Lior Khermosh';=20 'hubmib@ietf.org'
Cc:=20 Hariprasad V. Nair
Subject:=20 RE: Clarifications in EPON Device MIB

 

Hello Mr.=20 Khermosh,

 

Thanks for=20 your reply. I am forwarding the earlier questions posted by me and = your reply=20 for that,  to the = mailing=20 list.

 

Few more=20 questions on your reply :

 

1.=20 Currently, as far as I know,  = the=20 standard 802.3ah does not suggest a de-asserting mechanism.=20

 

While=20 standard specify a way to report the Critical link event, link fault = and=20 Dying  Gasp events in = the form of=20 Flags field in the OAMPDU, it does not talk about resetting=20 them.

Similar is=20 the case for all the Errored Events though an assertion and = de-assertion is=20 possible in this case without deviating from the standard, I=20 think.

However all=20 the Global Events, Temperature and Voltage specific events and the = Vendor=20 SpecificAlarm Events,  = are not=20 defined in the standard. Can they be optional=20 then?

 

2. One=20 thing I missed to point out in my previous mail : Attribute=20 eponDeviceObjectOrganizationSpecificEventState seems to be identical = to the=20 eponDeviceObjectVendorSpecificEventState attribute. Or are they=20 different?  Please=20 clarify.

 

Thanks

Raj=20 Subramanian.

 

 

-----Original=20 Message-----
From: = Lior=20 Khermosh [mailto:lior.khermosh@passave.com]
Sent: Sunday, February 15,=20 2004 = 12:34=20 PM
To: Rajagopalan = Subramanian
Subject: RE: Clarifications in = EPON=20 Device MIB

 

Dear=20 Mr. = Subramanian,

 

Thank you=20 very much for your comments. They are very helpful. I would like to = ask the=20 permission to send the comments and replies to the hubmib = reflector for=20 the interest of all people.

 

eponDeviceObjectOnuLoopback – As=20 defined now it is redundant and should be removed.=20

 

From=20 eponDeviceObjectDyingGaspAlarmState = :

When=20 the dyingGaspAlarm state is removed the dying gasp alarm is=20 reset.

I=20 added it to the text.

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

 

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed so I = suggest to=20 keep them. I will add a description.

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed. Iwill = add a=20 description.

 

The difference in my = opinion=20 is:

 

Alarm:

When=20 the value of the alarm input is above the threshold defined for the = alarm the=20 alarm is asserted. When the condition is below that threshold the = alarm is=20 de-asserted.

 

Event:

When=20 the indication of the event input occurs the event is asserted. When = the input=20 is removed that event is de-asserted.

 

Event is more = referring to a=20 system condition while alarm indicates a bad thing happening in the=20 system.

 

eponDeviceObjectPowerDown=20

I think it is. An ONU = might have=20 a battery back up and when the device is starting to get down it = indicates=20 Power down. In my opinion it is a very important indication for the=20 carrier.

 

 

Best=20 regards,

Lior=20 Khermosh

 

 

 

-----Original=20 Message-----
From:=20 Rajagopalan Subramanian [mailto:rajas@Centillium.com]
Sent: Wednesday, February = 11,=20 2004 = 6:51=20 AM
To:=20 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications in = EPON Device=20 MIB

Hello=20 Mr.Khermosh,

 

I have few questions = in the=20 Device MIB that you had proposed as part of the=20 draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you can help me get it=20 clarified.

 

eponDeviceObjectOnuLoopback=20 –

In what way is this = attribute=20 different from the one defined in the EFM MIB, = dot3OamLoopbackCommand. In an=20 implementation should both of these be=20 supported?

 

 

From=20 eponDeviceObjectDyingGaspAlarmState (Entry 8) to=20 eponDeviceObjectOrganizationSpecificEventState(Entry=20 27)=20 –

The SYNTAX in the = MIB=20 attribute says it’s a TruthValue and the description says that = ‘this bit=20 should be asserted when we receive the corresponding event’. = My question is=20 : The bit will be set when we receive an event but when will we = reset it ?=20 It cannot be always ‘1’ whenever the user reads this = attribute,=20 right?

 

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

The description says = ‘ this=20 event defines the state of the *respective* event of the OAM = Alarm=20 Indications as specified in the [802.3ah] clause=20 57.

But I could not = locate these=20 attributes in the Draft2.0 version of the standard. Can you give me = pointers=20 as to where I should be looking into?

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The description for = these two=20 attributes are Identical.  I could not a VendorAlarm and a = VendorEvent,=20 separately in the clause 57. Can you give some info=20 please?

 

eponDeviceObjectPowerDown=20

Is setting the = PowerDown a=20 valid scenario for the EPON?

 

Thanks for your=20 time.

 

Regards,

Raj=20 Subramanian

Centillium=20 India,=20

Bangalore,=20 INDIA

+91=20 80 25523575

 

<= /BODY> ------=_NextPart_000_0035_01C3F861.A3A324C0-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Feb 22 09:54:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27865 for ; Sun, 22 Feb 2004 09:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuuzY-0002ye-Rx; Sun, 22 Feb 2004 09:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auuz4-0002xu-IK for hubmib@optimus.ietf.org; Sun, 22 Feb 2004 09:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27852 for ; Sun, 22 Feb 2004 09:53:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Auuz2-0005ZB-00 for hubmib@ietf.org; Sun, 22 Feb 2004 09:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auuy5-0005XF-00 for hubmib@ietf.org; Sun, 22 Feb 2004 09:52:30 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1Auuxo-0005V8-00; Sun, 22 Feb 2004 09:52:12 -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 i1MEmIjG003351; Sun, 22 Feb 2004 09:48:18 -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 i1MEmGjG003346; Sun, 22 Feb 2004 09:48:17 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F953.722AC8B1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 22 Feb 2004 16:52:08 +0200 Message-ID: Thread-Topic: hubmib agenda at ietf-59 Thread-Index: AcP5JwE1gkvGQHWhTtmoRu9blDfNSg== From: "Romascanu, Dan (Dan)" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] hubmib agenda at ietf-59 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F953.722AC8B1 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please find below the hubmib wg agenda Regards, Dan ---------------------- Ethernet Interfaces and Hub MIB WG (hubmib) Wednesday, March 3 at 0900-1130 1. Agenda bashing, minutes, taker, etc. (Dan) - 5 minutes 2. WG status (Dan) - 10 minutes 3. Generic EFM MIB Issues (Dan on behalf of Matt) - 30 minutes 4. EPON MIB Issues (Lior) - 30 minutes 5. EFM Cu Issues (Dan on behalf of Eduard) - 30 minutes 6. Open Discussion (or early lunch) - 45 minutes Current I-Ds: - Generic EFM MIB - = =20 - EPON MIB - = - EFM Copper MIB - = ------_=_NextPart_001_01C3F953.722AC8B1 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib agenda at ietf-59

Please find below the hubmib = wg agenda

Regards,

Dan

----------------------

Ethernet = Interfaces and Hub MIB WG (hubmib)

Wednesday, = March 3 at 0900-1130

1. Agenda = bashing, minutes, taker, etc. (Dan)  - 5 minutes

2. WG = status (Dan) - 10 minutes

3. Generic = EFM MIB Issues (Dan on behalf of Matt) - 30 minutes

4. EPON MIB = Issues (Lior) - 30 minutes

5. EFM Cu = Issues (Dan on behalf of Eduard) - 30 minutes

6. Open = Discussion (or early lunch) - 45 minutes

Current = I-Ds:

- = Generic EFM MIB - <http://www.ietf.cnri.reston.va.us/internet-drafts/draf= t-ietf-hubmib-efm-mib-00.txt>

- EPON = MIB - <http://www.ietf.cnri.reston.va.us/internet-drafts= /draft-ietf-hubmib-efm-epon-mib-00.txt>

- EFM = Copper MIB - <http://www.ietf.cnri.reston.va.us/internet-drafts/d= raft-ietf-hubmib-efm-cu-mib-00.txt>



------_=_NextPart_001_01C3F953.722AC8B1-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Sun Feb 22 09:54:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27867 for ; Sun, 22 Feb 2004 09:54:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuuzZ-0002z9-Gq for hubmib-archive@odin.ietf.org; Sun, 22 Feb 2004 09:54:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MEs1Z5011460 for hubmib-archive@odin.ietf.org; Sun, 22 Feb 2004 09:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuuzY-0002ye-Rx; Sun, 22 Feb 2004 09:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auuz4-0002xu-IK for hubmib@optimus.ietf.org; Sun, 22 Feb 2004 09:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27852 for ; Sun, 22 Feb 2004 09:53:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Auuz2-0005ZB-00 for hubmib@ietf.org; Sun, 22 Feb 2004 09:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auuy5-0005XF-00 for hubmib@ietf.org; Sun, 22 Feb 2004 09:52:30 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1Auuxo-0005V8-00; Sun, 22 Feb 2004 09:52:12 -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 i1MEmIjG003351; Sun, 22 Feb 2004 09:48:18 -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 i1MEmGjG003346; Sun, 22 Feb 2004 09:48:17 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F953.722AC8B1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Sun, 22 Feb 2004 16:52:08 +0200 Message-ID: Thread-Topic: hubmib agenda at ietf-59 Thread-Index: AcP5JwE1gkvGQHWhTtmoRu9blDfNSg== From: "Romascanu, Dan (Dan)" To: Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_50_60, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] hubmib agenda at ietf-59 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F953.722AC8B1 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please find below the hubmib wg agenda Regards, Dan ---------------------- Ethernet Interfaces and Hub MIB WG (hubmib) Wednesday, March 3 at 0900-1130 1. Agenda bashing, minutes, taker, etc. (Dan) - 5 minutes 2. WG status (Dan) - 10 minutes 3. Generic EFM MIB Issues (Dan on behalf of Matt) - 30 minutes 4. EPON MIB Issues (Lior) - 30 minutes 5. EFM Cu Issues (Dan on behalf of Eduard) - 30 minutes 6. Open Discussion (or early lunch) - 45 minutes Current I-Ds: - Generic EFM MIB - = =20 - EPON MIB - = - EFM Copper MIB - = ------_=_NextPart_001_01C3F953.722AC8B1 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable hubmib agenda at ietf-59

Please find below the hubmib = wg agenda

Regards,

Dan

----------------------

Ethernet = Interfaces and Hub MIB WG (hubmib)

Wednesday, = March 3 at 0900-1130

1. Agenda = bashing, minutes, taker, etc. (Dan)  - 5 minutes

2. WG = status (Dan) - 10 minutes

3. Generic = EFM MIB Issues (Dan on behalf of Matt) - 30 minutes

4. EPON MIB = Issues (Lior) - 30 minutes

5. EFM Cu = Issues (Dan on behalf of Eduard) - 30 minutes

6. Open = Discussion (or early lunch) - 45 minutes

Current = I-Ds:

- = Generic EFM MIB - <http://www.ietf.cnri.reston.va.us/internet-drafts/draf= t-ietf-hubmib-efm-mib-00.txt>

- EPON = MIB - <http://www.ietf.cnri.reston.va.us/internet-drafts= /draft-ietf-hubmib-efm-epon-mib-00.txt>

- EFM = Copper MIB - <http://www.ietf.cnri.reston.va.us/internet-drafts/d= raft-ietf-hubmib-efm-cu-mib-00.txt>



------_=_NextPart_001_01C3F953.722AC8B1-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Mon Feb 23 03:03:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12571 for ; Mon, 23 Feb 2004 03:03:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvB3N-0000Lr-I1; Mon, 23 Feb 2004 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av7so-0004KZ-UC for hubmib@optimus.ietf.org; Sun, 22 Feb 2004 23:39:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23221 for ; Sun, 22 Feb 2004 23:39:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av7sm-0006JM-00 for hubmib@ietf.org; Sun, 22 Feb 2004 23:39:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av7rq-0006Ge-00 for hubmib@ietf.org; Sun, 22 Feb 2004 23:38:58 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1Av7rB-0006BL-00 for hubmib@ietf.org; Sun, 22 Feb 2004 23:38:13 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id DF3B418F3BA; Sun, 22 Feb 2004 20:47:50 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Sun, 22 Feb 2004 20:37:38 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2C8224@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'Lior Khermosh'" , hubmib@ietf.org Cc: "Hariprasad V. Nair" Subject: RE: [Hubmib] RE: Clarifications in EPON Device MIB Date: Sun, 22 Feb 2004 20:37:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F9C6.BB0CBD10" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F9C6.BB0CBD10 Content-Type: text/plain Lior, Thanks for your reply. Can you provide your comments on the following too? 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Saturday, February 21, 2004 1:31 PM To: Rajagopalan Subramanian; hubmib@ietf.org Cc: Hariprasad V. Nair Subject: [Hubmib] RE: Clarifications in EPON Device MIB Raj, Indeed the MPCP is using sync time which is the addition of both. Without intervening with MPCP considerations the optical devices has separate agc and cdr times which from management perspective are very interesting to be exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to them as different parameters which only the added time is complying). In order to comply to the MPCP I will add an attribute for sync time but my opinion is that agc and cdr time should also be maintained for management. Best regards, Lior -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Thursday, February 19, 2004 3:48 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr.Khermosh, One more query in addition to the ones I sent few days back. 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We donot have any reference to these in the 802.3ah drafts. If I am not wrong, these two are replaced by the 'SyncTime' in the draft 1.414 itself. Should we reflect this in the MIB too? Or am I missing something?! Thanks Raj. -----Original Message----- From: Rajagopalan Subramanian Sent: Monday, February 16, 2004 5:49 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------_=_NextPart_001_01C3F9C6.BB0CBD10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Lior,

Thanks for your reply.

 

Can = you provide your  comments on the = following too?

 

1. Currently, as far as I know,  the standard 802.3ah does not suggest a de-asserting mechanism. =

 

While standard specify a way to report the Critical link = event, link fault and Dying  Gasp = events in the form of Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the case for all the Errored Events though an = assertion and de-assertion is possible in this case without deviating from the = standard, I think.

However all the Global Events, Temperature and Voltage = specific events and the Vendor SpecificAlarm Events,  are not defined in the standard. Can they be optional = then?

 

2. One thing I missed to point out in my previous mail : = Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to = the eponDeviceObjectVendorSpecificEventState attribute. Or are they = different?  Please = clarify.

Thanks

Raj

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Saturday, February 21, = 2004 1:31 PM
To: Rajagopalan = Subramanian; hubmib@ietf.org
Cc: Hariprasad V. = Nair
Subject: [Hubmib] RE: Clarifications in EPON Device MIB

 

Raj,

Indeed the MPCP = is using sync time which is the addition of both. Without intervening with MPCP considerations the optical devices has separate agc and cdr times which = from management perspective are very interesting to be exchanged. = (please note that the 802.3ah in clasue 60 and 65 refer to them as different = parameters which only the added time is complying). In order to comply to the MPCP = I will add an attribute for sync time but my opinion is that agc and cdr time = should also be maintained for management.

 

 

Best = regards,

Lior

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Thursday, February 19, = 2004 3:48 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: Hariprasad V. = Nair
Subject: RE: = Clarifications in EPON Device MIB

Hello = Mr.Khermosh,

 

One more query = in addition to the ones I sent few days back.

 

3.  In the dot3MpcpEntry table : = there are two fields dot3MpcpReceiverSettlingTime = and  dot3MpcpCdrLockTi= me.

We donot have = any reference to these in the 802.3ah drafts.  = If I am not wrong, these two are replaced by the ‘SyncTime’ in the draft 1.414 itself. Should we reflect this in the MIB = too?

 

Or am I missing something?!

 

Thanks =

Raj.

 

-----Original = Message-----
From: Rajagopalan = Subramanian
Sent: = Monday, February 16, = 2004 5:49 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: Hariprasad V. = Nair
Subject: RE: = Clarifications in EPON Device MIB

 

Hello Mr. = Khermosh,

 

Thanks for your = reply. I am forwarding the earlier questions posted by me and your reply for = that,  to the mailing = list.

 

Few more questions on your reply :

 

=

1. Currently, as = far as I know,  the standard = 802.3ah does not suggest a de-asserting mechanism.

 

While standard = specify a way to report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the = case for all the Errored Events though an assertion and de-assertion is possible = in this case without deviating from the standard, I = think.

However all the = Global Events, Temperature and Voltage specific events and the Vendor = SpecificAlarm Events,  are not defined = in the standard. Can they be optional then?

 

2. One thing I = missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to = the eponDeviceObjectVendorSpecificEventState attribute. Or are they = different?  Please = clarify.

 

Thanks

Raj = Subramanian.

 

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Sunday, February 15, = 2004 12:34 PM
To: Rajagopalan = Subramanian
Subject: RE: = Clarifications in EPON Device MIB

 

Dear = Mr. Subramanian,

 

Thank you very = much for your comments. They are very helpful. I would like to ask the = permission to send the comments and replies to the hubmib reflector for the = interest of all people.

 

eponDeviceObjectOnuLoopba= ck – As defined now it is redundant and should be removed. =

 

From = eponDeviceObjectDyingGaspAlarmState :

When the dyingGaspAlarm state is removed the dying gasp alarm is = reset.

I added it to the text.

 

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , = eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

 

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed so I = suggest to keep them. I will add a description.

 

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed. Iwill add = a description.

 

The difference in my = opinion is:

 

Alarm:=

When the value of the alarm input is above the threshold defined for the = alarm the alarm is asserted. When the condition is below that threshold the alarm = is de-asserted.

 

Event:=

When the indication of the event input occurs the event is asserted. When = the input is removed that event is de-asserted.

 

Event is more referring = to a system condition while alarm indicates a bad thing happening in the = system.

 

eponDeviceObjectPowerDown=

I think it is. An ONU = might have a battery back up and when the device is starting to get down it = indicates Power down. In my opinion it is a very important indication for the = carrier.

 

 

Best = regards,

Lior = Khermosh

 

 

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Wednesday, February 11, = 2004 6:51 AM
To: = 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications = in EPON Device MIB

Hello = Mr.Khermosh,

 <= /font>

I have few questions in = the Device MIB that you had proposed as part of the = draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you = can help me get it clarified.

 =

eponDeviceObjectOnuLoopba= ck = –

In what way is this = attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. = In an implementation should both of these be = supported?

 =

 =

From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry = 27) = –

The SYNTAX in the MIB = attribute says it’s a TruthValue and the description says that ‘this = bit should be asserted when we receive the corresponding event’. My = question is : The bit will be set when we receive an event but when will we = reset it ? It cannot be always ‘1’ whenever the user reads this = attribute, right?

 =

 =

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

The description says = ‘ this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause = 57.

But I could not locate = these attributes in the Draft2.0 version of the standard. Can you give me = pointers as to where I should be looking into?

 =

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The description for = these two attributes are Identical.  I could not a VendorAlarm and a = VendorEvent, separately in the clause 57. Can you give some info = please?

 =

eponDeviceObjectPowerDown=

Is setting the PowerDown = a valid scenario for the EPON?

 =

Thanks for your = time.

 

Regards,

Raj = Subramanian

Centillium India,

Bangalore, INDIA=

+91 80 25523575

 

------_=_NextPart_001_01C3F9C6.BB0CBD10-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Mon Feb 23 03:03:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12588 for ; Mon, 23 Feb 2004 03:03:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvB3P-0000Mh-8y for hubmib-archive@odin.ietf.org; Mon, 23 Feb 2004 03:03:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N832E2001370 for hubmib-archive@odin.ietf.org; Mon, 23 Feb 2004 03:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvB3N-0000Lr-I1; Mon, 23 Feb 2004 03:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Av7so-0004KZ-UC for hubmib@optimus.ietf.org; Sun, 22 Feb 2004 23:39:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23221 for ; Sun, 22 Feb 2004 23:39:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Av7sm-0006JM-00 for hubmib@ietf.org; Sun, 22 Feb 2004 23:39:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Av7rq-0006Ge-00 for hubmib@ietf.org; Sun, 22 Feb 2004 23:38:58 -0500 Received: from mxout.centillium.com ([63.163.147.9] helo=ns2.centillium.com) by ietf-mx with esmtp (Exim 4.12) id 1Av7rB-0006BL-00 for hubmib@ietf.org; Sun, 22 Feb 2004 23:38:13 -0500 Received: from mercury.centillium_nt.centillium.com (unknown [209.172.118.8]) by ns2.centillium.com (Postfix) with ESMTP id DF3B418F3BA; Sun, 22 Feb 2004 20:47:50 -0800 (PST) Received: by mercury.centillium_nt.centillium.com with Internet Mail Service (5.5.2656.59) id ; Sun, 22 Feb 2004 20:37:38 -0800 Message-ID: <43E6B958AA8D9E48A3CCE2088577E7BA2C8224@apollo.centillium_nt.centillium.com> From: Rajagopalan Subramanian To: "'Lior Khermosh'" , hubmib@ietf.org Cc: "Hariprasad V. Nair" Subject: RE: [Hubmib] RE: Clarifications in EPON Device MIB Date: Sun, 22 Feb 2004 20:37:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F9C6.BB0CBD10" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=3.3 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C3F9C6.BB0CBD10 Content-Type: text/plain Lior, Thanks for your reply. Can you provide your comments on the following too? 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Saturday, February 21, 2004 1:31 PM To: Rajagopalan Subramanian; hubmib@ietf.org Cc: Hariprasad V. Nair Subject: [Hubmib] RE: Clarifications in EPON Device MIB Raj, Indeed the MPCP is using sync time which is the addition of both. Without intervening with MPCP considerations the optical devices has separate agc and cdr times which from management perspective are very interesting to be exchanged. (please note that the 802.3ah in clasue 60 and 65 refer to them as different parameters which only the added time is complying). In order to comply to the MPCP I will add an attribute for sync time but my opinion is that agc and cdr time should also be maintained for management. Best regards, Lior -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Thursday, February 19, 2004 3:48 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr.Khermosh, One more query in addition to the ones I sent few days back. 3. In the dot3MpcpEntry table : there are two fields dot3MpcpReceiverSettlingTime and dot3MpcpCdrLockTime. We donot have any reference to these in the 802.3ah drafts. If I am not wrong, these two are replaced by the 'SyncTime' in the draft 1.414 itself. Should we reflect this in the MIB too? Or am I missing something?! Thanks Raj. -----Original Message----- From: Rajagopalan Subramanian Sent: Monday, February 16, 2004 5:49 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State...................... eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------_=_NextPart_001_01C3F9C6.BB0CBD10 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Lior,

Thanks for your reply.

 

Can = you provide your  comments on the = following too?

 

1. Currently, as far as I know,  the standard 802.3ah does not suggest a de-asserting mechanism. =

 

While standard specify a way to report the Critical link = event, link fault and Dying  Gasp = events in the form of Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the case for all the Errored Events though an = assertion and de-assertion is possible in this case without deviating from the = standard, I think.

However all the Global Events, Temperature and Voltage = specific events and the Vendor SpecificAlarm Events,  are not defined in the standard. Can they be optional = then?

 

2. One thing I missed to point out in my previous mail : = Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to = the eponDeviceObjectVendorSpecificEventState attribute. Or are they = different?  Please = clarify.

Thanks

Raj

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Saturday, February 21, = 2004 1:31 PM
To: Rajagopalan = Subramanian; hubmib@ietf.org
Cc: Hariprasad V. = Nair
Subject: [Hubmib] RE: Clarifications in EPON Device MIB

 

Raj,

Indeed the MPCP = is using sync time which is the addition of both. Without intervening with MPCP considerations the optical devices has separate agc and cdr times which = from management perspective are very interesting to be exchanged. = (please note that the 802.3ah in clasue 60 and 65 refer to them as different = parameters which only the added time is complying). In order to comply to the MPCP = I will add an attribute for sync time but my opinion is that agc and cdr time = should also be maintained for management.

 

 

Best = regards,

Lior

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Thursday, February 19, = 2004 3:48 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: Hariprasad V. = Nair
Subject: RE: = Clarifications in EPON Device MIB

Hello = Mr.Khermosh,

 

One more query = in addition to the ones I sent few days back.

 

3.  In the dot3MpcpEntry table : = there are two fields dot3MpcpReceiverSettlingTime = and  dot3MpcpCdrLockTi= me.

We donot have = any reference to these in the 802.3ah drafts.  = If I am not wrong, these two are replaced by the ‘SyncTime’ in the draft 1.414 itself. Should we reflect this in the MIB = too?

 

Or am I missing something?!

 

Thanks =

Raj.

 

-----Original = Message-----
From: Rajagopalan = Subramanian
Sent: = Monday, February 16, = 2004 5:49 PM
To: 'Lior Khermosh'; 'hubmib@ietf.org'
Cc: Hariprasad V. = Nair
Subject: RE: = Clarifications in EPON Device MIB

 

Hello Mr. = Khermosh,

 

Thanks for your = reply. I am forwarding the earlier questions posted by me and your reply for = that,  to the mailing = list.

 

Few more questions on your reply :

 

=

1. Currently, as = far as I know,  the standard = 802.3ah does not suggest a de-asserting mechanism.

 

While standard = specify a way to report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field in the OAMPDU, it does not talk about resetting = them.

Similar is the = case for all the Errored Events though an assertion and de-assertion is possible = in this case without deviating from the standard, I = think.

However all the = Global Events, Temperature and Voltage specific events and the Vendor = SpecificAlarm Events,  are not defined = in the standard. Can they be optional then?

 

2. One thing I = missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to = the eponDeviceObjectVendorSpecificEventState attribute. Or are they = different?  Please = clarify.

 

Thanks

Raj = Subramanian.

 

 

-----Original = Message-----
From: Lior Khermosh [mailto:lior.khermosh@passave.com]
Sent: = Sunday, February 15, = 2004 12:34 PM
To: Rajagopalan = Subramanian
Subject: RE: = Clarifications in EPON Device MIB

 

Dear = Mr. Subramanian,

 

Thank you very = much for your comments. They are very helpful. I would like to ask the = permission to send the comments and replies to the hubmib reflector for the = interest of all people.

 

eponDeviceObjectOnuLoopba= ck – As defined now it is redundant and should be removed. =

 

From = eponDeviceObjectDyingGaspAlarmState :

When the dyingGaspAlarm state is removed the dying gasp alarm is = reset.

I added it to the text.

 

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , = eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

 

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed so I = suggest to keep them. I will add a description.

 

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at the 802.3ah draft. I will remove this reference. However I still think that = as alarms and event for device in access system they are needed. Iwill add = a description.

 

The difference in my = opinion is:

 

Alarm:=

When the value of the alarm input is above the threshold defined for the = alarm the alarm is asserted. When the condition is below that threshold the alarm = is de-asserted.

 

Event:=

When the indication of the event input occurs the event is asserted. When = the input is removed that event is de-asserted.

 

Event is more referring = to a system condition while alarm indicates a bad thing happening in the = system.

 

eponDeviceObjectPowerDown=

I think it is. An ONU = might have a battery back up and when the device is starting to get down it = indicates Power down. In my opinion it is a very important indication for the = carrier.

 

 

Best = regards,

Lior = Khermosh

 

 

 

-----Original Message-----
From: Rajagopalan = Subramanian [mailto:rajas@Centillium.com]
Sent: = Wednesday, February 11, = 2004 6:51 AM
To: = 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications = in EPON Device MIB

Hello = Mr.Khermosh,

 <= /font>

I have few questions in = the Device MIB that you had proposed as part of the = draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you = can help me get it clarified.

 =

eponDeviceObjectOnuLoopba= ck = –

In what way is this = attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. = In an implementation should both of these be = supported?

 =

 =

From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry = 27) = –

The SYNTAX in the MIB = attribute says it’s a TruthValue and the description says that ‘this = bit should be asserted when we receive the corresponding event’. My = question is : The bit will be set when we receive an event but when will we = reset it ? It cannot be always ‘1’ whenever the user reads this = attribute, right?

 =

 =

eponDeviceObjectTemperatu= reEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State……………R= 30;…. = eponDeviceObjectGlobalEve= nt7State

The description says = ‘ this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause = 57.

But I could not locate = these attributes in the Draft2.0 version of the standard. Can you give me = pointers as to where I should be looking into?

 =

eponDeviceObjectVendorSpe= cificAlarmState, eponDeviceObjectVendorSpecificEventState =

The description for = these two attributes are Identical.  I could not a VendorAlarm and a = VendorEvent, separately in the clause 57. Can you give some info = please?

 =

eponDeviceObjectPowerDown=

Is setting the PowerDown = a valid scenario for the EPON?

 =

Thanks for your = time.

 

Regards,

Raj = Subramanian

Centillium India,

Bangalore, INDIA=

+91 80 25523575

 

------_=_NextPart_001_01C3F9C6.BB0CBD10-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Feb 25 05:27:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09185 for ; Wed, 25 Feb 2004 05:27:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwFo-0002Jo-M9; Wed, 25 Feb 2004 05:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwFb-0002Ja-BX for hubmib@optimus.ietf.org; Wed, 25 Feb 2004 05:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09177 for ; Wed, 25 Feb 2004 05:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwFX-0005Q3-00 for hubmib@ietf.org; Wed, 25 Feb 2004 05:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvwEf-0005LT-00 for hubmib@ietf.org; Wed, 25 Feb 2004 05:25:50 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AvwEJ-0005GD-00 for hubmib@ietf.org; Wed, 25 Feb 2004 05:25:27 -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 i1PAOWs2013951 for ; Wed, 25 Feb 2004 05:24:32 -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 i1PAOUs2013903 for ; Wed, 25 Feb 2004 05:24:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FB89.AE2D7B68" Date: Wed, 25 Feb 2004 12:25:24 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-hubmib-efm-mib-00.txt Thread-Index: AcP7ia46JOoBv13aR3e1gzY20RuKDg== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FB89.AE2D7B68 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Here are my comments concerning draft-ietf-hubmib-efm-mib-00.txt. Regards, Dan A. Technical A1. The content of the MIB and all references need to be updated with = the changes in IEEE 802.3 D3.1 A2. if row creation in dot3OamTable is automatic, there is no need for = the dot3OamRowStatus object A3. Need to specify what objects need to be stored in non-volatile = memory in tables A4. dot3OamMode has a MAX-ACCESS of read-write - thus it needs a default = value at initialization A5. If row creation in dot3OamPeerTable is automatic, there is no need = for the dot3OamPeerRowStatus object A6. Should not we add a timer that would limit the time between = dot3OamLoopbackCommand sending a loopback OAMPDU with the loopback = enable flags set and reset. The motivation is to avoid cases when the = second command may be lost. B. Editorial - major B1 - There are still formatting problems, especially concerning the = maximum number of characters per line. Such problems in the MIB = definition section do not allow for clean compilation of the text as it = is in the draft.=20 B2. - The Formatted references section, besides being incomplete does = not include all the documents required by the boilerplate. See = http://www.ops.ietf.org/mib-boilerplate.html. Also missing are the other = two EFM MIB documents referenced in Section 3. B3. Missing - copyright notice on the front page. Also, the year needs = to be updated in the copyright notice in Section 11. C. Editorial - minor C1. Make sure that the data in the REVISION clause is identical with the = date in the adjoining comment C2. DESCRIPTION clause of dot3OamTable - what does 'primary' mean? C3. in DESCRIPTION clause of dot3OamEventConfigTable, first phrase, = specify that we deal with OAM notifications, to avoid the confusion with = SNMP notifications. C4. The DESCRIPTION clauses of the event groups in the conformance = section seem to be identical one with the other. ------_=_NextPart_001_01C3FB89.AE2D7B68 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-hubmib-efm-mib-00.txt

Here are my comments = concerning draft-ietf-hubmib-efm-mib-00.txt.

Regards,

Dan

A. = Technical

A1. The = content of the MIB and all references need to be updated with the = changes in IEEE 802.3 D3.1

A2. if row = creation in dot3OamTable is automatic, there is no need for the = dot3OamRowStatus object

A3. Need to = specify what objects need to be stored in non-volatile memory in = tables

A4. = dot3OamMode has a MAX-ACCESS of read-write - thus it needs a default = value at initialization

A5. If row = creation in dot3OamPeerTable is automatic, there is no need for the = dot3OamPeerRowStatus object

A6. Should = not we add a timer that would limit the time between = dot3OamLoopbackCommand sending a loopback OAMPDU with the loopback = enable flags set and reset. The motivation is to avoid cases when the = second command may be lost.


B. = Editorial - major

B1 - There = are still formatting problems, especially concerning the maximum number = of characters per line. Such problems in the MIB definition section do = not allow for clean compilation of the text as it is in the draft. =

B2. - The = Formatted references section, besides being incomplete does not include = all the documents required by the boilerplate. See http://www.ops.ietf= .org/mib-boilerplate.html. Also missing are the other two EFM MIB = documents referenced in Section 3.

B3. Missing = - copyright notice on the front page. Also, the year needs to be updated = in the copyright notice in Section 11.





C. = Editorial - minor

C1. Make = sure that the data in the REVISION clause is identical with the date in = the adjoining comment

C2. = DESCRIPTION clause of dot3OamTable - what does 'primary' = mean?

C3. in = DESCRIPTION clause of dot3OamEventConfigTable, first phrase, specify = that we deal with OAM notifications, to avoid the confusion with SNMP = notifications.

C4. The = DESCRIPTION clauses of the event groups in the conformance section seem = to be identical one with the other.



------_=_NextPart_001_01C3FB89.AE2D7B68-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Wed Feb 25 05:27:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09202 for ; Wed, 25 Feb 2004 05:27:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwFt-0002K8-AY for hubmib-archive@odin.ietf.org; Wed, 25 Feb 2004 05:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PAR5Oh008926 for hubmib-archive@odin.ietf.org; Wed, 25 Feb 2004 05:27:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwFo-0002Jo-M9; Wed, 25 Feb 2004 05:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvwFb-0002Ja-BX for hubmib@optimus.ietf.org; Wed, 25 Feb 2004 05:26:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09177 for ; Wed, 25 Feb 2004 05:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvwFX-0005Q3-00 for hubmib@ietf.org; Wed, 25 Feb 2004 05:26:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvwEf-0005LT-00 for hubmib@ietf.org; Wed, 25 Feb 2004 05:25:50 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AvwEJ-0005GD-00 for hubmib@ietf.org; Wed, 25 Feb 2004 05:25:27 -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 i1PAOWs2013951 for ; Wed, 25 Feb 2004 05:24:32 -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 i1PAOUs2013903 for ; Wed, 25 Feb 2004 05:24:31 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FB89.AE2D7B68" Date: Wed, 25 Feb 2004 12:25:24 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-hubmib-efm-mib-00.txt Thread-Index: AcP7ia46JOoBv13aR3e1gzY20RuKDg== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Comments on draft-ietf-hubmib-efm-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FB89.AE2D7B68 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Here are my comments concerning draft-ietf-hubmib-efm-mib-00.txt. Regards, Dan A. Technical A1. The content of the MIB and all references need to be updated with = the changes in IEEE 802.3 D3.1 A2. if row creation in dot3OamTable is automatic, there is no need for = the dot3OamRowStatus object A3. Need to specify what objects need to be stored in non-volatile = memory in tables A4. dot3OamMode has a MAX-ACCESS of read-write - thus it needs a default = value at initialization A5. If row creation in dot3OamPeerTable is automatic, there is no need = for the dot3OamPeerRowStatus object A6. Should not we add a timer that would limit the time between = dot3OamLoopbackCommand sending a loopback OAMPDU with the loopback = enable flags set and reset. The motivation is to avoid cases when the = second command may be lost. B. Editorial - major B1 - There are still formatting problems, especially concerning the = maximum number of characters per line. Such problems in the MIB = definition section do not allow for clean compilation of the text as it = is in the draft.=20 B2. - The Formatted references section, besides being incomplete does = not include all the documents required by the boilerplate. See = http://www.ops.ietf.org/mib-boilerplate.html. Also missing are the other = two EFM MIB documents referenced in Section 3. B3. Missing - copyright notice on the front page. Also, the year needs = to be updated in the copyright notice in Section 11. C. Editorial - minor C1. Make sure that the data in the REVISION clause is identical with the = date in the adjoining comment C2. DESCRIPTION clause of dot3OamTable - what does 'primary' mean? C3. in DESCRIPTION clause of dot3OamEventConfigTable, first phrase, = specify that we deal with OAM notifications, to avoid the confusion with = SNMP notifications. C4. The DESCRIPTION clauses of the event groups in the conformance = section seem to be identical one with the other. ------_=_NextPart_001_01C3FB89.AE2D7B68 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-hubmib-efm-mib-00.txt

Here are my comments = concerning draft-ietf-hubmib-efm-mib-00.txt.

Regards,

Dan

A. = Technical

A1. The = content of the MIB and all references need to be updated with the = changes in IEEE 802.3 D3.1

A2. if row = creation in dot3OamTable is automatic, there is no need for the = dot3OamRowStatus object

A3. Need to = specify what objects need to be stored in non-volatile memory in = tables

A4. = dot3OamMode has a MAX-ACCESS of read-write - thus it needs a default = value at initialization

A5. If row = creation in dot3OamPeerTable is automatic, there is no need for the = dot3OamPeerRowStatus object

A6. Should = not we add a timer that would limit the time between = dot3OamLoopbackCommand sending a loopback OAMPDU with the loopback = enable flags set and reset. The motivation is to avoid cases when the = second command may be lost.


B. = Editorial - major

B1 - There = are still formatting problems, especially concerning the maximum number = of characters per line. Such problems in the MIB definition section do = not allow for clean compilation of the text as it is in the draft. =

B2. - The = Formatted references section, besides being incomplete does not include = all the documents required by the boilerplate. See http://www.ops.ietf= .org/mib-boilerplate.html. Also missing are the other two EFM MIB = documents referenced in Section 3.

B3. Missing = - copyright notice on the front page. Also, the year needs to be updated = in the copyright notice in Section 11.





C. = Editorial - minor

C1. Make = sure that the data in the REVISION clause is identical with the date in = the adjoining comment

C2. = DESCRIPTION clause of dot3OamTable - what does 'primary' = mean?

C3. in = DESCRIPTION clause of dot3OamEventConfigTable, first phrase, specify = that we deal with OAM notifications, to avoid the confusion with SNMP = notifications.

C4. The = DESCRIPTION clauses of the event groups in the conformance section seem = to be identical one with the other.



------_=_NextPart_001_01C3FB89.AE2D7B68-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Wed Feb 25 08:08:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15123 for ; Wed, 25 Feb 2004 08:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avylf-0007Ag-3B; Wed, 25 Feb 2004 08:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvylZ-00078Y-0T for hubmib@optimus.ietf.org; Wed, 25 Feb 2004 08:07:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15117 for ; Wed, 25 Feb 2004 08:07:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvylY-0005Tx-00 for hubmib@ietf.org; Wed, 25 Feb 2004 08:07:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avykh-0005OO-00 for hubmib@ietf.org; Wed, 25 Feb 2004 08:07:04 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AvykG-0005I9-00 for hubmib@ietf.org; Wed, 25 Feb 2004 08:06:36 -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 i1PD5ds2015065 for ; Wed, 25 Feb 2004 08:05:39 -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 i1PD5as2015030 for ; Wed, 25 Feb 2004 08:05:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FBA0.2FA564AF" Date: Wed, 25 Feb 2004 15:06:30 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-hubmib-efm-cu-mib-00.txt Thread-Index: AcP7oC+3KZKw5JsmT4y8zzMMw4m5BQ== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Comments on draft-ietf-hubmib-efm-cu-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FBA0.2FA564AF Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable please find below my comments on draft-ietf-hubmib-efm-cu-mib-00.txt Regards, Dan A. Technical A1. The MIB module does not compile cleanly. I suggest using one of the = tools described in http://www.ops.ietf.org/mib-review-tools.html to = check syntactic accuracy before the next round. I mentioned some of the = errors below. A1. macro `NOTIFICATION-TYPE' has not been imported from module = `SNMPv2-SMI' A2. Enumerated values are expected to be in ascending order - = efmCuPmi10PPayloadURateProfile, efmCuPmi10PPayloadDRateProfile A3. Gauge32 and transmission are imported and never used.=20 A4. The compliance clauses are broken. Groups are defined and not = referenced. A5. All content and references need to be updated according to IEEE = 802.3ah D3.1 A6 - The changes in the MAU MIB need to be brought to the WG, as they = will need a Charter update A7 - Need to specify whether non-volatile storage is required for values = of objects with read-write MAX-ACCESS in tables A8 - Need to specify default values for objects with read-write = MAX-ACCESS A9 - Not clear how efmCuPmiLinkDefect works. I think that there is a = need for an object here.=20 B. Editorial - Major B1 - There are still formatting problems, especially concerning the = maximum number of characters per line. Such problems in the MIB = definition section do not allow for clean compilation of the text as it = is in the draft. B2 - References need to be included in a separate section. B3 - It would help to add a 'Structure of the MIB' section B4 - I recommend that we concentrate the 'mapping to Clause 30' = statements in a separate section, out of the MIB module C. Editorial - Minor C1 - Change the affiliation of the WG chair to 'Avaya' from 'Avaya Inc.' ------_=_NextPart_001_01C3FBA0.2FA564AF Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-hubmib-efm-cu-mib-00.txt

please find below my comments = on draft-ietf-hubmib-efm-cu-mib-00.txt

Regards,

Dan

A. = Technical

A1. The MIB = module does not compile cleanly. I suggest using one of the tools = described in http://www.ops.iet= f.org/mib-review-tools.html to check syntactic accuracy before the = next round. I mentioned some of the errors below.

A1. = macro `NOTIFICATION-TYPE' has not been = imported from module `SNMPv2-SMI'

A2. = Enumerated values are expected to be in ascending order = - efmCuPmi10PPayloadURateProfile, = efmCuPmi10PPayloadDRateProfile

A3. Gauge32 = and transmission are imported and never used.

A4. The = compliance clauses are broken. Groups are defined and not = referenced.

A5. All = content and references need to be updated according to IEEE 802.3ah = D3.1

A6 - The = changes in the MAU MIB need to be brought to the WG, as they will need a = Charter update

A7 - Need = to specify whether non-volatile storage is required for values of = objects with read-write MAX-ACCESS in tables

A8 - Need = to specify default values for objects with read-write = MAX-ACCESS

A9 - Not = clear how efmCuPmiLinkDefect works. I think that there is a need for an = object here.


B. = Editorial - Major

B1 - = There are still formatting problems, especially concerning the maximum = number of characters per line. Such problems in the MIB definition = section do not allow for clean compilation of the text as it is in the = draft.

B2 - = References need to be included in a separate section.

B3 - It = would help to add a 'Structure of the MIB' section

B4 - I = recommend that we concentrate the 'mapping to Clause 30' statements in a = separate section, out of the MIB module


C. = Editorial - Minor

C1 - Change = the affiliation of the WG chair to 'Avaya' from 'Avaya = Inc.'


------_=_NextPart_001_01C3FBA0.2FA564AF-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Wed Feb 25 08:08:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15125 for ; Wed, 25 Feb 2004 08:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avylh-0007CN-LB for hubmib-archive@odin.ietf.org; Wed, 25 Feb 2004 08:08:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PD85og027603 for hubmib-archive@odin.ietf.org; Wed, 25 Feb 2004 08:08:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avylf-0007Ag-3B; Wed, 25 Feb 2004 08:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvylZ-00078Y-0T for hubmib@optimus.ietf.org; Wed, 25 Feb 2004 08:07:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15117 for ; Wed, 25 Feb 2004 08:07:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvylY-0005Tx-00 for hubmib@ietf.org; Wed, 25 Feb 2004 08:07:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avykh-0005OO-00 for hubmib@ietf.org; Wed, 25 Feb 2004 08:07:04 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1AvykG-0005I9-00 for hubmib@ietf.org; Wed, 25 Feb 2004 08:06:36 -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 i1PD5ds2015065 for ; Wed, 25 Feb 2004 08:05:39 -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 i1PD5as2015030 for ; Wed, 25 Feb 2004 08:05:37 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FBA0.2FA564AF" Date: Wed, 25 Feb 2004 15:06:30 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-hubmib-efm-cu-mib-00.txt Thread-Index: AcP7oC+3KZKw5JsmT4y8zzMMw4m5BQ== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Comments on draft-ietf-hubmib-efm-cu-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FBA0.2FA564AF Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable please find below my comments on draft-ietf-hubmib-efm-cu-mib-00.txt Regards, Dan A. Technical A1. The MIB module does not compile cleanly. I suggest using one of the = tools described in http://www.ops.ietf.org/mib-review-tools.html to = check syntactic accuracy before the next round. I mentioned some of the = errors below. A1. macro `NOTIFICATION-TYPE' has not been imported from module = `SNMPv2-SMI' A2. Enumerated values are expected to be in ascending order - = efmCuPmi10PPayloadURateProfile, efmCuPmi10PPayloadDRateProfile A3. Gauge32 and transmission are imported and never used.=20 A4. The compliance clauses are broken. Groups are defined and not = referenced. A5. All content and references need to be updated according to IEEE = 802.3ah D3.1 A6 - The changes in the MAU MIB need to be brought to the WG, as they = will need a Charter update A7 - Need to specify whether non-volatile storage is required for values = of objects with read-write MAX-ACCESS in tables A8 - Need to specify default values for objects with read-write = MAX-ACCESS A9 - Not clear how efmCuPmiLinkDefect works. I think that there is a = need for an object here.=20 B. Editorial - Major B1 - There are still formatting problems, especially concerning the = maximum number of characters per line. Such problems in the MIB = definition section do not allow for clean compilation of the text as it = is in the draft. B2 - References need to be included in a separate section. B3 - It would help to add a 'Structure of the MIB' section B4 - I recommend that we concentrate the 'mapping to Clause 30' = statements in a separate section, out of the MIB module C. Editorial - Minor C1 - Change the affiliation of the WG chair to 'Avaya' from 'Avaya Inc.' ------_=_NextPart_001_01C3FBA0.2FA564AF Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-hubmib-efm-cu-mib-00.txt

please find below my comments = on draft-ietf-hubmib-efm-cu-mib-00.txt

Regards,

Dan

A. = Technical

A1. The MIB = module does not compile cleanly. I suggest using one of the tools = described in http://www.ops.iet= f.org/mib-review-tools.html to check syntactic accuracy before the = next round. I mentioned some of the errors below.

A1. = macro `NOTIFICATION-TYPE' has not been = imported from module `SNMPv2-SMI'

A2. = Enumerated values are expected to be in ascending order = - efmCuPmi10PPayloadURateProfile, = efmCuPmi10PPayloadDRateProfile

A3. Gauge32 = and transmission are imported and never used.

A4. The = compliance clauses are broken. Groups are defined and not = referenced.

A5. All = content and references need to be updated according to IEEE 802.3ah = D3.1

A6 - The = changes in the MAU MIB need to be brought to the WG, as they will need a = Charter update

A7 - Need = to specify whether non-volatile storage is required for values of = objects with read-write MAX-ACCESS in tables

A8 - Need = to specify default values for objects with read-write = MAX-ACCESS

A9 - Not = clear how efmCuPmiLinkDefect works. I think that there is a need for an = object here.


B. = Editorial - Major

B1 - = There are still formatting problems, especially concerning the maximum = number of characters per line. Such problems in the MIB definition = section do not allow for clean compilation of the text as it is in the = draft.

B2 - = References need to be included in a separate section.

B3 - It = would help to add a 'Structure of the MIB' section

B4 - I = recommend that we concentrate the 'mapping to Clause 30' statements in a = separate section, out of the MIB module


C. = Editorial - Minor

C1 - Change = the affiliation of the WG chair to 'Avaya' from 'Avaya = Inc.'


------_=_NextPart_001_01C3FBA0.2FA564AF-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Feb 26 06:39:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05845 for ; Thu, 26 Feb 2004 06:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJr3-0008NN-8m; Thu, 26 Feb 2004 06:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJqo-0008MJ-TH for hubmib@optimus.ietf.org; Thu, 26 Feb 2004 06:38:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05822 for ; Thu, 26 Feb 2004 06:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJqk-0003H4-00 for hubmib@ietf.org; Thu, 26 Feb 2004 06:38:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJps-0003A2-00 for hubmib@ietf.org; Thu, 26 Feb 2004 06:37:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AwJp8-00033A-00 for hubmib@ietf.org; Thu, 26 Feb 2004 06:37:02 -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 i1QBX1pc022317 for ; Thu, 26 Feb 2004 06:33:01 -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 i1QBWwpc022288 for ; Thu, 26 Feb 2004 06:33:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC5C.D5A1BADC" Date: Thu, 26 Feb 2004 13:36:54 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-hubmib-efm-epon-mib-00.txt Thread-Index: AcP8XNWQFhj+WPFYSVSaCMrlZvIjcA== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Comments on draft-ietf-hubmib-efm-epon-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC5C.D5A1BADC Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please find below my comments wrt. = draft-ietf-hubmib-efm-epon-mib-00.txt. Regards, Dan A. Technical A1. It is recommended to use Integer32 or Unsigned32 rather than INTEGER = for objects which indicate an integer value, with the exception of = enumeration objects. A2. unknown object identifier label `dot3EfmeponMIB' in the first MIB = module. A3. There is a left-over bracket in the definition of = eponDeviceObjectOnuLoopback which prevents correct compilation of the = MIB module.=20 A4 It would be very useful to add a section defining the relationship = between the objects in this MIB and the management objects defined in = IEEE 802.3 ah A5. The MIB content needs to be aligned with the latest IEEE 802.3ah = draft (3.1?) B. Editorial - major B1. The formatting instructions have not been followed in a manner = consistent with other Internet-Drafts. For example - left side alignment = of text B2. Each MIB module should be contained in one document section or = subsection and not be divided in subsections. B3. There should be both a copyright notice at the beginning of the = document, and a copyright section at the end of the document. B4. The abstract section should not include references B5. The Security section needs to include the complete and explicit list = of writeable objects, not only examples. C. Editorial - minor C1. Expiration date is typically six month after publication. There is = no reason to take an earlier date. C2. WG Chair affiliation needs to be changed from Avaya Inc. to Avaya ------_=_NextPart_001_01C3FC5C.D5A1BADC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-hubmib-efm-epon-mib-00.txt

Please find below my comments = wrt. draft-ietf-hubmib-efm-epon-mib-00.txt.

Regards,

Dan

A. = Technical

A1. It = is recommended to use Integer32 or Unsigned32 rather than INTEGER for = objects which indicate an integer value, with the exception of = enumeration objects.

A2. unknown object identifier = label `dot3EfmeponMIB' in the first MIB module.

A3. There = is a left-over bracket in the definition of eponDeviceObjectOnuLoopback which prevents correct = compilation of the MIB module.

A4 It = would be very useful to add a section defining the relationship between = the objects in this MIB and the management objects defined in IEEE 802.3 = ah

A5. The = MIB content needs to be aligned with the latest IEEE 802.3ah draft = (3.1?)




B. = Editorial - major

B1. The = formatting instructions have not been followed in a manner consistent = with other Internet-Drafts. For example - left side alignment of = text

B2. Each = MIB module should be contained in one document section or subsection and = not be divided in subsections.

B3. = There should be both a copyright notice at the beginning of the = document, and a copyright section at the end of the = document.

B4. The = abstract section should not include references

B5. The = Security section needs to include the complete and explicit list of = writeable objects, not only examples.







C. = Editorial - minor

C1. = Expiration date is typically six month after publication. There is no = reason to take an earlier date.

C2. WG = Chair affiliation needs to be changed from Avaya Inc. to = Avaya



------_=_NextPart_001_01C3FC5C.D5A1BADC-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Feb 26 06:39:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05847 for ; Thu, 26 Feb 2004 06:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJr4-0008O3-S7 for hubmib-archive@odin.ietf.org; Thu, 26 Feb 2004 06:39:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QBd2Dw032235 for hubmib-archive@odin.ietf.org; Thu, 26 Feb 2004 06:39:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJr3-0008NN-8m; Thu, 26 Feb 2004 06:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwJqo-0008MJ-TH for hubmib@optimus.ietf.org; Thu, 26 Feb 2004 06:38:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05822 for ; Thu, 26 Feb 2004 06:38:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwJqk-0003H4-00 for hubmib@ietf.org; Thu, 26 Feb 2004 06:38:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwJps-0003A2-00 for hubmib@ietf.org; Thu, 26 Feb 2004 06:37:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AwJp8-00033A-00 for hubmib@ietf.org; Thu, 26 Feb 2004 06:37:02 -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 i1QBX1pc022317 for ; Thu, 26 Feb 2004 06:33:01 -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 i1QBWwpc022288 for ; Thu, 26 Feb 2004 06:33:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC5C.D5A1BADC" Date: Thu, 26 Feb 2004 13:36:54 +0200 Message-ID: Thread-Topic: Comments on draft-ietf-hubmib-efm-epon-mib-00.txt Thread-Index: AcP8XNWQFhj+WPFYSVSaCMrlZvIjcA== From: "Romascanu, Dan (Dan)" To: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_30_40,HTML_MESSAGE autolearn=no version=2.60 Subject: [Hubmib] Comments on draft-ietf-hubmib-efm-epon-mib-00.txt Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC5C.D5A1BADC Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Please find below my comments wrt. = draft-ietf-hubmib-efm-epon-mib-00.txt. Regards, Dan A. Technical A1. It is recommended to use Integer32 or Unsigned32 rather than INTEGER = for objects which indicate an integer value, with the exception of = enumeration objects. A2. unknown object identifier label `dot3EfmeponMIB' in the first MIB = module. A3. There is a left-over bracket in the definition of = eponDeviceObjectOnuLoopback which prevents correct compilation of the = MIB module.=20 A4 It would be very useful to add a section defining the relationship = between the objects in this MIB and the management objects defined in = IEEE 802.3 ah A5. The MIB content needs to be aligned with the latest IEEE 802.3ah = draft (3.1?) B. Editorial - major B1. The formatting instructions have not been followed in a manner = consistent with other Internet-Drafts. For example - left side alignment = of text B2. Each MIB module should be contained in one document section or = subsection and not be divided in subsections. B3. There should be both a copyright notice at the beginning of the = document, and a copyright section at the end of the document. B4. The abstract section should not include references B5. The Security section needs to include the complete and explicit list = of writeable objects, not only examples. C. Editorial - minor C1. Expiration date is typically six month after publication. There is = no reason to take an earlier date. C2. WG Chair affiliation needs to be changed from Avaya Inc. to Avaya ------_=_NextPart_001_01C3FC5C.D5A1BADC Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-hubmib-efm-epon-mib-00.txt

Please find below my comments = wrt. draft-ietf-hubmib-efm-epon-mib-00.txt.

Regards,

Dan

A. = Technical

A1. It = is recommended to use Integer32 or Unsigned32 rather than INTEGER for = objects which indicate an integer value, with the exception of = enumeration objects.

A2. unknown object identifier = label `dot3EfmeponMIB' in the first MIB module.

A3. There = is a left-over bracket in the definition of eponDeviceObjectOnuLoopback which prevents correct = compilation of the MIB module.

A4 It = would be very useful to add a section defining the relationship between = the objects in this MIB and the management objects defined in IEEE 802.3 = ah

A5. The = MIB content needs to be aligned with the latest IEEE 802.3ah draft = (3.1?)




B. = Editorial - major

B1. The = formatting instructions have not been followed in a manner consistent = with other Internet-Drafts. For example - left side alignment of = text

B2. Each = MIB module should be contained in one document section or subsection and = not be divided in subsections.

B3. = There should be both a copyright notice at the beginning of the = document, and a copyright section at the end of the = document.

B4. The = abstract section should not include references

B5. The = Security section needs to include the complete and explicit list of = writeable objects, not only examples.







C. = Editorial - minor

C1. = Expiration date is typically six month after publication. There is no = reason to take an earlier date.

C2. WG = Chair affiliation needs to be changed from Avaya Inc. to = Avaya



------_=_NextPart_001_01C3FC5C.D5A1BADC-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Feb 26 12:17:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25408 for ; Thu, 26 Feb 2004 12:17:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwP88-00083e-SI; Thu, 26 Feb 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwP7Q-0007wb-4O for hubmib@optimus.ietf.org; Thu, 26 Feb 2004 12:16:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25235 for ; Thu, 26 Feb 2004 12:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwP7O-0003BW-00 for hubmib@ietf.org; Thu, 26 Feb 2004 12:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwP6A-00031F-00 for hubmib@ietf.org; Thu, 26 Feb 2004 12:15:00 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AwP50-0002pa-00 for hubmib@ietf.org; Thu, 26 Feb 2004 12:13:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC8B.D289FD84" Date: Thu, 26 Feb 2004 12:13:15 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714023387BB@mailserv.hatteras.com> Thread-Topic: Dot3OamEntry in EFM-COMMON-MIB Thread-Index: AcP3dpJw5gJh1G7OQkawMl4TazheUAFFMScw From: "Matt Squire" To: "Rajagopalan Subramanian" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC8B.D289FD84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thats a good point. The difficulty is that the actual "statistic" is = not available, but the "event" is available. The difference being that = if the event never happens, there is nothing in the event table, and = therefore the info isn't there. If the event does happen, the info is = there in the event. =20 =20 Quite the predicament. =20 My thought would be that we make all of the event information available = in the MIB, so that the running total is available when the event = occurs, but to not try to introduce the actual statistics that do not = currenly exist in the Ethernet MIB (for example, symbol errors). =20 =20 Does that work? -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Friday, February 20, 2004 12:58 AM To: Matt Squire Cc: 'hubmib@ietf.org' Subject: RE: Dot3OamEntry in EFM-COMMON-MIB Hi Matt, Its good to have Traps to report whenever there is an OAM event.=20 =20 But according to the 802.3ah Standard, in the section 30A.19, = aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = 'GET' attributes of am OAM object class. The definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also implies that they should be updated as and when we receive or send = an Event Notification. This made me believe that these events should also be maintained as SNMP = (statistics) table attributes. =20 Your thoughts please. =20 Thanks Raj Subramanian =20 =20 -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com]=20 Sent: Friday, February 06, 2004 9:14 AM =20 Thats a good question. I'm still a little unsure of how to best map the = event tables into MIB stuff. But we will almost definitly include the = running totals into the event information, along with all of the other = fields in the event TLVs. =20 =20 One possibility is to simply map each OAM event to a notification (SNMP = trap), where we take all fields (including the running totals) into the = trap. Thats the way I'm leaning presently, where we don't maintain any = SNMP tables for the events, and instead just map them to SNMP traps. If = you think thats good/bad, let me know. =20 =20 - Matt -----Original Message----- From: jayaprakash.kulkarni@wipro.com = [mailto:jayaprakash.kulkarni@wipro.com] Sent: Tuesday, January 20, 2004 6:24 AM To: Matt Squire Subject: Dot3OamEntry in EFM-COMMON-MIB Hi Matt =20 Got one more doubt while going through the = draft-squire-hubmib-efm-mib-00.txt =20 Are you planning to provide the following running-total counters in the = Dot3OamEntry along with the dot3OamThreshold and Config objects? =20 dot3OamErrSymRunningTotal dot3OamErrFrameSecsSummaryRunningTotal dot3OamErrFrameRunningTotal dot3OamErrFramePeriodRunningTotal =20 regards Jayaprakash =20 Confidentiality Notice =20 =20 The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. =20 Confidentiality Notice The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------_=_NextPart_001_01C3FC8B.D289FD84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Thats=20 a good point.  The difficulty is that the actual "statistic" is not = available, but the "event" is available.  The difference being that = if the=20 event never happens, there is nothing in the event table, and therefore = the info=20 isn't there.  If the event does happen, the info is there in the=20 event. 
 
Quite=20 the predicament.
 
My=20 thought would be that we make all of the event information available in = the MIB,=20 so that the running total is available when the event occurs, but to not = try to=20 introduce the actual statistics that do not currenly exist in the = Ethernet MIB=20 (for example, symbol errors). 
 
Does=20 that work?
-----Original Message-----
From: Rajagopalan = Subramanian=20 [mailto:rajas@Centillium.com]
Sent: Friday, February 20, = 2004 12:58=20 AM
To: Matt Squire
Cc:=20 'hubmib@ietf.org'
Subject: RE: Dot3OamEntry in=20 EFM-COMMON-MIB

Hi=20 Matt,

Its = good to=20 have Traps to report whenever there is an OAM event.=20

 

But=20 according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = ‘GET’ attributes=20 of am OAM object class.

The=20 definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also=20 implies that they should be updated as and when we receive or send an = Event=20 Notification.

This made=20 me believe that these events should also be maintained as SNMP = (statistics)=20 table attributes.

 

Your=20 thoughts please.

 

Thanks

Raj=20 Subramanian

 

 

-----Original=20 Message-----
From: = Matt=20 Squire [mailto:MSquire@HatterasNetworks.com]
Sent: Friday, February 06,=20 2004 = 9:14=20 AM

 

Thats a good=20 question.  I'm still a little unsure of how to best map the event = tables=20 into MIB stuff. =20 But=20 we will almost definitly include the running totals into the event=20 information, along with all of the other fields in the event=20 TLVs. 

 

One=20 possibility is to simply map each OAM event to a notification (SNMP = trap),=20 where we take all fields (including the running totals) into the = trap. =20 Thats the way I'm leaning presently, where we don't maintain any SNMP = tables=20 for the events, and instead just map them to SNMP traps.  If you = think=20 thats good/bad, let me know. 

 

-=20 Matt

-----Original=20 Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Tuesday, January 20, = 2004 6:24=20 AM
To: Matt=20 Squire
Subject:=20 Dot3OamEntry in EFM-COMMON-MIB

Hi=20 Matt

 

Got one more doubt = while going=20 through the=20 = draft-squire-hubmib-efm-mib-00.txt

 

Are you planning to = provide the=20 following running-total counters in the Dot3OamEntry along with the=20 dot3OamThreshold and Config = objects?

 

dot3OamErrSymRunningTotal

dot3OamErrFrameSecsSummaryRunningTotal

dot3OamErrFrameRunningTotal

dot3OamErrFramePeriodRunningTotal

 

regards

Jayaprakash

 

Confidentiality =
Notice
 
 
The information contained in this electronic message and any =
attachments to this message are =
intended
for =
the exclusive use of the addressee(s) and may contain confidential or =
privileged information. If
you are not the intended recipient, please notify =
the sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 

Confidentiality =
Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------_=_NextPart_001_01C3FC8B.D289FD84-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Feb 26 12:17:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25425 for ; Thu, 26 Feb 2004 12:17:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwP89-000845-OI for hubmib-archive@odin.ietf.org; Thu, 26 Feb 2004 12:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QHH1Km030996 for hubmib-archive@odin.ietf.org; Thu, 26 Feb 2004 12:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwP88-00083e-SI; Thu, 26 Feb 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwP7Q-0007wb-4O for hubmib@optimus.ietf.org; Thu, 26 Feb 2004 12:16:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25235 for ; Thu, 26 Feb 2004 12:16:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwP7O-0003BW-00 for hubmib@ietf.org; Thu, 26 Feb 2004 12:16:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwP6A-00031F-00 for hubmib@ietf.org; Thu, 26 Feb 2004 12:15:00 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AwP50-0002pa-00 for hubmib@ietf.org; Thu, 26 Feb 2004 12:13:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC8B.D289FD84" Date: Thu, 26 Feb 2004 12:13:15 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714023387BB@mailserv.hatteras.com> Thread-Topic: Dot3OamEntry in EFM-COMMON-MIB Thread-Index: AcP3dpJw5gJh1G7OQkawMl4TazheUAFFMScw From: "Matt Squire" To: "Rajagopalan Subramanian" Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE, HTML_TAG_EXISTS_TBODY,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Dot3OamEntry in EFM-COMMON-MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3FC8B.D289FD84 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thats a good point. The difficulty is that the actual "statistic" is = not available, but the "event" is available. The difference being that = if the event never happens, there is nothing in the event table, and = therefore the info isn't there. If the event does happen, the info is = there in the event. =20 =20 Quite the predicament. =20 My thought would be that we make all of the event information available = in the MIB, so that the running total is available when the event = occurs, but to not try to introduce the actual statistics that do not = currenly exist in the Ethernet MIB (for example, symbol errors). =20 =20 Does that work? -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Friday, February 20, 2004 12:58 AM To: Matt Squire Cc: 'hubmib@ietf.org' Subject: RE: Dot3OamEntry in EFM-COMMON-MIB Hi Matt, Its good to have Traps to report whenever there is an OAM event.=20 =20 But according to the 802.3ah Standard, in the section 30A.19, = aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = 'GET' attributes of am OAM object class. The definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also implies that they should be updated as and when we receive or send = an Event Notification. This made me believe that these events should also be maintained as SNMP = (statistics) table attributes. =20 Your thoughts please. =20 Thanks Raj Subramanian =20 =20 -----Original Message----- From: Matt Squire [mailto:MSquire@HatterasNetworks.com]=20 Sent: Friday, February 06, 2004 9:14 AM =20 Thats a good question. I'm still a little unsure of how to best map the = event tables into MIB stuff. But we will almost definitly include the = running totals into the event information, along with all of the other = fields in the event TLVs. =20 =20 One possibility is to simply map each OAM event to a notification (SNMP = trap), where we take all fields (including the running totals) into the = trap. Thats the way I'm leaning presently, where we don't maintain any = SNMP tables for the events, and instead just map them to SNMP traps. If = you think thats good/bad, let me know. =20 =20 - Matt -----Original Message----- From: jayaprakash.kulkarni@wipro.com = [mailto:jayaprakash.kulkarni@wipro.com] Sent: Tuesday, January 20, 2004 6:24 AM To: Matt Squire Subject: Dot3OamEntry in EFM-COMMON-MIB Hi Matt =20 Got one more doubt while going through the = draft-squire-hubmib-efm-mib-00.txt =20 Are you planning to provide the following running-total counters in the = Dot3OamEntry along with the dot3OamThreshold and Config objects? =20 dot3OamErrSymRunningTotal dot3OamErrFrameSecsSummaryRunningTotal dot3OamErrFrameRunningTotal dot3OamErrFramePeriodRunningTotal =20 regards Jayaprakash =20 Confidentiality Notice =20 =20 The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. =20 Confidentiality Notice The information contained in this electronic message and any attachments = to this message are intended for the exclusive use of the addressee(s) and may contain confidential = or privileged information. If you are not the intended recipient, please notify the sender at Wipro or = Mailadmin@wipro.com immediately and destroy all copies of this message and any attachments. ------_=_NextPart_001_01C3FC8B.D289FD84 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Thats=20 a good point.  The difficulty is that the actual "statistic" is not = available, but the "event" is available.  The difference being that = if the=20 event never happens, there is nothing in the event table, and therefore = the info=20 isn't there.  If the event does happen, the info is there in the=20 event. 
 
Quite=20 the predicament.
 
My=20 thought would be that we make all of the event information available in = the MIB,=20 so that the running total is available when the event occurs, but to not = try to=20 introduce the actual statistics that do not currenly exist in the = Ethernet MIB=20 (for example, symbol errors). 
 
Does=20 that work?
-----Original Message-----
From: Rajagopalan = Subramanian=20 [mailto:rajas@Centillium.com]
Sent: Friday, February 20, = 2004 12:58=20 AM
To: Matt Squire
Cc:=20 'hubmib@ietf.org'
Subject: RE: Dot3OamEntry in=20 EFM-COMMON-MIB

Hi=20 Matt,

Its = good to=20 have Traps to report whenever there is an OAM event.=20

 

But=20 according to the 802.3ah Standard, in the section 30A.19, aOAMLocalErrSymPeriodEvent and aOAMRemoteErrSymPeriodEvent are listed as = ‘GET’ attributes=20 of am OAM object class.

The=20 definition for these in the sections 30.11.1.1.30 and 30.11.1.1.37 = also=20 implies that they should be updated as and when we receive or send an = Event=20 Notification.

This made=20 me believe that these events should also be maintained as SNMP = (statistics)=20 table attributes.

 

Your=20 thoughts please.

 

Thanks

Raj=20 Subramanian

 

 

-----Original=20 Message-----
From: = Matt=20 Squire [mailto:MSquire@HatterasNetworks.com]
Sent: Friday, February 06,=20 2004 = 9:14=20 AM

 

Thats a good=20 question.  I'm still a little unsure of how to best map the event = tables=20 into MIB stuff. =20 But=20 we will almost definitly include the running totals into the event=20 information, along with all of the other fields in the event=20 TLVs. 

 

One=20 possibility is to simply map each OAM event to a notification (SNMP = trap),=20 where we take all fields (including the running totals) into the = trap. =20 Thats the way I'm leaning presently, where we don't maintain any SNMP = tables=20 for the events, and instead just map them to SNMP traps.  If you = think=20 thats good/bad, let me know. 

 

-=20 Matt

-----Original=20 Message-----
From:=20 jayaprakash.kulkarni@wipro.com=20 [mailto:jayaprakash.kulkarni@wipro.com]
Sent: Tuesday, January 20, = 2004 6:24=20 AM
To: Matt=20 Squire
Subject:=20 Dot3OamEntry in EFM-COMMON-MIB

Hi=20 Matt

 

Got one more doubt = while going=20 through the=20 = draft-squire-hubmib-efm-mib-00.txt

 

Are you planning to = provide the=20 following running-total counters in the Dot3OamEntry along with the=20 dot3OamThreshold and Config = objects?

 

dot3OamErrSymRunningTotal

dot3OamErrFrameSecsSummaryRunningTotal

dot3OamErrFrameRunningTotal

dot3OamErrFramePeriodRunningTotal

 

regards

Jayaprakash

 

Confidentiality =
Notice
 
 
The information contained in this electronic message and any =
attachments to this message are =
intended
for =
the exclusive use of the addressee(s) and may contain confidential or =
privileged information. If
you are not the intended recipient, please notify =
the sender at Wipro or Mailadmin@wipro.com =
immediately
and destroy all copies of this message and any =
attachments.

 

Confidentiality =
Notice


The information contained in this electronic message and any attachments =
to this message are intended
for the exclusive use of the addressee(s) and may contain confidential =
or privileged information. If
you are not the intended recipient, please notify the sender at Wipro or =
Mailadmin@wipro.com immediately
and destroy all copies of this message and any attachments.
------_=_NextPart_001_01C3FC8B.D289FD84-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Thu Feb 26 17:20:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12875 for ; Thu, 26 Feb 2004 17:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwTrP-0001G9-Im; Thu, 26 Feb 2004 17:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwTrH-0001F6-Vr for hubmib@optimus.ietf.org; Thu, 26 Feb 2004 17:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12857 for ; Thu, 26 Feb 2004 17:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwTrF-0005Ym-00 for hubmib@ietf.org; Thu, 26 Feb 2004 17:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwTqO-0005T7-00 for hubmib@ietf.org; Thu, 26 Feb 2004 17:19:01 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AwTpn-0005Ly-00 for hubmib@ietf.org; Thu, 26 Feb 2004 17:18:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Thu, 26 Feb 2004 17:17:53 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714023387C8@mailserv.hatteras.com> Thread-Topic: EFM Common MIB - issues Thread-Index: AcP8tl1aaa5kPivjTCiMmCJUQ/q4ow== From: "Matt Squire" To: Cc: "Dan Romascanu (Dan) (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] EFM Common MIB - issues Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Below are some issues I'm running into when working on the next version = of the EFM Common MIB. Would appreciate any feedback. =20 - Matt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) "Common" vs "OAM". Right now, we call this MIB the EFM "common" MIB. = The idea, originally, was that this would cover anything common across = all EFM PHYs. Right now, the only thing in this MIB is OAM. The new = copper and EPON work have their own MIB. So should we re-name/re-focus = this MIB to be just OAM and not "common"? Although the difference to = the MIB section is negligible (a few name changes), I think the = difference in the overview/intro section is substantial. If "common", = it needs to talk about .3ah in all its glory, and provide an overview of = OAM/copper/PON. If "OAM", that goes away and its a relatively focused = overview/intro. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2) Loopback. I'd like to go to a loopback control that looks like=20 Dot3OamLoopbackEntry ::=3D SEQUENCE { dot3OamLoopbackCommand INTEGER, dot3OamLoopbackStatus INTEGER } Where you can issue a loopback command with the first entry, and the = second entry gives a loopoback state. The difficulty/benefit of the = loopback status variable is that in OAM and C30, we expose the = local/remote multiplexor/parser state, but there's no simple loopback = status. It seems more beneficial from a management status to provide = something simpler than exposing parser/mux status on each end of the = link. So here's what I'm thinking, and I'd appreciate thoughts if its = acceptable to try to simplify the interface like this, or of people = would rather have the parser/mux states available and let the user = figure out how that relates to a good loopback operation. =20 dot3OamLoopbackStatus OBJECT-TYPE SYNTAX INTEGER {=20 noLoopback (1),=20 initiatingLoopback (2), remoteLoopback (3), terminatingLoopback (4), localLoopback (5), unknown (6) }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION "The loopback status of the OAM entity. This=20 status is determined by a combination of the local parser and multiplexer states, the remote parser and multiplexer states, as well as by the actions of the local OAM client. When operating in normal mode with no loopback in progress, the status reads noLoopback(1). =20 =20 If the OAM client has sent an OAM loopback PDU and is waiting for a response, where the local parser and multiplexer states are DISCARD (see [802.3ah, 57.2.11.1]), the status is=20 'initiatingLoopback'. In this case, the local OAM entity has yet to receive any acknowledgement that the remote OAM entity has received its loopback command request. =20 =20 If the local OAM client knows that the remote OAM entity is in loopback mode (via the remote state information as described in [802.3ah, 57.2.11.1, 30.11.1.1.15]), the status is remoteLoopback(3). If the local OAM client is in the process of terminating the remote loopback [802.3ah, 57.2.11.3, 30.11.1.1.14], with its local multiplexer and parser states in DISCARD, the status is terminatingLoopback(4). If the remote OAM client has put the local OAM entity in loopback mode as indicated by its local parser state, the status is localLoopback(5). =20 The unknown(6) status indicates the parser and multiplexer combination is unexpected. This status may be returned if the OAM loopback is in a transition state but should not persist. =20 The values of this attribute correspond to the following values of the local and remote paser and multiplexer states, where 'X' means the state can be any value. =20 value LclPrsr LclMux RmtPrsr RmtMux noLoopback FWD FWD FWD FWD =20 initLoopback DISCARD DISCARD FWD FWD=20 rmtLoopback DISCARD FWD LPBK DISCARD tmtngLoopback DISCARD DISCARD LPBK DISCARD lclLoopback LPBK DISCARD DISCARD FWD unknown ** any other combination ** "=20 REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.11.1.1.14, 30.11.1.1.15" =20 ::=3D { dot3OamLoopbackEntry 2 } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3) Counters. For all of the counters, do we have to (or just should we) = always include some text reference on discontinuities, and if so, can we = just reference the ifCounterDiscontinuityTime or do we need something = else. For example, is the following text sufficient/good for each = counter: =20 Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 4) Event counters exposure. As has been discussed a little on the list, = Events can expose information thats not always there, and its kind of = funky. The primary example is symbol errors. There is not Ethernet = counter for symbol errors. However, we have events that trigger on = symbol errors, and if the event occurs, the number of symbol errors that = have occurred *at the time of the event* is available. So its a = counter, but its a snapshot view. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 5) Event Control. I had received a suggestion to have more control on = events (e.g. be able to turn them on/off). Such controls don't exist in = C30. However, the issueing of events happens architecturally within the = OAM client, which is sort of a black box and not specified within the = document. So I'd like to add controls for each event to (a) if that = event occurs, send an Event Notification OAMPDU, (b) if that event = occurs, send a SNMP notification, and (c) if that event is received from = the OAM peer, send a SNMP notification. I'm thinking about attributes = like the following (below is for Errored Symbol Events, but this applies = to other events too): =20 dot3OamErrSymPeriodWindow OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of symbols over which the=20 threshold is defined. =20 =20 If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating the threshold has been crossed in this window. =20 " REFERENCE "[802.3ah], 30.11.1.1.34" =20 ::=3D { dot3OamEventConfigEntry 1 } =20 dot3OamErrSymPeriodThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of symbols errors that must occur=20 for this event to be triggered. =20 =20 If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating the threshold has been crossed in this window. =20 " REFERENCE "[802.3ah], 30.11.1.1.34" =20 ::=3D { dot3OamEventConfigEntry 2 } dot3OamErrSymPeriodEvNotifEnable OBJECT-TYPE=20 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the occurence of Errored = Symbol=20 Period Events should result in Event Notification OAMPDUs generated by the OAM layer. = =20 By default, this object should have the value enabled(1) for Ethernet like interfaces that support OAM. If the OAM layer does not support event notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. =20 " REFERENCE "N/A" =20 ::=3D { dot3OamEventConfigEntry 3 } =20 dot3OamErrSymPeriodLclTrapEnable OBJECT-TYPE=20 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the occurence of Errored = Symbol=20 Period Events should result in SNMP traps.=20 =20 By default, this object should have the value disabled(1) for Ethernet like interfaces that support OAM. If the OAM layer does not support event notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. =20 " REFERENCE "N/A" =20 ::=3D { dot3OamEventConfigEntry 4 } =20 dot3OamErrSymPeriodRmtTrapEnable OBJECT-TYPE=20 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the reception of Errored=20 Symbol Period event from an OAM peer should=20 result in an SNMP trap.=20 =20 By default, this object should have the value disabled(1) for Ethernet like interfaces that support OAM. If the OAM layer does not support event notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. =20 " REFERENCE "N/A" =20 ::=3D { dot3OamEventConfigEntry 5 } The idea being you can set threshold that define "when something bad" = happens. Then you have additional control that define what you do about = it - e.g. send OAM events, send SNMP notifications, etc. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Thu Feb 26 18:06:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12877 for ; Thu, 26 Feb 2004 17:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwTrX-0001IJ-LH for hubmib-archive@odin.ietf.org; Thu, 26 Feb 2004 17:20:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1QMKBOv004904 for hubmib-archive@odin.ietf.org; Thu, 26 Feb 2004 17:20:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwTrP-0001G9-Im; Thu, 26 Feb 2004 17:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwTrH-0001F6-Vr for hubmib@optimus.ietf.org; Thu, 26 Feb 2004 17:19:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12857 for ; Thu, 26 Feb 2004 17:19:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwTrF-0005Ym-00 for hubmib@ietf.org; Thu, 26 Feb 2004 17:19:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwTqO-0005T7-00 for hubmib@ietf.org; Thu, 26 Feb 2004 17:19:01 -0500 Received: from mailserv.hatterasnetworks.com ([63.89.58.4]) by ietf-mx with esmtp (Exim 4.12) id 1AwTpn-0005Ly-00 for hubmib@ietf.org; Thu, 26 Feb 2004 17:18:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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: Thu, 26 Feb 2004 17:17:53 -0500 Message-ID: <8052E2EA753D144EB906B7A7AA399714023387C8@mailserv.hatteras.com> Thread-Topic: EFM Common MIB - issues Thread-Index: AcP8tl1aaa5kPivjTCiMmCJUQ/q4ow== From: "Matt Squire" To: Cc: "Dan Romascanu (Dan) (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.7 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Subject: [Hubmib] EFM Common MIB - issues Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Below are some issues I'm running into when working on the next version = of the EFM Common MIB. Would appreciate any feedback. =20 - Matt =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) "Common" vs "OAM". Right now, we call this MIB the EFM "common" MIB. = The idea, originally, was that this would cover anything common across = all EFM PHYs. Right now, the only thing in this MIB is OAM. The new = copper and EPON work have their own MIB. So should we re-name/re-focus = this MIB to be just OAM and not "common"? Although the difference to = the MIB section is negligible (a few name changes), I think the = difference in the overview/intro section is substantial. If "common", = it needs to talk about .3ah in all its glory, and provide an overview of = OAM/copper/PON. If "OAM", that goes away and its a relatively focused = overview/intro. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 2) Loopback. I'd like to go to a loopback control that looks like=20 Dot3OamLoopbackEntry ::=3D SEQUENCE { dot3OamLoopbackCommand INTEGER, dot3OamLoopbackStatus INTEGER } Where you can issue a loopback command with the first entry, and the = second entry gives a loopoback state. The difficulty/benefit of the = loopback status variable is that in OAM and C30, we expose the = local/remote multiplexor/parser state, but there's no simple loopback = status. It seems more beneficial from a management status to provide = something simpler than exposing parser/mux status on each end of the = link. So here's what I'm thinking, and I'd appreciate thoughts if its = acceptable to try to simplify the interface like this, or of people = would rather have the parser/mux states available and let the user = figure out how that relates to a good loopback operation. =20 dot3OamLoopbackStatus OBJECT-TYPE SYNTAX INTEGER {=20 noLoopback (1),=20 initiatingLoopback (2), remoteLoopback (3), terminatingLoopback (4), localLoopback (5), unknown (6) }=20 MAX-ACCESS read-only=20 STATUS current=20 DESCRIPTION "The loopback status of the OAM entity. This=20 status is determined by a combination of the local parser and multiplexer states, the remote parser and multiplexer states, as well as by the actions of the local OAM client. When operating in normal mode with no loopback in progress, the status reads noLoopback(1). =20 =20 If the OAM client has sent an OAM loopback PDU and is waiting for a response, where the local parser and multiplexer states are DISCARD (see [802.3ah, 57.2.11.1]), the status is=20 'initiatingLoopback'. In this case, the local OAM entity has yet to receive any acknowledgement that the remote OAM entity has received its loopback command request. =20 =20 If the local OAM client knows that the remote OAM entity is in loopback mode (via the remote state information as described in [802.3ah, 57.2.11.1, 30.11.1.1.15]), the status is remoteLoopback(3). If the local OAM client is in the process of terminating the remote loopback [802.3ah, 57.2.11.3, 30.11.1.1.14], with its local multiplexer and parser states in DISCARD, the status is terminatingLoopback(4). If the remote OAM client has put the local OAM entity in loopback mode as indicated by its local parser state, the status is localLoopback(5). =20 The unknown(6) status indicates the parser and multiplexer combination is unexpected. This status may be returned if the OAM loopback is in a transition state but should not persist. =20 The values of this attribute correspond to the following values of the local and remote paser and multiplexer states, where 'X' means the state can be any value. =20 value LclPrsr LclMux RmtPrsr RmtMux noLoopback FWD FWD FWD FWD =20 initLoopback DISCARD DISCARD FWD FWD=20 rmtLoopback DISCARD FWD LPBK DISCARD tmtngLoopback DISCARD DISCARD LPBK DISCARD lclLoopback LPBK DISCARD DISCARD FWD unknown ** any other combination ** "=20 REFERENCE "[802.3ah], REFERENCE 57.2.11, 30.11.1.1.14, 30.11.1.1.15" =20 ::=3D { dot3OamLoopbackEntry 2 } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 3) Counters. For all of the counters, do we have to (or just should we) = always include some text reference on discontinuities, and if so, can we = just reference the ifCounterDiscontinuityTime or do we need something = else. For example, is the following text sufficient/good for each = counter: =20 Discontinuities of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of the ifCounterDiscontinuityTime. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= 4) Event counters exposure. As has been discussed a little on the list, = Events can expose information thats not always there, and its kind of = funky. The primary example is symbol errors. There is not Ethernet = counter for symbol errors. However, we have events that trigger on = symbol errors, and if the event occurs, the number of symbol errors that = have occurred *at the time of the event* is available. So its a = counter, but its a snapshot view. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D 5) Event Control. I had received a suggestion to have more control on = events (e.g. be able to turn them on/off). Such controls don't exist in = C30. However, the issueing of events happens architecturally within the = OAM client, which is sort of a black box and not specified within the = document. So I'd like to add controls for each event to (a) if that = event occurs, send an Event Notification OAMPDU, (b) if that event = occurs, send a SNMP notification, and (c) if that event is received from = the OAM peer, send a SNMP notification. I'm thinking about attributes = like the following (below is for Errored Symbol Events, but this applies = to other events too): =20 dot3OamErrSymPeriodWindow OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of symbols over which the=20 threshold is defined. =20 =20 If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating the threshold has been crossed in this window. =20 " REFERENCE "[802.3ah], 30.11.1.1.34" =20 ::=3D { dot3OamEventConfigEntry 1 } =20 dot3OamErrSymPeriodThreshold OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of symbols errors that must occur=20 for this event to be triggered. =20 =20 If dot3OamErrSymPeriodThreshold symbol errors occur within a window of dot3OamErrSymPeriodWindow symbols, an Event Notification OAMPDU should be generated with an Errored Symbol Period Event TLV indicating the threshold has been crossed in this window. =20 " REFERENCE "[802.3ah], 30.11.1.1.34" =20 ::=3D { dot3OamEventConfigEntry 2 } dot3OamErrSymPeriodEvNotifEnable OBJECT-TYPE=20 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the occurence of Errored = Symbol=20 Period Events should result in Event Notification OAMPDUs generated by the OAM layer. = =20 By default, this object should have the value enabled(1) for Ethernet like interfaces that support OAM. If the OAM layer does not support event notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. =20 " REFERENCE "N/A" =20 ::=3D { dot3OamEventConfigEntry 3 } =20 dot3OamErrSymPeriodLclTrapEnable OBJECT-TYPE=20 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the occurence of Errored = Symbol=20 Period Events should result in SNMP traps.=20 =20 By default, this object should have the value disabled(1) for Ethernet like interfaces that support OAM. If the OAM layer does not support event notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. =20 " REFERENCE "N/A" =20 ::=3D { dot3OamEventConfigEntry 4 } =20 dot3OamErrSymPeriodRmtTrapEnable OBJECT-TYPE=20 SYNTAX INTEGER { enabled(1), disabled(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "Indicates whether the reception of Errored=20 Symbol Period event from an OAM peer should=20 result in an SNMP trap.=20 =20 By default, this object should have the value disabled(1) for Ethernet like interfaces that support OAM. If the OAM layer does not support event notifications (as indicated via the dot3OamFunctionsSupported attribute), this value is ignored. =20 " REFERENCE "N/A" =20 ::=3D { dot3OamEventConfigEntry 5 } The idea being you can set threshold that define "when something bad" = happens. Then you have additional control that define what you do about = it - e.g. send OAM events, send SNMP notifications, etc. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Feb 27 15:40:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23368 for ; Fri, 27 Feb 2004 15:40:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwomB-0003k0-5w; Fri, 27 Feb 2004 15:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlG7-00055Y-Tc for hubmib@optimus.ietf.org; Fri, 27 Feb 2004 11:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13608 for ; Fri, 27 Feb 2004 11:54:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwlG6-0007Tj-00 for hubmib@ietf.org; Fri, 27 Feb 2004 11:54:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwlFB-0007MJ-00 for hubmib@ietf.org; Fri, 27 Feb 2004 11:53:48 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AwlEW-0007EC-00 for hubmib@ietf.org; Fri, 27 Feb 2004 11:53:04 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.91vs) with SMTP id 3-070890763; Fri, 27 Feb 2004 11:52:46 -0500 (EST) From: "Lior khermosh" To: "'Rajagopalan Subramanian'" , , Cc: "'Hariprasad V. Nair'" Date: Fri, 27 Feb 2004 18:54:40 +0200 Message-ID: <000201c3fd52$667d7730$af2718ac@passave.co.il> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C3FD63.2A064730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A1A@apollo.centillium_nt.centillium.com> X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C3FD63.2A064730 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Raj, >1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. Isn't a deasserting mechanism also useful? For instance if the link is bad the alarm might be received a lot of times. A deassertion option will allow to remove such alarm. > Can they be optional then? How would then you suggest to define them. will a separate conformance group do? > 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the > eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. We can remove one but add a mechanism to insert OUI to identify a vendor - in the event. Best regards, Lior -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Monday, February 16, 2004 2:19 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. >From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State........ eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? >From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State........ eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------=_NextPart_000_0003_01C3FD63.2A064730 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Raj,
 

>1. Currently, as far as I know, =  the standard 802.3ah does not = suggest a=20 de-asserting mechanism.

 

Isn't a deasserting mechanism also useful? = For instance=20 if the link is bad the alarm might be received a lot of times. A = deassertion=20 option will allow to remove such alarm.

 

> Can they be optional=20 then?

How would then you = suggest to=20 define them. will a separate conformance group=20 do?

 

> 2. One thing I missed to point = out in my=20 previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState = seems=20 to be identical to the 

> = eponDeviceObjectVendorSpecificEventState=20 attribute. Or are they different? =20 Please clarify.

 

We can remove one = but add a=20 mechanism to insert OUI to identify a vendor - in the=20 event.

 

Best=20 regards,
Lior
 
-----Original Message-----
From: = Rajagopalan=20 Subramanian [mailto:rajas@Centillium.com]
Sent: Monday, = February=20 16, 2004 2:19 PM
To: 'Lior Khermosh';=20 'hubmib@ietf.org'
Cc: Hariprasad V. Nair
Subject: = RE:=20 Clarifications in EPON Device MIB

Hello Mr.=20 Khermosh,

 

Thanks for = your reply. I=20 am forwarding the earlier questions posted by me and your reply for = that,=20  to the mailing=20 list.

 

Few more = questions on=20 your reply :

 

1. Currently, = as far as=20 I know,  the standard = 802.3ah does=20 not suggest a de-asserting mechanism.

 

While standard = specify a=20 way to report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field=20 in the OAMPDU, it does not talk about resetting=20 them.

Similar is the = case for=20 all the Errored Events though an assertion and de-assertion is = possible in=20 this case without deviating from the standard, I=20 think.

However all = the Global=20 Events, Temperature and Voltage specific events and the Vendor = SpecificAlarm=20 Events,  are not defined = in the=20 standard. Can they be optional then?

 

2. One thing I = missed to=20 point out in my previous mail : Attribute=20 eponDeviceObjectOrganizationSpecificEventState seems to be identical = to the=20 eponDeviceObjectVendorSpecificEventState attribute. Or are they=20 different?  Please=20 clarify.

 

Thanks

Raj=20 Subramanian.

 

 

-----Original=20 Message-----
From: = Lior=20 Khermosh [mailto:lior.khermosh@passave.com]
Sent: Sunday, February 15,=20 2004 = 12:34=20 PM
To: Rajagopalan = Subramanian
Subject: RE: Clarifications in = EPON=20 Device MIB

 

Dear=20 Mr. = Subramanian,

 

Thank you=20 very much for your comments. They are very helpful. I would like to = ask the=20 permission to send the comments and replies to the hubmib = reflector for=20 the interest of all people.

 

eponDeviceObjectOnuLoopback – As=20 defined now it is redundant and should be removed.=20

 

From=20 eponDeviceObjectDyingGaspAlarmState = :

When=20 the dyingGaspAlarm state is removed the dying gasp alarm is=20 reset.

I=20 added it to the text.

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

 

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed so I = suggest to=20 keep them. I will add a description.

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed. Iwill = add a=20 description.

 

The difference in my = opinion=20 is:

 

Alarm:

When=20 the value of the alarm input is above the threshold defined for the = alarm the=20 alarm is asserted. When the condition is below that threshold the = alarm is=20 de-asserted.

 

Event:

When=20 the indication of the event input occurs the event is asserted. When = the input=20 is removed that event is de-asserted.

 

Event is more = referring to a=20 system condition while alarm indicates a bad thing happening in the=20 system.

 

eponDeviceObjectPowerDown=20

I think it is. An ONU = might have=20 a battery back up and when the device is starting to get down it = indicates=20 Power down. In my opinion it is a very important indication for the=20 carrier.

 

 

Best=20 regards,

Lior=20 Khermosh

 

 

 

-----Original=20 Message-----
From:=20 Rajagopalan Subramanian [mailto:rajas@Centillium.com]
Sent: Wednesday, February = 11,=20 2004 = 6:51=20 AM
To:=20 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications in = EPON Device=20 MIB

Hello = Mr.Khermosh,

 

I = have few=20 questions in the Device MIB that you had proposed as part of the=20 draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you can help me get it=20 clarified.

 

eponDeviceObjectOnuLoopback=20 –

In = what way is=20 this attribute different from the one defined in the EFM MIB,=20 dot3OamLoopbackCommand. In an implementation should both of these be = supported?

 

 

From=20 eponDeviceObjectDyingGaspAlarmState (Entry 8) to=20 eponDeviceObjectOrganizationSpecificEventState(Entry=20 27)=20 –

The = SYNTAX in the=20 MIB attribute says it’s a TruthValue and the description says = that ‘this bit=20 should be asserted when we receive the corresponding event’. = My question is=20 : The bit will be set when we receive an event but when will we = reset it ?=20 It cannot be always ‘1’ whenever the user reads this = attribute,=20 right?

 

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

The = description=20 says ‘ this event defines the state of the *respective* event of the OAM = Alarm=20 Indications as specified in the [802.3ah] clause=20 57.

But I = could not=20 locate these attributes in the Draft2.0 version of the standard. Can = you=20 give me pointers as to where I should be looking=20 into?

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The = description=20 for these two attributes are Identical.  I could not a = VendorAlarm and=20 a VendorEvent, separately in the clause 57. Can you give some info=20 please?

 

eponDeviceObjectPowerDown=20

Is = setting the=20 PowerDown a valid scenario for the = EPON?

 

Thanks for your=20 time.

 

Regards,

Raj=20 Subramanian

Centillium=20 India,=20

Bangalore,=20 INDIA

+91=20 80 25523575

 

<= /BODY> ------=_NextPart_000_0003_01C3FD63.2A064730-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From exim@www1.ietf.org Fri Feb 27 15:40:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23389 for ; Fri, 27 Feb 2004 15:40:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwomG-0003lZ-FH for hubmib-archive@odin.ietf.org; Fri, 27 Feb 2004 15:40:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1RKe8nq014469 for hubmib-archive@odin.ietf.org; Fri, 27 Feb 2004 15:40:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwomB-0003k0-5w; Fri, 27 Feb 2004 15:40:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AwlG7-00055Y-Tc for hubmib@optimus.ietf.org; Fri, 27 Feb 2004 11:54:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13608 for ; Fri, 27 Feb 2004 11:54:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AwlG6-0007Tj-00 for hubmib@ietf.org; Fri, 27 Feb 2004 11:54:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AwlFB-0007MJ-00 for hubmib@ietf.org; Fri, 27 Feb 2004 11:53:48 -0500 Received: from mail14a.sanjose14-verio.com ([128.121.143.14]) by ietf-mx with smtp (Exim 4.12) id 1AwlEW-0007EC-00 for hubmib@ietf.org; Fri, 27 Feb 2004 11:53:04 -0500 Received: from www.passave.com (128.121.207.126) by mail14a.sanjose14-verio.com (RS ver 1.0.91vs) with SMTP id 3-070890763; Fri, 27 Feb 2004 11:52:46 -0500 (EST) From: "Lior khermosh" To: "'Rajagopalan Subramanian'" , , Cc: "'Hariprasad V. Nair'" Date: Fri, 27 Feb 2004 18:54:40 +0200 Message-ID: <000201c3fd52$667d7730$af2718ac@passave.co.il> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C3FD63.2A064730" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <43E6B958AA8D9E48A3CCE2088577E7BA2F7A1A@apollo.centillium_nt.centillium.com> X-Loop-Detect: 1 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=AWL,HTML_60_70, HTML_FONTCOLOR_BLUE,HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE,TRACKER_ID autolearn=no version=2.60 Subject: [Hubmib] RE: Clarifications in EPON Device MIB Sender: hubmib-admin@ietf.org Errors-To: hubmib-admin@ietf.org X-BeenThere: hubmib@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C3FD63.2A064730 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Raj, >1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. Isn't a deasserting mechanism also useful? For instance if the link is bad the alarm might be received a lot of times. A deassertion option will allow to remove such alarm. > Can they be optional then? How would then you suggest to define them. will a separate conformance group do? > 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the > eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. We can remove one but add a mechanism to insert OUI to identify a vendor - in the event. Best regards, Lior -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Monday, February 16, 2004 2:19 PM To: 'Lior Khermosh'; 'hubmib@ietf.org' Cc: Hariprasad V. Nair Subject: RE: Clarifications in EPON Device MIB Hello Mr. Khermosh, Thanks for your reply. I am forwarding the earlier questions posted by me and your reply for that, to the mailing list. Few more questions on your reply : 1. Currently, as far as I know, the standard 802.3ah does not suggest a de-asserting mechanism. While standard specify a way to report the Critical link event, link fault and Dying Gasp events in the form of Flags field in the OAMPDU, it does not talk about resetting them. Similar is the case for all the Errored Events though an assertion and de-assertion is possible in this case without deviating from the standard, I think. However all the Global Events, Temperature and Voltage specific events and the Vendor SpecificAlarm Events, are not defined in the standard. Can they be optional then? 2. One thing I missed to point out in my previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState seems to be identical to the eponDeviceObjectVendorSpecificEventState attribute. Or are they different? Please clarify. Thanks Raj Subramanian. -----Original Message----- From: Lior Khermosh [mailto:lior.khermosh@passave.com] Sent: Sunday, February 15, 2004 12:34 PM To: Rajagopalan Subramanian Subject: RE: Clarifications in EPON Device MIB Dear Mr. Subramanian, Thank you very much for your comments. They are very helpful. I would like to ask the permission to send the comments and replies to the hubmib reflector for the interest of all people. eponDeviceObjectOnuLoopback - As defined now it is redundant and should be removed. >From eponDeviceObjectDyingGaspAlarmState : When the dyingGaspAlarm state is removed the dying gasp alarm is reset. I added it to the text. eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State........ eponDeviceObjectGlobalEvent7State The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed so I suggest to keep them. I will add a description. eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The alarms are not defined at the 802.3ah draft. I will remove this reference. However I still think that as alarms and event for device in access system they are needed. Iwill add a description. The difference in my opinion is: Alarm: When the value of the alarm input is above the threshold defined for the alarm the alarm is asserted. When the condition is below that threshold the alarm is de-asserted. Event: When the indication of the event input occurs the event is asserted. When the input is removed that event is de-asserted. Event is more referring to a system condition while alarm indicates a bad thing happening in the system. eponDeviceObjectPowerDown I think it is. An ONU might have a battery back up and when the device is starting to get down it indicates Power down. In my opinion it is a very important indication for the carrier. Best regards, Lior Khermosh -----Original Message----- From: Rajagopalan Subramanian [mailto:rajas@Centillium.com] Sent: Wednesday, February 11, 2004 6:51 AM To: 'lior.khermosh@passave.com' Cc: Rajagopalan Subramanian Subject: Clarifications in EPON Device MIB Hello Mr.Khermosh, I have few questions in the Device MIB that you had proposed as part of the draft-ietf-hubmib-efm-epon-mib-00. I would appreciate if you can help me get it clarified. eponDeviceObjectOnuLoopback - In what way is this attribute different from the one defined in the EFM MIB, dot3OamLoopbackCommand. In an implementation should both of these be supported? >From eponDeviceObjectDyingGaspAlarmState (Entry 8) to eponDeviceObjectOrganizationSpecificEventState(Entry 27) - The SYNTAX in the MIB attribute says it's a TruthValue and the description says that 'this bit should be asserted when we receive the corresponding event'. My question is : The bit will be set when we receive an event but when will we reset it ? It cannot be always '1' whenever the user reads this attribute, right? eponDeviceObjectTemperatureEventIndicationState, eponDeviceObjectPowerVoltageEventIndicationState , eponDeviceObjectGlobalEvent0State........ eponDeviceObjectGlobalEvent7State The description says ' this event defines the state of the *respective* event of the OAM Alarm Indications as specified in the [802.3ah] clause 57. But I could not locate these attributes in the Draft2.0 version of the standard. Can you give me pointers as to where I should be looking into? eponDeviceObjectVendorSpecificAlarmState, eponDeviceObjectVendorSpecificEventState The description for these two attributes are Identical. I could not a VendorAlarm and a VendorEvent, separately in the clause 57. Can you give some info please? eponDeviceObjectPowerDown Is setting the PowerDown a valid scenario for the EPON? Thanks for your time. Regards, Raj Subramanian Centillium India, Bangalore, INDIA +91 80 25523575 ------=_NextPart_000_0003_01C3FD63.2A064730 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Raj,
 

>1. Currently, as far as I know, =  the standard 802.3ah does not = suggest a=20 de-asserting mechanism.

 

Isn't a deasserting mechanism also useful? = For instance=20 if the link is bad the alarm might be received a lot of times. A = deassertion=20 option will allow to remove such alarm.

 

> Can they be optional=20 then?

How would then you = suggest to=20 define them. will a separate conformance group=20 do?

 

> 2. One thing I missed to point = out in my=20 previous mail : Attribute eponDeviceObjectOrganizationSpecificEventState = seems=20 to be identical to the 

> = eponDeviceObjectVendorSpecificEventState=20 attribute. Or are they different? =20 Please clarify.

 

We can remove one = but add a=20 mechanism to insert OUI to identify a vendor - in the=20 event.

 

Best=20 regards,
Lior
 
-----Original Message-----
From: = Rajagopalan=20 Subramanian [mailto:rajas@Centillium.com]
Sent: Monday, = February=20 16, 2004 2:19 PM
To: 'Lior Khermosh';=20 'hubmib@ietf.org'
Cc: Hariprasad V. Nair
Subject: = RE:=20 Clarifications in EPON Device MIB

Hello Mr.=20 Khermosh,

 

Thanks for = your reply. I=20 am forwarding the earlier questions posted by me and your reply for = that,=20  to the mailing=20 list.

 

Few more = questions on=20 your reply :

 

1. Currently, = as far as=20 I know,  the standard = 802.3ah does=20 not suggest a de-asserting mechanism.

 

While standard = specify a=20 way to report the Critical link event, link fault and Dying  Gasp events in the form of = Flags field=20 in the OAMPDU, it does not talk about resetting=20 them.

Similar is the = case for=20 all the Errored Events though an assertion and de-assertion is = possible in=20 this case without deviating from the standard, I=20 think.

However all = the Global=20 Events, Temperature and Voltage specific events and the Vendor = SpecificAlarm=20 Events,  are not defined = in the=20 standard. Can they be optional then?

 

2. One thing I = missed to=20 point out in my previous mail : Attribute=20 eponDeviceObjectOrganizationSpecificEventState seems to be identical = to the=20 eponDeviceObjectVendorSpecificEventState attribute. Or are they=20 different?  Please=20 clarify.

 

Thanks

Raj=20 Subramanian.

 

 

-----Original=20 Message-----
From: = Lior=20 Khermosh [mailto:lior.khermosh@passave.com]
Sent: Sunday, February 15,=20 2004 = 12:34=20 PM
To: Rajagopalan = Subramanian
Subject: RE: Clarifications in = EPON=20 Device MIB

 

Dear=20 Mr. = Subramanian,

 

Thank you=20 very much for your comments. They are very helpful. I would like to = ask the=20 permission to send the comments and replies to the hubmib = reflector for=20 the interest of all people.

 

eponDeviceObjectOnuLoopback – As=20 defined now it is redundant and should be removed.=20

 

From=20 eponDeviceObjectDyingGaspAlarmState = :

When=20 the dyingGaspAlarm state is removed the dying gasp alarm is=20 reset.

I=20 added it to the text.

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

 

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed so I = suggest to=20 keep them. I will add a description.

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The alarms are not = defined at=20 the 802.3ah draft. I will remove this reference. However I still think = that as=20 alarms and event for device in access system they are needed. Iwill = add a=20 description.

 

The difference in my = opinion=20 is:

 

Alarm:

When=20 the value of the alarm input is above the threshold defined for the = alarm the=20 alarm is asserted. When the condition is below that threshold the = alarm is=20 de-asserted.

 

Event:

When=20 the indication of the event input occurs the event is asserted. When = the input=20 is removed that event is de-asserted.

 

Event is more = referring to a=20 system condition while alarm indicates a bad thing happening in the=20 system.

 

eponDeviceObjectPowerDown=20

I think it is. An ONU = might have=20 a battery back up and when the device is starting to get down it = indicates=20 Power down. In my opinion it is a very important indication for the=20 carrier.

 

 

Best=20 regards,

Lior=20 Khermosh

 

 

 

-----Original=20 Message-----
From:=20 Rajagopalan Subramanian [mailto:rajas@Centillium.com]
Sent: Wednesday, February = 11,=20 2004 = 6:51=20 AM
To:=20 'lior.khermosh@passave.com'
Cc: Rajagopalan = Subramanian
Subject: Clarifications in = EPON Device=20 MIB

Hello = Mr.Khermosh,

 

I = have few=20 questions in the Device MIB that you had proposed as part of the=20 draft-ietf-hubmib-efm-epon-mib-00. I would appreciate  if you can help me get it=20 clarified.

 

eponDeviceObjectOnuLoopback=20 –

In = what way is=20 this attribute different from the one defined in the EFM MIB,=20 dot3OamLoopbackCommand. In an implementation should both of these be = supported?

 

 

From=20 eponDeviceObjectDyingGaspAlarmState (Entry 8) to=20 eponDeviceObjectOrganizationSpecificEventState(Entry=20 27)=20 –

The = SYNTAX in the=20 MIB attribute says it’s a TruthValue and the description says = that ‘this bit=20 should be asserted when we receive the corresponding event’. = My question is=20 : The bit will be set when we receive an event but when will we = reset it ?=20 It cannot be always ‘1’ whenever the user reads this = attribute,=20 right?

 

 

eponDeviceObjectTemperatureEventIndicationState,=20 eponDeviceObjectPowerVoltageEventIndicationState ,=20 = eponDeviceObjectGlobalEvent0State……………̷= 0;…. = eponDeviceObjectGlobalEvent7State=20

The = description=20 says ‘ this event defines the state of the *respective* event of the OAM = Alarm=20 Indications as specified in the [802.3ah] clause=20 57.

But I = could not=20 locate these attributes in the Draft2.0 version of the standard. Can = you=20 give me pointers as to where I should be looking=20 into?

 

eponDeviceObjectVendorSpecificAlarmState,=20 eponDeviceObjectVendorSpecificEventState =

The = description=20 for these two attributes are Identical.  I could not a = VendorAlarm and=20 a VendorEvent, separately in the clause 57. Can you give some info=20 please?

 

eponDeviceObjectPowerDown=20

Is = setting the=20 PowerDown a valid scenario for the = EPON?

 

Thanks for your=20 time.

 

Regards,

Raj=20 Subramanian

Centillium=20 India,=20

Bangalore,=20 INDIA

+91=20 80 25523575

 

<= /BODY> ------=_NextPart_000_0003_01C3FD63.2A064730-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib