Bridge WG D. Harrington, Ed. Internet-Draft Effective Software Consulting Expires: September 1, 2006 February 28, 2006 Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG draft-harrington-8021-mib-transition-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract 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. Harrington Expires September 1, 2006 [Page 1] Internet-Draft 8021 MIB Transition February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. New IEEE MIB Work . . . . . . . . . . . . . . . . . . . . . . 4 2.1. New MIB PARs . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. IEEE MIB Modules in ASCII format . . . . . . . . . . . . . 4 2.3. OID Registration for New MIB Modules . . . . . . . . . . . 5 2.4. Editing New IEEE MIB Modules . . . . . . . . . . . . . . . 6 3. Current Bridge WG Documents . . . . . . . . . . . . . . . . . 6 3.1. Transferring Current Bridge WG Documents . . . . . . . . . 6 3.2. Updating IETF MIB Modules . . . . . . . . . . . . . . . . 7 3.3. Clarifications . . . . . . . . . . . . . . . . . . . . . . 8 3.4. IANA OID Registration . . . . . . . . . . . . . . . . . . 9 4. Mailing List Discussions . . . . . . . . . . . . . . . . . . . 10 5. Bridge WG Mailing List Announcements . . . . . . . . . . . . . 10 6. IETF MIB Doctor Reviews . . . . . . . . . . . . . . . . . . . 10 6.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Review Guidelines . . . . . . . . . . . . . . . . . . . . 11 6.3. Review Format . . . . . . . . . . . . . . . . . . . . . . 13 6.4. Review Weight . . . . . . . . . . . . . . . . . . . . . . 14 7. Communicating the Transition Plan . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Intellectual Property Considerations . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Sample text for IEEE to request rights from authors . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Harrington Expires September 1, 2006 [Page 2] Internet-Draft 8021 MIB Transition February 2006 1. Introduction 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. The current Bridge WG documents are o "Definitions of Managed Objects for Bridges" [RFC4188], o "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol" [RFC4318] o "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions" [RFC4363], and o Definitions of Managed Objects for Source Routing Bridges [RFC1525] This document is meant to establish some clear expectations between IETF and IEEE about the transition of Bridge WG MIB modules to the IEEE 802.1 WG, so that the plan can be reviewed by the IESG, IAB, IETF, and IEEE. There might be some case-by-case situations that arise, but this document describes the general strategy. 1.1. Motivation Having SNMP MIB modules to provide management functionality for its technologies is important for the 802.1 community, so it needs to charter this work as part of the Project Authorization Requests (PARs) for each new project, to ensure that resources are being mobilized for execution. This is also true with respect to MIB support for already completed 802.1 projects - maintenance projects need to include the development of SNMP MIB modules. The IESG has mandated that IETF WGs that produce a protocol are also required to develop the corresponding MIB module rather than leaving that to "the SNMP experts" to do later. Part of the motivation was obviously to make the protocols more manageable, but part of the motivation was also balancing the workload better and getting the content experts more involved in the management design. While the IESG does not mandate that other standards development organizations (SDOs) do so, if such work comes into the IETF, then we want the other SDO to bring in subject matter expertise to work with us, or, even better, to take the lead themselves. The manpower problem is certainly an aspect that is relevant. IEEE 802 MIB documents could be developed in the IETF, but only if the subject matter experts come to IETF to actually participate (lead) the work. The content experts need to be more involved in the MIB module development, and resources need to be dedicated to completing the work, whether editing is done in the IEEE or the IETF. The IETF is OK with other organizations (like 802) doing MIB documents Harrington Expires September 1, 2006 [Page 3] Internet-Draft 8021 MIB Transition February 2006 themselves, and the IETF offers to help review them from an SNMP/MIB/ SMI perspective. This is true even after the transition, since quality MIB modules are important to smooth management of the Internet and the technologies it runs on. 2. New IEEE MIB Work 2.1. New MIB PARs The IEEE-SA Standards Board New Standards Committee (NesCom) deals with the Projects Approval Requests - see http://standards.ieee.org/board/nes/. PARs are roughly the equivalent of an IETF Working Group Charter, and include information concerning the scope, purpose, and justification for standardization projects. Following early discussions concerning the transfer of MIB work from the IETF Bridge MIB WG to the IEEE 802.1 WG, the development of SMIv2 MIB modules associated with IEEE 802.1 projects has been included within the scope of the work of new projects. For example the PAR form of the IEEE 802.1ah - Provider Backbone Bridges [PAR-IEEE802.1ah] includes in Section 13 - "Scope of Proposed Project" an explicit reference to 'support management including SNMP'. Although it is not mandatory for the MIB development work to be specified explicitly in a new PAR to have the work done - see work done in IEEE 802.1AB [IEEE802.1AB]and IEEE 802.1AE [IEEE802.1AE]- it is RECOMMENDED that IEEE 802.1 WG PARs include explicit wording in the scope section wherever there is need for MIB development as part of the standard. Since the IETF Bridge MIB WG does not intend to develop MIB modules in the future, it is recommended to direct submitters of new work in the bridge management space to the IEEE 802.1 WG, and to not publish their proposed MIB modules as Internet-Drafts. 2.2. IEEE MIB Modules in ASCII format Having MIB modules be made freely and openly available in an ASCII format will be a critical factor in having the SNMP community accept the transfer of 802.1 MIB development from IETF Bridge WG to IEEE 802.1 WG. While 802.1 can certainly decide they're going to develop MIB modules in the PDF format that they use for their documents without publishing an ASCII version, most network management systems can import a MIB module that is in ASCII format but not one in PDF Harrington Expires September 1, 2006 [Page 4] Internet-Draft 8021 MIB Transition February 2006 format. Not publishing an ASCII version of the MIB module would negatively impact implementers and deployers of MIB modules, and would make IETF review of MIB modules more difficult. The 802.1 WG web site requires a password for access to standards in development. The WG has started making the MIB module portion of their documents available as separate ASCII files during project development, and allowing IETF personnel to access these documents for review purposes. IEEE 802 has a policy that approved specifications are available for a fee for the first six months after completion, and freely available six months after they are completed. Once the specification is completed, the ASCII version of the MIB module is made freely available on the 802.1 WG website (http://www.ieee802.org/1/pages/MIBS.html). There may be some issues about what gets included in the freely available specification. The SMIv2 MIB module alone will probably be insufficient; some discussion of the structure of the MIB, the anticipated use cases for MIB objects, the relationship to other MIB modules, and security considerations will also need to be made available to ensure appropriate implementation and deployment of the MIB module within the Internet environment. For most implementers, the freely available specification six months after completion will be adequate. The 2001 version of the SMIv2 MIB module for 802.1X (the IEEE8021- PAE-MIB) has been published in ASCII on http://www.ieee802.org/1/pages/MIBS.html. This document should be updated with enough surrounding documentation to be clear, and to address deployment issues such as security considerations. The 802.1 WG submitted the IEEE8021-PAE-MIB document to be published as an informational RFC. In the future, it would be better to point interested parties to the appropriate 802.1 WG public website to prevent confusion over who is maintaining the document. 2.3. OID Registration for New MIB Modules As the 802.1 WG updates the 802.1 standards, new MIB modules will need to be developed and registered, and they will be registered under the 802.1 registration branch, as was done with the 802.1X MIB module. IEEE has an established set of arcs in 802 for registration of OIDs and it makes sense for the IEEE to administer the registration of MIB module assignments for MIB modules they maintain, rather than asking Harrington Expires September 1, 2006 [Page 5] Internet-Draft 8021 MIB Transition February 2006 IANA to provide such registrations. The administration of the 802 arc is documented in IEEE 802b. 2.4. Editing New IEEE MIB Modules MIB module editors will need to be regular attendees and become members over time, as is the norm for 802.1 membership. Showing up at the meetings is the important factor because official IEEE work is done in the meetings, rather than on mailing lists as in the IETF. For exceptional conditions, the Chair has the power to bestow membership ahead of the usual attendance requirement. During the transition, to accommodate IETF candidates for editor, work can take place over email and outside of the meetings initially 3. Current Bridge WG Documents 3.1. Transferring Current Bridge WG Documents While reviewing the legal issues associated with transferring Brtidge WG documents to the IEEE 802.1 WG, it was concluded that the IETF does not have sufficient legal authority to make the transfer without the consent of the document authors. RFC1286, RFC1493 and RFC 1525 apparently precede any specific IETF document describing the copyright and intellectual property rights that authors grant to the IETF. RFC2674 falls under RFC 2026 [RFC2026] rules. The three recent updates, [RFC4188], [RFC4318], and [RFC4363] fall under BCP 78, as documented in RFC3978 [RFC3978]. To permit the maintenance responsibilities for documents containing the BRIDGE-MIB [RFC4188] and the P-BRIDGE-MIB and Q-BRIDGE-MIB [RFC4363] and RSTP-MIB [RFC4318] to become the responsibility of the IEEE 802.1 WG, the IEEE 802.1 WG will need to get permission from the authors, and/or the companies to whom the authors have assigned their intellectual property rights in these documents, so they can publish derivative works. The IETF lawyer and the IEEE IPR lawyer have agreed upon a sample letter for use by the IEEE 802.1 WG to request the necessary permissions from the authors, which is shown in Appendix B. The Bridge WG chairs reviewed the author lists for the documents and provided the list of authors and their last known addresses and the documents with which they were associated to the IEEE lawyer. The IETF will retain all its rights in the published RFCs. Harrington Expires September 1, 2006 [Page 6] Internet-Draft 8021 MIB Transition February 2006 3.2. Updating IETF MIB Modules The updates to the Bridge WG documents addresssed changes documented in 802.1t, 802.1u, 802.1v, and 802.1w. These amendments were merged with 802.1D-1998 by the IEEE 802.1 WG to form 802.1D-2004. The Bridge WG did not address changes that resulted from that merger of documents. The 802.1 WG will need to work through the management objects in the existing documents to determine whether they are consistent with new emerging specifications, including 802.1D-2004. During the final work on these documents in the Bridge WG, there were some issues that we decided not to resolve and to allow them to be dealt with as part of the future work in the 802.1 WG. Work on the following items was deferred to the IEEE: the 'autoEdgePort' parameter (802.1D-2004 clause 17.3.3) the BridgeID object references to 802.1D-1998 were not updated to 802.1D-2004 some objects in RFC4363 may have been obsoleted in 802.1D-2004 Description of dot1dPortOutboundAccessPriority seems wrong, but it followed the description in 802.1D-1998. An issue was raised concerning dot1dTpPortInFrames and dot1dTpPortOutFrames. This is an issue left over from RFC 1493. It was thought that the IEEE might be able to write separate documents containing updates to their technologies, such as 802.1Q, and include a separate MIB module to augment the IETF MIB modules. However, recent changes to the IEEE standards are expected to require changing the way the MIB tables are INDEXED, which is not allowed under SMI rules, so the IEEE will need to rewrite the MIB modules, and assign object identifiers under the ieee802 branch. The IETF MIB Doctors will work with the IEEE 802.1 WG, as requested and as available, to make the transition, attempting to maintain backwards compatibility where possible. For backwards compatibility, the existing IETF documents will still be valid and remain unchanged. If an 802.1 WG document must update or obsolete the IETF version of a Bridge MIB document, the 802.1 WG can create and submit an internet- draft to the IESG to be published as an RFC that points to the openly available IEEE copy and the IEEE standard. The IESG would need to approve the publication of the RFC. The RFC status would be reflected in the RFC-INDEX and also in the database so it will be reflected on the RFC-Editor web page, so we don't have a problem with synchronization between the copies being published. Harrington Expires September 1, 2006 [Page 7] Internet-Draft 8021 MIB Transition February 2006 3.3. Clarifications As the 802.1 WG handles the MIB development, the IEEE-standard "managed variables" and the associated IEEE MIB module objects will probably correspond, as many existing BRIDGE-MIB objects already correspond to 802.1 management variables, such as these from 802.1Q. Virtual Bridge MIB object IEEE 802.1Q-2003 Reference dot1qBase dot1qVlanVersionNumber 12.10.1.1 read bridge vlan config dot1qMaxVlanId 12.10.1.1 read bridge vlan config dot1qMaxSupportedVlans 12.10.1.1 read bridge vlan config dot1qNumVlans dot1qGvrpStatus 12.9.2.1/2 read/set garp applicant controls IEEE allows definitions to be clarified in a manner that can actually alter the semantics of a managed variable somewhat, such as by changing the range. SMI rules generally prevent changing the semantics of defined MIB objects without obsoleting the current object and replacing it with an object with a new descriptor and OID registration. It is expected that, once both an IEEE MIB definition and the "managed variable" descriptions are in the same document, this problem will go away, as IEEE can update both at the same time in the approved manner. The need to fix a description in an IETF Bridge MIB module in a manner that would not be SMI legal would precipitate the need to define an IEEE MIB module, which might copy and replace the whole IETF MIB module, or just add the necessary objects. Copying the IETF MIB module and changing the descriptors and reassigning new IEEE OIDs would not be backwards compatible, and existing applications would need to be updated to access the new objects, so it is recommended that the IETF MIB module not be copied and modified unless really necessary. The current practice in the 802.1 WG is to define the management variable and then a mapping table to associated MIB module objects (as shown above). The 802.1 WG could redefine the mapping from an IEEE managed variable to a new IEEE MIB object if the 802.1 management variable semantics changed, thus allowing the 802.1 WG to 'do it right' by SMI rules, supplementing the old MIB object with a new one. An updated mapping would be reflected in the compliance clause of the supplemental SMIv2 MIB module; it may be desirable to document the old mapping information in the description clause of the new object in the SMIv2 MIB module. Harrington Expires September 1, 2006 [Page 8] Internet-Draft 8021 MIB Transition February 2006 Often the mapping of 802 variables to MIB objects isn't and doesn't have to be a 1:1 mapping. In the future 802 variables may be invented with Web-based services in mind, but today the primarily focus is on SNMP usage, and incorporating MIB modules into the specs themselves will likely further that focus. The level of redirection that exists today between 802 variables and MIB objects might be useful for the transition process when changing 802 management variable semantics and supplementing MIB objects. The existing Bridge documents represent the current state of bridging management, and the documents contain compliance clauses describing the current requirements to be compliant to the IETF standards. As the IEEE develops additional MIB modules, new compliance clauses will define the new "state of the art", without needing to obsolete the old MIB objects or the old compliance clauses. Therefore, the plan is that the current Bridge MIB modules will be "frozen in time", and updated only via the development of independent MIB modules by the 802.1 WG. 3.4. IANA OID Registration The IETF and IEEE 802.1 have separate registration branches in the OID tree. The Bridge MIB modules are registered under the IETF branch, and some assignments are maintained by IANA. As 802.1 standards are modified, the changes may include needed modifications to supplement the existing tables. This can be handled by developing an IEEE MIB module that augments the existing tables, or reuses the indexing of the existing tables. The new modules can be assigned under the IEEE arc. When the changes only require the additional of one or two objects to the existing MIB modules, it may seem simpler for the 802.1 WG to define additional managed objects within the IANA-controlled registration tree. This approach is not recommended because of the difficulties of coordinating the changes between the two organizations, and working the changes through the processes while trying to remain timely for each organization. Such additions would probably require approval by the Area Directors of Operations and Management after IETF MIB Doctor review. This would create dependencies between the work of the two organizations, and it might generate special cases for IANA to prevent the IEEE being bogged down by IETF processes.. The approach of developing an IEEE MIB module and defining a new compliance clause is simpler than dealing with such dependencies. We need a balance between disruption to existing implementations and Harrington Expires September 1, 2006 [Page 9] Internet-Draft 8021 MIB Transition February 2006 efficiency in making changes. Keeping the existing trees in their place minimizes disruption to existing implementations. 4. Mailing List Discussions The Bridge WG has completed its documents, and the WG has been closed, The mailing list will remain open for a while. The Bridge WG chairs will discourage discussion of ongoing IEEE MIB module work on the Bridge WG list and ask that the discussion be moved to the IEEE list, with a notice comparable to: Note that this work is out of scope for the Bridge WG mailing list. The appropriate mailing list for IEEE 802.1 MIB module discussion is STDS-802-1-L@listserv.ieee.org. To subscribe to the STDS-802-1-L list, go to http://www.ieee802.org/1/email-pages/ To see the general information about 802,1, including how they work and how to participate, go to http://www.ieee802.org/1/ To see presentations on the technology, go to http://www.ieee802.org/1/files/public/ and look in the docs2004, docs2005, and docs2006 directories. 5. Bridge WG Mailing List Announcements If requested by the 802.1 WG chair or vice-chair, the Bridge WG chairs will post an announcement that the 802.1 WG is planning to start work on developing or updating bridge-related MIB modules and is seeking volunteers. The Bridge WG chairs watch the 802.1 list, and if something significant to the Bridge WG comes up, such as the 802.1 chairs call for review of three fairly-stable pre-PAR proposals, or a decision needs to be made between three proposals after a PAR has been approved, or an official Draft is completed and needs review, then the Bridge WG chairs can post the document(s) on the Bridge WG mailing list for extra review. 6. IETF MIB Doctor Reviews Harrington Expires September 1, 2006 [Page 10] Internet-Draft 8021 MIB Transition February 2006 6.1. Introduction The leaders of the Bridge WG, 802.1 WG, IETF O&M area, and IEEE 802 area have discussed having IETF MIB Doctors review 802 developed MIB modules. This is a loose offering. The expectation is that IETF will maintain a group of MIB Doctors who can review 802 developed MIB modules, when a MIB Doctor is available and willing to do such review. It is the choice of individual MIB Doctors to provide technical advice and MIB Doctor reviews, and it is the willingness of the 802.1 editors and the support of the 802.1 chairs that determine whether the advice is accepted or not. It is not formalized as in the IETF. In the IETF, the O&M Area Directors get "pushed" by other Area Directors to have MIB module documents reviewed by MIB Doctors when they start to come to WG Last Call, IETF Last Call, and certainly no later than when they appear on the IESG agenda. This demand requires prioritization of requests for MIB Doctor reviews by the Area Directors and prioritization by MIB Doctors when deciding whether to accept a request to review documents. When there are many IETF MIB documents in the queue and an IEEE MIB module document comes along for review, it will be the choice of the individual MIB Doctors whether to accept such a request, and how to prioritize their work. It will be helpful to MIB Doctors if the 802.1 chair requests a review early in development, after a MIB module design has been established but before an editor has done much detailing of the MIB module, so a MIB Doctor can ensure that the table relationships and indexing are reasonable. Then it will be helpful if the 802.1 chair requests reviews only for important ballots, such as sponsor ballots, rather than for every revision. It is recommended that the 802.1 WG establish their own MIB Doctor review team, to provide a review of MIB modules and to resolve most issues before requesting a review from the IETF MIB Doctors. This will help the 802.1 WG avoid delays caused by dependency on IETF MIB Doctors, and pre-reviewed documents will make it easier for an IETF MIB Doctor to find time to perform a requested review. The IETF is willing to make a loose offering to help the 802.1 WG establish and train such an IEEE MIB Doctor team. 6.2. Review Guidelines The IETF has developed a set of "Best Current Practice" MIB review guidelines [RFC4181], so editors and other WG members can check the Harrington Expires September 1, 2006 [Page 11] Internet-Draft 8021 MIB Transition February 2006 document against the guidelines before requesting a MIB Doctor review. The 802.1 WG editor should utilize the MIB review guidelines before requesting a MIB Doctor review. The MIB review guidelines are also intended to help editors by guiding MIB Doctors, so reviews by different MIB Doctors will remain fairly consistent. Each MIB Doctor has their own "pet peeves", and the guidelines can help an editor know whether a review point is based on the consensus of the MIB Doctors, or a pet peeve. Many SMI constraints and IETF editing constraints and best current practices are discussed in the mib-review-guidelines. However, many aspects of good MIB design (e.g. table fate-sharing, good index choices, etc.) are more art than science, and are not discussed in the guidelines. Those might be more useful to other SDOs (and IETF editors) than guidelines relating to IETF boilerplate requirements. The MIB Doctors have discussed starting a design guidelines document. The MIB review guidelines were used when reviewing the 802.1AB [IEEE802.1AB]and 802.1AE [IEEE802.1AE]documents. During those reviews, there were some issues found with the review-guidelines that we need to evaluate further. In the IETF boilerplates, some of the terms have different meaning in IETF and IEEE, and different editing style guidelines are being used by the different bodies. It would be good to develop an 802 MIB boilerplate that is consistent with the IETF boilerplate, in purpose if not in terminology. There are many IETF-specific aspects of the MIB review guidelines, and the IEEE should probably formalize their own guidelines to supplement the IETF guidelines. For example, an IETF standard MIB module must use the approved boilerplates for MIB modules, IANA considerations, IPR, and ID-nits that do not directly apply to IEEE MIB module work. For the most part, the IETF guidelines have been applied to IEEE MIB modules with minor adjustments, even though the IEEE has its own rules of document formatting, IPR, and OID assignments. An IETF MIB document template that contains all the required sections, following RFC Editor guidelines and the MIB review guidelines, is under development to help editors get started developing a MIB module document. The template will help MIB Doctors check new MIB modules more efficiently by providing the most up-to- date MIB module boilerplate, with sections in the preferred order, suggestions for what to include in certain sections, and the references required to support boilerplate text. It is recommended that the IEEE 802.1 WG establish a comparable template, following the Harrington Expires September 1, 2006 [Page 12] Internet-Draft 8021 MIB Transition February 2006 IEEE editing guidelines and the MIB review guidelines where appropriate. Such an IEEE template could simply result in being the management clause of an 802.1 document, to be filled in with technology-specific information. In 802.1AB, the MIB clause was restructured to include modified IETF boilerplates and security considerations. This might be a good start on such an IEEE template. It would be helpful to MIB Doctors and editors if the unmodified template was available in ASCII format for comparison to a document in development, to verify that the appropriate boilerplate text is being used. When the 802.1 WG creates a PAR for 802.1 Bridge MIB maintenance, the creation of such a template might be included in the PAR. 6.3. Review Format The 802.1 WG uses a template for comments, in the following format, so the onus to provide new text is on the reviewer, not the editor. NAME: COMMENT TYPE: [E=Editorial, ER=Editorial Required] [T=Technical, TR=Technical Required] CLAUSE: PAGE: LINE: COMMENT START: COMMENT END: SUGGESTED CHANGES START: SUGGESTED CHANGES END: MIB Doctor reviews in the IETF are typically done in simple text email, and often contain a long list of review comments. MIB Doctor reviews sometimes raise a general design issue rather than an issue with specific text, and some MIB Doctor comments refer to "global" problems, such as many objects that do not specify persistence requirements. For global problems, IETF MIB Doctors are not required to provide the replacement text for each of these instances when doing 802.1 MIB module reviews. For example, if the naming of objects does not follow recommended conventions throughout the document, the MIB Doctor can point out the relevant clause in the MIB review guidelines without suggesting each replacement object name. This is an important concession to the IETF MIB Doctors, to better suit the Harrington Expires September 1, 2006 [Page 13] Internet-Draft 8021 MIB Transition February 2006 nature of their reviews, even though this puts the onus on the editor to fix the problem without explicit suggested changes. During the transition, the chair and vice-chair of the 802.1 WG are willing to accept simple emails, as long as they give enough information to understand what the problem is and how to fix it. The comments should include a problem description, a suggested resolution, and a page and line number. It would be helpful if comments are submitted in the preferred format, since this makes it easier for the editor to understand exactly what is being requested, to log the comment for review, and to review the comment in the meeting environment. The majority of MIB comments can usually be handled outside of the official balloting process. 6.4. Review Weight In the IETF, MIB Doctor review happens as part of the process of approving a standard. When a document is submitted to the IESG for approval as a standard, the Area Director/IESG requests a MIB Doctor review. Failure to pass the review can stop forward progress of a document in the standardization process at the discretion of the Area Director. MIB Doctors take their role seriously and perform detailed reviews. In the IEEE, the board that approves a standard is separate from the 802.1 WG, and the reviews MIB Doctors will do based on this transition plan are done within the 802.1 WG. So a MIB Doctor review in the 802.1 WG is akin to an IETF WG chair asking for a MIB Doctor to sanity-check the work, rather than a formal "MIB Doctor review". Formally, comments from any origin carry the same weight in 802.1; even voting status in the WG doesn't make your comments more weighty than a non-voter. The 802.1 WG is not permitted to ignore any comments, regardless of origin. Serious comments are always taken seriously and never ignored. The IEEE typically requires comments to be officially submitted in a specific format, including proposed replacement text, which is then reviewed at the meetings, and the decisions are documented in disposition documents. These comments and dispositions are available from the 802.1 private website. IETF personnel can be given the password to the website by the 802.1 WG chair, so they can see previous and current comments and dispositions. We should not give the impression that the IEEE documents have received the organized, coordinated, and formalized MIB Doctor review as done in the IETF, if such review is done on an ad-hoc basis, and not necessarily as part of the advancement process. We need to be Harrington Expires September 1, 2006 [Page 14] Internet-Draft 8021 MIB Transition February 2006 clear what is said, because the phrase "This document has passed MIB Doctor review" has quite some weight in the IETF. We need to clarify whether to describe the reviews done as having been done by an "IETF MIB Doctor" or "IEEE 802 MIB Doctor", or a generic "MIB Doctor". MIB Doctor reviews be copied to the document editor, and to the 802.1 chair 7. Communicating the Transition Plan The transition plan was discussed in the Bridge WG at IETF61, and included a presentation "Bridge MIB Transition to IEEE 802.ppt" available in the proceedings. The intent to transition was also posted on the Bridge WG mailing list during notices of the Bridge WG closure, including the WG Action announcement of February 15, 2006. The transition was discussed with the 802.1 WG at the San Antonio, San Francisco, and Garden Grove meetings. Presentations are available in http://www.ieee802.org/1/files/public/docs2004/ new-bridge-mib-transition-1104.ppt, http://www.ieee802.org/1/files/ public/docs2005/liaison-ietf-congdon-0705.pdf, and http:// www.ieee802.org/1/files/public/docs2005/ liaison-ietf-congdon-0905.pdf. 8. Security Considerations This document describes a plan to transition MIB module responsibility from the IETF Bridge WG to the IEEE 802.1 WG. It does not impact security. 9. IANA Considerations Although this document discusses issues related to IANA assignment of OIDs, no IANA actions are required by this document. 10. Intellectual Property Considerations On November 29, 2005, a teleconference was held that included Jorge Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David Harrington, to discuss the Intellectual Property Issues. The following is a summary of the results: Harrington Expires September 1, 2006 [Page 15] Internet-Draft 8021 MIB Transition February 2006 The IETF/ISOC gets a non-exclusive copyright from RFC authors so that the IETF can publish RFCs, let 3rd parties translate RFCs into other languages, let 3rd parties reproduce RFCs as-is and to create derivative works within the IETF standard process. The author(s) retain all their rights other than the right to withdraw the permission for the IETF to do the above. If anyone (including the IEEE) wants to reproduce any RFC as-is they can do so without any specific permission - but it has to be "as-is" and that includes the ISOC copyright - since the right for 3rd parties to reproduce RFCs is part of the rights the IETF gets from the author(s). The author(s) of a RFC can tell another group (e.g., the IEEE) that the other group can produce their own versions of the RFC if the author(s) want to since the IETF does not get from the author(s) the right to stop them from doing so. If the author(s) give another group the permission to create derivative works, this has nothing (legally) to do with the IETF since the agreement is just between the author(s) and the other group. Because of that, there is no reason for an ISOC copyright to appear since the new document is not an IETF document. It would be nice if the other group were to include a note to say that their document is based on RFC XXXX, and the author(s) can insist on that if they want but the IETF has no formal role in the granting of permissions so the IETF cannot require the pointer to the RFC. A new proposal being considered in the IPR working group might change this process so that the IETF would get from the authors the right to grant permission to other groups to produce derivative works. If that were the case the IETF could then insist on the pointer to the RFC and an ISOC copyright if the IETF wanted to do so. But even if this proposal is accepted the authors could still grant permission on their own without any IETF involvement. There is a desire to ensure that the IETF has sufficient rights to do derivatives of its own works. If the IETF decides, as part of a liaison arrangement with another SDO, to hand over maintenance of a specification to them, and the authors give the other SDO permission to create derivative works, the IETF still retains the permission granted by the authors to create derivative works within the IETF standard process. The IETF strongly recommends that any derivative works developed by another standards body DO acknowledge that the work builds on prior IETF work, with reference to the RFC(s) the work derives from. MIB modules compliant to the IETF Best Current Practices "Guidelines for Harrington Expires September 1, 2006 [Page 16] Internet-Draft 8021 MIB Transition February 2006 MIB Documents" [RFC4181] contain REVISION clauses that document how/ where earlier versions were published. Jorge has crafted a sample document that other SDOs may use as a guideline for producing their own documents on "how to ask the question" to solicit authors' permissions, and the template is included in this document in Appendix B.. 11. References 11.1. Normative References [RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005. [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed Objects for Bridges", RFC 4188, September 2005. [RFC4318] D.Levi and D.Harrington, "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", RFC 4318, December 2005. [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions", RFC 4363, January 2006. 11.2. Informative References [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. [IEEE802.1AB] "IEEE Std 802.1AB-2005, Standard for Local and metropolitan area networks - Station and Media Access Control Connectivity Discovery", IEEE Std 802.1AB- 2005 IEEE Std, 2005. [IEEE802.1AE] "IEEE P802.1AE-2006, Draft Standard for Local and Harrington Expires September 1, 2006 [Page 17] Internet-Draft 8021 MIB Transition February 2006 metropolitan area networks - Media Access Control (MAC) Security.", http://www.ieee802.org/1/files/private/ ae-drafts/d4/802-1ae-d4-0.pdf IEEE Draft, January 2006. [PAR-IEEE802.1ah] "http://standards.ieee.org/board/nes/projects/ 802-1ah.pdf", 802-1ah IEEE PAR, December 2004. Appendix A. Contributors Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 Tel Aviv, 61131 Israel +972 3-645-8414 dromasca@avaya.com Tony Jeffree Chair, 802.1 WG 11A Poplar Grove Sale Cheshire M33 3AX UK +44 161 973 4278 tony@jeffree.co.uk Paul Congdon Vice Chair, 802.1 WG Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 US +1 916 785 5753 paul.congdon@hp.com Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL +31-348-407-775 bwijnen@lucent.com Harrington Expires September 1, 2006 [Page 18] Internet-Draft 8021 MIB Transition February 2006 Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US +1 425 818 4011 bernarda@microsoft.com Appendix B. Sample text for IEEE to request rights from authors > "Dear Author, The IEEE P802.1 working group wishes to incorporate portions of IETF RFC XXXX (specifically YYY MIB modules) as part of IEEE Draft Standard P802.1 and, to develop, modify and evolve such portions as part of the IEEE standardization process. Because the authors of contributions to the IETF standards retain most intellectual property rights with respect to such contributions under IETF policies in effect during the development of RFC XXXX and, because you are an author of said document, the IEEE hereby requests that you kindly agree to submit your contributions in RFC XXXX to the IEEE for inclusion in IEEE P802.1. Please note that IETF is aware of and supports this request. Attached hereto, please find a copyright permission letter template that we ask you to kindly sign and return, granting the afore mentioned rights to the IEEE. Sincerely yours, IEEE" Appendix C. Change Log [RFCEditor: please remove the change log before publication] Changes from -00- removed uncited references fixed some citations (re-)moved sections on updating OIDs, IANA OID Registration, and mailing list usage, comment formats updated MIB Doctor review section updated clarifications section updated URLs for presentations about the transition updated Intellectual Property section based on teleconference with IETF lawyer Harrington Expires September 1, 2006 [Page 19] Internet-Draft 8021 MIB Transition February 2006 updated IEEE references removed empty history section rewrote the "Updating IETF MIB Modules" section added appendix with sample letter to authors removed sections no longer needed after discussions with legal counsel Author's Address David Harrington (editor) Effective Software Consulting Harding Rd Portsmouth NH USA Phone: +1 603 436 8634 Email: dbharrington@comcast.net Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Harrington Expires September 1, 2006 [Page 20] Internet-Draft 8021 MIB Transition February 2006 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Harrington Expires September 1, 2006 [Page 21]