RFC 4663

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

📅 published September 2006, from ietf

RFC 4663: Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG ✨

Okay bestie, here's the vibe check. This is an Informational doc, dated September 2006, written by D. Harrington, Ed. from Effective Software Consulting 💼. It's from the Network Working Group. The title block doesn't list anything it obsoletes or updates, so there's no drama there 🫶.

Status of This Memo 📜

This memo gives information to the Internet community. It does not specify an Internet standard of any kind, so no pressure, it's just good info 💅. Distribution of this memo is unlimited 🌸.

Copyright (C) The Internet Society (2006). 🎀

Abstract 🦋

Okay so the big idea: this doc lays out the plan for moving responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group over to the IEEE 802.1 Working Group. Why IEEE 802.1? Because they're the ones who build the bridging technology those MIB modules are designed to manage, so it's giving "the right people, finally" 👑.

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 🌷

So this doc is all about transitioning responsibility for bridging-related MIB modules from the IETF Bridge MIB WG to the IEEE 802.1 WG, which builds the bridging tech those MIB modules manage 🧚. The current Bridge MIB WG documents are:

  • "Definitions of Managed Objects for Bridges" [RFC4188],
  • "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol" [RFC4318]
  • "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions" [RFC4363], and
  • "Definitions of Managed Objects for Source Routing Bridges" [RFC1525].

The purpose here is to set clear expectations between the IETF and IEEE about moving Bridge MIB WG MIB modules to the IEEE 802.1 WG 🤝. That way the IESG, IAB, IETF, and IEEE can all review the plan. Some case-by-case situations might pop up, and the appropriate liaisons will handle those, but this doc sketches the overall strategy 💜.

1.1. Motivation 💪

Having SNMP MIB modules for its technologies is a big deal for the 802.1 community 📈. So they need to charter this work as part of the Project Authorization Requests (PARs) for each new project, so resources actually get mobilized for execution. The same goes for MIB support on 802.1 projects that are already finished: maintenance projects need to include developing SNMP MIB modules too 🔧.

The IESG has mandated that IETF WGs producing a protocol are also required to develop the matching MIB module, instead of leaving it to "the SNMP experts" to do later 📋. Part of the reason is obviously to make protocols more manageable, but part of it is balancing the workload better and getting the content experts more involved in the management design 🙌. If this kind of work comes into the IETF from other standards development organizations (SDOs), then the IETF encourages that SDO to bring in subject matter expertise to work with us, or, even better, to take the lead themselves 🦸.

The manpower problem is definitely a real factor 😅. IEEE 802 MIB documents could be developed in the IETF, but only if the subject matter experts come to the IETF to participate in (lead) the work. The content experts need to be more involved in MIB module development, and resources need to be dedicated to finishing the work, whether the editing happens in the IEEE or the IETF 💅. The IETF finds it acceptable if other organizations (like IEEE 802) write MIB documents themselves, and the IETF offers to help review them from an SNMP/MIB/Structure of Management Information (SMI) perspective 🫶. This stays 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) handles the Projects Approval Requests. You can find them at http://standards.ieee.org/board/nes/. PARs are roughly the equivalent of IETF Working Group Charters, and they include info about the scope, purpose, and justification for standardization projects 🧾.

After early discussions about moving MIB work from the IETF Bridge MIB WG to the IEEE 802.1 WG, SMIv2 MIB modules tied to IEEE 802.1 projects got included in the scope of new projects. The latest Project Approval Requests (PAR) for 802.1 projects, starting with P802.1ah (Provider Backbone Bridges), approved in December 2004, include explicit text about this 👀.

For example, the PAR form of IEEE 802.1ah, Provider Backbone Bridges [PAR-IEEE802.1ah], has an explicit reference to 'support management including SNMP' in Section 13, "Scope of Proposed Project" 🎯.

It's not mandatory that MIB development be spelled out explicitly in a new PAR for the work to get done. See the work done in IEEE 802.1AB [IEEE802.1AB] and IEEE 802.1AE [IEEE802.1AE] for examples 🌈. Still, it is recommended that IEEE 802.1 WG PARs include explicit wording in the scope section wherever MIB development is needed 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. It should also 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 ASCII format is a critical factor in getting the SNMP community to accept the transfer of 802.1 MIB development from the IETF Bridge MIB WG to the IEEE 802.1 WG 💖. Sure, 802.1 can totally decide to publish MIB modules only in the PDF format they use for their documents. But without an ASCII version, most network management systems can't import the MIB module, since they can import ASCII but not PDF 🙃. Not publishing an ASCII version would hurt implementers and deployers of MIB modules, and it would make IETF review of MIB modules harder 😤.

