Network Working Group                                 D. Harrington, Ed.
Request for Comments: 4663                 Effective Software Consulting
Category: Informational                                   September 2006
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).




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.

本文件描述了将桥接相关MIB模块的责任从IETF桥接MIB工作组转移到IEEE 802.1工作组的计划,该工作组开发了MIB模块设计用于管理的桥接技术。

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 ....................................................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
1. 介绍

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

本文件描述了将桥接相关MIB模块的责任从IETF桥接MIB工作组转移到IEEE 802.1工作组的计划,该工作组开发了MIB模块设计用于管理的桥接技术。当前的桥MIB工作组文档是

o "Definitions of Managed Objects for Bridges" [RFC4188],

o “桥的托管对象定义”[RFC4188],

o "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol" [RFC4318]

o “具有快速生成树协议的网桥托管对象定义”[RFC4318]

o "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering, and Virtual LAN Extensions" [RFC4363], and

o “具有流量类、多播过滤和虚拟LAN扩展的网桥的托管对象定义”[RFC4363],以及

o "Definitions of Managed Objects for Source Routing Bridges" [RFC1525].

o “源路由桥的托管对象定义”[RFC1525]。

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

本文件旨在建立IETF和IEEE之间关于桥接MIB WG MIB模块向IEEE 802.1 WG过渡的明确预期,以便IESG、IAB、IETF和IEEE可以审查该计划。可能会出现一些个案情况,这些情况将由适当的联络人处理,但本文件描述了总体战略。

1.1. Motivation
1.1. 动机

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.

让SNMP MIB模块为其技术提供管理功能对于802.1社区非常重要,因此它需要将此项工作作为每个新项目的项目授权请求(PAR)的一部分,以确保调动资源来执行。对于已经完成的802.1项目的MIB支持也是如此-维护项目需要包括SNMP MIB模块的开发。

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.

人力问题当然是一个相关的方面。IEEE 802 MIB文档可以在IETF中开发,但前提是主题专家来到IETF参与(领导)工作。内容专家需要更多地参与MIB模块的开发,无论编辑是在IEEE还是在IETF中完成,都需要投入资源来完成工作。IETF认为,如果其他组织(如IEEE 802)自己编写MIB文档,IETF可以接受,并且IETF提供帮助,从SNMP/MIB/管理信息结构(SMI)的角度审查这些文档。即使在过渡之后也是如此,因为高质量的MIB模块对于顺利管理互联网及其运行的技术非常重要。

2. New IEEE MIB Work
2. 新的IEEE MIB工作
2.1. New MIB PARs
2.1. 新型MIB部件
   The IEEE-SA Standards Board New Standards Committee (NesCom) deals
   with the Projects Approval Requests; see  PARs are roughly the
   The IEEE-SA Standards Board New Standards Committee (NesCom) deals
   with the Projects Approval Requests; see  PARs are roughly the

equivalent of IETF Working Group Charters and include information concerning the scope, purpose, and justification for standardization projects.


Following early discussions concerning the transfer of MIB work from the IETF Bridge MIB WG to the IEEE 802.1 WG, the development of SMIv2 MIB modules associated with IEEE 802.1 projects has been included within the scope of the work of new projects.

在关于将MIB工作从IETF桥接MIB工作组转移到IEEE 802.1工作组的早期讨论之后,与IEEE 802.1项目相关的SMIv2 MIB模块的开发已包含在新项目的工作范围内。

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

例如,IEEE 802.1AH、提供商骨干桥的PAR形式[PAR-IEEE802.1AH],包括在第13节“提议项目的范围”中,明确引用“支持管理,包括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.

虽然不是强制性的,MIB开发工作在新的PAR中被明确指定以完成工作(参见IEEE 802.1ab[IEEE802.1Ab]和IEEE802.1Ae[IEEE802.1Ae])中所做的工作,如果需要MIB开发作为标准的一部分,建议IEEE 802.1 WG PAR在范围部分中包含明确的措辞。

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.

由于IETF网桥MIB工作组不打算在未来开发MIB模块,网桥管理领域新工作的提交人应直接提交给IEEE 802.1工作组,并且建议他们不要将其提议的MIB模块发布为互联网草案。

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.

使MIB模块以ASCII格式自由、公开地可用将是使SNMP社区接受802.1 MIB开发从IETF桥接MIB工作组转移到IEEE 802.1工作组的一个关键因素。尽管802.1肯定可以决定仅以用于文档的PDF格式发布MIB模块,而不发布ASCII版本,但大多数网络管理系统可以导入ASCII格式的MIB模块,但不能导入PDF格式的MIB模块。不发布ASCII版本的MIB模块将对MIB模块的实施者和部署者产生负面影响,并使IETF审查MIB模块变得更加困难。

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.

802.1 WG网站需要密码才能访问正在开发的标准。工作组已开始在项目开发期间将其文档中的MIB模块部分作为单独的ASCII文件提供,并允许IETF参与者访问这些文档以进行标准前审查。

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 or

IEEE 802有一项政策,即批准的规范在批准后的前六个月内免费提供,在批准后的六个月内免费提供。一旦规范获得批准,MIB模块的ASCII版本将在802.1 WG网站上免费提供(参见 或

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.

关于免费提供的规范中包含的内容,可能存在一些问题。单是SMIv2 MIB模块可能是不够的;还需要对MIB的结构、与其他MIB模块的关系以及安全注意事项进行一些讨论,以确保在Internet环境中适当实施和部署MIB模块。对于大多数实现者来说,在批准六个月后免费提供的规范就足够了。

2.3. OID Registration for New MIB Modules
2.3. 新MIB模块的OID注册

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

IETF和IEEE 802在对象标识符(OID)树中有单独的注册分支(ARC)。桥接MIB模块在IETF分支下注册,一些分配由IANA维护。IEEE 802 arc的管理记录在[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.

随着IEEE 802.1工作组更新IEEE 802.1标准,变更可能包括对现有表格进行补充所需的修改。这可以通过开发一个IEEE MIB模块来处理,该模块可以扩充现有表,或者重用现有表的索引。新模块可以在802.1注册分支下注册,就像802.1X MIB模块一样。

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.

当更改只需要向现有MIB模块添加一个或两个对象时,802.1 WG在IANA控制的注册树中定义其他托管对象似乎更简单。不建议采用这种方法,因为难以协调两个组织之间的变更,也难以通过流程处理变更,同时尽量为每个组织保持及时。此类增加可能需要在IETF MIB医生审查后获得运营和管理区域总监的批准。这将在两个组织的工作之间创建依赖关系,并且可能为IANA生成特殊情况,以防止IEEE被IETF过程所拖累。

The approach of developing an IEEE MIB module and defining a new compliance clause is simpler than dealing with such dependencies.

开发IEEE MIB模块并定义新的符合性条款的方法比处理此类依赖性更简单。

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. 当前桥MIB工作组文档
3.1. Transferring Current Bridge MIB WG Documents
3.1. 传输当前桥MIB WG文档

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.

在审查与将桥接MIB工作组文件传输至IEEE 802.1工作组相关的法律问题期间,得出结论认为,IETF没有足够的法律权限在未经文件作者同意的情况下进行传输。

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

RFC1286、RFC1493和RFC1525显然先于描述作者授予IETF的版权和知识产权的任何特定IETF文件。RFC2674属于RFC 2026[RFC2026]规则。最近的三次更新[RFC4188]、[RFC4318]和[RFC4363]属于BCP 78,如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.

为了允许他们根据包含BRIDGE-MIB[RFC4188]、P-BRIDGE-MIB、Q-BRIDGE-MIB[RFC4363]和RSTP-MIB[RFC4318]的文件执行衍生工作的维护和开发,IEEE 802.1工作组需要获得作者和/或作者在这些文件中转让其知识产权的公司的许可。

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.

IETF知识产权事务法律顾问和IEEE标准协会标准知识产权经理已就IEEE 802.1工作组使用的样本信函达成一致,以请求作者提供必要的许可,如附录B所示。Bridge MIB工作组主席审查了文件的作者名单,并提供了作者名单及其最后的已知地址,以及与IEEE标准协会标准知识产权经理相关的文件。

The IETF will retain all the rights granted at the time of publication in the published RFCs.


3.2. Updating IETF MIB Modules
3.2. 更新IETF MIB模块

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.

桥MIB工作组文件的更新解决了802.1t、802.1u、802.1v和802.1w中记录的更改。IEEE 802.1工作组将这些修订与802.1D-1998合并,形成802.1D-2004。Bridge MIB工作组没有解决由于文档合并而导致的更改。

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 “autoEdgePort”参数(802.1D-2004第17.3.3条)。

o The BridgeID object.

o BridgeID对象。

o References to 802.1D-1998 were not updated to 802.1D-2004.

o 对802.1D-1998的引用未更新为802.1D-2004。

o Some objects in RFC4363 may have been obsoleted in 802.1D-2004

o RFC4363中的某些对象可能已在802.1D-2004中淘汰

o Description of dot1dPortOutboundAccessPriority seems wrong, but it followed the description in 802.1D-1998.

o Dot1PortOutboundAccessPriority的描述似乎错误,但它遵循了802.1D-1998中的描述。

o An issue was raised concerning dot1dTpPortInFrames and dot1dTpPortOutFrames. This is an issue left over from RFC 1493.

o 提出了一个关于dot1dtpportinframe和dot1dtpportoutframe的问题。这是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.

据认为,IEEE可能能够编写单独的文档,其中包含对其技术的更新,如802.1Q,并包括一个单独的MIB模块来扩充IETF MIB模块。然而,IEEE标准的最新更改预计将要求更改MIB表的索引方式,这在SMI规则下是不允许的,因此IEEE将需要重写MIB模块并在ieee802分支下分配对象标识符。

For backwards compatibility, the existing IETF documents will still be valid and remain unchanged.


If an 802.1 WG document must update or obsolete the IETF version of a Bridge MIB document, the 802.1 WG can create and submit an internet-draft to the IESG to be published as an RFC that points to the openly available IEEE copy and the IEEE standard. The IESG would need to approve the publication of the RFC. The RFC status would be reflected in the RFC-INDEX and also in the database, so it will be reflected on the RFC-Editor web page. Thus, we don't have a problem with synchronization between the copies being published.


3.3. Clarifications on Variables Mapping and Compliance
3.3. 关于变量映射和合规性的澄清

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.

随着802.1 WG处理MIB开发,IEEE标准“管理变量”和相关IEEE MIB模块对象可能会对应,因为许多现有的桥接MIB对象已经对应于802.1管理变量,例如来自802.1Q的管理变量。

Virtual Bridge MIB object IEEE 802.1Q-2003 Reference

虚拟网桥MIB对象IEEE 802.1Q-2003参考

dot1qBase dot1qVlanVersionNumber read bridge vlan config dot1qMaxVlanId read bridge vlan config dot1qMaxSupportedVlans read bridge vlan config dot1qNumVlans dot1qGvrpStatus read/set garp applicant controls

dot1qBase dot1qVlanVersionNumber读取网桥vlan配置dot1qMaxVlanId读取网桥vlan配置dot1qMaxSupportedVlans读取网桥vlan配置DOT1QNUMVLAN dot1qGvrpStatus读取/设置garp申请人控件

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.

IEEE允许以某种方式澄清定义,这种方式实际上可以在某种程度上改变托管变量的语义,例如通过改变范围。SMI规则通常防止更改已定义MIB对象的语义,而不会废弃当前对象,并用具有新描述符和OID注册的对象替换它。预计,一旦IEEE MIB定义和“管理变量”描述在同一文档中,这个问题就会消失,因为IEEE可以以批准的方式同时更新这两个定义。

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.

需要以SMI不合法的方式修复IETF桥接MIB模块中的描述,这将导致需要定义IEEE MIB模块,该模块可能复制和替换整个IETF MIB模块,或者只添加必要的对象。复制IETF MIB模块、更改描述符和重新分配新的IEEE OID将不向后兼容,需要更新现有应用程序以访问新对象。因此,建议不要复制和修改IETF MIB模块,除非确实需要这样做。

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.

802.1工作组中的当前实践是定义管理变量,然后定义到相关MIB模块对象的映射表(如上所示)。如果802.1管理变量语义发生变化,802.1工作组可以重新定义从IEEE管理变量到新IEEE MIB对象的映射,从而允许802.1工作组根据SMI规则“正确操作”,用新的MIB对象补充旧的MIB对象。更新后的映射将反映在补充SMIv2 MIB模块的合规条款中;可能需要在SMIv2 MIB模块中的新对象的description子句中记录旧映射信息。

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
4. 邮件列表讨论

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:

邮件列表将保留一段时间。邮件列表管理员将不鼓励对桥接MIB工作组列表上正在进行的IEEE MIB模块工作进行讨论,并要求将讨论移至IEEE列表,并附上与以下内容类似的通知:

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 To subscribe to the STDS-802-1-L list, go to To see the general information about 802,1, including how they work and how to participate, go to To see presentations on the technology, go to and look in the docs2004, docs2005, and docs2006 directories.

这项工作超出了Bridge MIB WG邮件列表的范围。IEEE 802.1 MIB模块讨论的适当邮件列表为 要订阅STDS-802-1-L列表,请转到 要查看有关802,1的一般信息,包括它们如何工作以及如何参与,请转到 要查看有关该技术的演示,请转到 看看docs2004,docs2005,和docs2006目录。

5. IETF MIB Doctor Reviews
5. IETF MIB医生评论
5.1. Introduction
5.1. 介绍

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.

桥接MIB工作组、802.1工作组、IETF O&M领域和IEEE 802项目的领导人讨论了让IETF MIB医生审查IEEE 802开发的MIB模块。这是一个宽松的提议。

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.

预计IETF将维持一组MIB医生,当MIB医生可用并愿意进行此类审查时,他们可以审查IEEE 802开发的MIB模块。提供技术建议和MIB医生评论是个人MIB医生的选择,决定建议是否被接受的是802.1编辑的意愿和802.1主席的支持。这并不像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.

当队列中有许多IETF MIB文档,并且有一个IEEE MIB模块文档需要审查时,MIB医生可以选择是否接受这样的请求,以及如何确定他们工作的优先级。

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.

建议802.1工作组建立自己的MIB医生审查小组,对MIB模块进行审查,并在请求IETF MIB医生审查之前解决大多数问题。这将有助于802.1工作组避免因依赖IETF MIB医生而导致的延迟,预审查的文件将使IETF MIB医生更容易找到时间执行请求的审查。IETF愿意提供宽松的服务,帮助802.1工作组建立和培训这样一个IEEE MIB医生团队。

5.2. Review Guidelines
5.2. 审查准则

The IETF has developed Guidelines for Authors and Reviewers of MIB Documents [RFC4181] so that authors and other WG members can check their document against the guidelines before requesting a MIB Doctor review. The 802.1 WG editor should use the RFC4181 guidelines before requesting a MIB Doctor review.


RFC4181 also intended to help editors by guiding MIB Doctors, so reviews by different MIB Doctors will remain fairly consistent. Each MIB Doctor has his or her own "pet peeves", and RFC4181 can help an editor know whether a review point is based on the consensus of the MIB Doctors, or on a pet peeve.


Many SMI constraints, IETF editing constraints, and best current practices are discussed in RFC4181. However, many aspects of good MIB design (e.g., table fate-sharing, good index choices) are more art than science and are not discussed in the guidelines. Those might be more useful to other SDOs (and IETF editors) than guidelines relating to IETF boilerplate requirements. The MIB Doctors have discussed starting a design guidelines document.


RFC4181 was used for reviewing the 802.1AB [IEEE802.1AB] and 802.1AE [IEEE802.1AE] documents. During those reviews, there were some anomalies about the IEEE use of the guidelines that we need to evaluate further.


For example, in the IETF boilerplates, some of the terms have different meanings in IETF and IEEE, and different editing style guidelines are being used by the different bodies. It would be good to develop an 802 MIB boilerplate that is consistent with the IETF boilerplate, in purpose if not in terminology.


The IETF uses [RFC4181] as a reference document for IETF documents containing MIB modules. It is recommended that in time IEEE 802.1 WG develop its own guidelines for IEEE MIB modules review. Until this happens, Section 3 (General Documentation Guidelines) and Section 4 (SMIv2 Guidelines) in RFC4181 can be used, with the following exceptions and modifications:

IETF使用[RFC4181]作为包含MIB模块的IETF文件的参考文件。建议IEEE 802.1工作组及时制定自己的IEEE MIB模块审查指南。在此之前,可以使用RFC4181中的第3节(通用文档指南)和第4节(SMIv2指南),但有以下例外和修改:

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 在第3节的介绍性段落中,MIB文件中必须包含的章节列表应根据IEEE需求和风格指南进行调整。

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 第3.1节至第3.4节适用于IETF文件,其中提到可以编辑IETF样板文件,以符合IEEE需求和样式指南。

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 第3.5节(IANA注意事项)不适用,但可替换为IEEE关于命名和OID空间分配的建议。

o Sections 3.6 does not apply.

o 第3.6节不适用。

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 第3.7节(版权声明)不适用,可替换为与IEEE版权规则相对应的文本。例外情况是,文件最初由IETF发布,然后由IEEE接管,在这种情况下,除非文件作者另有约定,否则必须包括有关IETF版权(如第3.7节所述)和IEEE版权的通知。

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 第3.8节(知识产权)不适用,可替换为反映IEEE知识产权规则的通知。

o Sections 4.1 and 4.2 apply as in the IETF document.

o 第4.1节和第4.2节适用于IETF文件。

o Section 4.3 (Naming Hierarchy) applies with changes related to the OID root of the IEEE 802.1 MIB modules.

o 第4.3节(命名层次结构)适用于与IEEE 802.1 MIB模块的OID根相关的更改。

o Sections 4.4 to 4.8 apply as in the IETF document

o 第4.4至4.8节适用于IETF文件

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.

o 第4.9节适用,但如果IETF设计的模块被IEEE接管并继续使用,可能会出现一些有趣的问题。为了符合要求,IEEE应继续在IETF OID空间中工作和维护MIB模块。

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.

IETF MIB文档模板包含所有必需的部分,遵循RFC编辑器指南和MIB审查指南,正在开发中,以帮助编辑器开始开发MIB模块文档。该模板将帮助MIB医生更有效地检查新的MIB模块,方法是提供最新的MIB模块样板,以首选顺序列出各节,建议在某些节中包含哪些内容,以及支持样板文本所需的参考。建议IEEE 802.1工作组根据IEEE编辑指南和RFC4181指南(如适用)建立一个可比较的模板。

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.


The IETF MIB documents include the following text relative to the Internet Management Framework as part of the standard boilerplate:

IETF MIB文件包括以下与互联网管理框架相关的文本,作为标准样板的一部分:

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to Section 7 of RFC 3410 [RFC3410].

有关描述当前互联网标准管理框架的文件的详细概述,请参阅RFC 3410[RFC3410]第7节。

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

托管对象通过虚拟信息存储(称为管理信息库或MIB)进行访问。MIB对象通常通过简单网络管理协议(SNMP)进行访问。MIB中的对象是使用管理信息结构(SMI)中定义的机制定义的。本备忘录规定了符合SMIv2的MIB模块,如STD 58、RFC 2578[RFC2578]、STD 58、RFC 2579[RFC2579]和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.

建议包含MIB模块的IEEE 802.1标准在IEEE文件的MIB部分中包含类似的小节,并在其参考部分中包含适当的参考。

If IEEE 802.1 WG wants to craft its own guidelines, based on RFC4181, it will need to get the author's permission.

如果IEEE 802.1工作组希望根据RFC4181制定自己的指南,则需要获得作者的许可。

5.3. Review Format
5.3. 审查格式

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.




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.

IETF中的MIB医生评审通常通过简单的文本电子邮件完成,通常包含一长串评审意见。MIB Doctor评论有时会提出一般性的设计问题,而不是特定文本的问题,一些MIB Doctor评论提到“全局”问题,例如许多对象没有指定持久性要求。

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.

对于全局问题,IETF MIB医生在进行802.1 MIB模块审查时不需要为每个实例提供替换文本。例如,如果对象的命名在整个文档中没有遵循推荐的约定,MIB医生可以指出RFC4181中的相关条款,而不建议每个替换对象名称。这是IETF MIB医生的一项重要让步,以更好地适应他们评论的性质,尽管这让编辑有责任在没有明确建议更改的情况下修复问题。

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
5.4. 复习重量

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


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

我们不应该给人这样的印象,即IEEE文件已经收到了IETF中所做的有组织、协调和正式的MIB医生审查,如果此类审查是在临时基础上进行的,并且不一定是作为推进过程的一部分。我们需要弄清楚所说的是什么,因为“本文件已通过MIB医生审查”这句话在IETF中有相当大的份量。我们需要澄清是否将审查描述为由“IETF MIB医生”或“IEEE 802 MIB医生”或一般“MIB医生”完成。

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


6. Communicating the Transition Plan
6. 传达过渡计划

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.

过渡计划在IETF61的桥接MIB工作组中进行了讨论,并包括一个演示,“桥接MIB过渡到IEEE 802.ppt”,可在会议记录中获得。

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 new-bridge-mib-transition-1104.ppt, public/docs2005/liaison-ietf-congdon-0705.pdf, and liaison-ietf-congdon-0905.pdf.

在圣安东尼奥、旧金山和加登格罗夫会议上与802.1 WG进行了讨论。演示文稿可在 new-bridge-mib-transition-1104.ppt, public/docs2005/liance-ietf-congdon-0705.pdf,以及 联络-ietf-congdon-0905.pdf。

7. Security Considerations
7. 安全考虑

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.

本文件描述了将MIB模块责任从IETF桥接MIB工作组转移到IEEE 802.1工作组的计划。它不会影响安全。

8. IANA Considerations
8. IANA考虑

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


9. Intellectual Property Considerations
9. 知识产权考虑

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.

如果作者给予另一组创作衍生作品的许可,这与IETF无关(法律上),因为协议仅在作者和另一组之间。因此,没有理由出现ISOC版权,因为新文档不是IETF文档。如果另一个组包含一个注释,说明他们的文档基于RFC XXXX,并且作者可以坚持这样做,如果他们愿意的话,但是IETF在授予权限方面没有正式的角色,因此IETF不能要求指向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.


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.

2006年1月11日,与IEEE标准协会标准知识产权经理Claudio M.Stanziola举行了另一次电话会议,审查法律问题。作为讨论的结果,IETF知识产权问题法律顾问起草了一份样本文件,其他SDO可将其作为指导方针,制作自己关于“如何提问”的文件,以征求作者的许可。该模板包含在本文件附录B中。

Appendix A. Contributors

Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 POB 58173 Tel Aviv, 61581 Israel Phone +972 3-645-8414 EMail:

Dan Romascanu Avaya Atidim科技园,特拉维夫3号楼POB 58173,61581以色列电话+972 3-645-8414电子邮件

Tony Jeffree Chair, 802.1 WG 11A Poplar Grove Sale Cheshire M33 3AX UK Phone: +44 161 973 4278 EMail:

Tony Jeffree主席,802.1 WG 11A杨树林销售柴郡M33 3AX英国电话:+44 161 973 4278电子邮件

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惠普公司802.1 WG副主席HP ProCurve Networking 8000 Foothills Blvd,加利福尼亚州罗斯维尔市南5662号,邮编95747美国电话:+1 916 785 5753电子邮件:Paul。

Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL Phone: +31-348-407-775 EMail:

Bert Wijnen-Lucent Technologies Schagen 33 3461 GL Linschoten NL电话:+31-348-407-775电子邮件

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Phone: +1 425 818 4011 EMail:

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond,WA 98052美国电话:+1 425 818 4011电子邮件

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.

IEEE P802.1工作组希望将IETF RFC XXXX的部分(特别是YYY MIB模块)纳入IEEE标准草案P802.1,并开发、修改和发展这些部分,作为IEEE标准化过程的一部分。

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.

由于在RFC XXXX的开发过程中,IETF标准贡献的作者保留了IETF政策下关于这些贡献的大部分知识产权,并且由于您是上述文件的作者,IEEE特此请求您同意向IEEE提交RFC XXXX中的供款,以纳入IEEE P802.1。请注意,IETF了解并支持此请求。

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"




Normative References


[RFC1525] Decker, E., McCloghrie, K., Langille, P., and A. Rijsinghani, "Definitions of Managed Objects for Source Routing Bridges", RFC 1525, September 1993.

[RFC1525]Decker,E.,McCloghrie,K.,Langille,P.,和A.Rijsinghani,“源路由桥的托管对象定义”,RFC 15251993年9月。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026]Bradner,S.,“互联网标准过程——第3版”,BCP 9,RFC 2026,1996年10月。

[RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.

[RFC3978]Bradner,S.,“IETF在贡献中的权利”,BCP 78,RFC 3978,2005年3月。

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

[RFC4188]Norseth,K.和E.Bell,“网桥托管对象的定义”,RFC 4188,2005年9月。

[RFC4318] Levi, D. and D. Harrington, "Definitions of Managed Objects for Bridges with Rapid Spanning Tree Protocol", RFC 4318, December 2005.

[RFC4318]Levi,D.和D.Harrington,“具有快速生成树协议的网桥托管对象的定义”,RFC 4318,2005年12月。

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

[RFC4363]Levi,D.和D.Harrington,“具有流量类、多播过滤和虚拟LAN扩展的网桥的托管对象定义”,RFC 4363,2006年1月。

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.1AB]“IEEE标准802.1AB-2005,局域网和城域网标准-站点和媒体访问控制连接发现”,IEEE标准802.1AB-2005 IEEE标准,2005年。

[IEEE802.1AE] "IEEE P802.1AE-2006, Draft Standard for Local and metropolitan area networks - Media Access Control (MAC) Security.", private/ae-drafts/d4/802-1ae-d4-0.pdf IEEE Draft, January 2006.

[IEEE802.1AE]“IEEE P802.1AE-2006,局域网和城域网标准草案-媒体访问控制(MAC)安全性。”, private/ae drafts/d4/802-1ae-d4-0.pdf IEEE草案,2006年1月。

[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] " projects/802-1ah.pdf", 802-1ah IEEE PAR, December 2004.

[PAR-IEEE802.1ah]“ 项目/ 802-1AH.PDF“,802-1AH IEEE PAR,2004年12月。

[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

[RFC2578]McCloghrie,K.,Perkins,D.,和J.Schoenwaeld,“管理信息的结构版本2(SMIv2)”,STD 58,RFC 2578,1999年4月。

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

[RFC2580]McCloghrie,K.,Perkins,D.,和J.Schoenwaeld,“SMIv2的一致性声明”,STD 58,RFC 25801999年4月。

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.

[RFC3410]Case,J.,Mundy,R.,Partain,D.,和B.Stewart,“互联网标准管理框架的介绍和适用性声明”,RFC 34102002年12月。

[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.

[RFC4181]Heard,C.,“MIB文件的作者和评审者指南”,BCP 111,RFC 41812005年9月。

Author's Address


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

David Harrington(编辑)美国新罕布什尔州朴茨茅斯哈丁路有效软件咨询公司

   Phone: +1 603 436 8634
   Phone: +1 603 436 8634

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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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




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