Network Working Group D. Harrington, Ed. Request for Comments: 4663 Effective Software Consulting Category: Informational September 2006 Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG Status of This Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage.
1. Introduction ....................................................2 1.1. Motivation .................................................3 2. New IEEE MIB Work ...............................................3 2.1. New MIB PARs ...............................................3 2.2. IEEE MIB Modules in ASCII Format ...........................4 2.3. OID Registration for New MIB Modules .......................5 3. Current Bridge MIB WG Documents .................................6 3.1. Transferring Current Bridge MIB WG Documents ...............6 3.2. Updating IETF MIB Modules ..................................6 3.3. Clarifications on Variables Mapping and Compliance .........8 4. Mailing List Discussions ........................................9 5. IETF MIB Doctor Reviews .........................................9 5.1. Introduction ...............................................9 5.2. Review Guidelines .........................................10 5.3. Review Format .............................................13 5.4. Review Weight .............................................14 6. Communicating the Transition Plan ..............................15 7. Security Considerations ........................................15 8. IANA Considerations ............................................15 9. Intellectual Property Considerations ...........................16 Appendix A. Contributors .........................................18 Appendix B. Sample Text for IEEE to Request Rights from Authors ..19 Normative References ..............................................20 Informative References ............................................20 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 MIB WG MIB modules to the IEEE 802.1 WG, so that the plan can be reviewed by the IESG, IAB, IETF, and IEEE. Some case-by-case situations might arise, which will be handled by the appropriate liaisons, but this document describes the general strategy. http://standards.ieee.org/board/nes/. PARs are roughly the
equivalent of IETF Working Group Charters 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. The latest Project Approval Requests (PAR) of the 802.1 projects, starting with the P802.1ah (Provider Backbone Bridges) approved in December 2004, include explicit text on this respect. 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 that the MIB development work 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 a 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, submitters of new work in the bridge management space should be directed to the IEEE 802.1 WG, and it should be recommended that they not publish their proposed MIB modules as Internet-Drafts.
IEEE 802 has a policy whereby approved specifications are available for a fee for the first six months after approval, and freely available six months after they are approved. Once the specification is approved, the ASCII version of the MIB module is made freely available on the 802.1 WG website (see http://www.ieee802.org/1/files/public/MIBs/ or 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 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 approval will be adequate. IEEE.802b]. As the IEEE 802.1 WG updates the IEEE 802.1 standards, 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 that reuses the indexing of the existing tables. The new modules can be registered under the 802.1 registration branch, as was done with the 802.1X MIB module. When the changes only require the addition 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 of 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 from 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 efficiency in making changes. Keeping the existing trees in their place minimizes disruption to existing implementations. RFC1286, RFC1493, and RFC1525 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 them to perform maintenance and development of derivations works from documents containing the BRIDGE-MIB [RFC4188], P-BRIDGE- MIB, Q-BRIDGE-MIB [RFC4363], and RSTP-MIB [RFC4318], 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. The IETF legal counsel for IPR matters and the IEEE Standards Association Manager of Standards Intellectual Property 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 MIB 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 Standards Association Manager of Standards Intellectual Property. The IETF will retain all the rights granted at the time of publication in the published RFCs.
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 MIB WG, there were some issues that we decided not to resolve, which allows 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: o The 'autoEdgePort' parameter (802.1D-2004 clause 17.3.3). o The BridgeID object. o References to 802.1D-1998 were not updated to 802.1D-2004. o Some objects in RFC4363 may have been obsoleted in 802.1D-2004 o Description of dot1dPortOutboundAccessPriority seems wrong, but it followed the description in 802.1D-1998. o 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 to include a separate MIB module to augment the IETF MIB modules. However, recent changes to the IEEE standards are expected to require that the way the MIB tables are INDEXED be changed, 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. 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. Thus, we don't have a problem with synchronization between the copies being published.
Often, the mapping of 802 variables to MIB objects isn't a 1:1 mapping and doesn't have to be. In the future, 802.1 variables may be invented with Web-based services in mind, but today the primary 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 802.1 management variable semantics are changed and MIB objects are supplemented. 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 addition 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. 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.
The expectation is that IETF will maintain a group of MIB Doctors who can review IEEE 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. This is not as formalized as it is 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 that 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 its 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. RFC4181] so that authors and other WG members can check their document against the guidelines before requesting a MIB Doctor review. The 802.1 WG editor should use the RFC4181 guidelines before requesting a MIB Doctor review.
RFC4181 also intended to help editors by guiding MIB Doctors, so reviews by different MIB Doctors will remain fairly consistent. Each MIB Doctor has his or her own "pet peeves", and RFC4181 can help an editor know whether a review point is based on the consensus of the MIB Doctors, or on a pet peeve. Many SMI constraints, IETF editing constraints, and best current practices are discussed in RFC4181. However, many aspects of good MIB design (e.g., table fate-sharing, good index choices) 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. RFC4181 was used for reviewing the 802.1AB [IEEE802.1AB] and 802.1AE [IEEE802.1AE] documents. During those reviews, there were some anomalies about the IEEE use of the guidelines that we need to evaluate further. For example, in the IETF boilerplates, some of the terms have different meanings 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. 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 its own guidelines for IEEE MIB modules review. Until this happens, Section 3 (General Documentation Guidelines) and Section 4 (SMIv2 Guidelines) in RFC4181 can be used, with the following exceptions and modifications: o 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. o Sections 3.1 through 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. o Section 3.5 (IANA Considerations) does not apply but may be replaced by a section with IEEE recommendations on naming and OID space assignments. o Sections 3.6 does not apply.
o Section 3.7 (Copyright Notices) does not apply and may be replaced with text corresponding to the IEEE copyright rules. The exception is the case where a document was originally issued by the IETF, and then taken over by the IEEE, in which case, unless the document authors agree otherwise, notices concerning the IETF copyrights (as described in Section 3.7) and IEEE copyrights must be included. o Section 3.8 (Intellectual Property) does not apply and may be replaced with a notice reflecting the intellectual property rules of the IEEE. o Sections 4.1 and 4.2 apply as in the IETF document. o Section 4.3 (Naming Hierarchy) applies with changes related to the OID root of the IEEE 802.1 MIB modules. o Sections 4.4 to 4.8 apply as in the IETF document o 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. 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 IEEE editing guidelines and the RFC4181 guidelines, where appropriate. Such an IEEE template could simply be 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 automated 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.
The IETF MIB documents include the following text relative to the Internet Management Framework as part of the standard boilerplate: For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base, or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579], and STD 58, RFC 2580 [RFC2580]. It is recommended that the IEEE 802.1 standards that contain MIB modules include a similar sub-section in the MIB section of the IEEE document, and the appropriate references in their reference section. If IEEE 802.1 WG wants to craft its own guidelines, based on RFC4181, it will need to get the author's permission.
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 RFC4181 without suggesting each replacement object name. This is an important concession to the IETF MIB Doctors, to better suit the 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 the official balloting process.
from the 802.1 private website. IETF participants can be given the password to the website by the 802.1 WG chair, so that 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 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 by a generic "MIB Doctor". MIB Doctor reviews be copied to the document editor, and to the 802.1 chair. 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.
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 documented in RFC4181 contain REVISION clauses that document how/where earlier versions were published. On January 11, 2006, another teleconference was held, to review the legal issues with Claudio M. Stanziola, the IEEE Standards Association Manager of Standards Intellectual Property. As a result of that discussion, the IETF Legal Counsel on IPR matters 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. The template is included in this document in Appendix B.
[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] Levi, D. 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. [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 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. [IEEE.802b] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Overview and Architecture, Amendment 2: Registration of Object Identifiers", IEEE Standard 802, 2004. [PAR-IEEE802.1ah] "http://standards.ieee.org/board/nes/ projects/802-1ah.pdf", 802-1ah IEEE PAR, December 2004.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002. [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
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. 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 firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).