The 802.1 WG web site requires a password to access standards in development 🔐. The WG has started making the MIB module portion of their documents available as separate ASCII files during project development, and they let IETF participants access these for pre-standard review 🍓.

IEEE 802 has a policy where approved specifications cost a fee for the first six months after approval, and then they're freely available six months after approval 💸. Once the spec 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 not be enough. Some discussion of the MIB's structure, its relationship to other MIB modules, and security considerations will also need to be made available, so the MIB module can be implemented and deployed properly within the Internet environment 🛡️. For most implementers, though, 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 modifications needed 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, the same way the 802.1X MIB module was 🧩.

When the changes only require adding one or two objects to the existing MIB modules, it may seem simpler for the 802.1 WG to define additional managed objects inside the IANA-controlled registration tree 🤷‍♀️. This approach is not recommended, though, because coordinating changes between the two organizations is hard, and so is pushing changes through both processes while staying timely for each one ⏰. Such additions would probably need approval by the Area Directors of Operations and Management after IETF MIB Doctor review. That would create dependencies between the work of the two organizations, and it might create special cases for IANA, just so the IEEE doesn't get bogged down by IETF processes 😵‍💫.

Developing an IEEE MIB module and defining a new compliance clause is simpler than dealing with those dependencies 💅.

We need a balance between disruption to existing implementations and efficiency in making changes ⚖️. Keeping the existing trees where they are minimizes disruption to existing implementations 🫧.

3. Current Bridge MIB WG Documents 📚

3.1. Transferring Current Bridge MIB WG Documents 💌

okay so there's some legal drama here 🍿 While the team was reviewing the legal issues of moving Bridge MIB WG documents over to the IEEE 802.1 WG, they concluded that the IETF doesn't have enough legal authority to make that transfer without the consent of the document authors. 😭

RFC1286, RFC1493, and RFC1525 apparently came out before any specific IETF document described the copyright and intellectual property rights that authors grant to the IETF. RFC2674 falls under the RFC 2026 [RFC2026] rules. The three newer updates, [RFC4188], [RFC4318], and [RFC4363], fall under BCP 78, as documented in RFC3978 [RFC3978]. 📜

So if the IEEE 802.1 WG wants to keep maintaining and making derivative works from documents with the BRIDGE-MIB [RFC4188], P-BRIDGE-MIB, Q-BRIDGE-MIB [RFC4363], and RSTP-MIB [RFC4318], they'll need permission from the authors and/or the companies the authors gave their intellectual property rights to. 🙏

The IETF legal counsel for IPR matters and the IEEE Standards Association Manager of Standards Intellectual Property agreed on a sample letter the 802.1 WG can use to ask the authors for those permissions. It's shown in Appendix B. ✉️ The Bridge MIB WG chairs also went through the author lists and handed the IEEE Standards Association Manager the authors, their last known addresses, and which documents each one was linked to. 🗂️

The IETF keeps all the rights it was granted at the time of publication in the published RFCs. 🔒

3.2. Updating IETF MIB Modules 🛠️

The updates to the Bridge MIB WG documents covered changes from 802.1t, 802.1u, 802.1v, and 802.1w. The IEEE 802.1 WG then merged those amendments with 802.1D-1998 to make 802.1D-2004. The Bridge MIB WG didn't address the changes that came out of that merger. 🤷‍♀️

The 802.1 WG will need to go through the management objects in the existing documents and check whether they still match new emerging specs, including 802.1D-2004. There were some issues at the end of the Bridge MIB WG's work that they chose not to resolve, so those can be handled as part of the 802.1 WG's future work. 🧩

Work on the following items was deferred to the IEEE:

  • The autoEdgePort parameter (802.1D-2004 clause 17.3.3).
  • The BridgeID object.
  • References to 802.1D-1998 were not updated to 802.1D-2004.
  • Some objects in RFC4363 may have been obsoleted in 802.1D-2004.
  • The description of dot1dPortOutboundAccessPriority seems wrong, but it followed the description in 802.1D-1998.
  • An issue was raised concerning dot1dTpPortInFrames and dot1dTpPortOutFrames. This is an issue left over from RFC 1493.

