Please find below my Last Call comments to this document. I believe that the document is close to completion, but there still are a number of rather consistent edits that I would rather see dealt in a new version. As the document includes quite extensive discussions of IPR transfer issues, I suggest that we ensure that the text is read and agreed by the IETF and IEEE 802 IPR lawyers. Content: 1. I do not believe that this type of document should include key words usage as per RFC 2119. For example in section 2.1, paragraph 4 2. last paragraph in 2.1 - sounds like the IETF should forbid contributors to publish MIB modules documents as Internet-Drafts. I do not believe that this is the intent, or even possible, so I would suggest to change the text: s/and to not publish their proposed MIB modules/and to recommend them not to publish their proposed MIB modules/ 3. It looks to me like all section 2.4 relates to IEEE participation procedures, is not part of the transition process and is something where the IETF has no real saying. I suggest to eliminate this section 4. Section 3.1 should refer to section 7 for more information concerning the transfer of intellectual property rights of the current Bridge MIB WG documents. Also, in the third paragraph it should be made clear that the transfer is not only for 'maintenance responsibilities' but also for 'performing derivative work'. 5. I believe that the document could provide more specific recommendations about how IEEE 802 MIB review guidelines could be derived, and what of RFC 4181 can be used until such a document is being issued by the IEEE, which can take quite a long time. I suggest that the following text is introduced replacing the 6th paragraph in Section 6.1: The IETF uses [RFC4181] as a reference document for IETF documents containing MIB modules. It is recommended that in time IEEE 802.1 WG develop their own guidelines for IEEE MIB modules review. Until this happens Section 3 (General Documentation Guidelines) and Section 4 (SMIv2 Guidelines) in the current IETF document can be used with the following exceptions and modifications: - In the introductory paragraphs of Section 3, the list of sections that MUST be included in a MIB document should be adapted to the IEEE needs and style guide. . - Sections 3.1 to 3.4 apply as in the IETF document, with the mention that the IETF boilerplate could be edited to comply to the IEEE needs and style guide - Section 3.5 (IANA Considerations Section) does not apply, but may be replaced by a section with IEEE recommendations on naming and OID space assignments - Sections 3.6 does not apply - Section 3.7 (Copyright notices) does not apply and may be replace with text corresponding to the IEEE copyright rules. The exception is the case where a document was originally issues by the IETF, and then taken over by the IEEE, in which case, according to the legal advice notices concerning the IETF copyrights (as described in the current section 3.7) and IEEE copyrights MUST be included [editor note - to finalize after legal advice is received from IEEE and IETF lawyers] - Section 3.8 (Intellectual Property) does not apply and may be replaced with a notice reflecting the intellectual property rules of the IEEE - Sections 4.1 and 4.2 apply as in the IETF document - Section 4.3 (Naming Hierarchy) applies with changes related to the OID root of the IEEE 802.1 MIB modules - Sections 4.4 to 4.8 apply as in the IETF document - Section 4.9 applies, but some interesting problems may arise if IETF designed modules are being taken over and continued by the IEEE. In order to comply to the requirement the IEEE should continue to work and maintain the MIB module in the IETF OID space. Editorial: 1. Section 1.1, third paragraph: s/(like 802)/(like IEEE 802)/ 2. Section 2.1, first paragraph: s/equivalent of an IETF Working Group Charter/equivalent of the IETF Working Group Charters/ 3. Section 2.2, first paragraph: s/to develop MIB modules in the PDF format/to publish MIB modules only in the PDF format/ 4. Section 2.2, second paragraph: s/IETF personnel/IETF participants/ 5. Section 2.2. third paragraph: s/completion/approval/; s/completed/approved/ 6. The list in Section 3.2, third paragraph should be dashed 7. Section 3.3, paragraph 5, line 2: s/variable/variables/ 8. Section 3.3, paragraph 6: s/802 variables/IEEE 802.1 variables/ 9. I believe that Sections 2.3 (OID Registration for new MIB modules) and 3.4 (IANA OID Registration) can and should be merged. Some of the text in 3.4 seems more a justification and could be eliminated 10. In many places in the document, including the title the name Bridge WG is being used. Actually the official name of the WG was Bridge MIB WG, while the acronym was bridge (not with capital letter). I suggest a global s/Bridge WG/Bridge MIB WG/ 11. Section 6.1, first paragraph: s/IEEE 802 area/IEEE 802 project/ and s/802 developped MIB modules/IEEE 802 developped MIB modules/ 12. Section 6.1, second paragraph: s/802 developped MIB modules/IEEE 802 developped MIB modules/ and s/It is not formalized/This is not as formalized/ 13. Section 10, last paragraph s/Jorge/The IETF lawyer/ > -----Original Message----- > From: The IESG [mailto:iesg-secretary@xxxxxxxx] > Sent: Friday, March 03, 2006 11:16 PM > To: IETF-Announce > Subject: Last Call: 'Transferring MIB Work from IETF Bridge > WG to IEEE 802.1 WG' to Informational RFC > > The IESG has received a request from an individual submitter > to consider the following document: > > - 'Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG ' > <draft-harrington-8021-mib-transition-01.txt> as an > Informational RFC > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send any > comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists > by 2006-03-17. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-harrington-8021-mib- > transition-01.txt > > This document describes the plan to transition responsibility for > bridging-related MIB modules from the IETF Bridge WG to the IEEE > 802.1 WG, which develops the bridging technology the MIB > modules are > designed to manage. > > This is not a WG document, but has been discussed quite > extensively already. The document is intended as > Informational RFC. Therefor a > 2 week IETF Last Call is being used for IETF community-wide review. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf