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
将MIB工作从IETF网桥MIB WG传输到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).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes the plan to transition responsibility for bridging-related MIB modules from the IETF Bridge MIB Working Group to the IEEE 802.1 Working Group, which develops the bridging technology the MIB modules are designed to manage.
本文件描述了将桥接相关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
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可以审查该计划。可能会出现一些个案情况，这些情况将由适当的联络人处理，但本文件描述了总体战略。
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.
IESG已经规定，产生协议的IETF工作组也必须开发相应的MIB模块，而不是将其留给“SNMP专家”以后去做。部分动机显然是为了使协议更易于管理，但部分动机也是为了更好地平衡工作量，让内容专家更多地参与管理设计。如果其他标准开发组织（SDO）将此类工作纳入IETF，那么我们鼓励其他SDO引入主题专家与我们合作，或者更好的是，自己带头。
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模块对于顺利管理互联网及其运行的技术非常重要。
The IEEE-SA Standards Board New Standards Committee (NesCom) deals
with the Projects Approval Requests; see
http://standards.ieee.org/board/nes/. PARs are roughly the
The IEEE-SA Standards Board New Standards Committee (NesCom) deals
with the Projects Approval Requests; see
http://standards.ieee.org/board/nes/. PARs are roughly the
equivalent of IETF Working Group Charters and include information concerning the scope, purpose, and justification for standardization projects.
等同于IETF工作组章程，包括关于标准化项目的范围、目的和理由的信息。
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.
从2004年12月批准的P802.1ah（提供商主干网桥）开始，802.1项目的最新项目批准请求（PAR）包括这方面的明确文本。
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模块发布为互联网草案。
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 http://www.ieee802.org/1/files/public/MIBs/ or http://www.ieee802.org/1/pages/MIBS.html).
IEEE 802有一项政策，即批准的规范在批准后的前六个月内免费提供，在批准后的六个月内免费提供。一旦规范获得批准，MIB模块的ASCII版本将在802.1 WG网站上免费提供（参见http://www.ieee802.org/1/files/public/MIBs/ 或http://www.ieee802.org/1/pages/MIBS.html).
There may be some issues about what gets included in the freely available specification. The SMIv2 MIB module alone will probably be insufficient; some discussion of the structure of the MIB, the relationship to other MIB modules, and security considerations will also need to be made available to ensure appropriate implementation and deployment of the MIB module within the Internet environment. For most implementers, the freely available specification six months after approval will be adequate.
关于免费提供的规范中包含的内容，可能存在一些问题。单是SMIv2 MIB模块可能是不够的；还需要对MIB的结构、与其他MIB模块的关系以及安全注意事项进行一些讨论，以确保在Internet环境中适当实施和部署MIB模块。对于大多数实现者来说，在批准六个月后免费提供的规范就足够了。
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.
我们需要在对现有实现的中断和进行更改的效率之间取得平衡。将现有的树保留在适当的位置可以最大限度地减少对现有实现的中断。
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.
IETF将保留在发布的RFC中发布时授予的所有权利。
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.
802.1工作组需要通过现有文件中的管理对象来确定它们是否符合新出现的规范，包括802.1D-2004。在桥接MIB工作组中对这些文档进行最后工作期间，有一些问题我们决定不解决，这使得它们可以作为802.1工作组未来工作的一部分来处理。
Work on the following items was deferred to the IEEE:
以下项目的工作推迟至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.
为了向后兼容，现有的IETF文件仍然有效且保持不变。
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.
如果802.1工作组文件必须更新或淘汰网桥MIB文件的IETF版本，则802.1工作组可以创建并向IESG提交互联网草案，以RFC形式发布，该草案指向公开可用的IEEE副本和IEEE标准。IESG需要批准RFC的发布。RFC状态将反映在RFC索引和数据库中，因此它将反映在RFC编辑器网页上。因此，我们在正在发布的副本之间的同步方面没有问题。
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 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
dot1qBase dot1qVlanVersionNumber 12.10.1.1读取网桥vlan配置dot1qMaxVlanId 12.10.1.1读取网桥vlan配置dot1qMaxSupportedVlans 12.10.1.1读取网桥vlan配置DOT1QNUMVLAN dot1qGvrpStatus 12.9.2.1/2读取/设置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.
通常，802变量到MIB对象的映射不是1:1映射，也不一定是1:1映射。在未来，802.1变量可能是在考虑基于Web的服务的情况下发明的，但今天的主要重点是SNMP的使用，将MIB模块纳入规范本身可能会进一步突出这一重点。当更改802.1管理变量语义并补充MIB对象时，802变量和MIB对象之间存在的重定向级别对于转换过程可能很有用。
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.
现有桥接文件代表桥接管理的当前状态，文件包含描述符合IETF标准的当前要求的合规条款。随着IEEE开发额外的MIB模块，新的合规条款将定义新的“最新状态”，而无需淘汰旧的MIB对象或旧的合规条款。因此，计划是，当前的桥接MIB模块将“及时冻结”，并仅通过802.1工作组开发独立的MIB模块进行更新。
The Bridge MIB WG has completed its documents, and the WG has been closed.
桥梁MIB工作组已完成其文件，工作组已关闭。
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 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.
这项工作超出了Bridge MIB WG邮件列表的范围。IEEE 802.1 MIB模块讨论的适当邮件列表为STDS-802-1-L@listserv.ieee.org. 要订阅STDS-802-1-L列表，请转到http://www.ieee802.org/1/email-pages/ 要查看有关802,1的一般信息，包括它们如何工作以及如何参与，请转到http://www.ieee802.org/1/ 要查看有关该技术的演示，请转到http://www.ieee802.org/1/files/public/ 看看docs2004，docs2005，和docs2006目录。
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.
在IETF中，运维区域主管在开始工作组最后一次呼叫、IETF最后一次呼叫时，以及在不晚于他们出现在IESG议程上时，被其他区域主管“催促”让MIB医生审查MIB模块文件。该要求要求区域总监对MIB医生审核请求进行优先排序，并要求MIB医生在决定是否接受文件审核请求时进行优先排序。
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.
如果802.1主席在MIB模块设计完成后，但在编辑器对MIB模块进行详细说明之前，在开发早期请求审查，这将有助于MIB医生，以便MIB医生能够确保表关系和索引合理。如果802.1主席只要求对重要投票（如赞助商投票）进行审查，而不是对每一次修订进行审查，这将是有益的。
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医生团队。
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.
IETF已经为MIB文件的作者和审查者制定了指南[RFC4181]，以便作者和其他工作组成员在请求MIB医生审查之前可以对照指南检查他们的文件。802.1工作组编辑器应在请求MIB医生审查之前使用RFC4181指南。
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.
RFC4181还旨在通过指导MIB医生来帮助编辑，因此不同MIB医生的评论将保持相当一致。每个MIB医生都有自己的“宠物脾气”，RFC4181可以帮助编辑了解评论点是基于MIB医生的共识，还是基于宠物脾气。
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中讨论了许多SMI约束、IETF编辑约束和当前最佳实践。然而，好的MIB设计的许多方面（例如，表命运共享、好的索引选择）更多的是艺术而不是科学，指南中没有讨论。与IETF样板要求相关的指南相比，这些指南对其他SDO（和IETF编辑器）可能更有用。MIB的医生们已经讨论过开始一份设计指南文件。
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.
RFC4181用于审查802.1AB[IEEE802.1AB]和802.1AE[IEEE802.1AE]文件。在这些审查期间，IEEE对指南的使用存在一些异常情况，我们需要进一步评估。
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.
例如，在IETF样板中，一些术语在IETF和IEEE中有不同的含义，不同的机构使用不同的编辑风格指南。最好开发一个与IETF样板一致的802-MIB样板，如果不是在术语上，也是在目的上。
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.
这样的IEEE模板可能只是802.1文档的管理条款，用特定于技术的信息填充。在802.1AB中，对MIB条款进行了重组，以包括修改后的IETF样板和安全注意事项。这可能是这样一个IEEE模板的良好开端。如果未修改的模板以ASCII格式提供，以便与开发中的文档进行自动比较，从而验证是否使用了适当的样板文本，这将有助于MIB医生和编辑。
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.
当802.1个WG为802.1个桥MIB维护创建PAR时，这样的模板的创建可能包含在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制定自己的指南，则需要获得作者的许可。
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.
802.1工作组使用以下格式的评论模板，因此提供新文本的责任在于审阅者，而不是编辑。
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:
名称：评论类型：[E=编辑，ER=需要编辑][T=技术，TR=需要技术]条款：页码：行：评论开始：评论结束：建议更改开始：建议更改结束：
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.
在过渡期间，802.1工作组的主席和副主席愿意接受简单的电子邮件，只要他们提供足够的信息来了解问题所在以及如何解决问题。评论应包括问题描述、建议的解决方案以及页码和行号。如果评论以首选格式提交，这将很有帮助，因为这使编辑更容易准确地理解所请求的内容，记录评论以供审阅，并在会议环境中审阅评论。大多数MIB评论通常可以在官方投票过程之外处理。
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.
在IETF中，MIB医生评审是标准批准过程的一部分。当文件作为标准提交给IESG审批时，区域总监/IESG要求MIB医生审查。未通过审查可能会阻止标准化过程中文件的前进，由区域主管决定。MIB医生认真对待他们的角色，并进行详细审查。
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".
在IEEE中，批准标准的委员会独立于802.1工作组，MIB医生将根据该过渡计划进行的审查在802.1工作组内完成。因此，802.1工作组中的MIB医生审查类似于IETF工作组主席要求MIB医生检查工作是否正常，而不是正式的“MIB医生审查”。
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.
在形式上，任何来源的评论在802.1中都具有相同的权重；即使是工作组中的投票身份也不会使一个人的评论比非投票人的评论更重要。802.1工作组不允许忽略任何评论，无论其来源如何。严肃的评论总是被认真对待，从不被忽视。
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
IEEE通常要求以特定格式正式提交意见，包括建议的替换文本，然后在会议上进行审查，并将决定记录在处置文件中。这些评论和处置是可用的
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.
来自802.1私人网站。IETF参与者可以通过802.1工作组主席获得网站密码，以便他们可以查看以前和当前的评论和处置。
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.
MIB医生评论将被复制到文档编辑器和802.1椅子上。
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.
在桥梁MIB工作组关闭通知期间，包括2006年2月15日工作组行动公告期间，过渡意图也被张贴在桥梁MIB工作组邮件列表上。
The transition was discussed with the 802.1 WG at the San Antonio, San Francisco, and Garden Grove meetings. Presentations are available in http://www.ieee802.org/1/files/public/docs2004/ new-bridge-mib-transition-1104.ppt, http://www.ieee802.org/1/files/ public/docs2005/liaison-ietf-congdon-0705.pdf, and http://www.ieee802.org/1/files/public/docs2005/ liaison-ietf-congdon-0905.pdf.
在圣安东尼奥、旧金山和加登格罗夫会议上与802.1 WG进行了讨论。演示文稿可在http://www.ieee802.org/1/files/public/docs2004/ new-bridge-mib-transition-1104.ppt，http://www.ieee802.org/1/files/ public/docs2005/liance-ietf-congdon-0705.pdf，以及http://www.ieee802.org/1/files/public/docs2005/ 联络-ietf-congdon-0905.pdf。
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工作组的计划。它不会影响安全。
Although this document discusses issues related to IANA assignment of OIDs, no IANA actions are required by this document.
尽管本文件讨论了与OID的IANA分配相关的问题，但本文件不要求IANA采取任何行动。
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:
2005年11月29日，举行了一次电话会议，与会者包括豪尔赫·孔特雷拉斯、斯科特·布拉德纳、伯纳德·阿博巴、伯特·维恩和大卫·哈林顿，讨论知识产权问题。以下是结论摘要：
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.
IETF/ISOC从RFC作者处获得非排他性版权许可，以便IETF可以发布RFC，让第三方将RFC翻译成其他语言，让第三方按原样复制RFC，并在IETF标准流程内创建衍生作品。作者保留除撤销IETF执行上述操作的许可之外的所有权利。
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).
如果任何人（包括IEEE）希望按原样复制任何RFC，他或她可以不经任何特定许可，但必须按原样复制（包括ISOC版权通知），因为第三方复制RFC的权利是IETF从作者处获得的权利的一部分。
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.
RFC的作者可以告诉另一个组（如IEEE），另一个组可以制作自己的RFC版本，因为IETF没有从作者那里获得阻止他们这样做的权利。
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.
人们希望确保IETF有足够的权利对自己的作品进行衍生。如果IETF决定，作为与另一SDO的联络安排的一部分，将规范的维护移交给他们，并且如果作者给予另一SDO创建衍生作品的许可，IETF仍然保留作者授予的在IETF标准流程内创建衍生作品的许可。
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.
IETF强烈建议由另一标准机构开发的任何衍生作品确认该作品建立在IETF之前的作品之上，并参考该作品衍生的RFC。符合RFC4181中记录的IETF最佳现行实践的MIB模块包含修订条款，记录早期版本的发布方式/发布地点。
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中。
Dan Romascanu Avaya Atidim Technology Park, Bldg. #3 POB 58173 Tel Aviv, 61581 Israel Phone +972 3-645-8414 EMail: dromasca@avaya.com
Dan Romascanu Avaya Atidim科技园，特拉维夫3号楼POB 58173，61581以色列电话+972 3-645-8414电子邮件：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
Tony Jeffree主席，802.1 WG 11A杨树林销售柴郡M33 3AX英国电话：+44 161 973 4278电子邮件：tony@jeffree.co.uk
Paul Congdon Vice Chair, 802.1 WG Hewlett Packard Company HP ProCurve Networking 8000 Foothills Blvd, M/S 5662 Roseville, CA 95747 US Phone: +1 916 785 5753 EMail: paul.congdon@hp.com
Paul Congdon惠普公司802.1 WG副主席HP ProCurve Networking 8000 Foothills Blvd，加利福尼亚州罗斯维尔市南5662号，邮编95747美国电话：+1 916 785 5753电子邮件：Paul。congdon@hp.com
Bert Wijnen Lucent Technologies Schagen 33 3461 GL Linschoten NL Phone: +31-348-407-775 EMail: bwijnen@lucent.com
Bert Wijnen-Lucent Technologies Schagen 33 3461 GL Linschoten NL电话：+31-348-407-775电子邮件：bwijnen@lucent.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Phone: +1 425 818 4011 EMail: bernarda@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond，WA 98052美国电话：+1 425 818 4011电子邮件：bernarda@microsoft.com
> "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.
随函附上一份版权许可证模板，我们恳请您签字并返还，授予IEEE上述权利。
Sincerely yours, IEEE"
你诚挚的，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.
[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.", http://www.ieee802.org/1/files/ private/ae-drafts/d4/802-1ae-d4-0.pdf IEEE Draft, January 2006.
[IEEE802.1AE]“IEEE P802.1AE-2006，局域网和城域网标准草案-媒体访问控制（MAC）安全性。”，http://www.ieee802.org/1/files/ 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.
[IEEE.802b]电气和电子工程师协会，“局域网和城域网：概述和体系结构，修改件2：对象标识符的注册”，IEEE标准802，2004年。
[PAR-IEEE802.1ah] "http://standards.ieee.org/board/nes/ projects/802-1ah.pdf", 802-1ah IEEE PAR, December 2004.
[PAR-IEEE802.1ah]“http://standards.ieee.org/board/nes/ 项目/ 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.
《埃尔德·斯密克标准》，1999年4月，第25R页，第79页。
[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
EMail: dbharrington@comcast.net
Phone: +1 603 436 8634
EMail: dbharrington@comcast.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（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中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。