[Hubmib] Pls put on IESG agenda: - draft-ietf-hubmib-efm-epon-mib-06.txt ( PS)
"Wijnen, Bert (Bert)" <bwijnen@lucent.com> Tue, 21 November 2006 16:26 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYRy-0004Ta-0O; Tue, 21 Nov 2006 11:26:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYRx-0004TS-1r for hubmib@ietf.org; Tue, 21 Nov 2006 11:26:21 -0500
Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYRv-0006qq-C5 for hubmib@ietf.org; Tue, 21 Nov 2006 11:26:21 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id kALGQEnp003184; Tue, 21 Nov 2006 10:26:15 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <R9BL8GJA>; Tue, 21 Nov 2006 17:26:13 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550AF7F50A@nl0006exch001u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Dan Romascanu (E-mail)" <dromasca@avaya.com>
Date: Tue, 21 Nov 2006 17:26:10 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f2984bf50fb52a9e56055f779793d783
Cc: "Hubmib Mailing List (E-mail)" <hubmib@ietf.org>
Subject: [Hubmib] Pls put on IESG agenda: - draft-ietf-hubmib-efm-epon-mib-06.txt ( PS)
X-BeenThere: hubmib@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ethernet Interfaces an Hub MIB WG <hubmib.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:hubmib@ietf.org>
List-Help: <mailto:hubmib-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hubmib>, <mailto:hubmib-request@ietf.org?subject=subscribe>
Errors-To: hubmib-bounces@ietf.org
Dan (and HUBMIB WG members). This document is now ready to go onto the IESG agenda for consideration as a Proposed Standard RFC. Thanks to Lior for the latest revision(s) which have addressed all the IETF Last Call comments and other comments that came in as well. Bert ------- PROTO SHEPEHRD writeup: (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? yes (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Document did have WG review (Dan Romascanu, CM Heard, Matt Squire, Edward Beili and Bert Wijnen), MIB doctor review (David Perkins), IETF Last Call review. These resulted in a few new revisions. IEEE 802.3 WG (specificall 802.3ah) has also reviewed and commented during the development of this document. Document is in good shape now and has had enough review. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There was/is some concern about quality of English. However, a call for volunteers to do a check on that has not resulted in a reviewer for that specific aspect. The author did do another pass, and it improved to a level that AD and WG chair find good enough. We assume the RFC-Editor will correct any remaining serious issues. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG is does not have too many active participants, but there is consensus and support from the active participants. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) no (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Nov 21st, 2006: idnits 1.118 tmp/draft-ietf-hubmib-efm-epon-mib-06.txt: Checking nits according to http://www.ietf.org/ID-Checklist.html: Checking conformance with RFC 3978/3979 boilerplate... the boilerplate looks good. No nits found. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: Nothing found here (but these checks do not cover all of 1id-guidelines.txt yet). Miscellaneous warnings: None. Experimental warnings: None. No nits found. MIB doctor review was done by David Perkins. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. I see that [RFC2119] is listed under informative references. It should be moved to the normative references section. I also see that (now that rfc3636bis document has been approved by IESG), we might remove citation/refrence to rfc3636 itsels altogether and just cite/reference the new-rfc3636bis-to-be. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? yes (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? yes (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary 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 interfaces that conform to the Ethernet Passive Optical Networks (EPON) standard as defined in the IEEE Std 802.3ah-2004, which are extended capabilities to the Ethernet like interfaces. Working Group Summary The working Group has consensus to publish this document as a Proposed Standard RFC. Document Quality The document has been reviewed by various WG members (and chairs) of the HUBMIB WG. IEEE802.3ah did various reviews and comments throughout the development of this document. MIB Doctor review was done by David Perkins. IETF Last Call also resulted in some comments. All review comments have been addressed. We are not aware of any current implementations. Personnel Bert Wijnen (WG chair of hubmib) is the PROTO SHEPHERD. Dan ROmascanu is the Responsible Area Director. Possible notes to RFC-Editor Page 99, pls move reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. from the informative to the normative section. Possibly replace all citations/references to rfc3636 and replace them with the new rfc3636bis-to-be (which has been approved by IESG already, and which obsoletes RFC3636). Bert Wijnen HUBMIB WG chair _______________________________________________ Hubmib mailing list Hubmib@ietf.org https://www1.ietf.org/mailman/listinfo/hubmib
- [Hubmib] Pls put on IESG agenda: - draft-ietf-hub… Wijnen, Bert (Bert)