It was thought the IEEE might be able to write separate documents updating its own technologies, like 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 that the way the MIB tables are INDEXED be changed, and that isn't 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 has to 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 RFC points to the openly available IEEE copy and the IEEE standard. The IESG would need to approve publishing the RFC. The RFC status gets reflected in the RFC-INDEX and in the database, so it shows up on the RFC-Editor web page too. Thus, there's no synchronization problem 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. Lots of existing BRIDGE-MIB objects already correspond to 802.1 management variables, like 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 way that can actually change the semantics of a managed variable a bit, like 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 that has a new descriptor and OID registration. The good news is that once both an IEEE MIB definition and the "managed variable" descriptions live in the same document, this problem should disappear, since IEEE can update both at the same time in the approved manner. 🎉

If you need to fix a description in an IETF Bridge MIB module in a way that isn't SMI legal, you'd end up needing an IEEE MIB module. It might copy and replace the whole IETF MIB module, or it might just add the necessary objects. Copying the IETF MIB module, changing the descriptors, and reassigning new IEEE OIDs would not be backwards compatible, so existing applications would need updates 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, then add a mapping table to the associated MIB module objects (as shown above). If the 802.1 management variable semantics ever change, the 802.1 WG could redefine the mapping from an IEEE managed variable to a new IEEE MIB object. That lets the 802.1 WG "do it right" by SMI rules by supplementing the old MIB object with a new one. An updated mapping would show up in the compliance clause of the supplemental SMIv2 MIB module, and it may be desirable to document the old mapping information in the description clause of the new object in that module. 🪄

Often, the mapping of 802 variables to MIB objects isn't 1:1, and it doesn't have to be. 🤓 In the future, 802.1 variables may be invented with Web-based services in mind. Today, though, the main focus is on SNMP usage, and putting MIB modules into the specs themselves will likely keep that focus going. The level of redirection that exists today between 802 variables and MIB objects might come in handy during the transition when 802.1 management variable semantics change and MIB objects get supplemented. 🦋

The existing Bridge documents represent the current state of bridging management, and they contain compliance clauses describing the current requirements for compliance with the IETF standards. As the IEEE develops additional 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. So the plan is that the current Bridge MIB modules will be "frozen in time", and only updated through the development of independent MIB modules by the 802.1 WG. 🧊💜

4. Mailing List Discussions 📬

The Bridge MIB WG has finished its documents, and the WG has been closed. 🎀

The mailing list will stay open for a while. The mailing list administrators will discourage discussion of ongoing IEEE MIB module work on the Bridge MIB WG list, and they'll ask that the discussion move to the IEEE list. They'll post a notice comparable to this one:

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, the 802.1 WG, the IETF O&M area, and the IEEE 802 project have talked about having IETF MIB Doctors review IEEE 802 developed MIB modules. This is a loose offering. 🤝

The expectation is that the IETF will maintain a group of MIB Doctors who can review IEEE 802 - developed MIB modules, whenever a MIB Doctor is available and willing to do the review. It's up to each individual MIB Doctor whether to provide technical advice and MIB Doctor reviews. Whether the advice gets accepted depends on the willingness of the 802.1 editors and the support of the 802.1 chairs. 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. That usually happens when the documents start coming up for WG Last Call, IETF Last Call, and certainly no later than when they show up on the IESG agenda. 😅 This demand means the area directors have to prioritize requests for MIB Doctor reviews, and the MIB Doctors have to prioritize when deciding whether to accept a request to review documents. 🗓️

When there are lots of IETF MIB documents in the queue and an IEEE MIB module document comes along for review, it's up to each individual MIB Doctor whether to accept the request and how to prioritize their work. 🙃

It will help MIB Doctors if the 802.1 chair requests a review early in development. The ideal time is after a MIB module design has been established but before an editor has done much detailing of the MIB module. That way, a MIB Doctor can make sure the table relationships and indexing are reasonable. After that, it will also help 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 set up its own MIB Doctor review team to review MIB modules and resolve most issues before requesting a review from the IETF MIB Doctors. This will help the 802.1 WG avoid delays caused by depending on IETF MIB Doctors. Pre-reviewed documents will also make it easier for an IETF MIB Doctor to find time for 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 📋✨

okay so the IETF wrote the Guidelines for Authors and Reviewers of MIB Documents [RFC4181] so authors and other WG members can check their doc against them before asking for a MIB Doctor review 🫶 The 802.1 WG editor should use the RFC4181 guidelines before requesting a MIB Doctor review.

RFC4181 also helps editors by guiding the MIB Doctors, so reviews from different doctors stay fairly consistent 💅 Every MIB Doctor has their own pet peeves 🙈 and RFC4181 can help an editor tell whether a review point reflects MIB Doctor consensus or just a pet peeve.

