[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 RFC 4663

Bridge WG                                             D. Harrington, Ed.
Internet-Draft                             Effective Software Consulting
Expires: April 9, 2006                                   October 6, 2005


       Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG
              draft-harrington-8021-mib-transition-00.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 April 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the plan to transition responsibility for
   bridging-related MIB modules from the IETF Bridge WG to the IEEE
   802.1 WG, which develops the bridging technology the MIB modules are
   designed to manage.








Harrington                Expires April 9, 2006                 [Page 1]

Internet-Draft             8021 MIB Transition              October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  History  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  New IEEE MIB Work  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  New MIB PARs . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  IEEE MIB Modules in ASCII format . . . . . . . . . . . . .  5
     2.3.  OID Registration . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Editing New IEEE MIB Modules . . . . . . . . . . . . . . .  6
   3.  Current Bridge WG Documents  . . . . . . . . . . . . . . . . .  6
     3.1.  Transferring Current Bridge WG Documents . . . . . . . . .  7
     3.2.  Updating IETF MIB modules  . . . . . . . . . . . . . . . .  7
     3.3.  Clarifications . . . . . . . . . . . . . . . . . . . . . .  7
     3.4.  IANA OID Registration  . . . . . . . . . . . . . . . . . .  9
   4.  Mailing List Discussions . . . . . . . . . . . . . . . . . . . 10
     4.1.  Comment Formats  . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Bridge WG Mailing List Announcements . . . . . . . . . . . 11
   5.  MIB Doctor Reviews . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . 11
     5.2.  Review Guidelines  . . . . . . . . . . . . . . . . . . . . 12
     5.3.  Review Format  . . . . . . . . . . . . . . . . . . . . . . 13
     5.4.  Review Weight  . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Communicating the Transition Plan  . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Intellectual Property Considerations . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Contributors  . . . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 18



















Harrington                Expires April 9, 2006                 [Page 2]

Internet-Draft             8021 MIB Transition              October 2005


1.  Introduction

   This document describes the plan to transition responsibility for
   bridging-related MIB modules from the IETF Bridge WG to the IEEE
   802.1 WG, which develops the bridging technology the MIB modules are
   designed to manage.  The current Bridge WG documents are
   o  "Definitions of Managed Objects for Bridges" [RFC4188],
   o  "Definitions of Managed Objects for Bridges with Traffic Classes,
      Multicast Filtering and Virtual LAN Extensions" [I-D.ietf-bridge-
      ext-v2],
   o  "Definitions of Managed Objects for Bridges with Rapid Spanning
      Tree Protocol" [I-D.ietf-bridge-rstpmib], 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 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, but this document describes the general strategy.

   Some points requiring further WG research and discussion are
   identified by [discuss] markers in the text.  Points where further
   editorial work is required are identified by [todo] markers in the
   text.

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.  While the
   IESG does not mandate that other standards development organizations
   (SDOs) do so, if such work comes into the IETF, then we want 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.



Harrington                Expires April 9, 2006                 [Page 3]

