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.
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].
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 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 participate in (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
finds it acceptable if other organizations (like IEEE 802) do MIB
documents themselves, and the IETF offers to help review them from an
SNMP/MIB/Structure of Management Information (SMI) perspective. This
is true even after the transition, since quality MIB modules are
important for 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 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.
2.2. IEEE MIB Modules in ASCII Format
Making MIB modules 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 MIB WG to IEEE
802.1 WG. Although 802.1 can certainly decide to publish MIB modules
only 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
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 participants to access these documents
for pre-standard review purposes.
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.
2.3. OID Registration for New MIB Modules
The IETF and IEEE 802 have separate registration branches (arcs) in
the Object Identifier (OID) tree. The Bridge MIB modules are
registered under the IETF branch, and some assignments are maintained
by IANA. The administration of the IEEE 802 arc is documented in
[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.
3. Current Bridge MIB WG Documents
3.1. Transferring Current Bridge MIB WG Documents
During review of the legal issues associated with transferring Bridge
MIB 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 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.
3.2. Updating IETF MIB Modules
The updates to the Bridge MIB WG documents addressed 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 MIB 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 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.
3.3. Clarifications on Variables Mapping and Compliance
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, 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. Therefore it is
recommended that the IETF MIB module not be copied and modified
unless doing so is really necessary.
The current practice in the 802.1 WG is to define the management
variables 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.
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.
4. Mailing List Discussions
The Bridge MIB WG has completed its documents, and the WG has been
closed.
The mailing list will remain open for a while. The mailing list
administrators will discourage discussion of ongoing IEEE MIB module
work on the Bridge MIB WG list and ask that the discussion be moved
to the IEEE list, with a notice comparable to the following:
This work is out of scope for the Bridge MIB 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. IETF MIB Doctor Reviews
5.1. Introduction
The leaders of the Bridge MIB WG, 802.1 WG, IETF O&M area, and IEEE
802 project have discussed having IETF MIB Doctors review IEEE 802
developed MIB modules. This is a loose offering.
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.
5.2. Review Guidelines
The IETF has developed Guidelines for Authors and Reviewers of MIB
Documents [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