Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG
RFC 4663
Document | Type |
RFC - Informational
(September 2006; No errata)
Was draft-harrington-8021-mib-transition (individual in ops area)
|
|
---|---|---|---|
Author | David Harrington | ||
Last updated | 2015-10-14 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4663 (Informational) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Dan Romascanu | ||
Send notices to | bwijnen@lucent.com |
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). Abstract This 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. Harrington Informational [Page 1] RFC 4663 802.1 MIB Transition September 2006 Table of Contents 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 1. Introduction This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB WG to the IEEE 802.1 WG, which develops the bridging technology the MIB modules are designed to manage. The current Bridge MIB 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]. Harrington Informational [Page 2] RFC 4663 802.1 MIB Transition September 2006 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. 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 leave 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. If such work comes into the IETF from other standards development organizations (SDOs), then we encourage the other SDO to bring in subject matterShow full document text