[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 4441

Network Working Group                                      B. Aboba, Ed.
INTERNET-DRAFT                               Internet Architecture Board
Category: Informational
<draft-iab-ieee-802-rel-05.txt>
6 December 2005



                     The IEEE 802/IETF Relationship

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).  All Rights Reserved.

Abstract

   Since the late 1980s, IEEE 802 and IETF have cooperated in the
   development of SNMP MIBs and 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.







IAB                           Informational                     [Page 1]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


Table of Contents

1.     Introduction ..........................................    3
   1.1       Liaison Communications ..........................    3
   1.2       Access to IEEE 802 Archives .....................    4
   1.3       New Work Review .................................    4
   1.4       MIB Review ......................................    5
   1.5       EAP Review ......................................    5
   1.6       AAA Review ......................................    5
   1.7       Document Review .................................    6
   1.8       EtherType Allocation ............................    6
2.     Security Considerations ...............................    7
3.     IANA Considerations ...................................    7
4.     References ............................................    7
   4.1       Informative References ..........................    7
Acknowledgments ..............................................   12
Appendix A - Relationship History ............................   13
   A.1       MIB Development .................................   13
   A.2       AAA/EAP .........................................   16
Appendix B - IAB Members .....................................   20
Intellectual Property Statement ..............................   20
Disclaimer of Validity .......................................   20
Copyright Statement ..........................................   21




























IAB                           Informational                     [Page 2]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


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], the multicast filtering and VLAN extension MIB [RFC2674],
   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 3]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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 PARs, the New Work
   mailing list is used.  The IEEE 802 Executive Committee is subscribed
   to the list, so that they 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.

   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



IAB                           Informational                     [Page 4]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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 which 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 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
   assure 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 underway 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 its 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].

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



IAB                           Informational                     [Page 5]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   multiple potential applications, allocation from the IETF standard
   attribute space is preferred to creation of IEEE 802 Vendor-Specific
   attributes.  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 Vendor-Specific Attributes (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 adhoc 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.

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




IAB                           Informational                     [Page 6]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


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

3.  IANA Considerations

   This document does not create any registries or allocate any protocol
   parameters.

4.  References







IAB                           Informational                     [Page 7]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


4.1.  Informative References

[BCP102]  Daigle, L, "IAB Processes for Management of IETF Liaison
          Relationships", RFC 4052 (BCP 102), April 2005.

[BCP103]  Trowbridge, S., Bradner, S. and F. Baker, "Procedures for
          Handling Liaison Statements to and from the IETF", RFC 4053
          (BCP 103), 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 Extensible Authentication Protocol (EAP)",
          draft-adrangi-eap-network-discovery-14.txt, Internet draft
          (work in progress), August 2005.

[Housley] Housley, R. and B. Aboba, "AAA Key Management", draft-housley-
          aaa-key-mgmt-01.txt, Internet draft (work in progress),
          November 2005.

[IABLINK] Aboba, B., "Architectural Implications of Link Indications",
          draft-iab-link-indications-03.txt, Internet draft (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-802Liaison]
          IEEE 802 Liaison letter to Bert Wijnen and Bernard Aboba, July
          26, 2004, http://www.ietf.org/IESG/LIAISON/file41.pdf

[IEEE-802.1X-MIB]
          Norseth, K., "Definitions for Port Access Control (IEEE
          802.1X) MIB", Internet draft (work in progress), draft-ietf-
          bridge-8021x-03.txt, November 2003.





IAB                           Informational                     [Page 8]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


[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]
          IEEE Standards for Local and Metropolitan Area Networks:
          Overview and Architecture, ANSI/IEEE Std 802, 1990.

[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 9]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


[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", draft-ietf-eap-keying-08.txt, Internet draft (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", Internet draft (work in progress), draft-
          harrington-8021-mib-transition-00.txt, 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., et al., "Definitions of Managed Objects for
          Bridges", RFC 1493, July 1993.

[RFC2108] Graaf, K., et al., "Definitions of Managed Objects for IEEE
          802.3 Repeater Devices using SMIv2", RFC 2108, February 1997.

[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
          Protocol (EAP)", RFC 2284, March 1998.




IAB                           Informational                    [Page 10]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


[RFC2390] Bradley, T., Brown, C and A. Malis, "Inverse Address
          Resolution Protocol", RFC 2390, September 1998.

[RFC2674] Bell, E., et al., "Definitions of Managed Objects for Bridges
          with Traffic Classes, Multicast Filtering and Virtual LAN
          Extensions", RFC 2674, August 1999.

[RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2867] Zorn, G., Mitton, D. and B. Aboba, "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",  RFC 3575, July
          2003.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS 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 RADIUS Usage Guidelines", RFC 3580, September
          2003.

[RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 3621,
          December 2003.

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



IAB                           Informational                    [Page 11]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


[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 EAP Peer and Authenticator", RFC 4137, August
          2005.

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

[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

Acknowledgments

   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]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


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

   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



IAB                           Informational                    [Page 13]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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 Interfaces 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 user name and
   password for IEEE 802.3 document access are not for publication on
   any IETF Web site or mail list.

A.1.3 802.1p/Q MIB

   In 1996 as the 802.1p and 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
   which 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.

   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.



IAB                           Informational                    [Page 14]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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 IEEE 802.1 as well
   as 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 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 draft within the
   Bridge WG, there was not sufficient interest to complete its
   publication as an RFC.  As a result, the draft has now expired.

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 re-
   writing of part of [RFC1493].



IAB                           Informational                    [Page 15]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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 cut-backs.  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 lead 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.

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




IAB                           Informational                    [Page 16]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


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



IAB                           Informational                    [Page 17]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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.lX-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-802Liaison1] 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-802Liaison2].  This included a request from IEEE 802.11i for
   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



IAB                           Informational                    [Page 18]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   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.

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


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


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

Intellectual Property Statement

   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.

Disclaimer of Validity

   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



IAB                           Informational                    [Page 20]


INTERNET-DRAFT         IEEE 802/IETF Relationship        6 December 2005


   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







































IAB                           Informational                    [Page 21]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/