Bridge MIB WG                                         D. Harrington, Ed.
Internet-Draft                             Effective Software Consulting
Intended status: Informational                              May 30, 2006
Expires: December 1, 2006


     Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG
              draft-harrington-8021-mib-transition-03.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 December 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 MIB Working Group
   to the IEEE 802.1 Working Group, which develops the bridging
   technology the MIB modules are designed to manage.







Harrington              Expires December 1, 2006                [Page 1]


Internet-Draft             8021 MIB Transition                  May 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
   3.  Current Bridge MIB WG Documents  . . . . . . . . . . . . . . .  6
     3.1.  Transferring Current Bridge MIB WG Documents . . . . . . .  6
     3.2.  Updating IETF MIB Modules  . . . . . . . . . . . . . . . .  7
     3.3.  Clarifications on Variables Mapping and Compliance . . . .  8
   4.  Mailing List Discussions . . . . . . . . . . . . . . . . . . .  9
   5.  IETF MIB Doctor Reviews  . . . . . . . . . . . . . . . . . . .  9
     5.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 10
     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 . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.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 . . . . . . . . . . 21




















Harrington              Expires December 1, 2006                [Page 2]


Internet-Draft             8021 MIB Transition                  May 2006


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.  There might be some case-by-case situations that
   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 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.  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 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



Harrington              Expires December 1, 2006                [Page 3]


Internet-Draft             8021 MIB Transition                  May 2006


   is OK with other organizations (like IEEE 802) doing MIB documents
   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 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 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, submitters of new work in the bridge management space
   should be directed to the IEEE 802.1 WG, and to recommend they 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



Harrington              Expires December 1, 2006                [Page 4]


Internet-Draft             8021 MIB Transition                  May 2006


   the transfer of 802.1 MIB development from IETF Bridge MIB WG to IEEE
   802.1 WG.  While 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 that 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 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 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 additional of one or two objects to
   the existing MIB modules, it may seem simpler for the 802.1 WG to



Harrington              Expires December 1, 2006                [Page 5]


Internet-Draft             8021 MIB Transition                  May 2006


   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
   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

   While reviewing 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 of and the development of
   derivations works from documents containing the BRIDGE-MIB [RFC4188]
   and the P-BRIDGE-MIB and 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



Harrington              Expires December 1, 2006                [Page 6]


Internet-Draft             8021 MIB Transition                  May 2006


   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 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 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 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:
   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 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.

   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



Harrington              Expires December 1, 2006                [Page 7]


Internet-Draft             8021 MIB Transition                  May 2006


   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 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
   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



Harrington              Expires December 1, 2006                [Page 8]


Internet-Draft             8021 MIB Transition                  May 2006


   new object in the SMIv2 MIB module.

   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.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 changing 802.1 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 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:

   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






Harrington              Expires December 1, 2006                [Page 9]


Internet-Draft             8021 MIB Transition                  May 2006


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 or not.  This is not as 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.

5.2.  Review Guidelines

   The IETF has developed Guidelines for Authors and Reviewers of MIB
   Documents [RFC4181], so authors and other WG members can check their



Harrington              Expires December 1, 2006               [Page 10]


Internet-Draft             8021 MIB Transition                  May 2006


   document against the guidelines before requesting a MIB Doctor
   review.  The 802.1 WG editor should utilize 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 their own "pet peeves", and RFC4181 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 RFC4181.  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.

   RFC4181 was used when 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 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.

   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 their 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 to 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 Section) 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



Harrington              Expires December 1, 2006               [Page 11]


Internet-Draft             8021 MIB Transition                  May 2006


      the IETF, and then taken over by the IEEE, in which case, unless
      otherwise agreed by the document authors, notices concerning the
      IETF copyrights (as described in the current 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 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 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:









Harrington              Expires December 1, 2006               [Page 12]


Internet-Draft             8021 MIB Transition                  May 2006


    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 their own guidelines based on
   RFC4181, they will need to get the author's permission.

5.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



Harrington              Expires December 1, 2006               [Page 13]


Internet-Draft             8021 MIB Transition                  May 2006


   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 of the official balloting process.

5.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 participants can be given the
   password to the website by the 802.1 WG chair, so they can see
   previous and current comments and dispositions.




Harrington              Expires December 1, 2006               [Page 14]


Internet-Draft             8021 MIB Transition                  May 2006


   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 a generic "MIB Doctor".

   MIB Doctor reviews be copied to the document editor, and to the 802.1
   chair


6.  Communicating the Transition Plan

   The transition plan was discussed in the Bridge MIB 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 MIB WG mailing
   list during notices of the Bridge MIB 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.


7.  Security Considerations

   This document describes a plan to transition MIB module
   responsibility from the IETF Bridge MIB WG to the IEEE 802.1 WG.  It
   does not impact security.


8.  IANA Considerations

   Although this document discusses issues related to IANA assignment of
   OIDs, no IANA actions are required by this document.


9.  Intellectual Property Considerations

   On November 29, 2005, a teleconference was held that included Jorge



Harrington              Expires December 1, 2006               [Page 15]


Internet-Draft             8021 MIB Transition                  May 2006


   Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David
   Harrington, to discuss the Intellectual Property Issues.  The
   following is a summary of the conclusions:

   The IETF/ISOC gets a non-exclusive copyright license from RFC authors
   so that the IETF can publish RFCs, let third parties translate RFCs
   into other languages, let third 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 notice - since the right for
   third 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.

   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 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



Harrington              Expires December 1, 2006               [Page 16]


Internet-Draft             8021 MIB Transition                  May 2006


   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, and the template is included in this document
   in Appendix B.


10.  References

10.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.

10.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 December 1, 2006               [Page 17]


Internet-Draft             8021 MIB Transition                  May 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.

   [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.


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





Harrington              Expires December 1, 2006               [Page 18]


Internet-Draft             8021 MIB Transition                  May 2006


      Schagen 33
      3461 GL Linschoten
      NL
      +31-348-407-775
      bwijnen@lucent.com

      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





Harrington              Expires December 1, 2006               [Page 19]


Internet-Draft             8021 MIB Transition                  May 2006


      (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 legal counsel
      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

























Harrington              Expires December 1, 2006               [Page 20]


Internet-Draft             8021 MIB Transition                  May 2006


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
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Harrington              Expires December 1, 2006               [Page 21]