A lot of SMI constraints, IETF editing constraints, and best current practices are covered in RFC4181. BUT 😭 many parts of good MIB design (like table fate-sharing and good index choices) are more art than science, and the guidelines don't cover them. Those topics might be more useful to other SDOs (and IETF editors) than the IETF boilerplate rules are. The MIB Doctors have talked about starting a design guidelines document 🌸

RFC4181 was used to review 802.1AB [IEEE802.1AB] and 802.1AE [IEEE802.1AE]. During those reviews, some anomalies showed up in how the IEEE used the guidelines, and we need to look into them more 🔍

For example, some terms in the IETF boilerplates mean different things in the IETF and the IEEE, and the two bodies use different editing style guidelines. It would be great to make an 802 MIB boilerplate that matches the IETF one in purpose, even if the terminology is different 🦋

The IETF uses [RFC4181] as a reference for IETF documents that contain MIB modules. The plan is that over time, the IEEE 802.1 WG develops its own guidelines for reviewing IEEE MIB modules. Until that happens, Section 3 (General Documentation Guidelines) and Section 4 (SMIv2 Guidelines) of RFC4181 can be used, with these exceptions and changes:

  • 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.
  • Sections 3.1 through 3.4 apply as in the IETF document, with the note that the IETF boilerplate could be edited to comply with the IEEE needs and style guide.
  • Section 3.5 (IANA Considerations) does not apply, but it may be replaced by a section with IEEE recommendations on naming and OID space assignments.
  • Section 3.6 does not apply.
  • Section 3.7 (Copyright Notices) does not apply and may be replaced with text matching the IEEE copyright rules. The exception is when a document was originally issued by the IETF and then taken over by the IEEE. In that case, unless the document authors agree otherwise, notices about the IETF copyrights (as described in Section 3.7) and the IEEE copyrights must be included 📜
  • Section 3.8 (Intellectual Property) does not apply and may be replaced with a notice that reflects the IEEE intellectual property rules.
  • Sections 4.1 and 4.2 apply as in the IETF document.
  • Section 4.3 (Naming Hierarchy) applies, with changes related to the OID root of the IEEE 802.1 MIB modules.
  • Sections 4.4 to 4.8 apply as in the IETF document
  • Section 4.9 applies, but some interesting problems may come up if IETF-designed modules are taken over and continued by the IEEE. To comply with the requirement, the IEEE should keep working on and maintaining the MIB module in the IETF OID space 🧚

There's also an IETF MIB document template under development. It contains all the required sections, follows the RFC Editor guidelines and the MIB review guidelines, and helps editors get started on a MIB module document. It 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 put in certain sections, and the references needed to support the boilerplate text 💖 It's recommended that the IEEE 802.1 WG set up a comparable template that follows the IEEE editing guidelines and the RFC4181 guidelines, where appropriate.

Such an IEEE template could just be the management clause of an 802.1 document, filled in with technology-specific information. In 802.1AB, the MIB clause was restructured to include modified IETF boilerplates and security considerations, so that could be a good start for an IEEE template 🌈 It would also help MIB Doctors and editors if the unmodified template were available in ASCII format, so they could automatically compare it to a document in development and check that the right boilerplate text is being used.

When the 802.1 WG creates a PAR for 802.1 Bridge MIB maintenance, the creation of this template might be included in the PAR.

The IETF MIB documents include the following text about 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's recommended that IEEE 802.1 standards that contain MIB modules include a similar sub-section in the MIB section of the IEEE document, along with the appropriate references in their reference section 📚

If the IEEE 802.1 WG wants to write 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 comment template 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 usually done in plain text email and often contain a long list of review comments. Sometimes a MIB Doctor review raises a general design issue rather than a problem with specific text. Some MIB Doctor comments refer to "global" problems, like lots of objects that don't specify persistence requirements 🫠

For global problems, IETF MIB Doctors aren't required to provide replacement text for every single instance when they do 802.1 MIB module reviews. For example, if object naming doesn't follow the recommended conventions throughout the document, the MIB Doctor can point to the relevant clause in RFC4181 without suggesting every replacement object name. This is an important concession to the IETF MIB Doctors, so the reviews fit the nature of their work, even though it 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 the problem and how to fix it. Comments should include a problem description, a suggested resolution, and a page and line number. It would be really helpful if comments were submitted in the preferred format, since that makes it easier for the editor to see exactly what's being requested, log the comment for review, and go over it in the meeting environment 🎀 Most 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 or IESG requests a MIB Doctor review. Failing the review can stop a document from moving forward in standardization, at the discretion of the area director. MIB Doctors take their role seriously and do detailed reviews 🔥

In the IEEE, the board that approves a standard is separate from the 802.1 WG, and the reviews MIB Doctors do under this transition plan happen within the 802.1 WG. So a MIB Doctor review in the 802.1 WG is more like an IETF WG chair asking a MIB Doctor to sanity-check the work, rather than a formal "MIB Doctor review" 🧐

Formally, comments from any source carry the same weight in 802.1. Even voting status in the WG doesn't make someone's comments weightier than those of a non-voter. The 802.1 WG is not permitted to ignore any comments, no matter where they come from. Serious comments are always taken seriously and never ignored 🫶

The IEEE typically requires comments to be officially submitted in a specific format that includes proposed replacement text. Those comments are then reviewed at the meetings, and the decisions are written up in disposition documents. These comments and dispositions are available on the 802.1 private website, and the 802.1 WG chair can give IETF participants the password 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 formal MIB Doctor review that the IETF does, if that review is done ad hoc and isn't necessarily part of the advancement process. We need to be clear about what we say, because the phrase "This document has passed MIB Doctor review" carries a lot of weight in the IETF 🚨 We need to clarify whether reviews should be described as done by an "IETF MIB Doctor" or an "IEEE 802 MIB Doctor", or by a generic "MIB Doctor".

MIB Doctor reviews are to 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, with a presentation called "Bridge MIB Transition to IEEE 802.ppt", which is available in the proceedings 🎞️

The intent to transition was also posted on the Bridge MIB WG mailing list when the Bridge MIB WG closure notices went out, 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. The presentations are available at 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 ✨

okay so on November 29, 2005 there was a teleconference with Jorge Contreras, Scott Bradner, Bernard Aboba, Bert Wijnen, and David Harrington to talk through the intellectual property issues 🧠 here's the tea on what they concluded:

The IETF/ISOC gets a non-exclusive copyright license from RFC authors. That lets the IETF publish RFCs, lets third parties translate RFCs into other languages, lets third parties reproduce RFCs as-is, and lets them make derivative works inside the IETF standard process 📚 The author(s) keep all of their rights, except the right to take back that permission for the IETF to do the above 🔐

If anyone (including the IEEE) wants to reproduce an RFC as-is, they can do it without asking for specific permission. But it has to be "as-is," and that includes the ISOC copyright notice 💅 The reason is that the right for third parties to reproduce RFCs is one of the rights the IETF gets from the author(s), so the notice stays attached.

The author(s) of an RFC can tell another group (for example, the IEEE) that the group can make its own versions of the RFC. The IETF doesn't get the right from the author(s) to stop them, so the IETF can't block it 🙈

If the author(s) give another group permission to make derivative works, that's legally between the author(s) and that group, so it has nothing (legally) to do with the IETF 🫶 Because the new document isn't an IETF document, there's no reason for an ISOC copyright to show up on it. It would be nice if the other group included a note saying 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 that pointer 🌸

There's a desire to make sure the IETF has enough rights to make derivatives of its own work 👑 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 that other SDO permission to create derivative works, the IETF still keeps the permission the authors granted to create derivative works within the IETF standard process. Main character energy for the IETF, honestly ✨

The IETF strongly recommends that any derivative works made by another standards body DO acknowledge that the work builds on prior IETF work, with reference to the RFC(s) it derives from 🦋 MIB modules that follow the IETF Best Current Practices documented in RFC4181 contain REVISION clauses that record how and where earlier versions were published 📝

Then on January 11, 2006 there was another teleconference to review the legal issues with Claudio M. Stanziola, the IEEE Standards Association Manager of Standards Intellectual Property 🤝 As a result, the IETF Legal Counsel on IPR matters wrote a sample document that other SDOs can use as a guideline for "how to ask the question" when they want to get authors' permission. The template is in Appendix B of this document 💖

Appendix A. Contributors ✨

These are the amazing people who helped make this happen 🫶 Here they are with their contact info, exactly as written:

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

Appendix B. Sample Text for IEEE to Request Rights from Authors 💌

This is the sample letter that other SDOs can use when they want to ask authors for rights 🌈 Copied exactly as written:

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

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.

[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 🖊️

The editor of this document is David Harrington. His details are below:

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

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

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. It also doesn't claim to have made any independent effort to identify any such rights. Information on the procedures for 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 send that 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). Thank you for reading, bestie! 🌈✨

📦 where this page comes from