From mailman-admin@ietf.org Sat Mar 1 12:20:13 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12275 for ; Sat, 1 Mar 2003 12:20:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h21HTJp31977 for ; Sat, 1 Mar 2003 12:29:19 -0500 Date: Sat, 01 Mar 2003 12:29:19 -0500 Message-ID: <20030301172919.26394.80686.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 mailnull@www1.ietf.org Fri Mar 7 12:28:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18629 for ; Fri, 7 Mar 2003 12:28:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27HdcD17919 for hubmib-archive@odin.ietf.org; Fri, 7 Mar 2003 12:39:38 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HdbO17912; Fri, 7 Mar 2003 12:39:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C14O15481 for ; Fri, 7 Mar 2003 07:01:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20227; Fri, 7 Mar 2003 06:49:04 -0500 (EST) Message-Id: <200303071149.GAA20227@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: Fri, 07 Mar 2003 06:49:04 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-mau-mib-v3-03.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 : Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) Author(s) : J. Flick Filename : draft-ietf-hubmib-mau-mib-v3-03.txt Pages : 62 Date : 2003-3-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-mau-mib-v3-03.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-mau-mib-v3-03.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-mau-mib-v3-03.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: <2003-3-6124214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-mau-mib-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-mau-mib-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124214.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Fri Mar 7 12:28:06 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18647 for ; Fri, 7 Mar 2003 12:28:06 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Hdfv17950 for hubmib-archive@odin.ietf.org; Fri, 7 Mar 2003 12:39:41 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HdfO17945; Fri, 7 Mar 2003 12:39:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C19O15489 for ; Fri, 7 Mar 2003 07:01:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20245; Fri, 7 Mar 2003 06:49:09 -0500 (EST) Message-Id: <200303071149.GAA20245@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: Fri, 07 Mar 2003 06:49:09 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-etherif-mib-v3-03.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 : Definitions of Managed Objects for the Ethernet-like Interface Types Author(s) : J. Flick Filename : draft-ietf-hubmib-etherif-mib-v3-03.txt Pages : 64 Date : 2003-3-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-etherif-mib-v3-03.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-etherif-mib-v3-03.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-etherif-mib-v3-03.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: <2003-3-6124223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-etherif-mib-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124223.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 7 12:28:10 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18663 for ; Fri, 7 Mar 2003 12:28:10 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HdbO17912; Fri, 7 Mar 2003 12:39:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C14O15481 for ; Fri, 7 Mar 2003 07:01:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20227; Fri, 7 Mar 2003 06:49:04 -0500 (EST) Message-Id: <200303071149.GAA20227@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: Fri, 07 Mar 2003 06:49:04 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-mau-mib-v3-03.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 : Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) Author(s) : J. Flick Filename : draft-ietf-hubmib-mau-mib-v3-03.txt Pages : 62 Date : 2003-3-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing IEEE 802.3 Medium Attachment Units (MAUs). This memo obsoletes RFC 2668. This memo extends that specification by including management information useful for the management of 10 gigabit per second (Gb/s) MAUs. This memo also obsoletes RFC 1515. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-mau-mib-v3-03.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-mau-mib-v3-03.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-mau-mib-v3-03.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: <2003-3-6124214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-mau-mib-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-mau-mib-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124214.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 7 12:28:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18680 for ; Fri, 7 Mar 2003 12:28:12 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27HdfO17945; Fri, 7 Mar 2003 12:39:41 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27C19O15489 for ; Fri, 7 Mar 2003 07:01:09 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20245; Fri, 7 Mar 2003 06:49:09 -0500 (EST) Message-Id: <200303071149.GAA20245@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: Fri, 07 Mar 2003 06:49:09 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-etherif-mib-v3-03.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 : Definitions of Managed Objects for the Ethernet-like Interface Types Author(s) : J. Flick Filename : draft-ietf-hubmib-etherif-mib-v3-03.txt Pages : 64 Date : 2003-3-6 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-etherif-mib-v3-03.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-etherif-mib-v3-03.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-etherif-mib-v3-03.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: <2003-3-6124223.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-etherif-mib-v3-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-etherif-mib-v3-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6124223.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Fri Mar 7 17:35:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10518 for ; Fri, 7 Mar 2003 17:35:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27MkiG21491 for hubmib-archive@odin.ietf.org; Fri, 7 Mar 2003 17:46:44 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MkhO21486; Fri, 7 Mar 2003 17:46:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MhhO21304 for ; Fri, 7 Mar 2003 17:43:43 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10234 for ; Fri, 7 Mar 2003 17:31:30 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id OAA25063; Fri, 7 Mar 2003 14:33:34 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 7 Mar 2003 14:33:25 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: hubmib@ietf.org Subject: Re: [Hubmib] I-D ACTION:draft-ietf-hubmib-mau-mib-v3-03.txt In-Reply-To: <200303071149.GAA20227@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , On Fri, 7 Mar 2003 Internet-Drafts@ietf.org wrote: > 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 : Definitions of Managed Objects for IEEE 802.3 Medium > Attachment Units (MAUs) > Author(s) : J. Flick > Filename : draft-ietf-hubmib-mau-mib-v3-03.txt > Pages : 62 > Date : 2003-3-6 Thanks to John Flick for posting this update. I have reviewed the changes relative to the -02 draft and on a quick look they all appear to be OK. I did notice two very minor things that can probably be addressed by the RFC Editor: - The title of Section 10 is "Authors' Addresses". I think that it should be "Author's Address" since there is now only one author. - The dates in the copyright notice on the front page and on the full copyright notice in Appendix B read (2002) instead of (2003). Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 7 17:35:07 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10535 for ; Fri, 7 Mar 2003 17:35:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MkhO21486; Fri, 7 Mar 2003 17:46:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MhhO21304 for ; Fri, 7 Mar 2003 17:43:43 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10234 for ; Fri, 7 Mar 2003 17:31:30 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id OAA25063; Fri, 7 Mar 2003 14:33:34 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 7 Mar 2003 14:33:25 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: hubmib@ietf.org Subject: Re: [Hubmib] I-D ACTION:draft-ietf-hubmib-mau-mib-v3-03.txt In-Reply-To: <200303071149.GAA20227@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , On Fri, 7 Mar 2003 Internet-Drafts@ietf.org wrote: > 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 : Definitions of Managed Objects for IEEE 802.3 Medium > Attachment Units (MAUs) > Author(s) : J. Flick > Filename : draft-ietf-hubmib-mau-mib-v3-03.txt > Pages : 62 > Date : 2003-3-6 Thanks to John Flick for posting this update. I have reviewed the changes relative to the -02 draft and on a quick look they all appear to be OK. I did notice two very minor things that can probably be addressed by the RFC Editor: - The title of Section 10 is "Authors' Addresses". I think that it should be "Author's Address" since there is now only one author. - The dates in the copyright notice on the front page and on the full copyright notice in Appendix B read (2002) instead of (2003). Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Fri Mar 7 17:36:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10661 for ; Fri, 7 Mar 2003 17:36:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h27Mm1921700 for hubmib-archive@odin.ietf.org; Fri, 7 Mar 2003 17:48:01 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Mm1O21695; Fri, 7 Mar 2003 17:48:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MlfO21680 for ; Fri, 7 Mar 2003 17:47:41 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10574 for ; Fri, 7 Mar 2003 17:35:28 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id OAA26455; Fri, 7 Mar 2003 14:37:32 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 7 Mar 2003 14:37:31 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: hubmib@ietf.org Subject: Re: [Hubmib] I-D ACTION:draft-ietf-hubmib-etherif-mib-v3-03.txt In-Reply-To: <200303071149.GAA20245@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , On Fri, 7 Mar 2003 Internet-Drafts@ietf.org wrote: > 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 : Definitions of Managed Objects for the Ethernet-like > Interface Types > Author(s) : J. Flick > Filename : draft-ietf-hubmib-etherif-mib-v3-03.txt > Pages : 64 > Date : 2003-3-6 Thanks to John Flick for posting this update. I have reviewed the changes relative to the -02 draft and on a quick look they all appear to be OK, with two exceptions: - There is a stray comma in the last sentence of the second paragraph of the Introduction (Section 1). The fix: s/version of this MIB, module,/version of this MIB module,/ - The date in the full copyright notice reads (2002) instead of (2003). Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 7 17:36:25 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10684 for ; Fri, 7 Mar 2003 17:36:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27Mm1O21695; Fri, 7 Mar 2003 17:48:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h27MlfO21680 for ; Fri, 7 Mar 2003 17:47:41 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10574 for ; Fri, 7 Mar 2003 17:35:28 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id OAA26455; Fri, 7 Mar 2003 14:37:32 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 7 Mar 2003 14:37:31 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: hubmib@ietf.org Subject: Re: [Hubmib] I-D ACTION:draft-ietf-hubmib-etherif-mib-v3-03.txt In-Reply-To: <200303071149.GAA20245@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , On Fri, 7 Mar 2003 Internet-Drafts@ietf.org wrote: > 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 : Definitions of Managed Objects for the Ethernet-like > Interface Types > Author(s) : J. Flick > Filename : draft-ietf-hubmib-etherif-mib-v3-03.txt > Pages : 64 > Date : 2003-3-6 Thanks to John Flick for posting this update. I have reviewed the changes relative to the -02 draft and on a quick look they all appear to be OK, with two exceptions: - There is a stray comma in the last sentence of the second paragraph of the Introduction (Section 1). The fix: s/version of this MIB, module,/version of this MIB module,/ - The date in the full copyright notice reads (2002) instead of (2003). Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Fri Mar 7 21:21:20 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04216 for ; Fri, 7 Mar 2003 21:21:20 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h282X7R11870 for hubmib-archive@odin.ietf.org; Fri, 7 Mar 2003 21:33:07 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282X7O11865; Fri, 7 Mar 2003 21:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282WsO11850 for ; Fri, 7 Mar 2003 21:32:54 -0500 Received: from palrel13.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04068 for ; Fri, 7 Mar 2003 21:20:35 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel13.hp.com (Postfix) with ESMTP id A61C41C014E7; Fri, 7 Mar 2003 18:22:40 -0800 (PST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id SAA16486; Fri, 7 Mar 2003 18:22:40 -0800 (PST) Message-ID: <3E6953ED.746D9723@rose.hp.com> Date: Fri, 07 Mar 2003 18:22:37 -0800 From: John Flick X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Hubmib Mailing List (E-mail)" Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-etherif-mib-v3-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit As you have probably already seen, I submitted an updated I-D which I believe addresses Bert's comments below. See below for more details on the changes to the doc. John "Wijnen, Bert (Bert)" wrote: > > Sorry that it took so long Sorry I took almost as long. > - sect 3.2.4. > Talks about deprecated things in IANA registry > Should also show up as an action in the IANA Considerations section > (I think IANA already did this, but still better to document > it as we would normally do) I added the following IANA considerations section: 10. IANA Considerations This document does not define any new name space to be administered by IANA. However, section 3.2.4 does specify that some of the defined values in a current IANA-maintained name space are to be marked as deprecated or obsolete. In particular, the following enumerated values in the IANAifType TEXTUAL-CONVENTION in the IANAifType-MIB module need to have an ASN.1 comment added stating that they have been deprecated: - iso88032Csmacd(7) - starLan(11) In addition, the following enumerated values need to have an ASN.1 comment added stating that they are obsolete: - fastEther(62) - fastEtherFX(69) - gigabitEthernet(117) In all of the above cases, the ASN.1 comment should indicate that ethernetCsmacd(6) should be used instead of these values. > - Sect 3.2.4 > Should we recommend (also in IANA Considerations section) that IAN > tries to contact registrants of those vendor specific ifTypes > to ask them to deprecate those registrations based on recommendations > in this document? I didn't add this recommendation, since the WG consensus on deprecating those ifTypes was pretty clear. Not sure if IANA contacts registrants on a change like this anyway, but I don't think that it would change the WG consensus. > - sect 3.2.10 > the things about ifAdminStatus and ifOperStatus are actually things that > we should also express in the MODULE-COMPLIANCE statements. As a result of subsequent comments from Mike Heard, and based on the MIB Review guidelines that were recently published, I updated the DESCRIPTION of the MODULE-COMPLIANCE statement as follows: DESCRIPTION "The compliance statement for managed network entities which have ethernet-like network interfaces. Note that compliance with this MIB module requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]. In addition, compliance with this MIB module requires compliance with the mauModIfCompl3 MODULE-COMPLIANCE statement of the MAU-MIB [MAU-MIB]." > - sect 3.4 > Should also be listed in IANA considerations section As noted in a message from Mike Heard, IANA does not maintain the chip set OID name space, so there is nothing to add to IANA considerations here. > - REVISION clause for this version... > - probably also should list which objects/other-things got deprecated > - and from the change log in the appendix I get the impression we should > probably list a few more things REVISION clause now reads as follows: REVISION "200302280000Z" -- February 28, 2003 DESCRIPTION "Updated to include support for 10 Gb/sec interfaces. This resulted in the following revisions: - Updated dot3StatsAlignmentErrors and dot3StatsSymbolErrors DESCRIPTIONs to reflect behaviour at 10 Gb/s - Added dot3StatsRateControlAbility and dot3RateControlStatus for management of the Rate Control function in 10 Gb/s WAN applications - Added 64-bit versions of all counters that are used on high-speed ethernet interfaces - Added object groups to contain the new objects - Deprecated etherStatsBaseGroup and split into etherStatsBaseGroup2 and etherStatsHalfDuplexGroup, so that interfaces which can only operate at full-duplex do not need to implement half-duplex-only statistics - Deprecated dot3Compliance and replaced it with dot3Compliance2, which includes the compliance information for the new object groups In addition, the dot3Tests and dot3Errors object identities have been deprecated, since there is no longer a standard method for using them. This version published as RFC XXXX." -- RFC Ed.: Replace XXXX with the actual RFC number & remove -- this note > - in DESCRIPTION of dot3StatsAlignmentErrors it says: > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of ifCounterDiscontinuityTime." > we can express requirement for ifCounterDiscontinuitytime in the > MODULE-COMPLIANCE. probably much more of IF-MIB is needed and so should > or at least could be expressed in MODULE-COMPLIANCE I believe this is covered by the changes to the DESCRIPTION clause in the MODULE-COMPLIANCE shown above. > - I believe there are a number of deprecated objects that do not include > a reason why they were deprecated in the DESCRIPTION clause. I believe these are all covered now. > - for line -- dot3 8 (on page 46) you have a reference [31] which I cannot > find in the references section Updated to [RFC2666]. > - Missing IANA Considerations section > IANA wants all actions nicely together in a one section so they can > quickly see what needs to be done and so they can point people to > one place as to why they did it. See above. > - Security considerations > - might be best to list the writeable objects and hwy they are > sensitive. Added the following: There is one management object defined in this MIB that has a MAX- ACCESS clause of read-write. That object, dot3PauseAdminMode, may be used to change the flow control configuration on a network interface, which may result in dropped packets, or sending flow control packets on links where the link partner will not understand them. Either action could be detrimental to network performance. > - Are there no other read-only objects that are sensitive? > The security ADs have become more picky on these things, so might want > to review and update. Added the following: Most of the objects in this MIB module contain statistical information about particular network links. In some network environments, this information may be considered sensitive. > Nits admin stuff > - In the abstract, it is sufficient to list just the RFC that is > being obsoleted, no need to have the title too. Abstract now reads: Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. The paragraph about ongoing evolution of Ethernet was moved to the Intro, to keep the Abstract short and to the point. > - I see read-only access for various INDEX objects. I think we inherited > this from old SMIv1 MIB modules. WOuld it be good to add a comment line > that says something aka > MAX-ACCESS read-only -- read-only since originally an SMIv1 index > that makes it clear to everyone, and then mib reviewers do not have to > re-check all the time Done > - The references are not split according to the listed split we published > and agreed upon on the mibs mailing list. But maybe better wait a little, > cause the new MIB boilerplate is coming out RSN (I think/hope) Done - updated boilerplate, and updated references accordingly. > - smilint complains that > 709: warning: use Integer32 instead of INTEGER in SMIv2 > which is > dot3CollCount OBJECT-TYPE > SYNTAX INTEGER (1..16) > I guess changing it to Integer32 would be OK since it is same base type. > But... up to editor/wg Fixed. > > Thanks, > Bert > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 7 21:21:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04259 for ; Fri, 7 Mar 2003 21:21:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282X7O11865; Fri, 7 Mar 2003 21:33:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282WsO11850 for ; Fri, 7 Mar 2003 21:32:54 -0500 Received: from palrel13.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04068 for ; Fri, 7 Mar 2003 21:20:35 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel13.hp.com (Postfix) with ESMTP id A61C41C014E7; Fri, 7 Mar 2003 18:22:40 -0800 (PST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id SAA16486; Fri, 7 Mar 2003 18:22:40 -0800 (PST) Message-ID: <3E6953ED.746D9723@rose.hp.com> Date: Fri, 07 Mar 2003 18:22:37 -0800 From: John Flick X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Hubmib Mailing List (E-mail)" Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-etherif-mib-v3-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit As you have probably already seen, I submitted an updated I-D which I believe addresses Bert's comments below. See below for more details on the changes to the doc. John "Wijnen, Bert (Bert)" wrote: > > Sorry that it took so long Sorry I took almost as long. > - sect 3.2.4. > Talks about deprecated things in IANA registry > Should also show up as an action in the IANA Considerations section > (I think IANA already did this, but still better to document > it as we would normally do) I added the following IANA considerations section: 10. IANA Considerations This document does not define any new name space to be administered by IANA. However, section 3.2.4 does specify that some of the defined values in a current IANA-maintained name space are to be marked as deprecated or obsolete. In particular, the following enumerated values in the IANAifType TEXTUAL-CONVENTION in the IANAifType-MIB module need to have an ASN.1 comment added stating that they have been deprecated: - iso88032Csmacd(7) - starLan(11) In addition, the following enumerated values need to have an ASN.1 comment added stating that they are obsolete: - fastEther(62) - fastEtherFX(69) - gigabitEthernet(117) In all of the above cases, the ASN.1 comment should indicate that ethernetCsmacd(6) should be used instead of these values. > - Sect 3.2.4 > Should we recommend (also in IANA Considerations section) that IAN > tries to contact registrants of those vendor specific ifTypes > to ask them to deprecate those registrations based on recommendations > in this document? I didn't add this recommendation, since the WG consensus on deprecating those ifTypes was pretty clear. Not sure if IANA contacts registrants on a change like this anyway, but I don't think that it would change the WG consensus. > - sect 3.2.10 > the things about ifAdminStatus and ifOperStatus are actually things that > we should also express in the MODULE-COMPLIANCE statements. As a result of subsequent comments from Mike Heard, and based on the MIB Review guidelines that were recently published, I updated the DESCRIPTION of the MODULE-COMPLIANCE statement as follows: DESCRIPTION "The compliance statement for managed network entities which have ethernet-like network interfaces. Note that compliance with this MIB module requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863]. In addition, compliance with this MIB module requires compliance with the mauModIfCompl3 MODULE-COMPLIANCE statement of the MAU-MIB [MAU-MIB]." > - sect 3.4 > Should also be listed in IANA considerations section As noted in a message from Mike Heard, IANA does not maintain the chip set OID name space, so there is nothing to add to IANA considerations here. > - REVISION clause for this version... > - probably also should list which objects/other-things got deprecated > - and from the change log in the appendix I get the impression we should > probably list a few more things REVISION clause now reads as follows: REVISION "200302280000Z" -- February 28, 2003 DESCRIPTION "Updated to include support for 10 Gb/sec interfaces. This resulted in the following revisions: - Updated dot3StatsAlignmentErrors and dot3StatsSymbolErrors DESCRIPTIONs to reflect behaviour at 10 Gb/s - Added dot3StatsRateControlAbility and dot3RateControlStatus for management of the Rate Control function in 10 Gb/s WAN applications - Added 64-bit versions of all counters that are used on high-speed ethernet interfaces - Added object groups to contain the new objects - Deprecated etherStatsBaseGroup and split into etherStatsBaseGroup2 and etherStatsHalfDuplexGroup, so that interfaces which can only operate at full-duplex do not need to implement half-duplex-only statistics - Deprecated dot3Compliance and replaced it with dot3Compliance2, which includes the compliance information for the new object groups In addition, the dot3Tests and dot3Errors object identities have been deprecated, since there is no longer a standard method for using them. This version published as RFC XXXX." -- RFC Ed.: Replace XXXX with the actual RFC number & remove -- this note > - in DESCRIPTION of dot3StatsAlignmentErrors it says: > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of ifCounterDiscontinuityTime." > we can express requirement for ifCounterDiscontinuitytime in the > MODULE-COMPLIANCE. probably much more of IF-MIB is needed and so should > or at least could be expressed in MODULE-COMPLIANCE I believe this is covered by the changes to the DESCRIPTION clause in the MODULE-COMPLIANCE shown above. > - I believe there are a number of deprecated objects that do not include > a reason why they were deprecated in the DESCRIPTION clause. I believe these are all covered now. > - for line -- dot3 8 (on page 46) you have a reference [31] which I cannot > find in the references section Updated to [RFC2666]. > - Missing IANA Considerations section > IANA wants all actions nicely together in a one section so they can > quickly see what needs to be done and so they can point people to > one place as to why they did it. See above. > - Security considerations > - might be best to list the writeable objects and hwy they are > sensitive. Added the following: There is one management object defined in this MIB that has a MAX- ACCESS clause of read-write. That object, dot3PauseAdminMode, may be used to change the flow control configuration on a network interface, which may result in dropped packets, or sending flow control packets on links where the link partner will not understand them. Either action could be detrimental to network performance. > - Are there no other read-only objects that are sensitive? > The security ADs have become more picky on these things, so might want > to review and update. Added the following: Most of the objects in this MIB module contain statistical information about particular network links. In some network environments, this information may be considered sensitive. > Nits admin stuff > - In the abstract, it is sufficient to list just the RFC that is > being obsoleted, no need to have the title too. Abstract now reads: Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Ethernet-like interfaces. This memo obsoletes RFC 2665. It updates that specification by including management information useful for the management of 10 Gigabit per second (Gb/s) Ethernet interfaces. Distribution of this memo is unlimited. Please forward comments to hubmib@ietf.org. The paragraph about ongoing evolution of Ethernet was moved to the Intro, to keep the Abstract short and to the point. > - I see read-only access for various INDEX objects. I think we inherited > this from old SMIv1 MIB modules. WOuld it be good to add a comment line > that says something aka > MAX-ACCESS read-only -- read-only since originally an SMIv1 index > that makes it clear to everyone, and then mib reviewers do not have to > re-check all the time Done > - The references are not split according to the listed split we published > and agreed upon on the mibs mailing list. But maybe better wait a little, > cause the new MIB boilerplate is coming out RSN (I think/hope) Done - updated boilerplate, and updated references accordingly. > - smilint complains that > 709: warning: use Integer32 instead of INTEGER in SMIv2 > which is > dot3CollCount OBJECT-TYPE > SYNTAX INTEGER (1..16) > I guess changing it to Integer32 would be OK since it is same base type. > But... up to editor/wg Fixed. > > Thanks, > Bert > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Fri Mar 7 21:35:14 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06304 for ; Fri, 7 Mar 2003 21:35:14 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h282l2H13676 for hubmib-archive@odin.ietf.org; Fri, 7 Mar 2003 21:47:02 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282l2O13671; Fri, 7 Mar 2003 21:47:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282kIO13651 for ; Fri, 7 Mar 2003 21:46:18 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06277 for ; Fri, 7 Mar 2003 21:33:58 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel12.hp.com (Postfix) with ESMTP id 6F0971C0118F; Fri, 7 Mar 2003 18:36:04 -0800 (PST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id SAA17292; Fri, 7 Mar 2003 18:36:02 -0800 (PST) Message-ID: <3E69570F.C0BBD5C3@rose.hp.com> Date: Fri, 07 Mar 2003 18:35:59 -0800 From: John Flick X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Hubmib Mailing List (E-mail)" Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-mau-mib-v3-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit As you have probably already seen, I submitted an updated I-D which I believe addresses Bert's comments below. See below for more details on the changes to the doc. John "Wijnen, Bert (Bert)" wrote: > > Sorry that it took so long Sorry I took almost as long. > - Sect 3.1 claims/states that rfc2668 will go to historic. > Well, you can recommend that in this document, but the WG cannot > just declare it. Maybe it is best to wriet a small doc that > recommends this action, similar to the way it was done for > draft-ietf-hubmib-1643-to-historic-01.txt > And maybe at the same time you can ask to make 2239 Historic > (instead of claiming so in sect 3.2) And are you also trying > to get 1515 to historic per sect 3.3? As per subsequent discussion, I removed the "go to historic" wording from 3.1 and 3.3, and state in the Abstract that this document obsoletes 2668 and 1515. Note: 1515 should have been obsoleted by 2239, so this is just fixing an earlier oversight. > - MODULE-IDENTITY latest (time wise) revision clause says > that updates were done for 10G support. I think that that > is indeed correect, but it would be probably good to add > that you also therefor added 64 bit counters, > And how about the new enumerations as listed under (6) in sect > A.1.? MODULE-IDENTITY REVISION now reads: REVISION "200302280000Z" -- February 28, 2003 DESCRIPTION "Updated to include support for 10 Gb/s MAUs. This resulted in the following revisions: - Added OBJECT-IDENTITY definitions for 10 gigabit MAU types - Added fiberLC jack type to JackType TC - Extended ifMauTypeListBits with bits for the 10 gigabit MAU types - Added enumerations to ifMauMediaAvailable, and updated its DESCRIPTION to reflect behaviour at 10 Gb/s - Added 64-bit version of ifMauFalseCarriers and added mauIfGrpHCStats object group to contain the new object - Deprecated mauModIfCompl2 and replaced it with mauModIfCompl3, which includes the new object group This version published as RFC XXXX." -- RFC Ed.: Replace XXXX with the actual RFC number & remove -- this note > - When I see things like: > dot3MauType10Base5 OBJECT-IDENTITY > STATUS current > DESCRIPTION "thick coax MAU (per 802.3 section 8)" > ::= { dot3MauType 2 } > then I thing that (per 802.3 section) is probably better captured > in some sort of REFERENCE clause, no? > You have a few more of those REFERENCE clauses added to all mauType OBJECT-IDENTITYs. > - in DESCRIPTION for rpMauJabberingStateEnters I read > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of rptrMonitorPortLastChange." > So I wonder if I should not see that under teh MODULE-COMPLIANCE As a result of subsequent comments from Mike Heard, and based on the MIB Review guidelines that were recently published, I updated the DESCRIPTION of the mauModRpCompl2 MODULE-COMPLIANCE statement as follows: DESCRIPTION "Compliance for MAUs attached to repeater ports. Note that compliance with this compliance statement requires compliance with the snmpRptrModCompl MODULE-COMPLIANCE statement of the SNMP-REPEATER-MIB [RFC2108]." > - in DESCRIPTION clause of ifMauMediaAvailableStateExits I read: > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of ifCounterDiscontinuityTime." > So I wonder if I should not see that under teh MODULE-COMPLIANCE As a result of subsequent comments from Mike Heard, and based on the MIB Review guidelines that were recently published, I updated the DESCRIPTION of the mauModIfCompl3 MODULE-COMPLIANCE statement as follows: DESCRIPTION "Compliance for MAUs attached to interfaces. Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863] and the dot3Compliance2 MODULE-COMPLIANCE statement of the EtherLike-MIB [ETHERIF]." > - I wonder if it would not be wise to change > ifMauType OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION "This object identifies the MAU type. An > initial set of MAU types are defined above. The > assignment of OBJECT IDENTIFIERs to new types of > into > ifMauType OBJECT-TYPE > SYNTAX AutonomousType > MAX-ACCESS read-only > STATUS current > DESCRIPTION "This object identifies the MAU type. An > initial set of MAU types are defined above. The > assignment of OBJECT-IDENTITIES to new types of > I think it is cleaner and I think it is a change that is allowed, > the underlying datatype is still OBJECT IDENTIFIER > > - Smae question for ifMauDefaultType Changed SYNTAX of rpMauType, ifMauType, and ifMauDefaultType to AutonomousType, and added appropriate IMPORT. > Nits and administrative comments > > - The RFC-Editor does no longer accept more than 5 authors/editors > on front page, see: http://www.rfc-editor.org/policy.html > I know I suggested the current format a year or so ago. > But RFC-Editor is changing the rules. Probably it is best to > keep John as Editor on front page and move the other names > in the acknowledgement section or in a contributors section > (this ection is talked about in the rfc-editor policy) Changed to list myself as the Editor on the front page and in the Author's Address section, and moved information about past editors and contributers to the Acknowledgements section. > - In the abstract, it is sufficient to list just the RFC that is > being obsoleted, no need to have the title too. Done > - you skip from sect 3.3. to sect 3.5 > is 3.4 missing, or did the counter just bump? Oops. Fixed. > - I see read-only access for various INDEX objects. I think we inherited > this from old SMIv1 MIB modules. WOuld it be good to add a comment line > that says something aka > MAX-ACCESS read-only -- read-only since originally an SMIv1 index > that makes it clear to everyone, and then mib reviewers do not have to > re-check all the time Done > - would it not be better to move the comments just before ifMauAutoNegTable > into the DESCRIPTION clause of the table itself? Done > - You have a number of objects and compliances that are deprecated. > It would be good to add a sentence (or two) to explain why. > Oops, I see that is stated at the end of the DESCRIPTION clause. > Mmm.. maybe would have been better at the beginning. Moved most descriptions of why things were deprecated to the beginning of the DESCRIPTION clauses. > - You may want to add in DESCRIPTION clause of broadMauBasicTable why the > table was deprecated DESCRIPTION of broadMauBasicTable now reads as follows: DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This entire table has been deprecated. There have been no reported implementations of this table, and it is unlikely that there ever will be. IEEE recommends that broadband MAU types should not be used for new installations. Table of descriptive and status information about the broadband MAUs connected to interfaces." > OK, I am still waiting for output from a smidiff run to check if indeed > all changes are legal. So based on that output I may have some more. > > Thanks, > Bert > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib Note: also added copyright statement to MODULE-IDENTITY of both this document and ether MIB document, as required by MIB Review guidelines. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Fri Mar 7 21:35:24 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06318 for ; Fri, 7 Mar 2003 21:35:24 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282l2O13671; Fri, 7 Mar 2003 21:47:02 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h282kIO13651 for ; Fri, 7 Mar 2003 21:46:18 -0500 Received: from palrel12.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06277 for ; Fri, 7 Mar 2003 21:33:58 -0500 (EST) Received: from rosemail.rose.hp.com (rosemail.rose.hp.com [15.96.64.26]) by palrel12.hp.com (Postfix) with ESMTP id 6F0971C0118F; Fri, 7 Mar 2003 18:36:04 -0800 (PST) Received: from rose.hp.com (ros54018fli.rose.hp.com [15.29.17.171]) by rosemail.rose.hp.com with ESMTP (8.7.1/8.7.3 SMKit7.02) id SAA17292; Fri, 7 Mar 2003 18:36:02 -0800 (PST) Message-ID: <3E69570F.C0BBD5C3@rose.hp.com> Date: Fri, 07 Mar 2003 18:35:59 -0800 From: John Flick X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Cc: "Hubmib Mailing List (E-mail)" Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-mau-mib-v3-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: 7bit As you have probably already seen, I submitted an updated I-D which I believe addresses Bert's comments below. See below for more details on the changes to the doc. John "Wijnen, Bert (Bert)" wrote: > > Sorry that it took so long Sorry I took almost as long. > - Sect 3.1 claims/states that rfc2668 will go to historic. > Well, you can recommend that in this document, but the WG cannot > just declare it. Maybe it is best to wriet a small doc that > recommends this action, similar to the way it was done for > draft-ietf-hubmib-1643-to-historic-01.txt > And maybe at the same time you can ask to make 2239 Historic > (instead of claiming so in sect 3.2) And are you also trying > to get 1515 to historic per sect 3.3? As per subsequent discussion, I removed the "go to historic" wording from 3.1 and 3.3, and state in the Abstract that this document obsoletes 2668 and 1515. Note: 1515 should have been obsoleted by 2239, so this is just fixing an earlier oversight. > - MODULE-IDENTITY latest (time wise) revision clause says > that updates were done for 10G support. I think that that > is indeed correect, but it would be probably good to add > that you also therefor added 64 bit counters, > And how about the new enumerations as listed under (6) in sect > A.1.? MODULE-IDENTITY REVISION now reads: REVISION "200302280000Z" -- February 28, 2003 DESCRIPTION "Updated to include support for 10 Gb/s MAUs. This resulted in the following revisions: - Added OBJECT-IDENTITY definitions for 10 gigabit MAU types - Added fiberLC jack type to JackType TC - Extended ifMauTypeListBits with bits for the 10 gigabit MAU types - Added enumerations to ifMauMediaAvailable, and updated its DESCRIPTION to reflect behaviour at 10 Gb/s - Added 64-bit version of ifMauFalseCarriers and added mauIfGrpHCStats object group to contain the new object - Deprecated mauModIfCompl2 and replaced it with mauModIfCompl3, which includes the new object group This version published as RFC XXXX." -- RFC Ed.: Replace XXXX with the actual RFC number & remove -- this note > - When I see things like: > dot3MauType10Base5 OBJECT-IDENTITY > STATUS current > DESCRIPTION "thick coax MAU (per 802.3 section 8)" > ::= { dot3MauType 2 } > then I thing that (per 802.3 section) is probably better captured > in some sort of REFERENCE clause, no? > You have a few more of those REFERENCE clauses added to all mauType OBJECT-IDENTITYs. > - in DESCRIPTION for rpMauJabberingStateEnters I read > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of rptrMonitorPortLastChange." > So I wonder if I should not see that under teh MODULE-COMPLIANCE As a result of subsequent comments from Mike Heard, and based on the MIB Review guidelines that were recently published, I updated the DESCRIPTION of the mauModRpCompl2 MODULE-COMPLIANCE statement as follows: DESCRIPTION "Compliance for MAUs attached to repeater ports. Note that compliance with this compliance statement requires compliance with the snmpRptrModCompl MODULE-COMPLIANCE statement of the SNMP-REPEATER-MIB [RFC2108]." > - in DESCRIPTION clause of ifMauMediaAvailableStateExits I read: > Discontinuities in the value of this counter can > occur at re-initialization of the management > system, and at other times as indicated by the > value of ifCounterDiscontinuityTime." > So I wonder if I should not see that under teh MODULE-COMPLIANCE As a result of subsequent comments from Mike Heard, and based on the MIB Review guidelines that were recently published, I updated the DESCRIPTION of the mauModIfCompl3 MODULE-COMPLIANCE statement as follows: DESCRIPTION "Compliance for MAUs attached to interfaces. Note that compliance with this compliance statement requires compliance with the ifCompliance3 MODULE-COMPLIANCE statement of the IF-MIB [RFC2863] and the dot3Compliance2 MODULE-COMPLIANCE statement of the EtherLike-MIB [ETHERIF]." > - I wonder if it would not be wise to change > ifMauType OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION "This object identifies the MAU type. An > initial set of MAU types are defined above. The > assignment of OBJECT IDENTIFIERs to new types of > into > ifMauType OBJECT-TYPE > SYNTAX AutonomousType > MAX-ACCESS read-only > STATUS current > DESCRIPTION "This object identifies the MAU type. An > initial set of MAU types are defined above. The > assignment of OBJECT-IDENTITIES to new types of > I think it is cleaner and I think it is a change that is allowed, > the underlying datatype is still OBJECT IDENTIFIER > > - Smae question for ifMauDefaultType Changed SYNTAX of rpMauType, ifMauType, and ifMauDefaultType to AutonomousType, and added appropriate IMPORT. > Nits and administrative comments > > - The RFC-Editor does no longer accept more than 5 authors/editors > on front page, see: http://www.rfc-editor.org/policy.html > I know I suggested the current format a year or so ago. > But RFC-Editor is changing the rules. Probably it is best to > keep John as Editor on front page and move the other names > in the acknowledgement section or in a contributors section > (this ection is talked about in the rfc-editor policy) Changed to list myself as the Editor on the front page and in the Author's Address section, and moved information about past editors and contributers to the Acknowledgements section. > - In the abstract, it is sufficient to list just the RFC that is > being obsoleted, no need to have the title too. Done > - you skip from sect 3.3. to sect 3.5 > is 3.4 missing, or did the counter just bump? Oops. Fixed. > - I see read-only access for various INDEX objects. I think we inherited > this from old SMIv1 MIB modules. WOuld it be good to add a comment line > that says something aka > MAX-ACCESS read-only -- read-only since originally an SMIv1 index > that makes it clear to everyone, and then mib reviewers do not have to > re-check all the time Done > - would it not be better to move the comments just before ifMauAutoNegTable > into the DESCRIPTION clause of the table itself? Done > - You have a number of objects and compliances that are deprecated. > It would be good to add a sentence (or two) to explain why. > Oops, I see that is stated at the end of the DESCRIPTION clause. > Mmm.. maybe would have been better at the beginning. Moved most descriptions of why things were deprecated to the beginning of the DESCRIPTION clauses. > - You may want to add in DESCRIPTION clause of broadMauBasicTable why the > table was deprecated DESCRIPTION of broadMauBasicTable now reads as follows: DESCRIPTION "********* THIS OBJECT IS DEPRECATED ********** This entire table has been deprecated. There have been no reported implementations of this table, and it is unlikely that there ever will be. IEEE recommends that broadband MAU types should not be used for new installations. Table of descriptive and status information about the broadband MAUs connected to interfaces." > OK, I am still waiting for output from a smidiff run to check if indeed > all changes are legal. So based on that output I may have some more. > > Thanks, > Bert > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib Note: also added copyright statement to MODULE-IDENTITY of both this document and ether MIB document, as required by MIB Review guidelines. _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Sat Mar 8 18:26:53 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04990 for ; Sat, 8 Mar 2003 18:26:53 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h28Nd5p15257 for hubmib-archive@odin.ietf.org; Sat, 8 Mar 2003 18:39:05 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28Nd4O15252; Sat, 8 Mar 2003 18:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NSpO14114 for ; Sat, 8 Mar 2003 18:28:51 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03263 for ; Sat, 8 Mar 2003 18:16:08 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id PAA15996; Sat, 8 Mar 2003 15:18:12 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 8 Mar 2003 15:18:09 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hubmib Mailing List Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , On Sun, 15 Dec 2002, C. M. Heard wrote: > > On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote: > > > - Sections 3.1, 3.2 and 3.3 talk about requirements to > > > implement pieces of other MIB modules. I see some of > > > it (from sonet mib) back in the MODULE-COMPLIANCE. > > > Should we not just include all of the required objects > > > from other MIB modules in the MODULE-COMPLIANCE? > > > > This subject was discussed at some length on the WG mailing > > list. The resolution was that we prefer, wherever possible, > > simply to reference an existing compliance statement. That > > was possible for the EtherLike-MIB (we point to > > dot3Compliance2) and the MAU-MIB (we point to mauModIfCompl3). > > It was not possible for the SONET-MIB, however, because we > > needed to make some objects [that are optional in] > > sonetCompliance2 mandatory for WIS applications. > > No change: since there was no feedback, I have assumed that the > rationale provided for keeping the existing compliance scheme > was OK. The consensus that was documented in the recently revised MIB review guidelines document -- which postdates the -06 version of the ETHER-WIS MIB -- is that modules incorporated by reference SHOULD be mentioned in the DESCRIPTION clause of a MODULE-COMPLIANCE statement as well as in the surrounding documentation, as John Flick has done in the recently-submitted EtherLike-MIB and the MAU-MIB drafts. If the AD, chair, and WG have no objections, I shall (after the IETF-56 I-D blackout ends) update the ETHER-WIS compliance statement to bring it into conformance with this guideline. It will need to mention the IF-MIB's ifCompliance3 statement, the IF-INVERTED-STACK-MIB's ifInvCompliance statement, the EtherLike-MIB's dot3Compliance2 statement, and the MAU-MIB's mauModIfCompl3 statement. In addition, after further review, I find that the following comment I made against the -04 draft was erroneous -- % While going over this stuff I notice that the MIB as presently % written requires that a conformant implementation allow any % combination of values for etherWisDeviceTxTestPatternMode and % etherWisDeviceRxTestPatternMode, but in fact hardware that is % based on the 802.3ae Clause 45 MDIO registers won't allow all % combinations to be set. -- since the 802.3ae Clause 45 MDIO registers _do_ in fact allow all combinations to be set. I would therefore like to remove the compliance statement language that I added to the -05 draft stating that an implementation doesn't have to allow different test modes in the transmit and receive path. Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sat Mar 8 18:26:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05020 for ; Sat, 8 Mar 2003 18:26:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28Nd4O15252; Sat, 8 Mar 2003 18:39:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h28NSpO14114 for ; Sat, 8 Mar 2003 18:28:51 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03263 for ; Sat, 8 Mar 2003 18:16:08 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.9.3/8.9.3) with ESMTP id PAA15996; Sat, 8 Mar 2003 15:18:12 -0800 (envelope-from heard@pobox.com) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 8 Mar 2003 15:18:09 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hubmib Mailing List Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , On Sun, 15 Dec 2002, C. M. Heard wrote: > > On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote: > > > - Sections 3.1, 3.2 and 3.3 talk about requirements to > > > implement pieces of other MIB modules. I see some of > > > it (from sonet mib) back in the MODULE-COMPLIANCE. > > > Should we not just include all of the required objects > > > from other MIB modules in the MODULE-COMPLIANCE? > > > > This subject was discussed at some length on the WG mailing > > list. The resolution was that we prefer, wherever possible, > > simply to reference an existing compliance statement. That > > was possible for the EtherLike-MIB (we point to > > dot3Compliance2) and the MAU-MIB (we point to mauModIfCompl3). > > It was not possible for the SONET-MIB, however, because we > > needed to make some objects [that are optional in] > > sonetCompliance2 mandatory for WIS applications. > > No change: since there was no feedback, I have assumed that the > rationale provided for keeping the existing compliance scheme > was OK. The consensus that was documented in the recently revised MIB review guidelines document -- which postdates the -06 version of the ETHER-WIS MIB -- is that modules incorporated by reference SHOULD be mentioned in the DESCRIPTION clause of a MODULE-COMPLIANCE statement as well as in the surrounding documentation, as John Flick has done in the recently-submitted EtherLike-MIB and the MAU-MIB drafts. If the AD, chair, and WG have no objections, I shall (after the IETF-56 I-D blackout ends) update the ETHER-WIS compliance statement to bring it into conformance with this guideline. It will need to mention the IF-MIB's ifCompliance3 statement, the IF-INVERTED-STACK-MIB's ifInvCompliance statement, the EtherLike-MIB's dot3Compliance2 statement, and the MAU-MIB's mauModIfCompl3 statement. In addition, after further review, I find that the following comment I made against the -04 draft was erroneous -- % While going over this stuff I notice that the MIB as presently % written requires that a conformant implementation allow any % combination of values for etherWisDeviceTxTestPatternMode and % etherWisDeviceRxTestPatternMode, but in fact hardware that is % based on the 802.3ae Clause 45 MDIO registers won't allow all % combinations to be set. -- since the 802.3ae Clause 45 MDIO registers _do_ in fact allow all combinations to be set. I would therefore like to remove the compliance statement language that I added to the -05 draft stating that an implementation doesn't have to allow different test modes in the transmit and receive path. Regards, Mike Heard _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Sun Mar 9 18:56:52 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05728 for ; Sun, 9 Mar 2003 18:56:51 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2A09Z816225 for hubmib-archive@odin.ietf.org; Sun, 9 Mar 2003 19:09:35 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A09YO16220; Sun, 9 Mar 2003 19:09:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A08HO16173 for ; Sun, 9 Mar 2003 19:08:17 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05349 for ; Sun, 9 Mar 2003 18:55:02 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h29NsNV05593 for ; Sun, 9 Mar 2003 18:54:23 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h29NsMC05589 for ; Sun, 9 Mar 2003 18:54:22 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Mar 2003 01:57:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt Thread-Index: AcLly+t2Sz03JOTzRQq8w6M+WeMkPgAyrNnA From: "Romascanu, Dan (Dan)" To: "C. M. Heard" , "Hubmib Mailing List" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2A08HO16174 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: 8bit I am OK with the changes proposed by Mike. Dan > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Sunday, March 09, 2003 1:18 AM > To: Hubmib Mailing List > Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt > > > On Sun, 15 Dec 2002, C. M. Heard wrote: > > > On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote: > > > > - Sections 3.1, 3.2 and 3.3 talk about requirements to > > > > implement pieces of other MIB modules. I see some of > > > > it (from sonet mib) back in the MODULE-COMPLIANCE. > > > > Should we not just include all of the required objects > > > > from other MIB modules in the MODULE-COMPLIANCE? > > > > > > This subject was discussed at some length on the WG mailing > > > list. The resolution was that we prefer, wherever possible, > > > simply to reference an existing compliance statement. That > > > was possible for the EtherLike-MIB (we point to > > > dot3Compliance2) and the MAU-MIB (we point to mauModIfCompl3). > > > It was not possible for the SONET-MIB, however, because we > > > needed to make some objects [that are optional in] > > > sonetCompliance2 mandatory for WIS applications. > > > > No change: since there was no feedback, I have assumed that the > > rationale provided for keeping the existing compliance scheme > > was OK. > > The consensus that was documented in the recently revised MIB review > guidelines document -- which postdates the -06 version of the > ETHER-WIS MIB -- is that modules incorporated by reference SHOULD be > mentioned in the DESCRIPTION clause of a MODULE-COMPLIANCE statement > as well as in the surrounding documentation, as John Flick has done > in the recently-submitted EtherLike-MIB and the MAU-MIB drafts. > > If the AD, chair, and WG have no objections, I shall (after the > IETF-56 I-D blackout ends) update the ETHER-WIS compliance statement > to bring it into conformance with this guideline. It will need to > mention the IF-MIB's ifCompliance3 statement, the > IF-INVERTED-STACK-MIB's ifInvCompliance statement, the > EtherLike-MIB's dot3Compliance2 statement, and the MAU-MIB's > mauModIfCompl3 statement. > > In addition, after further review, I find that the following comment > I made against the -04 draft was erroneous -- > > % While going over this stuff I notice that the MIB as presently > % written requires that a conformant implementation allow any > % combination of values for etherWisDeviceTxTestPatternMode and > % etherWisDeviceRxTestPatternMode, but in fact hardware that is > % based on the 802.3ae Clause 45 MDIO registers won't allow all > % combinations to be set. > > -- since the 802.3ae Clause 45 MDIO registers _do_ in fact allow all > combinations to be set. I would therefore like to remove the > compliance statement language that I added to the -05 draft stating > that an implementation doesn't have to allow different test modes in > the transmit and receive path. > > Regards, > > Mike Heard > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sun Mar 9 18:56:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05757 for ; Sun, 9 Mar 2003 18:56:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A09YO16220; Sun, 9 Mar 2003 19:09:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2A08HO16173 for ; Sun, 9 Mar 2003 19:08:17 -0500 Received: from iere.net.avaya.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05349 for ; Sun, 9 Mar 2003 18:55:02 -0500 (EST) Received: from iere.net.avaya.com (localhost [127.0.0.1]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h29NsNV05593 for ; Sun, 9 Mar 2003 18:54:23 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by iere.net.avaya.com (8.11.2/8.9.3) with ESMTP id h29NsMC05589 for ; Sun, 9 Mar 2003 18:54:22 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 10 Mar 2003 01:57:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Message-ID: Thread-Topic: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt Thread-Index: AcLly+t2Sz03JOTzRQq8w6M+WeMkPgAyrNnA From: "Romascanu, Dan (Dan)" To: "C. M. Heard" , "Hubmib Mailing List" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h2A08HO16174 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: 8bit I am OK with the changes proposed by Mike. Dan > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Sunday, March 09, 2003 1:18 AM > To: Hubmib Mailing List > Subject: Re: [Hubmib] AD review of draft-ietf-hubmib-wis-mib-04.txt > > > On Sun, 15 Dec 2002, C. M. Heard wrote: > > > On Sun, 17 Nov 2002, Wijnen, Bert (Bert) wrote: > > > > - Sections 3.1, 3.2 and 3.3 talk about requirements to > > > > implement pieces of other MIB modules. I see some of > > > > it (from sonet mib) back in the MODULE-COMPLIANCE. > > > > Should we not just include all of the required objects > > > > from other MIB modules in the MODULE-COMPLIANCE? > > > > > > This subject was discussed at some length on the WG mailing > > > list. The resolution was that we prefer, wherever possible, > > > simply to reference an existing compliance statement. That > > > was possible for the EtherLike-MIB (we point to > > > dot3Compliance2) and the MAU-MIB (we point to mauModIfCompl3). > > > It was not possible for the SONET-MIB, however, because we > > > needed to make some objects [that are optional in] > > > sonetCompliance2 mandatory for WIS applications. > > > > No change: since there was no feedback, I have assumed that the > > rationale provided for keeping the existing compliance scheme > > was OK. > > The consensus that was documented in the recently revised MIB review > guidelines document -- which postdates the -06 version of the > ETHER-WIS MIB -- is that modules incorporated by reference SHOULD be > mentioned in the DESCRIPTION clause of a MODULE-COMPLIANCE statement > as well as in the surrounding documentation, as John Flick has done > in the recently-submitted EtherLike-MIB and the MAU-MIB drafts. > > If the AD, chair, and WG have no objections, I shall (after the > IETF-56 I-D blackout ends) update the ETHER-WIS compliance statement > to bring it into conformance with this guideline. It will need to > mention the IF-MIB's ifCompliance3 statement, the > IF-INVERTED-STACK-MIB's ifInvCompliance statement, the > EtherLike-MIB's dot3Compliance2 statement, and the MAU-MIB's > mauModIfCompl3 statement. > > In addition, after further review, I find that the following comment > I made against the -04 draft was erroneous -- > > % While going over this stuff I notice that the MIB as presently > % written requires that a conformant implementation allow any > % combination of values for etherWisDeviceTxTestPatternMode and > % etherWisDeviceRxTestPatternMode, but in fact hardware that is > % based on the 802.3ae Clause 45 MDIO registers won't allow all > % combinations to be set. > > -- since the 802.3ae Clause 45 MDIO registers _do_ in fact allow all > combinations to be set. I would therefore like to remove the > compliance statement language that I added to the -05 draft stating > that an implementation doesn't have to allow different test modes in > the transmit and receive path. > > Regards, > > Mike Heard > > _______________________________________________ > Hubmib mailing list > Hubmib@ietf.org > https://www1.ietf.org/mailman/listinfo/hubmib > _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Sat Mar 22 11:07:31 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28853 for ; Sat, 22 Mar 2003 11:07:31 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2MGQOE18677 for hubmib-archive@odin.ietf.org; Sat, 22 Mar 2003 11:26:24 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MGQNO18672; Sat, 22 Mar 2003 11:26:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MGPHO18649 for ; Sat, 22 Mar 2003 11:25:17 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28836 for ; Sat, 22 Mar 2003 11:05:53 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h2MG89u21978; Sat, 22 Mar 2003 08:08:09 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 22 Mar 2003 08:08:06 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Mailing List cc: AToM MIB Mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hubmib] New WIS MIB draft now available 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: , Hub MIB and AToM MIB WG members, The latest WIS MIB draft, which was submitted on 17 March 2003, is now available at http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-07.txt The I-D actually made its appearance in the repository before the official announcement, which can be expected to arrive shortly. Here is what has changed since the previous version: 1.) The prerequisite external compliance statements (IF-MIB.ifCompliance3, IF-INVERTED-STACK-MIB.ifInvCompliance, EtherLike-MIB.dot3Compliance2, and MAU-MIB.mauModIfCompl3) are now listed explicitly in the etherWisCompliance DESCRIPTION clause. 2.) The OBJECT clauses for etherWisDeviceTxTestPatternMode and etherWisDeviceRxTestPatternMode no longer state that an implementation is not required to support certain combinations of settings because the Clause 45 MDIO registers do not, in fact, impose any inter-dependencies in the settings. 3.) The dates in the LAST-UPDATED and REVISION clauses of the MODULE-IDENTITY invocation were changed to the current date. 4.) References [ETHERIF] and [MAU-MIB] were updated to point to and , respectively. Note that change #1 brings the document into compliance with the recently issued MIB review guidelines document (which postdates the -06 version of the ETHER-WIS MIB) and that change #2 undoes an erroneous modification that was introduced into the -05 version. As I've noted before the following three normative references need to be progressed to Proposed Standard or higher prior to or simultaneously with the WIS MIB document in order for it to be published as an RFC: [SONETng] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", , work in progress. [ETHERIF] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", , work in progress. [MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", , work in progress. The IETF last call on [SONETng] recently expired and it is now in the "waiting for writeup" state. [ETHERIF] and [MAU-MIB] were recently updated to address A-D review comments, and I believe this means that the document package consisting of [ETHERIF], [MAU-MIB], this submission, and draft-ietf-hubmib-1643-to-historic-01.txt is ready for the next step. Thanks and regards, Mike -- C. M. Heard heard@pobox.com _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From hubmib-admin@ietf.org Sat Mar 22 11:07:47 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28879 for ; Sat, 22 Mar 2003 11:07:47 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MGQNO18672; Sat, 22 Mar 2003 11:26:23 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2MGPHO18649 for ; Sat, 22 Mar 2003 11:25:17 -0500 Received: from shell4.bayarea.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28836 for ; Sat, 22 Mar 2003 11:05:53 -0500 (EST) Received: from localhost (heard@localhost) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id h2MG89u21978; Sat, 22 Mar 2003 08:08:09 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 22 Mar 2003 08:08:06 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: Hub MIB Mailing List cc: AToM MIB Mailing list Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Hubmib] New WIS MIB draft now available 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: , Hub MIB and AToM MIB WG members, The latest WIS MIB draft, which was submitted on 17 March 2003, is now available at http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-07.txt The I-D actually made its appearance in the repository before the official announcement, which can be expected to arrive shortly. Here is what has changed since the previous version: 1.) The prerequisite external compliance statements (IF-MIB.ifCompliance3, IF-INVERTED-STACK-MIB.ifInvCompliance, EtherLike-MIB.dot3Compliance2, and MAU-MIB.mauModIfCompl3) are now listed explicitly in the etherWisCompliance DESCRIPTION clause. 2.) The OBJECT clauses for etherWisDeviceTxTestPatternMode and etherWisDeviceRxTestPatternMode no longer state that an implementation is not required to support certain combinations of settings because the Clause 45 MDIO registers do not, in fact, impose any inter-dependencies in the settings. 3.) The dates in the LAST-UPDATED and REVISION clauses of the MODULE-IDENTITY invocation were changed to the current date. 4.) References [ETHERIF] and [MAU-MIB] were updated to point to and , respectively. Note that change #1 brings the document into compliance with the recently issued MIB review guidelines document (which postdates the -06 version of the ETHER-WIS MIB) and that change #2 undoes an erroneous modification that was introduced into the -05 version. As I've noted before the following three normative references need to be progressed to Proposed Standard or higher prior to or simultaneously with the WIS MIB document in order for it to be published as an RFC: [SONETng] Tesink, K., "Definitions of Managed Objects for the SONET/SDH Interface Type", , work in progress. [ETHERIF] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", , work in progress. [MAU-MIB] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", , work in progress. The IETF last call on [SONETng] recently expired and it is now in the "waiting for writeup" state. [ETHERIF] and [MAU-MIB] were recently updated to address A-D review comments, and I believe this means that the document package consisting of [ETHERIF], [MAU-MIB], this submission, and draft-ietf-hubmib-1643-to-historic-01.txt is ready for the next step. Thanks and regards, Mike -- C. M. Heard heard@pobox.com _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib From mailnull@www1.ietf.org Mon Mar 24 07:31:32 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12452 for ; Mon, 24 Mar 2003 07:31:32 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h2OCpJf29657 for hubmib-archive@odin.ietf.org; Mon, 24 Mar 2003 07:51:19 -0500 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCpIO29651; Mon, 24 Mar 2003 07:51:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCl1O29402 for ; Mon, 24 Mar 2003 07:47:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11634; Mon, 24 Mar 2003 07:23:19 -0500 (EST) Message-Id: <200303241223.HAA11634@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: hubmib@ietf.org, atommib@research.telcordia.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Mar 2003 07:23:19 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-wis-mib-07.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 : Definition of Managed Objects for the Ethernet WAN Interface Sublayer Author(s) : C. Heard Filename : draft-ietf-hubmib-wis-mib-07.txt Pages : 43 Date : 2003-3-21 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the SONET/SDH Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-07.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-wis-mib-07.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-wis-mib-07.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: <2003-3-21154701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-wis-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-wis-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21154701.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 Mar 24 07:32:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12478 for ; Mon, 24 Mar 2003 07:32:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCpIO29651; Mon, 24 Mar 2003 07:51:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2OCl1O29402 for ; Mon, 24 Mar 2003 07:47:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11634; Mon, 24 Mar 2003 07:23:19 -0500 (EST) Message-Id: <200303241223.HAA11634@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: hubmib@ietf.org, atommib@research.telcordia.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 24 Mar 2003 07:23:19 -0500 Subject: [Hubmib] I-D ACTION:draft-ietf-hubmib-wis-mib-07.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 : Definition of Managed Objects for the Ethernet WAN Interface Sublayer Author(s) : C. Heard Filename : draft-ietf-hubmib-wis-mib-07.txt Pages : 43 Date : 2003-3-21 This document defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular, it defines objects for managing the Ethernet Wide Area Network (WAN) Interface Sublayer (WIS). The MIB module defined in this memo is an extension of the SONET/SDH Interface MIB and is implemented in conjunction with it and with the Ethernet-like Interface MIB, the 802.3 Medium Attachment Unit MIB, the Interfaces Group MIB, and the Inverted Stack Table MIB. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hubmib-wis-mib-07.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-wis-mib-07.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-wis-mib-07.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: <2003-3-21154701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-hubmib-wis-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-hubmib-wis-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21154701.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib