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)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4663 (Informational) | |
| 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
Show full document text