doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc4441.txt b/doc/rfc/rfc4441.txt
new file mode 100644
index 0000000..1c85cb5
--- /dev/null
+++ b/doc/rfc/rfc4441.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                      B. Aboba, Ed.
+Request for Comments: 4441                   Internet Architecture Board
+Category: Informational                                       March 2006
+
+
+                     The IEEE 802/IETF Relationship
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   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.
+
+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
+
+
+
+
+
+
+
+IAB                          Informational                      [Page 1]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+1.  Introduction
+
+   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.
+
+1.1.  Liaison Communications
+
+   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).
+
+   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.
+
+
+
+IAB                          Informational                      [Page 2]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   However, in this case substantially greater processing delays will
+   occur due to the need for manual handling by the IETF Secretariat
+   staff.
+
+   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.
+
+1.2.  Access to IEEE 802 Archives
+
+   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.
+
+1.3.  New Work Review
+
+   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.
+
+
+
+
+
+IAB                          Informational                      [Page 3]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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.
+
+1.4.  MIB Review
+
+   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.
+
+   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].
+
+1.5.  EAP Review
+
+   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].
+
+
+
+
+
+
+
+
+IAB                          Informational                      [Page 4]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+1.6.  AAA Review
+
+   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]:
+
+   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.
+
+   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.
+
+1.7.  Document Review
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+IAB                          Informational                      [Page 5]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+1.8.  EtherType Allocation
+
+   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].
+
+   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.
+
+2.  Security Considerations
+
+   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.
+
+   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.
+
+   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].
+
+   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.
+
+
+
+
+
+
+IAB                          Informational                      [Page 6]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+3.  Informative References
+
+   [BCP102]        Daigle, L. and Internet Architecture Board, "IAB
+                   Processes for Management of IETF Liaison
+                   Relationships", BCP 102, RFC 4052, April 2005.
+
+   [BCP103]        Trowbridge, S., Bradner, S., and F. Baker,
+                   "Procedures for Handling Liaison Statements to and
+                   from the IETF", BCP 103, RFC 4053, April 2005.
+
+   [EAPREVIEW]     EAP WG letter to Roger Marks, June 2005,
+                   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.
+
+   [IDSEL]         Adrangi, F., Lortz, V., Bari, F., and P. Eronen,
+                   "Identity Selection Hints for the Extensible
+                   Authentication Protocol (EAP)", RFC 4284, January
+                   2006.
+
+   [Housley]       Housley, R. and B. Aboba, "AAA Key Management", Work
+                   in Progress, November 2005.
+
+   [IABLINK]       Aboba, B., "Architectural Implications of Link
+                   Indications", Work in Progress, August 2005.
+
+   [IEEE-80211Liaison1]
+                   IEEE 802.11 liaison letter to Harald Alvestrand,
+                   February 2002,
+                   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-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-802Liaison]
+                   IEEE 802 Liaison letter to Bert Wijnen and Bernard
+                   Aboba, July 26, 2004,
+                   http://www.ietf.org/IESG/LIAISON/file41.pdf.
+
+
+
+IAB                          Informational                      [Page 7]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   [IEEE-802.1X-MIB]
+                   Norseth, K., "Definitions for Port Access Control
+                   (IEEE 802.1X) MIB", Work in Progress, November 2003.
+
+   [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-2004]
+                   IEEE Standards for Local and Metropolitan Area
+                   Networks: Port based Network Access Control, IEEE
+                   P802.1X-2004, December 2004.
+
+   [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.1Q]   IEEE Standards for Local and Metropolitan Area
+                   Networks: Draft Standard for Virtual Bridged Local
+                   Area Networks, P802.1Q, January 1998.
+
+   [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.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.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.
+
+
+
+
+
+
+IAB                          Informational                      [Page 8]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   [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.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-Liaison2]
+                   Liaison letter from IEEE 802.16 to Bernard Aboba, May
+                   5, 2005,
+                   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.
+
+   [Liaison-Page]  IETF Liaison Activities,
+                   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.
+
+   [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.
+
+   [Policy]        IEEE Project 802 LAN MAN Standards Committee (LMSC)
+                   Policies and Procedures, September 14, 2005,
+                   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.
+
+   [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.
+
+
+
+
+
+IAB                          Informational                      [Page 9]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   [RFC2284]       Blunk, L. and J. Vollbrecht, "PPP Extensible
+                   Authentication Protocol (EAP)", RFC 2284, March 1998.
+
+   [RFC2390]       Bradley, T., Brown, C., and A. Malis, "Inverse
+                   Address Resolution Protocol", RFC 2390, September
+                   1998.
+
+   [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.
+
+   [RFC2865]       Rigney, C., Willens, S., Rubens, A., and W. Simpson,
+                   "Remote Authentication Dial In User Service
+                   (RADIUS)", RFC 2865, June 2000.
+
+   [RFC2866]       Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
+
+   [RFC2867]       Zorn, G., Aboba, B., and D. Mitton, "RADIUS
+                   Accounting Modifications for Tunnel Protocol
+                   Support", RFC 2867, June 2000.
+
+   [RFC2868]       Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
+                   Holdrege, M., and I. Goyret, "RADIUS Attributes for
+                   Tunnel Protocol Support", RFC 2868, June 2000.
+
+   [RFC2869]       Rigney, C., Willats, W., and P. Calhoun, "RADIUS
+                   Extensions", RFC 2869, June 2000.
+
+   [RFC3162]       Aboba, B., Zorn, G., and D. Mitton, "RADIUS and
+                   IPv6", RFC 3162, August 2001.
+
+   [RFC3575]       Aboba, B., "IANA Considerations for RADIUS (Remote
+                   Authentication Dial In User Service)", RFC 3575, July
+                   2003.
+
+   [RFC3579]       Aboba, B. and P. Calhoun, "RADIUS (Remote
+                   Authentication Dial In User Service) Support For
+                   Extensible Authentication Protocol (EAP)", RFC 3579,
+                   September 2003.
+
+   [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.
+
+   [RFC3621]       Berger, A. and D. Romascanu, "Power Ethernet MIB",
+                   RFC 3621, December 2003.
+
+
+
+IAB                          Informational                     [Page 10]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   [RFC3635]       Flick, J., "Definitions of Managed Objects for the
+                   Ethernet-like Interface Types", RFC 3635, September
+                   2003.
+
+   [RFC3636]       Flick, J., "Definitions of Managed Objects for IEEE
+                   802.3 Medium Attachment Units (MAUs)", RFC 3636,
+                   September 2003.
+
+   [RFC3637]       Heard, C.M., Ed., "Definitions of Managed Objects for
+                   the Ethernet WAN Interface Sublayer", RFC 3637,
+                   September 2003.
+
+   [RFC3748]       Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
+                   and H. Levkowetz, "Extensible Authentication Protocol
+                   (EAP)", RFC 3748, June 2004.
+
+   [RFC4017]       Stanley, D., Walker, J., and B. Aboba, "Extensible
+                   Authentication Protocol (EAP) Method Requirements for
+                   Wireless LANs", RFC 4017, March 2005.
+
+   [RFC4118]       Yang, L., Zerfos, P., and E. Sadot, "Architecture
+                   Taxonomy for Control and Provisioning of Wireless
+                   Access Points (CAPWAP)", RFC 4118, June 2005.
+
+   [RFC4137]       Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
+                   "State Machines for Extensible Authentication
+                   Protocol (EAP) Peer and Authenticator", RFC 4137,
+                   August 2005.
+
+   [RFC4181]       Heard, C., Ed., "Guidelines for Authors and Reviewers
+                   of MIB Documents", BCP 111, RFC 4181, September 2005.
+
+   [RFC4188]       Norseth, K. and E. Bell, "Definitions of Managed
+                   Objects for Bridges", RFC 4188, September 2005.
+
+   [RFC4363]       Levi, D. and D. Harrington, "Definitions of Managed
+                   Objects for Bridges with Traffic Classes, Multicast
+                   Filtering, and Virtual LAN Extensions", RFC 4363,
+                   January 2006.
+
+   [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.
+
+
+
+
+
+
+IAB                          Informational                     [Page 11]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+4.  Acknowledgements
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 12]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+Appendix A.  Relationship History
+
+A.1.  MIB Development
+
+A.1.1.  Bridge MIB
+
+   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.
+
+   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.
+
+A.1.2.  MAU and Hub MIBs
+
+   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.
+
+   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.
+
+
+
+
+
+
+IAB                          Informational                     [Page 13]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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:
+
+   - 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.
+
+   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.
+
+A.1.3.  802.1p/Q MIB
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 14]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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.
+
+   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.
+
+A.1.4.  802.3ad and 802.1X MIBs
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+
+
+
+
+
+IAB                          Informational                     [Page 15]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+A.1.5.  802.1t, 802.1u, 802.1v, and 802.1w MIBs
+
+   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].
+
+   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.
+
+   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.
+
+A.2.  AAA/EAP
+
+   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].
+
+   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.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.
+
+A.2.1.  IEEE 802.1X
+
+   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.
+
+
+
+
+IAB                          Informational                     [Page 16]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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].
+
+   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.
+
+   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.
+
+   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.
+
+   The revision to IEEE 802.1X [IEEE-802.1X-2004] included the
+   following:
+
+   - a revised RADIUS usage appendix based on [RFC3580]
+   - clarifications based on [RFC3579]
+   - a revised IEEE 802.1X state machine, based on [RFC3748] and
+     [RFC4137]
+
+   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 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
+
+
+
+
+
+IAB                          Informational                     [Page 17]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+A.2.2.  IEEE 802.11i
+
+   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.
+
+   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.
+
+   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
+
+
+
+
+IAB                          Informational                     [Page 18]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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.
+
+   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].
+
+   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.
+
+   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.
+
+A.2.3.  IEEE 802.11F
+
+   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 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.
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 19]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+   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 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 20]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+Appendix B.  IAB Members at the Time of This Writing
+
+   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
+
+   EMail: bernarda@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 21]
+
+RFC 4441               IEEE 802/IETF Relationship             March 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+IAB                          Informational                     [Page 22]
+