Network Working Group B. Aboba, Ed.
Request for Comments: 4441 Internet Architecture Board
Category: Informational March 2006
Network Working Group B. Aboba, Ed.
Request for Comments: 4441 Internet Architecture Board
Category: Informational March 2006
The IEEE 802/IETF Relationship
ieee802/IETF关系
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
摘要
Since the late 1980s, IEEE 802 and IETF have cooperated in the development of Simple Network Management Protocol (SNMP) MIBs and Authentication, Authorization, and Accounting (AAA) applications. This document describes the policies and procedures that have developed in order to coordinate between the two organizations, as well as some of the relationship history.
自20世纪80年代末以来，IEEE 802和IETF一直在合作开发简单网络管理协议（SNMP）MIB和身份验证、授权和计费（AAA）应用程序。本文档描述了为协调两个组织而制定的政策和程序，以及一些关系历史。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Liaison Communications .....................................2
1.2. Access to IEEE 802 Archives ................................3
1.3. New Work Review ............................................3
1.4. MIB Review .................................................4
1.5. EAP Review .................................................4
1.6. AAA Review .................................................5
1.7. Document Review ............................................5
1.8. EtherType Allocation .......................................6
2. Security Considerations .........................................6
3. Informative References ..........................................7
4. Acknowledgements ...............................................12
Appendix A. Relationship History .................................13
A.1. MIB Development ..........................................13
A.2. AAA/EAP ..................................................16
Appendix B. IAB Members at the Time of This Writing ..............21
1. Introduction ....................................................2
1.1. Liaison Communications .....................................2
1.2. Access to IEEE 802 Archives ................................3
1.3. New Work Review ............................................3
1.4. MIB Review .................................................4
1.5. EAP Review .................................................4
1.6. AAA Review .................................................5
1.7. Document Review ............................................5
1.8. EtherType Allocation .......................................6
2. Security Considerations .........................................6
3. Informative References ..........................................7
4. Acknowledgements ...............................................12
Appendix A. Relationship History .................................13
A.1. MIB Development ..........................................13
A.2. AAA/EAP ..................................................16
Appendix B. IAB Members at the Time of This Writing ..............21
Since the late 1980s, participants in IEEE 802 and the IETF have
cooperated in the development of Management Information Bases (MIBs)
and Authentication, Authorization, and Accounting (AAA) applications
relating to IEEE standards. This has included the Bridge MIB
[RFC1493] [RFC4188], the multicast filtering and VLAN extension MIB
[RFC2674] [RFC4363], the Hub MIB [RFC2108], the Ethernet-like
Interfaces MIB [RFC3635], the MAU MIB [RFC3636], the WAN Interfaces
Sublayer MIB [RFC3637], the Power Ethernet MIB [RFC3621], IEEE 802.1X
RADIUS usage guidelines [RFC3580], the revised Extensible
Authentication Protocol (EAP) specification [RFC3748], RADIUS/EAP
[RFC3579], and the EAP State Machine specification [RFC4137]. This
document describes the policies and procedures that have been put in
place to encourage cooperation between the IETF and IEEE 802.
Details of the relationship history are included in Appendix A.
Since the late 1980s, participants in IEEE 802 and the IETF have
cooperated in the development of Management Information Bases (MIBs)
and Authentication, Authorization, and Accounting (AAA) applications
relating to IEEE standards. This has included the Bridge MIB
[RFC1493] [RFC4188], the multicast filtering and VLAN extension MIB
[RFC2674] [RFC4363], the Hub MIB [RFC2108], the Ethernet-like
Interfaces MIB [RFC3635], the MAU MIB [RFC3636], the WAN Interfaces
Sublayer MIB [RFC3637], the Power Ethernet MIB [RFC3621], IEEE 802.1X
RADIUS usage guidelines [RFC3580], the revised Extensible
Authentication Protocol (EAP) specification [RFC3748], RADIUS/EAP
[RFC3579], and the EAP State Machine specification [RFC4137]. This
document describes the policies and procedures that have been put in
place to encourage cooperation between the IETF and IEEE 802.
Details of the relationship history are included in Appendix A.
In order to improve communications between the IETF and IEEE 802, members of the Internet Engineering Steering Group (IESG) and Internet Architecture Board (IAB) (including Bert Wijnen, James Kempf, and Bernard Aboba) met with the IEEE 802 Executive Committee in Vancouver, Canada, in January 2004. At that meeting, a number of issues were discussed and new procedures were put in place.
为了改善IETF和IEEE 802之间的通信，互联网工程指导小组（IESG）和互联网体系结构委员会（IAB）的成员（包括伯特·维恩、詹姆斯·肯普夫和伯纳德·阿博巴）于2004年1月在加拿大温哥华会见了IEEE 802执行委员会。在那次会议上，讨论了一些问题，并制定了新的程序。
IETF Working Groups are organized into areas, which have one or more Area Directors. The Area Directors, plus the IETF Chair, comprise the Internet Engineering Steering Group (IESG). IEEE 802 Working Groups have one or more Task Groups. The IEEE 802 Working Group Chairs, plus the IEEE 802 Chair, comprise the IEEE 802 Executive Committee (ExComm).
IETF工作组分为多个区域，其中有一个或多个区域主管。区域总监以及IETF主席组成了互联网工程指导小组（IESG）。IEEE 802工作组有一个或多个任务组。IEEE 802工作组主席和IEEE 802主席组成IEEE 802执行委员会（ExComm）。
Participants in the IETF are appointed as liaisons to other organizations by the IAB or IESG as appropriate. This includes a liaison to IEEE 802 as well as liaisons to specific IEEE 802 Working Groups. The IETF liaison web page includes a list of IETF liaisons, as well as a pointer to the archive of liaison statements received by the IETF [Liaison-Page]. IETF processes for management of liaison relationships are described in [BCP102]; procedures for handling of incoming liaison statements are described in [BCP103]. In order to ensure that liaison statements from IEEE 802 to the IETF are archived and responded to, IEEE 802 liaisons to IETF should utilize the IETF liaison management tool to submit liaison communications. A username and password suitable for use with the tool can be obtained by sending mail to iesg-secretary@ietf.org. If a liaison management account is not available, liaison communications can be sent to the IETF liaison(s) to IEEE 802 and copied to statements@ietf.org.
IETF的参与者由IAB或IESG（视情况而定）指定为与其他组织的联络人。这包括与IEEE 802的联络以及与特定IEEE 802工作组的联络。IETF联络网页包括IETF联络人列表，以及指向IETF收到的联络声明档案的指针【联络页】。[BCP102]中描述了IETF联络关系管理流程；[BCP103]中描述了接收联络声明的处理程序。为了确保从IEEE 802到IETF的联络声明得到存档和响应，IEEF的IEEE 802联络应使用IETF联络管理工具提交联络通信。通过向iesg发送邮件，可以获得适合与该工具一起使用的用户名和密码-secretary@ietf.org. 如果联络管理账户不可用，联络通信可发送至IETF联络至IEEE 802，并复制至statements@ietf.org.
However, in this case substantially greater processing delays will occur due to the need for manual handling by the IETF Secretariat staff.
然而，在这种情况下，由于IETF秘书处工作人员需要手动处理，因此会出现更大的处理延迟。
Liaison requests from the IETF to IEEE 802 should be sent to the Chair(s) of the IEEE 802 WG to which the request pertains, with a copy sent to the IEEE 802 Chair and the IEEE 802 liaison(s) to IETF. IEEE 802 procedures for communicating with other standards bodies are described in Section 14.1 of [Policy]. Liaison communications to IEEE 802 WGs are archived by the individual WGs.
IETF向IEEE 802发出的联络请求应发送至该请求所属的IEEE 802工作组主席，并将副本发送至IEEE 802主席和IETF的IEEE 802联络人。[政策]第14.1节描述了与其他标准机构通信的IEEE 802程序。与IEEE 802工作组的联络通信由各个工作组存档。
Access to IEEE 802 standards more than six months old is provided free of charge on the IEEE 802 website via the Get IEEE 802 Program [GetIEEE-802]. Access to IEEE 802 work-in-progress has frequently arisen as an issue in cooperation between IETF and IEEE 802. While in the past IETF Working Groups (WGs) have successfully negotiated access to IEEE 802 work-in-progress, each instance has been handled separately and took significant time and effort to complete. In order to more easily enable document access for IETF WGs collaborating with IEEE 802, a liaison statement was sent to the IETF in July 2004 by Paul Nikolich, Chair of IEEE 802 [IEEE-802Liaison], describing the process by which IETF WGs can obtain access to IEEE 802 work-in-progress. IEEE 802 WG Chairs have the authority to grant membership in their WGs, and can use this authority to grant membership to an IETF WG chair upon request. The IETF WG chair will be provided with access to the username/password for the IEEE 802 WG archives, and is permitted to share that information with participants in the IETF WG. Since it is possible to participate in IETF without attending meetings, or even joining a mailing list, IETF WG chairs will provide the information to anyone who requests it. However, since IEEE 802 work-in-progress is copyrighted, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted.
IEEE 802网站上通过Get IEEE 802计划[GetIEEE-802]免费提供对超过六个月的IEEE 802标准的访问。在IETF和IEEE802之间的合作中，访问IEEE802正在进行的工作经常出现问题。虽然在过去，IETF工作组（WG）已经成功地协商了对正在进行的IEEE 802工作的访问，但每个实例都是单独处理的，需要花费大量的时间和精力才能完成。为了更容易地使IETF工作组能够访问与IEEE 802合作的文件，IEEE802[IEEE-802Liaison]主席Paul Nikolich于2004年7月向IETF发送了一份联络声明，描述了IETF工作组可以访问正在进行的IEEE 802工作的过程。IEEE 802工作组主席有权授予其工作组成员资格，并可根据请求使用此权限授予IETF工作组主席成员资格。IETF工作组主席将有权访问IEEE 802工作组档案的用户名/密码，并被允许与IETF工作组的参与者共享该信息。由于可以在不参加会议甚至不加入邮件列表的情况下参与IETF，IETF工作组主席将向任何请求信息的人提供信息。然而，由于IEEE 802正在进行的工作受版权保护，因此不允许将材料纳入IETF文档或在邮件列表或网站上发布用户名/密码。
In order to enable IEEE 802 review of proposed IETF WG charters, as well as to enable IETF review of proposed IEEE 802 Project Authorization Requests (PARs), the New Work mailing list is used. The IEEE 802 Executive Committee is subscribed to the list, so that it can receive proposed IETF WG Charters. Proposed IEEE 802 PARs are posted to the New Work list as well. Where a New Work announcement is of particular interest, it is also (manually) forwarded to the relevant IETF and IEEE 802 mailing lists.
为了使IEEE 802能够审查提议的IETF工作组章程，以及使IETF能够审查提议的IEEE 802项目授权请求（PAR），使用了新的工作邮件列表。IEEE 802执行委员会签署了该清单，以便其能够收到提议的IETF工作组章程。提议的IEEE 802 PAR也发布到新的工作列表中。如果对新的工作公告特别感兴趣，还（手动）将其转发至相关的IETF和IEEE 802邮件列表。
However, by the time an IETF WG Charter or IEEE 802 PAR appears on New Work, a IETF BOF or IEEE 802 "Call for Interest" has already occurred, interest has been demonstrated and considerable work has gone into development of the Charter or PAR. If problems are found at that point, it is often too late in the process to make major changes. Therefore, where a potential work item is likely to be controversial, discussions between IETF and IEEE 802 are encouraged to occur earlier in the process.
然而，当IETF WG宪章或IEEE 802 PAR出现在新的工作时，IETF BOF或IEEE 802“呼吁利益”已经发生，利益已经被证明，并且已经制定了大量的工作来发展章程或PAR。如果在这一点上发现了问题，那么在这个过程中做出重大改变往往为时已晚。因此，如果潜在的工作项目可能会引起争议，则鼓励IETF和IEEE 802在该过程的早期进行讨论。
With travel budgets under pressure, it has become increasingly difficult for companies to fund employees to attend both IEEE 802 and IETF meetings. As a result, an alternative is needed to past arrangements that involved chartering MIB work items within an IETF WG. In order to encourage wider review of MIBs developed by IEEE 802 WGs, it is recommended that Simple Network Management Protocol (SNMP) MIBs developed in IEEE 802 follow the MIB guidelines [RFC4181] and be reviewed as part of the IETF SNMP quality control process ('MIB Doctors'). An IEEE 802 group may request assignment of a 'MIB Doctor' to assist in a MIB review by contacting the IETF Operations and Management Area Director.
由于差旅预算面临压力，公司越来越难以资助员工参加IEEE 802和IETF会议。因此，需要一种替代方案，以取代过去涉及在IETF工作组内租用MIB工作项的安排。为了鼓励对IEEE 802 WGs开发的MIB进行更广泛的审查，建议在IEEE 802中开发的简单网络管理协议（SNMP）MIB遵循MIB指南[RFC4181]，并作为IETF SNMP质量控制过程（“MIB医生”）的一部分进行审查。IEEE 802组可通过联系IETF运行和管理区域总监，请求指派“MIB医生”协助MIB审查。
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the SNMP quality control process, the IETF and IEEE 802 seek to ensure quality while decreasing overhead. A trial run of this process has taken place in IEEE 802.1 where a MIB Doctor (David Harrington) has agreed to review IEEE 802.1 MIBs. Currently, discussion is under way on how change control of selected IEEE 802.1 MIB documents published as RFCs can be transferred to IEEE 802.1 [MIB-TRANSFER].
通过仅在IEEE 802内标准化IEEE 802 MIB，同时利用SNMP质量控制过程，IETF和IEEE 802寻求在降低开销的同时确保质量。该过程的试运行已在IEEE 802.1中进行，MIB医生（David Harrington）已同意审查IEEE 802.1 MIB。目前，正在讨论如何将作为RFC发布的选定IEEE 802.1 MIB文档的更改控制转移到IEEE 802.1[MIB-TRANSFER]。
Several IEEE 802 standards, including [IEEE-802.1X-2004], [IEEE-802.11i], and [IEEE-802.16e], depend on EAP [RFC3748] and EAP key management, described in [KEYFRAME]. Rather than developing their own EAP methods, or extensions for EAP key management, IEEE 802 working groups should send a liaison letter to the IETF, outlining the required functionality or requesting a review of draft text. Most recently, a security review of IEEE 802.16e D8 [EAPREVIEW] has been carried out by the EAP WG, at the request of the IEEE 802.16 Chair, Roger Marks [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2].
一些IEEE 802标准，包括[IEEE-802.1X-2004]、[IEEE-802.11i]和[IEEE-802.16e]，依赖于[KEYFRAME]中描述的EAP[RFC3748]和EAP密钥管理。IEEE 802工作组不应开发自己的EAP方法或EAP密钥管理扩展，而应向IETF发送一封联络信，概述所需的功能或要求审查草案文本。最近，应IEEE 802.16主席Roger Marks[IEEE-802.16-联络1][IEEE-802.16-联络2]的请求，EAP工作组对IEEE 802.16e D8[EAPREVIEW]进行了安全审查。
IEEE 802 WGs requiring new AAA applications should send a liaison request to the IETF. Where new attributes are required rather than a new application, an Internet-Draft can be submitted and review can be requested from AAA-related WGs such as the AAA or RADEXT WGs. For attributes of general utility, and particularly those useful in multiple potential applications, allocation from the IETF standard attribute space is preferred to creation of IEEE 802 Vendor-Specific Attributes (VSAs). As noted in [RFC3575]:
需要新AAA应用程序的IEEE 802 WGs应向IETF发送联络请求。如果需要新的属性而不是新的申请，则可以提交互联网草稿，并可以向AAA相关工作组（如AAA或RADEXT工作组）请求审查。对于通用属性，尤其是在多个潜在应用中有用的属性，从IETF标准属性空间进行分配比创建IEEE 802供应商特定属性（VSA）更可取。如[RFC3575]所述：
RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful.
RADIUS为特定于供应商的扩展（属性26）定义了一种机制，应鼓励使用该机制，而不是为特定于一家供应商的RADIUS实现的功能分配全局属性类型，在这种情况下，互操作性被认为是没有用的。
Where allocation of VSAs are required, it is recommended that IEEE 802 create a uniform format for all of IEEE 802, rather than having each IEEE 802 group create their own VSA format. The VSA format defined in [IEEE-802.11F] is inappropriate for this, since the Type field is only a single octet, allowing for only 255 attributes. Recently, the AAA Doctors list has been created within the IETF Operations and Management Area Directorate, serving a similar function to the MIB Doctors. While the AAA Doctors have not yet been called upon to assist with and review AAA work outside of the IETF, this group could potentially be of assistance to IEEE 802 working groups requiring help with AAA.
如果需要分配VSA，建议IEEE 802为所有IEEE 802创建统一的格式，而不是让每个IEEE 802组创建自己的VSA格式。[IEEE-802.11F]中定义的VSA格式不适用于此，因为类型字段仅为一个八位字节，仅允许255个属性。最近，在IETF运营和管理区域董事会内创建了AAA医生名单，其职能与MIB医生类似。虽然AAA医生尚未被要求协助和审查IETF之外的AAA工作，但该小组可能对需要AAA帮助的IEEE 802工作组提供帮助。
With the areas of cooperation between IEEE 802 and IETF increasing, the document review process has extended beyond the traditional subjects of SNMP MIBs and AAA. For example, as part of the IETF CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP Taxonomy Document [RFC4118]; Dorothy Stanley organized an ad hoc group for this purpose. IEEE 802.11 has also reviewed [IDSEL] and [IABLINK]. Within IETF, IEEE 802 comments are resolved using normal WG and IETF processes.
随着IEEE 802和IETF之间合作领域的增加，文档审查过程已经超出了传统的SNMP MIB和AAA主题。例如，作为IETF CAPWAP工作组章程的一部分，IEEE 802.11被要求审查CAPWAP分类文件[RFC4118]；多萝西·斯坦利为此组织了一个特设小组。IEEE 802.11还审查了[IDSEL]和[IABLINK]。在IETF中，IEEE 802评论使用正常的工作组和IETF过程来解决。
IETF participants can comment as part of the IEEE 802 ballot process, regardless of their voting status within IEEE 802. Comments must be composed in the format specified for the ballot, and submitted by the ballot deadline.
IETF参与者可以作为IEEE 802投票过程的一部分进行评论，而不管他们在IEEE 802中的投票状态如何。评论必须按照投票规定的格式撰写，并在投票截止日期前提交。
The EtherType field is very limited, so that allocations are made solely on an "as needed" basis. For related uses, a single EtherType should be requested, with additional fields serving as sub-protocol identifiers, rather than applying for multiple EtherTypes. EtherType allocation policy is described in [TYPE-TUT].
EtherType字段非常有限，因此只能根据“需要”进行分配。对于相关用途，应请求单个EtherType，并使用附加字段作为子协议标识符，而不是应用多个EtherType。EtherType分配策略在[TYPE-TUT]中描述。
While a fee is normally charged by IEEE 802 for the allocation of an EtherType, IEEE 802 will consider waiving the fee for allocations relating to an IETF standards track document, based on a request from the IESG.
虽然IEEE 802通常收取费用来分配以太网类型，但IEEE 802将考虑基于IESG的请求放弃与IETF标准轨道文件有关的分配费用。
As IEEE 802 becomes increasingly involved in the specification of standards for link-layer security, experience has shown that it is helpful to obtain outside review of work-in-progress prior to publication. This has proven somewhat challenging since access to IEEE 802 work-in-progress documents is often tightly controlled. For example, special permission had to be obtained for IEEE 802.11i to be able to circulate a version of its security standard-in-progress for review. A liaison between an IEEE 802 group and an IETF WG can help in obtaining the necessary level of review.
随着IEEE 802越来越多地参与到链路层安全标准的规范中，经验表明，在发布之前获得对正在进行的工作的外部审查是有帮助的。事实证明，这有点挑战性，因为对IEEE 802在建工作文档的访问通常受到严格控制。例如，IEEE 802.11i必须获得特殊许可，才能分发其正在进行的安全标准版本以供审查。IEEE 802小组和IETF工作组之间的联络有助于获得必要的审查级别。
Experience has also shown that IETF standards may not be written to the level of clarity required by the IEEE 802 standards process. In the case of EAP [RFC3748], the process of developing the EAP state machine specification [RFC4137] proved useful in uncovering aspects requiring clarification, and the joint review process exposed IEEE 802 and IETF documents-in-progress to wider review than might otherwise have been possible.
经验还表明，IETF标准可能没有达到IEEE 802标准过程所要求的清晰程度。在EAP[RFC3748]的案例中，开发EAP状态机规范[RFC4137]的过程被证明有助于发现需要澄清的方面，联合审查过程将IEEE 802和IETF文件暴露在更广泛的审查范围之外。
Similarly, the development of [IEEE-802.11i], [RFC3748], [KEYFRAME], and [RFC4017] led to a deeper understanding of the limitations and security vulnerabilities of the EAP/AAA system. As described in [Housley], it is not advisable to develop new AAA key management applications without completing a security analysis, such as the analysis provided in [KEYFRAME].
类似地，[IEEE-802.11i]、[RFC3748]、[KEYFRAME]和[RFC4017]的开发使人们对EAP/AAA系统的局限性和安全漏洞有了更深入的了解。如[Housley]所述，不建议在未完成安全分析（如[KEYFRAME]中提供的分析）的情况下开发新的AAA密钥管理应用程序。
Due to weaknesses in the RADIUS specification [RFC2865], it is relatively easy for protocol extensions to introduce serious security vulnerabilities. As a result, IETF review of IEEE 802 RADIUS extensions is advisable, and the RADIUS IANA Considerations [RFC3575] have been revised so as to require such a review in most cases.
由于RADIUS规范[RFC2865]的缺陷，协议扩展相对容易引入严重的安全漏洞。因此，IETF对IEEE 802 RADIUS扩展的审查是可取的，并且RADIUS IANA注意事项[RFC3575]已经修改，以便在大多数情况下需要进行此类审查。
[BCP102] Daigle, L. and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.
[BCP102]Daigle，L.和互联网架构委员会，“IETF联络关系管理的IAB流程”，BCP 102，RFC 4052，2005年4月。
[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.
[BCP103]Trowbridge，S.，Bradner，S.，和F.Baker，“处理进出IETF的联络声明的程序”，BCP 103，RFC 4053，2005年4月。
[EAPREVIEW] EAP WG letter to Roger Marks, June 2005, http://www.drizzle.com/~aboba/EAP/review.txt.
[EAP审查]EAP工作组致Roger Marks的信函，2005年6月，http://www.drizzle.com/~aboba/EAP/review.txt。
[GetIEEE-802] IEEE Standards Association Get IEEE 802 (R) Program, http://standards.ieee.org/getieee802/portfolio.html.
[GetIEEE-802]IEEE标准协会获得IEEE 802（R）计划，http://standards.ieee.org/getieee802/portfolio.html.
[IDSEL] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, January 2006.
[IDSEL]Adrangi，F.，Lortz，V.，Bari，F.，和P.Ernen，“可扩展身份验证协议（EAP）的身份选择提示”，RFC 4284，2006年1月。
[Housley] Housley, R. and B. Aboba, "AAA Key Management", Work in Progress, November 2005.
[Housley]Housley，R.和B.Aboba，“AAA密钥管理”，进展中的工作，2005年11月。
[IABLINK] Aboba, B., "Architectural Implications of Link Indications", Work in Progress, August 2005.
[IABLINK]Aboba，B.“连接指示的建筑影响”，正在进行的工作，2005年8月。
[IEEE-80211Liaison1] IEEE 802.11 liaison letter to Harald Alvestrand, February 2002, https://www.ietf.org/IESG/LIAISON/ieee802.11.txt.
[IEEE-801LIAISON1]IEEE 802.11致Harald Alvestrand的联络函，2002年2月，https://www.ietf.org/IESG/LIAISON/ieee802.11.txt.
[IEEE-80211Liaison2] Input To IETF EAP Working Group on Methods and Key Strength, March 2003, http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt.
[IEEE-80211Liaison2]对IETF EAP方法和关键强度工作组的输入，2003年3月，http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt.
[IEEE-802.11F] Institute of Electrical and Electronics Engineers, "IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", IEEE 802.11F, June 2003 (now deprecated).
[IEEE-802.11F]电气和电子工程师协会，“通过支持IEEE 802.11运行的配电系统间接入点协议实现多供应商接入点互操作性的IEEE试用推荐规程”，IEEE 802.11F，2003年6月（现已弃用）。
[IEEE-802Liaison] IEEE 802 Liaison letter to Bert Wijnen and Bernard Aboba, July 26, 2004, http://www.ietf.org/IESG/LIAISON/file41.pdf.
[IEEE-802Liison]IEEE 802致Bert Wijnen和Bernard Aboba的联络函，2004年7月26日，http://www.ietf.org/IESG/LIAISON/file41.pdf.
[IEEE-802.1X-MIB] Norseth, K., "Definitions for Port Access Control (IEEE 802.1X) MIB", Work in Progress, November 2003.
[IEEE-802.1X-MIB]Norseth，K.，“端口访问控制（IEEE 802.1X）MIB的定义”，正在进行的工作，2003年11月。
[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE P802.1X-2001, June 2001.
[IEEE-802.1X]IEEE局域网和城域网标准：基于端口的网络访问控制，IEEE P802.1X-2001，2001年6月。
[IEEE-802.1X-2004] IEEE Standards for Local and Metropolitan Area Networks: Port based Network Access Control, IEEE P802.1X-2004, December 2004.
[IEEE-802.1X-2004]IEEE局域网和城域网标准：基于端口的网络访问控制，IEEE P802.1X-2004，2004年12月。
[IEEE-802.1D] ISO/IEC 15802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D-1998), 1998.
[IEEE-802.1D]ISO/IEC 15802-3信息技术-系统间的电信和信息交换-局域网和城域网-通用规范-第3部分：媒体访问控制（MAC）网桥（也叫ANSI/IEEE标准802.1D-1998），1998年。
[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks: Draft Standard for Virtual Bridged Local Area Networks, P802.1Q, January 1998.
[IEEE-802.1Q]IEEE局域网和城域网标准：虚拟桥接局域网标准草案，P802.1Q，1998年1月。
[IEEE-802.3] ISO/IEC 8802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 1996.
[IEEE-802.3]ISO/IEC 8802-3信息技术-系统间远程通信和信息交换-局域网和城域网-通用规范-第3部分：带冲突检测的载波侦听多址（CSMA/CD）访问方法和物理层规范（也可称为ANSI/IEEE Std 802.3-1996），1996年。
[IEEE-802.11] Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE P802.11-2003, 2003.
[IEEE-802.11]信息技术-系统间电信和信息交换-局域网和城域网-特定要求第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范，IEEE P802.11-2003，2003。
[IEEE-802.11i] IEEE Supplement to Standard for Telecommunications and Information Exchange Between Systems - LAN/MAN Specific Requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications: Specification for Enhanced Security, IEEE P802.11i, July 2004.
[IEEE-802.11i]系统间电信和信息交换标准的IEEE补充—LAN/MAN特定要求—第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范：增强安全规范，IEEE P802.11i，2004年7月。
[IEEE-802.16e] IEEE Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems, Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands, IEEE P802.16e, September 2005.
[IEEE-802.16e]IEEE局域网和城域网标准-第16部分：固定和移动宽带无线接入系统的空中接口，许可频带内固定和移动组合操作的物理和介质接入控制层修正案，IEEE P802.16e，2005年9月。
[IEEE-802.16-Liaison1] Liaison letter from IEEE 802.16 to Bernard Aboba, March 17, 2005, http://ieee802.org/16/liaison/docs/L80216-05_025.pdf.
[IEEE-802.16-联络1]IEEE 802.16致Bernard Aboba的联络函，2005年3月17日，http://ieee802.org/16/liaison/docs/L80216-05_025.pdf.
[IEEE-802.16-Liaison2] Liaison letter from IEEE 802.16 to Bernard Aboba, May 5, 2005, http://ieee802.org/16/liaison/docs/L80216-05_039.pdf.
[IEEE-802.16-联络2]IEEE 802.16致Bernard Aboba的联络函，2005年5月5日，http://ieee802.org/16/liaison/docs/L80216-05_039.pdf.
[KEYFRAME] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2005.
[KEYFRAME]Aboba，B.，Simon，D.，Arkko，J.，Eronen，P.，和H.Levkowetz，“可扩展认证协议（EAP）密钥管理框架”，正在进行的工作，2005年10月。
[Liaison-Page] IETF Liaison Activities, http://www.ietf.org/liaisonActivities.html.
[联络页]IETF联络活动，http://www.ietf.org/liaisonActivities.html.
[MIB-TRANSFER] Harrington, D., "Transferring MIB Work from IETF Bridge WG to IEEE 802.1 WG", Work in Progress, October 2005.
[MIB-TRANSFER]Harrington，D.，“将MIB工作从IETF桥接工作组转移到IEEE 802.1工作组”，正在进行的工作，2005年10月。
[Mishra] Mishra, A. and W. Arbaugh, "An Initial Security Analysis of the IEEE 802.1X Standard", Department of Computer Science, University of Maryland College Park, CS-TR-4328, February 2002.
[米斯拉]米斯拉，A和W. Arbaugh，“IEEE 802.1x标准的初步安全分析”，马里兰大学计算机科学系，CS-TR 4328，2002年2月。
[Policy] IEEE Project 802 LAN MAN Standards Committee (LMSC) Policies and Procedures, September 14, 2005, http://www.ieee802.org/policies-and-procedures.pdf.
[政策]IEEE项目802 LAN MAN标准委员会（LMSC）政策和程序，2005年9月14日，http://www.ieee802.org/policies-and-procedures.pdf.
[RFC1493] Decker, E., Langille, P., Rijsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges", RFC 1493, July 1993.
[RFC1493]Decker，E.，Langille，P.，Rijsinghani，A.，和K.McCloghrie，“桥梁管理对象的定义”，RFC 1493，1993年7月。
[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, "Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2", RFC 2108, February 1997.
[RFC2108]de Graaf，K.，Romascan，D.，McMaster，D.，和K.McCloghrie，“使用SMIv2的IEEE 802.3中继器设备的受管对象定义”，RFC 2108，1997年2月。
[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[RFC2284]Blunk，L.和J.Vollbrecht，“PPP可扩展认证协议（EAP）”，RFC 2284，1998年3月。
[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[RFC2390]Bradley，T.，Brown，C.和A.Malis，“反向地址解析协议”，RFC 23901998年9月。
[RFC2674] Bell, E., Smith, A., Langille, P., Rijhsinghani, A., and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions", RFC 2674, August 1999.
[RFC2674]Bell，E.，Smith，A.，Langille，P.，Rijhsinghani，A.，和K.McCloghrie，“具有流量类、多播过滤和虚拟LAN扩展的网桥的托管对象定义”，RFC 2674，1999年8月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866]Rigney，C.，“半径会计”，RFC 28662000年6月。
[RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867]Zorn，G.，Aboba，B.和D.Mitton，“隧道协议支持的半径计算修改”，RFC 28672000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]Zorn，G.，Leifer，D.，Rubens，A.，Shriver，J.，Holdrege，M.，和I.Goyret，“隧道协议支持的半径属性”，RFC 28682000年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869]Rigney，C.，Willats，W.，和P.Calhoun，“半径延伸”，RFC 2869，2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162]Aboba，B.，Zorn，G.和D.Mitton，“RADIUS和IPv6”，RFC 3162，2001年8月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575]Aboba，B.“RADIUS（远程认证拨入用户服务）的IANA注意事项”，RFC 3575，2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580]Congdon，P.，Aboba，B.，Smith，A.，Zorn，G.，和J.Roese，“IEEE 802.1X远程认证拨入用户服务（RADIUS）使用指南”，RFC 35802003年9月。
[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621, December 2003.
[RFC3621]Berger，A.和D.Romascanu，“电力以太网MIB”，RFC 36212003年12月。
[RFC3635] Flick, J., "Definitions of Managed Objects for the Ethernet-like Interface Types", RFC 3635, September 2003.
[RFC3635]Flick，J.，“类似以太网接口类型的托管对象定义”，RFC 3635，2003年9月。
[RFC3636] Flick, J., "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)", RFC 3636, September 2003.
[RFC3636]Flick，J.，“IEEE 802.3介质连接单元（MAU）受管对象的定义”，RFC 36362003年9月。
[RFC3637] Heard, C.M., Ed., "Definitions of Managed Objects for the Ethernet WAN Interface Sublayer", RFC 3637, September 2003.
[RFC3637]Heard，C.M.，Ed.，“以太网WAN接口子层受管对象的定义”，RFC 3637，2003年9月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，“可扩展身份验证协议（EAP）”，RFC 3748，2004年6月。
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
[RFC4017]Stanley，D.，Walker，J.，和B.Aboba，“无线局域网的可扩展认证协议（EAP）方法要求”，RFC 401712005年3月。
[RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points (CAPWAP)", RFC 4118, June 2005.
[RFC4118]Yang，L.，Zerfos，P.，和E.Sadot，“无线接入点控制和供应（CAPWAP）的体系结构分类”，RFC 4118，2005年6月。
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, August 2005.
[RFC4137]Vollbrecht，J.，Eronen，P.，Petroni，N.，和Y.Ohba，“可扩展认证协议（EAP）对等方和认证方的状态机”，RFC 4137，2005年8月。
[RFC4181] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005.
[RFC4181]Heard，C.，Ed.，“MIB文件的作者和评审者指南”，BCP 111，RFC 41812005年9月。
[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月。
[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月。
[TYPE-TUT] IEEE Standards Association, "Use of the IEEE Assigned EtherType Field with IEEE Std 802.3, 1998 Edition Local and Metropolitan Area Networks", http://standards.ieee.org/regauth/ethertype/ type-tut.html.
[TYPE-TUT]IEEE标准协会，“IEEE指定以太网类型字段与IEEE Std 802.3的使用，1998版局域网和城域网”，http://standards.ieee.org/regauth/ethertype/ 键入-tut.html。
The authors would like to acknowledge Les Bell, Dan Romascanu, Dave Harrington, Tony Jeffree, Fred Baker, Paul Congdon, Paul Langille, and C. M. Heard for contributions to this document.
作者要感谢Les Bell、Dan Romascanu、Dave Harrington、Tony Jeffree、Fred Baker、Paul Congdon、Paul Langille和C.M.Heard对本文件的贡献。
The relationship between IETF and IEEE 802 began in the late 1980s with SNMP MIBs developed for the original IEEE 802.1D standard. Because the IEEE specification [IEEE-802.1D] contained only a functional definition of the counters and operations, the IETF's Bridge MIB WG took on the role of defining the Bridge MIB [RFC1493], which was published as an RFC. Fred Baker and later Keith McCloghrie served as chairs of the Bridge WG.
IETF和IEEE 802之间的关系始于20世纪80年代末，当时SNMP MIB是为最初的IEEE 802.1D标准开发的。由于IEEE规范[IEEE-802.1D]仅包含计数器和操作的功能定义，IETF的桥接MIB WG承担了定义桥接MIB[RFC1493]的角色，该桥接MIB被发布为RFC。弗雷德·贝克和后来的基思·麦克洛赫里担任桥梁工作组的主席。
The Bridge MIB combined the work of Keith McCloghrie, Eric Decker, and Paul Langille, with spanning tree expertise provided by Anil Rijsinghani. Mick Seaman (author of 802.1D) and Floyd Backes (who had written the code for Digital Equipment's spanning tree implementation) were the main contacts within IEEE 802.1. Since Mick, Floyd, Anil, and Paul all worked for Digital Equipment Corporation at the time, much of the coordination between IEEE 802.1 and the Bridge MIB WG took place in the hallways at Digital, rather than within official channels.
Bridge MIB将Keith McCloghrie、Eric Decker和Paul Langille的工作与Anil Rijsinghani提供的生成树专业知识相结合。Mick Seaman（802.1D的作者）和Floyd Backes（为数字设备的生成树实现编写了代码）是IEEE 802.1中的主要联系人。由于当时Mick、Floyd、Anil和Paul都在数字设备公司工作，IEEE 802.1和Bridge MIB WG之间的大部分协调工作都在数字公司的走廊进行，而不是在官方渠道内进行。
In the early 1990s when IEEE 802.3 was completing the first Ethernet standards, SNMP was not yet the dominant network management protocol. As a result, a 'protocol independent' MIB is included in Clause 30 of the IEEE 802.3 standard [IEEE-802.3], which is updated each time the Ethernet standard is enhanced to support higher speeds. In parallel, IEEE 802 participants interested in network management were active in the formation of the IETF HUBMIB WG, which took on the task of transforming IEEE 802 definitions into SNMP MIBs documented as Standards Track RFCs. This included Dan Romascanu, Chair of the IETF HUBMIB WG since 1996.
20世纪90年代初，当IEEE 802.3完成第一个以太网标准时，SNMP还不是主要的网络管理协议。因此，IEEE 802.3标准[IEEE-802.3]第30条中包含了一个“独立于协议”的MIB，该MIB在以太网标准每次增强以支持更高的速度时都会更新。同时，对网络管理感兴趣的IEEE 802参与者也积极参与了IETF HUBMIB工作组的组建，该工作组承担了将IEEE 802定义转换为SNMP MIB的任务，并记录为标准跟踪RFC。这包括Dan Romascanu，自1996年以来担任IETF HUBMIB工作组主席。
The Charter of the HUBMIB WG explicitly mentions that the IEEE 802.3 standard is the starting point for the Ethernet MIB, but at the same time reserves the right to deviate from the IEEE model -- either to cover only part of the capabilities offered by the standard or to add MIB objects that are not directly derived from the IEEE model (mostly implemented in software). If management needs lead to requirements for hardware support, the IETF HUBMIB WG is to provide this input to IEEE 802.3 in a timely manner.
HUBMIB工作组章程明确提到，IEEE 802.3标准是以太网MIB的起点，但同时保留偏离IEEE模型的权利——要么仅涵盖标准提供的部分功能，要么添加非直接从IEEE模型派生的MIB对象如果管理需要导致硬件支持需求，IETF HUBMIB工作组将及时向IEEE 802.3提供该输入。
Cooperation between the IETF HUBMIB WG and IEEE 802.3 has continued for more than a decade until today, mostly based on the work of a few editors supported by their companies, who are taking the IEEE standards and mapping them into a management data model and MIBs. Work items include:
IETF HUBMIB WG和IEEE 802.3之间的合作持续了十多年，直到今天，主要是基于其公司支持的少数编辑的工作，他们正在采用IEEE标准并将其映射到管理数据模型和MIB中。工作项目包括：
- The Hub MIB [RFC2108], which has gone through three iterations, and is probably ending its evolution, as repeaters are less used in Ethernets. - The MAU MIB, which has been updated each time a new Ethernet speed is developed, with [RFC3636] accommodating 10-Gbps Ethernet. - The Ethernet-like Interfaces MIB was not originally a work item of the HUBMIB WG, but the WG took responsibility for a revision, published as [RFC3635]. - The WAN Interface Sublayer MIB [RFC3637] and the Power Ethernet MIB [RFC3621] were developed in IEEE 802.3 and the IETF HUBMIB WG.
- 集线器MIB[RFC2108]经过三次迭代，可能正在结束其演变，因为中继器在以太网中使用较少。-MAU MIB，每次开发新的以太网速度时都会更新，[RFC3636]可容纳10 Gbps以太网。-类似以太网的接口MIB最初不是HUBMIB工作组的工作项，但工作组负责进行修订，发布为[RFC3635]。-广域网接口子层MIB[RFC3637]和电力以太网MIB[RFC3621]是在IEEE 802.3和IETF HUBMIB工作组中开发的。
In 2000, an official liaison was established between IEEE 802.3 and the IETF HUBMIB WG, and Dan Romascanu was appointed IETF liaison. The conditions of the liaison agreement allows editors and other participants in the IETF HUBMIB WG access to work-in-progress drafts in IEEE 802.3 on a personal basis, for the purpose of working on MIBs before the release of the standard. However, the username and password for IEEE 802.3 document access are not for publication on any IETF website or mailing list.
2000年，IEEE 802.3与IETF HUBMIB工作组建立了官方联络，Dan Romascanu被任命为IETF联络员。联络协议的条件允许IETF HUBMIB工作组的编辑和其他参与者以个人身份访问IEEE 802.3中正在进行的草案，以便在标准发布之前使用MIB。但是，IEEE 802.3文件访问的用户名和密码不可发布在任何IETF网站或邮件列表上。
In 1996 as the 802.1p and 802.1Q [IEEE-802.1Q] standards were being completed, a need was perceived for development of an SNMP MIB, based on the management clauses of those standards. IEEE 802 management clauses are written in a manner that was independent of any protocol that may be used to implement them.
1996年，随着802.1p和802.1Q[IEEE-802.1Q]标准的完成，人们认为有必要根据这些标准的管理条款开发SNMP MIB。IEEE 802管理条款的编写方式独立于可用于实现这些条款的任何协议。
At that time, there were a number of proprietary VLAN management MIBs that were both inadequate and difficult to understand. As a result, there was a need for a more comprehensive, simpler model for VLAN management, along with the priority and multicast filtering management also defined by these standards.
当时，有许多专有的VLAN管理MIB既不充分又难以理解。因此，需要一个更全面、更简单的VLAN管理模型，以及这些标准也定义的优先级和多播过滤管理。
A small group of participants from the 802.1 WG began working on the problem independently, then combined their work. The original authors of the Bridge MIB, on which some of the work was based, reviewed the initial work.
来自802.1工作组的一小群参与者开始独立解决这个问题，然后将他们的工作结合起来。桥MIB的原始作者（其中一些工作是基于桥MIB的）回顾了最初的工作。
By the end of 1997, the work was ready for review by a larger audience. Andrew Smith worked with Keith McCloghrie, chair of the Bridge MIB WG (dormant at the time), to obtain a meeting slot at the March 1998 IETF meeting. After this, review and development of the MIB continued on the IETF standards track.
到1997年底，该作品已准备好接受更多观众的审查。安德鲁·史密斯（Andrew Smith）与Bridge MIB工作组（当时处于休眠状态）主席基思·麦克洛赫里（Keith McCloghrie）合作，在1998年3月的IETF会议上获得了一个会议席位。此后，MIB的审查和开发继续在IETF标准轨道上进行。
During the development of [RFC2674], there was no official inter-working between the IETF Bridge MIB and IEEE 802.1 groups. Development of this MIB was successful, because the main developers (Andrew Smith and Les Bell) were involved in both the IEEE 802.1 and the IETF Bridge MIB WGs.
在[RFC2674]的开发过程中，IETF桥接MIB和IEEE 802.1组之间没有正式的交互工作。该MIB的开发是成功的，因为主要开发人员（Andrew Smith和Les Bell）都参与了IEEE 802.1和IETF桥接MIB WGs。
As part of the IEEE 802.3ad and IEEE 802.1X standards work, it was decided that it would be better to develop a MIB as part of the standards, rather than wait until an IETF WG was formed, and develop the MIBs separately, so as to avoid a significant time lag in their development.
作为IEEE 802.3ad和IEEE 802.1X标准工作的一部分，决定最好开发MIB作为标准的一部分，而不是等到IETF工作组成立后再单独开发MIB，以避免开发过程中出现明显的时间延迟。
As Les Bell was the participant in IEEE 802.3ad and IEEE 802.1 most familiar with SNMP MIB development, he put together the initial MIBs based on the management framework the groups had come up with. Additional assistance was then received for both MIBs from within the IEEE 802.3ad and IEEE 802.1X groups. Tony Jeffree, editor of both standards, acted as editor of the MIBs as well.
由于Les Bell是IEEE 802.3ad和IEEE 802.1的参与者，他最熟悉SNMP MIB的开发，因此他根据小组提出的管理框架将初始MIB组合在一起。然后，从IEEE 802.3ad和IEEE 802.1X组中接收到两个MIB的额外帮助。两个标准的编辑托尼·杰弗里（Tony Jeffree）也担任MIB的编辑。
The problem with IEEE 802 developing these MIBs without IETF involvement was the lack of review. IEEE 802 members are generally not familiar with MIBs, and very few comments were received as part of the balloting process for either MIB.
IEEE 802在没有IETF参与的情况下开发这些MIB的问题是缺乏审查。IEEE 802成员通常不熟悉MIB，并且在两个MIB的投票过程中很少收到评论。
In the case of the IEEE 802.3ad MIB, this meant that basic errors were not discovered until just before publication. Unfortunately, by then it was too late, and the corrections submitted to the IEEE 802.3ad chair and document editor did not get applied to the published version.
在IEEE 802.3ad MIB的情况下，这意味着直到发布之前才发现基本错误。不幸的是，那时已经太晚了，提交给IEEE 802.3ad主席和文档编辑器的更正没有应用到发布的版本中。
Subsequent to the publication of [IEEE-802.1X], the IEEE 802.1X MIB was reviewed within the Bridge WG, and several syntax errors were found. These have been corrected in the version of the MIB module that was developed as part of [IEEE-802.1X-2004]. However, while [IEEE-802.1X-MIB] was originally published as a work in progress within the Bridge WG, there was not sufficient interest to complete its publication as an RFC. As a result, the draft has now expired.
在[IEEE-802.1X]发布之后，网桥工作组对IEEE 802.1X MIB进行了审查，发现了几个语法错误。这些问题已在作为[IEEE-802.1X-2004]一部分开发的MIB模块版本中得到纠正。然而，虽然[IEEE-802.1X-MIB]最初是作为桥梁工作组的一项正在进行的工作发布的，但没有足够的兴趣将其作为RFC发布。因此，草案现在已经过期。
802.1t and 802.1u were minor amendments to the 802.1D and 802.1Q standards, requiring some additions to the MIB published in [RFC2674]. 802.1v was a new feature extending the VLAN classification schemes of 802.1Q, also requiring extensions to [RFC2674]. 802.1w was a new version of Spanning Tree, requiring rewriting of part of [RFC1493].
802.1t和802.1u是对802.1D和802.1Q标准的轻微修订，需要对[RFC2674]中发布的MIB进行一些补充。802.1v是扩展802.1Q的VLAN分类方案的新功能，也需要扩展到[RFC2674]。802.1w是生成树的新版本，需要重写[RFC1493]的一部分。
When Les Bell took on the role of Chair of the IETF Bridge MIB WG in 2001, these issues were raised as new work items and two volunteers were found to become editors of the Internet-Drafts. A work item was also included to publish the IEEE 802.1X MIB as an Informational RFC.
2001年，当Les Bell担任IETF Bridge MIB工作组主席时，这些问题作为新的工作项目被提出，两名志愿者被发现成为互联网草稿的编辑。还包括一个工作项，用于将IEEE 802.1X MIB发布为信息RFC。
This approach worked well for a while, but it then became difficult for the participants, including the editors and the Chair, to sustain a level of interest sufficient to overcome the difficulties introduced by budget cutbacks. As a result, the drafts have now expired, although there are no significant technical issues outstanding.
这种方法在一段时间内运作良好，但随后参与者，包括编辑和主席，很难保持足够的兴趣来克服预算削减带来的困难。因此，草案现已过期，尽管没有重大技术问题悬而未决。
Since the late 1990s, IEEE 802.1 has been involved in work relating to authentication and authorization [IEEE-802.1X], which led to discovery of issues in several IETF specifications, including [RFC2284] and [RFC2869]. Similarly, IETF participants have uncovered issues in early versions of the RADIUS usage specifications such as [RFC3580], as well as the IEEE 802.1X state machine [Mishra].
自20世纪90年代末以来，IEEE 802.1一直参与与认证和授权[IEEE-802.1X]相关的工作，这导致发现了多个IETF规范中的问题，包括[RFC2284]和[RFC2869]。同样，IETF参与者发现了早期版本的RADIUS使用规范（如[RFC3580]）以及IEEE 802.1X状态机[Mishra]中存在的问题。
In order to address these issues and ensure synchronization between IEEE 802.1 and the IETF EAP and AAA WGs, a liaison arrangement was utilized during the development of [IEEE-802.1X] and [IEEE-802.1X-2004].
为了解决这些问题并确保IEEE 802.1与IETF EAP和AAA WGs之间的同步，在[IEEE-802.1X]和[IEEE-802.1X-2004]的开发过程中采用了联络安排。
IEEE 802.11 groups such as IEEE 802.11i and IEEE 802.11F have also become dependent on EAP and AAA work. This relationship was more challenging since IEEE 802.11 required development of EAP methods and the EAP Key Management Framework, which represented substantial new IETF work, as opposed to the clarifications and updates required by IEEE 802.1.
IEEE 802.11组（如IEEE 802.11i和IEEE 802.11F）也依赖于EAP和AAA工作。这种关系更具挑战性，因为IEEE 802.11要求开发EAP方法和EAP密钥管理框架，这代表了大量新的IETF工作，而不是IEEE 802.1要求的澄清和更新。
IEEE 802.1X-2001 [IEEE-802.1X] defined the encapsulation of EAP [RFC2284] over IEEE 802, as well as a state machine for the joint operation of IEEE 802.1X and EAP.
IEEE 802.1X-2001[IEEE-802.1X]定义了EAP[RFC2284]在IEEE 802上的封装，以及IEEE 802.1X和EAP联合运行的状态机。
During the development of IEEE 802.1X-2001, several problems were discovered in the specification for RADIUS/EAP [RFC2869], and as a result, work was begun on a revision [RFC3579]. In addition, clarifications were required on how RADIUS attributes defined in [RFC2865], [RFC2866], [RFC2867], [RFC2868], [RFC2869], and [RFC3162] would be interpreted by IEEE 802.1X implementations. To address this, a non-normative RADIUS usage appendix was added to [IEEE-802.1X], and published as [RFC3580].
在IEEE 802.1X-2001的开发过程中，在RADIUS/EAP规范[RFC2869]中发现了几个问题，因此，开始了修订[RFC3579]的工作。此外，需要澄清IEEE 802.1X实现如何解释[RFC2865]、[RFC2866]、[RFC2867]、[RFC2868]、[RFC2869]和[RFC3162]中定义的半径属性。为了解决这个问题，在[IEEE-802.1X]中增加了一个非规范性的RADIUS使用附录，并发布为[RFC3580]。
Subsequent to the publication of [IEEE-802.1X], a formal analysis of the IEEE 802.1X state machine by the University of Maryland disclosed several security issues [Mishra]. Discussion within IEEE 802.1 pointed to lack of clarity in [RFC2284], which resulted from the absence of a specification for the EAP state machine specification.
在[IEEE-802.1x]发布之后，马里兰大学对IEEE 802.1x状态机的正式分析揭示了几个安全问题[米斯拉]。IEEE 802.1中的讨论指出[RFC2284]中缺乏明确性，这是由于缺乏EAP状态机规范。
At that time, EAP was handled within the IETF PPPEXT WG, which was largely inactive. In order to undertake work on a revised EAP specification as well as the specification of the EAP state machine, the IETF EAP WG was formed in July 2002. Bernard Aboba, a participant in IEEE 802.1 as well as PPPEXT, was named co-chair.
当时，EAP是在IETF PPPEXT工作组内处理的，该工作组基本上处于非活动状态。为了进行修改后的EAP规范以及EAP状态机规范的工作，IETF EAP工作组于2002年7月成立。IEEE802.1和PPPEXT的参与者Bernard Aboba被任命为联合主席。
Work on the EAP state machine [RFC4137] and revised EAP specification [RFC3748] proceeded in parallel within the EAP WG, with issues or changes in one document requiring changes to the other document, as well as revisions to [IEEE-802.1X-2004]. The revised RADIUS/EAP specification [RFC3579] was also reviewed within the EAP WG, since at that time the RADEXT WG had not yet been formed.
在EAP工作组内，EAP状态机[RFC4137]和经修订的EAP规范[RFC3748]的工作并行进行，一份文件中的问题或变更要求对另一份文件进行变更，并对[IEEE-802.1X-2004]进行修订。EAP工作组也对修订后的RADIUS/EAP规范[RFC3579]进行了审查，因为当时RADEXT工作组尚未成立。
The revision to IEEE 802.1X [IEEE-802.1X-2004] included the following:
IEEE 802.1X[IEEE-802.1X-2004]的修订版包括以下内容：
- a revised RADIUS usage appendix based on [RFC3580] - clarifications based on [RFC3579] - a revised IEEE 802.1X state machine, based on [RFC3748] and [RFC4137]
- 基于[RFC3580]的修订版RADIUS使用附录-基于[RFC3579]的澄清-基于[RFC3748]和[RFC4137]的修订版IEEE 802.1X状态机
Due to the deep dependencies between [IEEE-802.1X-2004], [RFC3748], and [RFC4137], a liaison was established between IEEE 802.1X-REV and the IETF EAP WG in August 2002. This enabled participants in the IETF EAP WG to obtain access to the IEEE 802.1X revision in progress.
由于[IEEE-802.1X-2004]、[RFC3748]和[RFC4137]之间存在深刻的依赖关系，IEEE 802.1X-REV与IETF EAP工作组于2002年8月建立了联系。这使IETF EAP工作组的参与者能够访问正在进行的IEEE 802.1X版本。
IEEE 802 groups are duty bound to consider all comments received, regardless of their origin. This allows IETF participants to comment as part of the IEEE 802 ballot process, regardless of their voting status within IEEE 802. Where there is active cooperation, IETF WGs may be made aware that IEEE 802 ballots are occurring and that their
IEEE 802组有义务考虑所有收到的评论，不管它们的起源。这允许IETF参与者作为IEEE 802投票过程的一部分进行评论，而不管他们在IEEE 802中的投票状态如何。在有积极合作的情况下，IETF工作组可以知道IEEE 802投票正在进行，并且他们的
comments are welcome. IEEE 802.1X-REV and IEEE 802.11i ballots were announced on the EAP WG mailing list, as are IEEE 802 interim meeting arrangements.
欢迎评论。IEEE 802.1X-REV和IEEE 802.11i投票已在EAP工作组邮件列表上公布，IEEE 802临时会议安排也已公布。
Similarly, during the IEEE 802.1X-REV ballot process, comments were received relating to [RFC3748], [RFC4137], and [RFC3579]. These comments were tracked on the EAP WG Issues List, and were subsequently addressed in the documents.
同样，在IEEE 802.1X-REV投票过程中，收到了与[RFC3748]、[RFC4137]和[RFC3579]相关的意见。这些意见在EAP工作组问题清单上进行了跟踪，随后在文件中进行了处理。
In April 2003, [RFC3580] was approved by the IESG for publication as an RFC, and in May 2003, [RFC3579] was approved for publication as an RFC. The review process for both drafts involved bringing the documents to IETF last call, and then reposting the IETF last-call announcement on the IEEE 802.1 mailing list. While ballot comments on IEEE 802.1X-REV were also reflected in changes to both documents, it was necessary for both documents to be approved for publication as RFCs well in advance of Sponsor Ballot, in order to ensure that RFC numbers would be assigned in time, so as to avoid delaying publication.
2003年4月，[RFC3580]被IESG批准作为RFC发布，2003年5月，[RFC3579]被批准作为RFC发布。两份草案的审查过程都涉及将文件提交给IETF last call，然后在IEEE 802.1邮件列表上重新发布IETF last call公告。虽然对IEEE 802.1X-REV的投票意见也反映在对两份文件的更改中，但有必要在发起人投票之前批准两份文件作为RFC发布，以确保及时分配RFC编号，从而避免延迟发布。
Overall, despite the complex inter-dependencies between [IEEE-802.1X-2004], [RFC3748], and [RFC4137], the documents were produced without undue delay. This was largely due to the work of joint participants in IEEE 802.1 and IETF EAP WG.
总的来说，尽管[IEEE-802.1X-2004]、[RFC3748]和[RFC4137]之间存在复杂的相互依赖关系，但这些文件的编制没有不当的延迟。这主要是由于IEEE 802.1和IETF EAP工作组的联合参与者所做的工作。
IEEE 802.11i was chartered to specify security enhancements to [IEEE-802.11]. Since [IEEE-802.11i] utilized IEEE 802.1X, it depended on [IEEE-802.1X-2004]. As a result, IEEE 802.11i and IEEE 802.1 held joint meetings at IEEE 802 plenaries and established a liaison arrangement that permitted members of either group (as well as EAP WG participants) access to IEEE 802.11i work-in-progress.
IEEE 802.11i被特许用于指定[IEEE-802.11]的安全增强功能。由于[IEEE-802.11i]使用了IEEE 802.1X，因此它依赖于[IEEE-802.1X-2004]。因此，IEEE 802.11i和IEEE 802.1在IEEE 802全体会议上举行了联席会议，并建立了联络安排，允许任一小组的成员（以及EAP工作组参与者）访问正在进行的IEEE 802.11i工作。
Since [IEEE-802.11i] depended on [IEEE-802.1X-2004], it inherited the dependencies of [IEEE-802.1X-2004], including work on EAP, EAP methods, and AAA support for EAP. In addition, since IEEE 802.11i utilized EAP for key management whereas [IEEE-802.1X] does not, additional security requirements arose with respect to EAP methods.
由于[IEEE-802.11i]依赖于[IEEE-802.1X-2004]，因此它继承了[IEEE-802.1X-2004]的依赖关系，包括EAP、EAP方法和对EAP的AAA支持。此外，由于IEEE 802.11i使用EAP进行密钥管理，而[IEEE-802.1X]没有，因此对EAP方法产生了额外的安全要求。
In February 2002, IEEE 802.11 sent a liaison letter to the IESG [IEEE-80211Liaison1] requesting additional work on EAP, EAP methods, and EAP key management. This letter was presented at the second EAP BOF at IETF 53, and was used as input to the EAP WG charter. In March 2003, another liaison letter was presented, providing further clarifications on requirements for EAP method work [IEEE-80211Liaison2]. This included a request from IEEE 802.11i for
2002年2月，IEEE 802.11向IESG[IEEE-801LIAISON1]发送了一封联络信，要求就EAP、EAP方法和EAP密钥管理开展更多工作。本函在IETF 53第二届EAP BOF上提交，并作为EAP工作组章程的输入。2003年3月，提交了另一封联络函，进一步澄清了EAP方法工作的要求[IEEE-801LIAISON2]。这包括IEEE 802.11i请求
the EAP WG to consider changing the mandatory-to-implement EAP method within [RFC3748], so as to provide a method meeting the security requirements of IEEE 802.11i.
EAP WG考虑改变强制执行EFP方法在[RCF378]内，从而提供一种符合IEEE 802.11i安全要求的方法。
During IETF 56, the request for changing the mandatory-to-implement method was considered by the EAP WG. A recommendation was made by the Internet Area Director Erik Nordmark that the IEEE 802.11i requirements be documented in an RFC and that the EAP WG consider the security requirements for EAP methods in various situations. It was recommended not to change the mandatory-to-implement method, since the EAP WG was not chartered to do work on methods. However, it was decided to produce a document describing the EAP method requirements for WLAN usage. This document was subsequently published as [RFC4017].
在IETF 56期间，EAP工作组考虑了更改强制实施方法的请求。互联网领域主任Erik Nordmark提出了IEEE 802.11i要求在RFC中被记录，并且EAP WG考虑在各种情况下对EAP方法的安全要求。建议不要更改强制实施方法，因为EAP工作组没有被授权进行方法方面的工作。然而，决定编制一份文件，描述无线局域网使用的EAP方法要求。本文件随后发布为[RFC4017]。
Most recently, IEEE 802.11r has been involved in discussions relating to fast handoff, which may potentially require AAA extensions as well as changes to the EAP key hierarchy. However, the direction of this work has not yet been determined so that no liaison request has been formulated yet.
最近，IEEE 802.11r参与了有关快速切换的讨论，这可能需要AAA扩展以及EAP密钥层次结构的更改。然而，这项工作的方向尚未确定，因此尚未提出联络要求。
In April 2003, Dorothy Stanley was appointed liaison from IEEE 802.11 to the IETF, in order to help coordinate between IEEE 802.11 and IETF WGs, including AAA, BMWG, CAPWAP, and EAP.
2003年4月，Dorothy Stanley被任命为IEEE802.11与IETF的联络人，以帮助协调IEEE802.11和IETF工作组，包括AAA、BMWG、CAPWAP和EAP。
IEEE 802.11F was chartered with development of a recommended practice for Inter-Access Point Communications. As part of development of an Inter-Access Point Protocol (IAPP), it was necessary to secure communications between the access points, as well as to support the reverse resolution of the MAC address of the previous access point to its IP address, so as to allow the two access points to communicate via IAPP. Since the two access points might not be on the same link, Inverse ARP [RFC2390] was not considered sufficient in all cases.
IEEE 802.11F是在制定接入点间通信推荐规程的过程中获得特许的。作为制定接入点间协议（IAPP）的一部分，有必要确保接入点之间的通信安全，并支持将先前接入点的MAC地址反向解析为其IP地址，以便允许两个接入点通过IAPP进行通信。由于两个接入点可能不在同一链路上，因此在所有情况下，反向ARP[RFC2390]都被认为是不够的。
IEEE 802.11F elected to extend the RADIUS protocol [RFC2865] to provide inverse address resolution as well as IPsec key management. This was accomplished via use of Vendor-Specific Attributes (VSAs), as well as new RADIUS commands, added through definition of additional values for the RADIUS Service-Type attribute. As a result, IETF review was not required under the IANA considerations included in [RFC2865]. Subsequently, the RADIUS IANA considerations [RFC3575] were revised so as to require IETF review in most cases.
IEEE 802.11F选择扩展RADIUS协议[RFC2865]，以提供反向地址解析以及IPsec密钥管理。这是通过使用特定于供应商的属性（VSA）以及通过定义RADIUS服务类型属性的附加值添加的新RADIUS命令来实现的。因此，根据[RFC2865]中包含的IANA考虑因素，不需要进行IETF审查。随后，修订了RADIUS IANA注意事项[RFC3575]，以便在大多数情况下要求IETF审查。
No liaison arrangement was developed between IEEE 802.11F and IETF WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants access to the IEEE 802.11F specifications prior to publication. Once IEEE 802.11F entered into Recirculation ballot, only comments relating to changes in the specification could be considered. As a result, issues raised relating to the IEEE 802.11F RADIUS extensions were rejected.
IEEE 802.11F和IETF工作组（如AAA工作组或SEAMOBY工作组）之间未制定任何联络安排，以允许IETF参与者在发布之前访问IEEE 802.11F规范。一旦IEEE 802.11F进入循环投票，就只能考虑与规范变更相关的意见。因此，与IEEE 802.11F RADIUS扩展相关的问题被拒绝。
IEEE 802.11F was a Trial Use Recommended Practice. The IEEE 802 Executive Committee approved its withdrawal on November 18, 2005. As a result, the RADIUS parameters allocated for use by IEEE 802.11F are available to be reclaimed.
IEEE 802.11F是一种试用推荐做法。IEEE 802执行委员会于2005年11月18日批准其退出。因此，可回收分配给IEEE 802.11F使用的RADIUS参数。
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Patrik Falstrom Bob Hinden Kurtis Lindqvist David Meyer Pekka Nikander Eric Rescorla Pete Resnick Jonathan Rosenberg Lixia Zhang
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Patrik Falstrom Bob Hinden Kurtis Lindqvist David Meyer Pekka Nikander Eric Rescorla Pete Resnick Jonathan Rosenberg Lixia Zhang
Author's Address
作者地址
Bernard Aboba Microsoft One Microsoft Way Redmond, WA 98052 USA
Bernard Aboba微软一路微软美国华盛顿州雷德蒙98052
EMail: bernarda@microsoft.com
EMail: bernarda@microsoft.com
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）提供。