Internet-Draft             8021 MIB Transition              October 2005


   Developing 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 is OK with other organizations (like 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.

1.2.  History


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 an IETF Working Group Charter, 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.

   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.

   The IEEE 802.1 Working Group is considering a new project for the
   Multiple Spanning Tree Protocol (MSTP).  This work is based on
   initial submissions, some of which were made in the IETF Bridge MIB
   Working Group.  The proposal for this PAR is documented at http://
   www.ieee802.org/1/files/public/docs2005/new-congdon-MSTP-MIB-0505
   .pdf.



Harrington                Expires April 9, 2006                 [Page 4]

Internet-Draft             8021 MIB Transition              October 2005


   Since the IETF Bridge MIB WG does not intend to develop MIB modules
   in the future, it is recommended to direct submitters of new work in
   the bridge management space to the IEEE 802.1 WG, and to 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
   the transfer of 802.1 MIB development from IETF Bridge WG to IEEE
   802.1 WG.  While 802.1 can certainly decide they're going to develop
   MIB modules in the PDF format, which 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.

   The 802.1 WG has started making the MIB module portion of their
   documents available as separate text files during project
   development, and allowing IETF personnel to access these documents
   for review purposes.  For completed specifications, the ASCII version
   of the MIB module is available on the 802.1 WG website
   (http://www.ieee802.org/1/pages/MIBS.html).

   There may be some issues about what gets included in the freely
   available specification.  The ASN.1 MIB module alone will probably be
   insufficient; some discussion of the structure of the MIB, the
   anticipated use cases for MIB objects, 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.

   The 2001 version of the ASN.1 MIB module for 802.1X (the IEEE8021-
   PAE-MIB) has been published in ASCII on
   http://www.ieee802.org/1/pages/MIBS.html, but should be updated with
   enough surrounding documentation to be clear, and to address
   deployment issues such as security considerations.

   [discuss] Did the 802.1 WG submit a document for 802.3ad, or is this
   a typo?

   The 802.1 WG has, with some projects (e.g., 802.1X, 802.3ad)
   submitted a MIB module document to be published as an informational
   RFC.  Since the IEEE is publishing a corresponding document as a
   standard, and the RFC is only informational, it would probably be
   better to point interested parties to the appropriate 802.1 WG public
   website to prevent confusion over who is maintaining the document.
   As we transition existing Bridge WG documents to the 802.1 WG, and



Harrington                Expires April 9, 2006                 [Page 5]

Internet-Draft             8021 MIB Transition              October 2005


   the 802.1 WG document obsoletes the last IETF version, the Bridge WG
   or the 802.1 WG should create a corresponding RFC that simply points
   to the openly available IEEE copy, so we don't have a problem with
   synchronization between the copies being published.

   [discuss] I haven't been able to locate the Informational RFC for
   802.1X MIB.

2.3.  OID Registration

   As the 802.1 WG updates the 802.1 standards, new MIB modules will
   need to be developed and registered, and they will be registered
   under the 802.1 registration branch, as was done with the 802.1X MIB
   module.

   IEEE has an established set of arcs in 802 for registration of OIDs
   and it makes sense for the IEEE to administer the registration of MIB
   module assignments for MIB modules they maintain, rather than asking
   IANA to provide such registrations.  The administration of the 802
   arc is documented in IEEE 802b.

2.4.  Editing New IEEE MIB Modules

   MIB module editors will need to be regular attendees and become
   members over time, as is the norm for 802.1 membership.  Showing up
   at the meetings is the important factor because official IEEE work is
   done in the meetings, rather than on mailing lists as in the IETF.

   For exceptional conditions, the Chair has the power to bestow
   membership ahead of the usual attendance requirement.

   During the transition, to accommodate IETF candidates for editor,
   work can take place over email and outside of the meetings initially


3.  Current Bridge WG Documents

   The Bridge WG documents have all been submitted for publication as
   Proposed Standards, and have been approved by the IESG.  The
   documents should not change except editorially before being published
   as RFCs.  It should be fine for the 802.1 WG to work against those
   documents while waiting for RFC publication, with the understanding
   that there is always a small chance an appeal could be filed, or
   other unusual events could cause the RFCs to not be published or to
   change technically.






Harrington                Expires April 9, 2006                 [Page 6]

Internet-Draft             8021 MIB Transition              October 2005


3.1.  Transferring Current Bridge WG Documents

   [discuss] We need to work out just how the transition of
   responsibility for existing MIB modules will happen.  The IETF will
   not want to give up all rights to the documents, and have the 802.1
   WG simply republish the existing documents under the IEEE name.

   The 802.1 WG will need to work through the management objects in the
   existing documents to determine whether they are consistent with
   their emerging specifications.

   During the final work on these documents in the Bridge WG, there were
   some issues that we decided not to solve and to allow it to be dealt
   with as part of the future work in the 802.1 WG.  It would be useful
   to document these known issues so future generations of Bridge MIB
   developers in the IEEE will not need to dig in the Bridge WG archives
   to see what issues existed. [discuss] Maybe write a short Internet-
   Draft that concludes where we got in the IETF, and what is left for
   the IEEE

3.2.  Updating IETF MIB modules

   [todo - wordsmith] The 802.1 WG sometimes modifies the wording of
   their standards under maintenance PARs.  Modifying the definitions in
   a published MIB module could prove illegal according to the SMI
   rules.  It may be best to expect that the BRIDGE-MIB and the
   P-BRIDGE-MIB and Q-BRIDGE-MIB and RSTP-MIB will remain in the IETF,
   and not be further modified by the IETF.  The IEEE can write a
   separate document that contains updates to their technologies, such
   as 802.1Q, and include a separate MIB module that augments the IETF
   documents.  They will not be able to modify the semantics of existing
   objects, per the SMI, so the IETF will not want to have the 802.1 WG
   publish the existing IETF MIB modules in their documents and
   inadvertently violate the rules of SMI, while following the rules of
   IEEE standards updating.

   [discuss] The 802.1 WG may need to deprecate and obsolete objects in
   the IETF documents.  How does this work without republishing the
   document under an IEEE arc?  Will the IETF publish an updated
   document with the deprecated/obsolete objects?

3.3.  Clarifications

   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.




Harrington                Expires April 9, 2006                 [Page 7]

Internet-Draft             8021 MIB Transition              October 2005


   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
   change the semantics somewhat.  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 the 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.

   For an 802.1 standard that hasn't yet defined a MIB module to
   supersede the IETF MIB module, the need to fix a description in the
   MIB module in a manner that would not be SMI legal would precipitate
   the need to also define an IEEE MIB module. [discuss] would this
   replace the whole IETF MIB module, or just the necessary objects?

   The current practice in the 7802.1 WG is to define the management
   variable and then a mapping table to associated MIB module objects
   (as shown above).  The 802.1 WG could redefine the mapping to a new
   MIB object if the 802.1 management variable semantics changed, thus
   allowing the 802.1 WG to 'do it right' by SMI rules, obsoleting the
   old MIB object and creating a new one.

   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 variables may be
   invented with Web-based services in mind, but today the primarily
   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 management
   variable semantics and obsoleting MIB objects. [discuss] As mentioned
   above, this mapping would not show up in the ASN.1 MIB module; this
   is in the surrounding text.  Should 802 document the mapping info in
   comments in the ASN.1 MIB module (beyond the REFERENCE clause)?

   [discuss] Will the IETF "turn over" the Bridge MIB module
   specifications to the 802.1 WG for maintenance, and thus Bridge MIB
   modules would be subject to the 802.1 rules?  Will the Bridge MIB
   modules be "frozen in time", and updated only via the development of



Harrington                Expires April 9, 2006                 [Page 8]

Internet-Draft             8021 MIB Transition              October 2005


   independent MIB modules developed by the 802.1 WG?  Or will IETF
   maintain ownership of the Bridge MIB modules, and perform maintenance
   on those modules as needed, if requested by the 802.1 WG?  [PC] this
   is really a general question of maintenance of MIB modules that
   aren't currently under the 802 tree.  I would hope we could do this
   in the least intrusive way for the end-user, but if we have to move
   the entire module under the 802 tree to get the necessary editing
   control, then this is what we will have to do.  What does the IETF
   prefer?

3.4.  IANA OID Registration

   The IETF and IEEE 802.1 have separate registration branches in the
   OID tree.  The Bridge MIB modules are registered under the IETF
   branch, and some assignments are maintained by IANA.

   As 802.1 standards are modified, the changes may include needed
   modifications to supplement the existing tables.  In many cases, 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 assigned under the IEEE arc.

   When the changes only require the additional of one or two objects to
   the existing MIB modules, it may be simpler for the 802.1 WG to
   define additional managed objects within the IANA-controlled
   registration tree.  Such additions should probably require approval
   by the Area Directors of Operations and Management after MIB Doctor
   review.  We should write a document similar to RFC3737 for an IANA
   controlled and administered Bridge OID registry. [discuss] Is this
   simpler than defining their own MIB modules using AUGMENTS?  Using an
   IEEE MIB certainly would seem simpler for additional scalars or
   sparse columns to existing tables.

   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.  There will
   certainly be appropriate review by IETF, but I'm hoping the IEEE
   doesn't have to get bogged down by process every time we need an OID
   from IANA. [discuss] Is there going to need to be special casing by
   IANA when we request such an OID?  What is the process?

   [discuss] If the 802.1 WG does their documents, and makes them
   publicly available and if we can check the MIB before it gets
   published, then maybe we can keep the OIDs as they currently are and
   let IEEE do extensions.  But it is clear that in the case that OID
   branches get assigned by IANA, we (IETF) would want to have sign-off
   authority.




Harrington                Expires April 9, 2006                 [Page 9]

Internet-Draft             8021 MIB Transition              October 2005


   [discuss] Tony's expectation would be that in time the 802.1-related
   MIB modules will all migrate to arcs under the 802 registration tree,
   so he would expect them to be defined in a new related table under
   the IEEE branch.  What makes the most sense in terms of supporting
   the MIB modules from the users point of view?  Seems it would be the
   least intrusive to keep the existing trees in place, and supplement
   them with IEEE objects in IEEE arcs.


4.  Mailing List Discussions

   After the Bridge WG is done with its documents, the WG will close,
   but the mailing list will remain open for possible BRIDGE-MIB related
   discussions, such as responding to implementer questions.

   One goal of the transition is to get the IEEE technology experts more
   involved in the related MIB module development.  IETF-comfortable
   people may find the IEEE process uncomfortable, but they need to get
   accustomed to the IEEE process.  Therefore, the Bridge WG chairs will
   discourage discussion of ongoing IEEE MIB module work on the Bridge
   WG list and ask that the discussion be moved to the IEEE list, with a
   notice comparable to:


   Note that this work is out of scope for the Bridge 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/docs2004

   The MSTP-MIB proposals are being collected for 802.1 to prove
   adequate interest and a good-enough-to-start-from-point to decide
   whether the 802.1 WG should accept this as a WG effort.  The
   discussion of the MSTP-MIB will be held on the 802.1 list to allow
   the 802.1 chair to keep it focused on the PAR and 5C justification
   (Cf: charter discussion) rather than on detailed discussions of the
   proposals.  It is important to keep discussions "in scope", and
   discussing the PAR and 5Cs justification is inappropriate for an IETF
   list, and discussing the technology details for a project not in the
   WG charter is usually inappropriate for an IETF list.







Harrington                Expires April 9, 2006                [Page 10]

Internet-Draft             8021 MIB Transition              October 2005


4.1.  Comment Formats

   The IEEE has a special format for comments regarding documents to
   ensure that all comments are reviewed and resolved during the
   meetings.  Informal discussions can be held on the 802.1 mailing
   list, but once the 802.1 WG runs a ballot in 802.1, they would like
   all comments to be submitted in 802.1 comment format.

4.2.  Bridge WG Mailing List Announcements

   If requested by the 802.1 WG chair or vice-chair, the Bridge WG
   chairs will post an announcement that the 802.1 WG is planning to
   start work on developing or updating bridge-related MIB modules and
   is seeking volunteers.

   The Bridge WG chairs watch the 802.1 list, and if something
   significant to the Bridge WG comes up, such as the 802.1 chairs call
   for review of three fairly-stable pre-PAR proposals, or a decision
   needs to be made between three proposals after a PAR has been
   approved, or an official Draft is completed and needs review, then
   the Bridge WG chairs can post the document(s) on the Bridge WG
   mailing list for extra review.


5.  MIB Doctor Reviews

5.1.  Introduction

   The leaders of the Bridge WG, 802.1 WG, IETF O&M area, and IEEE 802
   area have discussed having IETF MIB Doctors review 802 developed MIB
   modules.  This is a loose offering.

   The expectation is that IETF will maintain a group of MIB Doctors who
   can review 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.  It is
   not 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.




Harrington                Expires April 9, 2006                [Page 11]

Internet-Draft             8021 MIB Transition              October 2005


   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, rather than for every
   revision.

5.2.  Review Guidelines

   The IETF has developed a set of "Best Current Practice" MIB review
   guidelines, so editors and other WG members can check the document
   against the guidelines before requesting a MIB Doctor review.  The
   802.1 WG should utilize the MIB review guidelines before requesting a
   MIB Doctor review.

   The MIB review guidelines are 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
   the guidelines 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 the mib-review-guidelines.  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.

   The MIB review guidelines were used when reviewing the 802.1AB
   [IEEE802.1AB]and 802.1AE [IEEE802.1AE]documents.  During those
   reviews, there were some issues found with the review-guidelines that
   we need to evaluate further.

   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.

   There are many IETF-specific aspects of the MIB review guidelines,
   and the IEEE should probably formalize their own guidelines to



Harrington                Expires April 9, 2006                [Page 12]

Internet-Draft             8021 MIB Transition              October 2005


   supplement the IETF guidelines.  For example, an IETF standard MIB
   module must use the approved boilerplates for MIB modules, IANA
   considerations, IPR, and ID-nits that do not directly apply to IEEE
   MIB module work.  For the most part, the IETF guidelines have been
   applied to IEEE MIB modules with minor adjustments, even though the
   IEEE has its own rules of document formatting, IPR, and OID
   assignments.

   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 MIB review 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 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.

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:



Harrington                Expires April 9, 2006                [Page 13]

Internet-Draft             8021 MIB Transition              October 2005


   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, 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 the MIB review guidelines
   without suggesting each replacement object name.  This is an
   important concession to the 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.  In
   addition, since the MIB Modules are usually just one long clause in
   802.1 documents, the comment format is fairly straight forward.  Just
   a problem description, a suggested resolution, and a page and line
   number.  It would be good if comments could be submitted with each
   comment in the preferred format; this makes it easier on the editor
   to understand what is requested, easier to log the comment, and
   easier to review the comment in the meeting environment.  Hopefully,
   the majority of MIB comments can 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



Harrington                Expires April 9, 2006                [Page 14]

Internet-Draft             8021 MIB Transition              October 2005


   review".

   Formally, comments from any origin carry the same weight in 802.1;
   even voting status in the WG doesn't make your comments less 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 personnel can be given the
   password to the website by the 802.1 WG chair, so 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 a generic "MIB Doctor"
   [discuss]

   [discuss] Should MIB Doctor reviews be copied to the 802.1 chair?
   Should MIB Doctor reviews be explicitly requested by the 802.1 chair
   at certain key points in the process?


6.  Communicating the Transition Plan

   The transition plan was discussed in the Bridge WG at IETF61, and
   included a presentation "Bridge MIB Transition to IEEE 802.ppt"
   available in the proceedings.

   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.







Harrington                Expires April 9, 2006                [Page 15]

Internet-Draft             8021 MIB Transition              October 2005


7.  Security Considerations

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


8.  Intellectual Property Considerations

   There is a desire to ensure that the IETF has sufficient rights to do
   derivatives of its own works.

   One example is if we decide, as part of a liaison arrangement with
   another SDO, to hand over maintenance of a specification to them.

   There's at least one current instance of this in discussion; and it
   looks like we have to go and get specific permissions from the
   original authors.  But it isn't a blanket permission - we aren't
   about to relinquish control of RFC 2460 so that anybody can publish
   an IPv6 spec with a few bytes reversed.

   Bernard Aboba will arrange to have the IETF counsel review this
   document and clarify the intellectual property language.


9.  References

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

   [RFC4188]  Norseth, K. and E. Bell, "Definitions of Managed Objects
              for Bridges", RFC 4188, September 2005.

   [I-D.ietf-bridge-ext-v2]
              Harrington, D., "Definitions of Managed Objects for
              Bridges with Traffic Classes, Multicast  Filtering and
              Virtual LAN Extensions", draft-ietf-bridge-ext-v2-07 (work
              in progress), August 2005.

   [I-D.ietf-bridge-rstpmib]
              Bell, E., "Definitions of Managed Objects for Bridges with
              Rapid Spanning Tree  Protocol",
              draft-ietf-bridge-rstpmib-09 (work in progress),
              August 2005.




Harrington                Expires April 9, 2006                [Page 16]

Internet-Draft             8021 MIB Transition              October 2005


9.2.  Informative References

   [IEEE802.1AB]
              "[todo]",  , August 2005.

   [IEEE802.1AE]
              "[todo]",  , August 2005.

   [PAR-IEEE802.1ah]
              "http://standards.ieee.org/board/nes/projects/
              802-1ah.pdf", [todo] .


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
      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
      Schagen 33
      3461 GL Linschoten
      NL





Harrington                Expires April 9, 2006                [Page 17]

Internet-Draft             8021 MIB Transition              October 2005


      +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


Author's Address

   David Harrington (editor)
   Effective Software Consulting
   Harding Rd
   Portsmouth NH
   USA

   Phone: +1 603 436 8634
   Email: dbharrington@comcast.net


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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



Harrington                Expires April 9, 2006                [Page 18]

Internet-Draft             8021 MIB Transition              October 2005


   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 currently provided by the
   Internet Society.





























Harrington                Expires April 9, 2006                [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/