GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4663

Network Working Group D. Harrington, Ed. Request for Comments: 4663 Effective Software Consulting Category: Informational September 2006

   Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2006).

Abstract

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

Harrington Informational [Page 1] RFC 4663 802.1 MIB Transition September 2006

Table of Contents

 1. Introduction ....................................................2
    1.1. Motivation .................................................3
 2. New IEEE MIB Work ...............................................3
    2.1. New MIB PARs ...............................................3
    2.2. IEEE MIB Modules in ASCII Format ...........................4
    2.3. OID Registration for New MIB Modules .......................5
 3. Current Bridge MIB WG Documents .................................6
    3.1. Transferring Current Bridge MIB WG Documents ...............6
    3.2. Updating IETF MIB Modules ..................................6
    3.3. Clarifications on Variables Mapping and Compliance .........8
 4. Mailing List Discussions ........................................9
 5. IETF MIB Doctor Reviews .........................................9
    5.1. Introduction ...............................................9
    5.2. Review Guidelines .........................................10
    5.3. Review Format .............................................13
    5.4. Review Weight .............................................14
 6. Communicating the Transition Plan ..............................15
 7. Security Considerations ........................................15
 8. IANA Considerations ............................................15
 9. Intellectual Property Considerations ...........................16
 Appendix A.  Contributors .........................................18
 Appendix B.  Sample Text for IEEE to Request Rights from Authors ..19
 Normative References ..............................................20
 Informative References ............................................20

1. Introduction

 This document describes the plan to transition responsibility for
 bridging-related MIB modules from the IETF Bridge MIB WG to the IEEE
 802.1 WG, which develops the bridging technology the MIB modules are
 designed to manage.  The current Bridge MIB WG documents are
 o  "Definitions of Managed Objects for Bridges" [RFC4188],
 o  "Definitions of Managed Objects for Bridges with Rapid Spanning
    Tree Protocol" [RFC4318]
 o  "Definitions of Managed Objects for Bridges with Traffic Classes,
    Multicast Filtering, and Virtual LAN Extensions" [RFC4363], and
 o  "Definitions of Managed Objects for Source Routing Bridges"
    [RFC1525].

Harrington Informational [Page 2] RFC 4663 802.1 MIB Transition September 2006

 This document is meant to establish some clear expectations between
 IETF and IEEE about the transition of Bridge MIB WG MIB modules to
 the IEEE 802.1 WG, so that the plan can be reviewed by the IESG, IAB,
 IETF, and IEEE.  Some case-by-case situations might arise, which will
 be handled by the appropriate liaisons, but this document describes
 the general strategy.

1.1. Motivation

 Having SNMP MIB modules to provide management functionality for its
 technologies is important for the 802.1 community, so it needs to
 charter this work as part of the Project Authorization Requests
 (PARs) for each new project, to ensure that resources are being
 mobilized for execution.  This is also true with respect to MIB
 support for already completed 802.1 projects - maintenance projects
 need to include the development of SNMP MIB modules.
 The IESG has mandated that IETF WGs that produce a protocol are also
 required to develop the corresponding MIB module rather than leave
 that to "the SNMP experts" to do later.  Part of the motivation was
 obviously to make the protocols more manageable, but part of the
 motivation was also balancing the workload better and getting the
 content experts more involved in the management design.  If such work
 comes into the IETF from other standards development organizations
 (SDOs), then we encourage the other SDO to bring in subject 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

Harrington Informational [Page 3] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 4] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 5] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 6] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 7] RFC 4663 802.1 MIB Transition September 2006

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.

Harrington Informational [Page 8] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 9] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 10] RFC 4663 802.1 MIB Transition September 2006

 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.

Harrington Informational [Page 11] RFC 4663 802.1 MIB Transition September 2006

 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
    copyrights (as described in 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 be 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.

Harrington Informational [Page 12] RFC 4663 802.1 MIB Transition September 2006

 The IETF MIB documents include the following text relative to the
 Internet Management Framework as part of the standard boilerplate:
    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 its own guidelines, based on RFC4181,
 it 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 on 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.

Harrington Informational [Page 13] RFC 4663 802.1 MIB Transition September 2006

 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
 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 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 according to 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 to 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 one's comments more weighty
 than those of 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 that comments 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

Harrington Informational [Page 14] RFC 4663 802.1 MIB Transition September 2006

 from the 802.1 private website.  IETF participants can be given the
 password to the website by the 802.1 WG chair, so that 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 by 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.

Harrington Informational [Page 15] RFC 4663 802.1 MIB Transition September 2006

9. Intellectual Property Considerations

 On November 29, 2005, a teleconference was held that included Jorge
 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
 create derivative works within the IETF standard process.  The
 author(s) retain all of 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, he
 or she 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 its own versions of the RFC, 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 authors can insist on that if
 they want to, but the IETF has no formal role in granting
 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 if 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.

Harrington Informational [Page 16] RFC 4663 802.1 MIB Transition September 2006

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

Harrington Informational [Page 17] RFC 4663 802.1 MIB Transition September 2006

Appendix A. Contributors

 Dan Romascanu
 Avaya
 Atidim Technology Park, Bldg. #3
 POB 58173
 Tel Aviv, 61581
 Israel
 Phone +972 3-645-8414
 EMail: dromasca@avaya.com
 Tony Jeffree
 Chair, 802.1 WG
 11A Poplar Grove
 Sale
 Cheshire M33 3AX
 UK
 Phone: +44 161 973 4278
 EMail: 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
 Phone: +1 916 785 5753
 EMail: paul.congdon@hp.com
 Bert Wijnen
 Lucent Technologies
 Schagen 33
 3461 GL Linschoten
 NL
 Phone: +31-348-407-775
 EMail: bwijnen@lucent.com
 Bernard Aboba
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA 98052
 US
 Phone: +1 425 818 4011
 EMail: bernarda@microsoft.com

Harrington Informational [Page 18] RFC 4663 802.1 MIB Transition September 2006

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 kindly to sign and return, granting the
 aforementioned rights to the IEEE.
 Sincerely yours, IEEE"

Harrington Informational [Page 19] RFC 4663 802.1 MIB Transition September 2006

References

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]          Levi, D. 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.

Informative References

 [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
                    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.
 [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.
 [PAR-IEEE802.1ah]  "http://standards.ieee.org/board/nes/
                    projects/802-1ah.pdf", 802-1ah IEEE PAR, December
                    2004.

Harrington Informational [Page 20] RFC 4663 802.1 MIB Transition September 2006

 [RFC2578]          McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                    "Structure of Management Information Version 2
                    (SMIv2)", STD 58, RFC 2578, April 1999.
 [RFC2579]          McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                    "Textual Conventions for SMIv2", STD 58, RFC 2579,
                    April 1999.
 [RFC2580]          McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                    "Conformance Statements for SMIv2", STD 58, RFC
                    2580, April 1999.
 [RFC3410]          Case, J., Mundy, R., Partain, D., and B. Stewart,
                    "Introduction and Applicability Statements for
                    Internet-Standard Management Framework", RFC 3410,
                    December 2002.
 [RFC4181]          Heard, C., "Guidelines for Authors and Reviewers
                    of MIB Documents", BCP 111, RFC 4181, September
                    2005.

Author's Address

 David Harrington (editor)
 Effective Software Consulting
 Harding Rd
 Portsmouth NH
 USA
 Phone: +1 603 436 8634
 EMail: dbharrington@comcast.net

Harrington Informational [Page 21] RFC 4663 802.1 MIB Transition September 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.

Acknowledgement

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

Harrington Informational [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4663.txt · Last modified: 2006/09/05 23:44 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki