WDIFF

draft-aboba-ieee802-rel-02.txt --> draft-aboba-ieee802-rel-03.txt

Network Working Group Les Bell
INTERNET-DRAFT 3Com Europe Limited
Category: Informational Dan Romascanu
<draft-aboba-ieee802-rel-02.txt>
<draft-aboba-ieee802-rel-03.txt> Avaya Inc.
23 December 2003
1 April 2005 Bernard Aboba
Microsoft Corporation

History of the IEEE 802/IETF Relationship

This document is an Internet-Draft

By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and is any of which I become aware will be disclosed, in full conformance accordance with all
provisions of Section 10 of
RFC 2026. 3668.

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.

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
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 October 22, 2005.

Abstract

Since the mid 1990s, IEEE 802 and IETF have cooperated in the
development of SNMP MIBs and AAA applications. This document
describes the history of that cooperation, and the policies and
procedures that have developed in order to coordinate between the two
organizations.

Bell, Romascanu & Aboba Informational [Page 1]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003 1 April 2005

Table of Contents

1. Introduction .......................................... 3
2. MIB Development ....................................... 3
2.1 Bridge MIB ...................................... 3
2.2 MAU and Hub MIBs ................................ 3
2.3 802.1p/Q MIB .................................... 4
2.4 802.3ad and 802.1X MIBs ......................... 5
2.5 802.1t, 802.1u, 802.1v and 802.1w MIBs .......... 6
3. AAA/EAP ............................................... 6
3.1 IEEE 802.1X ..................................... 7
3.2 IEEE 802.11i .................................... 8
3.3 IEEE 802.11F .................................... 9
4. Recent Developments ................................... 10
5. Recommendations ....................................... 12
6. Security Considerations ............................... 13
7. IANA Considerations ................................... 14
8. References ............................................ 14
8.1 Informative References .......................... 14
Acknowledgments .............................................. 18
Authors' Addresses ........................................... 18
Intellectual Property Statement .............................. 19
Disclaimer of Validity ....................................... 19
Copyright Statement .......................................... 19

Bell, Romascanu & Aboba Informational [Page 2]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

1. Introduction

Since the late 1980s, participants in IEEE 802 and the IETF have
cooperated in the development of MIBs and AAA applications relating
to IEEE standards. This has included the Bridge MIB [RFC1493], the
Hub MIB [RFC2108], MAU MIB [RFC2668], revisions to the Ethernet-like
Interfaces MIB [RFC2665], the WAN Interfaces Sublayer MIB [WISMIB],
the Power Ethernet MIB [PETH], multicast filtering and VLAN extension
MIB [RFC2674], the IEEE 802.1X MIB [8021XMIB], IEEE 802.1X RADIUS
usage guidelines [RFC3580], RADIUS/EAP [RFC3579], the revised EAP
specification [RFC2284bis], [RFC3748], and the EAP State Machine specification
[EAPSTATE]. This document describes the history of the IEEE 802/IETF
relationship, as well as the policies and procedures that have been
put in place to encourage cooperation.

2. MIB Development

2.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 [IEEE8021D] [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 exertise 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.

2.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 [IEEE8023], [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

Bell, Romascanu & Aboba Informational [Page 2] 3]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003 1 April 2005

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
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 [RFC2668] now being revised to accommodate
10 Gbps Ethernet.
- The Ethernet-like Interfaces MIB was not originally a work item
of the HUBMIB WG, but since the publication of [RFC2665] the WG
has taken responsibility for a revision, which is now in progress.
- The WAN Interfaces Sublayer MIB [WISMIB], and the Power Ethernet MIB
[PETH] are relatively new items in IEEE 802.3 and the IETF HUBMIB WG,
and are currently under review by the IESG.

In 2000, an official liason liaison was established between IEEE 802.3 and
the IETF HUBMIB WG, and Dan Romascanu was appointed IETF liason. liaison.
The conditions of the liason 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 user name and
password for IEEE 802.3 document access are not for publication on
any IETF Web site or mail list.

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

Bell, Romascanu & Aboba Informational [Page 3] 4]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003 1 April 2005

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.

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.

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

Bell, Romascanu & Aboba Informational [Page 4] 5]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003 1 April 2005

To solicit additional review, the IEEE 802.1X MIB was re-published as
an Internet-Draft [8021XMIB] within the Bridge WG. This occurred
after publication of [IEEE8021X]. [IEEE-802.1X].

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

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.

3. AAA/EAP

Since the late 1990s, IEEE 802.1 has been involved in work relating
to authentication and authorization [IEEE8021X], [IEEE-802.1X], which has lead to
uncovering
discovery of issues in several IETF specifications, including
[RFC2284],
[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 liason liaison arrangement has
been devised that has so far been relatively successful.

More recently, 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 802.11F have also
become dependent on EAP and AAA work. This relationship is still evolving, but is somewhat was more
challenging since IEEE 802.11 has a need for features such as RADIUS extensions,
new required development of EAP methods and an
the EAP Keying Framework that represent Key Management Framework, which represented substantial new
IETF work, as opposed to the clarifications and updates that have been required by
IEEE 802.1. As a result, the
likelihood of IETF process delays affecting completion of IEEE
standards is considerably greater. Going forward, the IETF and IEEE
802 will need to work to resolve the tension between timely delivery

Bell, Romascanu & Aboba Informational [Page 5] 6]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

of standards and the need for thorough IETF review. 1 April 2005

3.1. IEEE 802.1X

IEEE 802.1X-2001 [IEEE8021X] [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 [IEEE8021X], 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 which was eventually published
as [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, and so implementations. To address
this, a non-normative RADIUS usage appendix was added to [IEEE8021X],
[IEEE-802.1X], and subsequently published as [RFC3580].

Subsequent to the publication of [IEEE8021X], [IEEE-802.1X], a formal analysis of
the IEEE 802.1X state machine by the University of Maryland disclosed
several security issues [Mishra]. After discussion Discussion within IEEE
802.1aa, the group chartered 802.1
pointed to revise IEEE 802.1X, it was decided
that the issues were the result of lack of clarity in [RFC2284], and which resulted from the
absence of an a specification for the EAP state machine document. specification.

At that time, work on EAP was handled within the IETF PPPEXT WG, which was
largely inactive. In order to handle undertake work on a revised EAP
specification [RFC2284bis] as well as an the specification of the EAP state machine document, machine, the
IETF EAP WG was formed in July 2002. Bernard Aboba, a participant in
IEEE 802.1X and IEEE 802.1aa, 802.1 as well as PPPEXT was named co-chair.

Work on the EAP state machine [EAPSTATE] and [RFC2284bis]
specifications have 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 in some cases revisions to IEEE 802.1X [IEEE8021aa]. [IEEE-802.1X-2004]. The revised
RADIUS/EAP specification [RFC3579] has been was also reviewed within EAP WG, although it is not a
since at that time the RADEXT WG work item.

A had not yet been formed.

The revision to IEEE 802.1X [IEEE8021aa] is now in progress, which
includes [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
- an EAP state machine, based on [EAPSTATE] [RFC3748] and [RFC2284bis]
[EAPSTATE]

Due to the deep dependencies between IEEE 802.1aa [IEEE-802.1X-2004], [RFC3748]
and EAP WG, [EAPSTATE], a
liason liaison was established between IEEE 802.1X-REV and
the two groups IETF EAP WG in August 2002. This
enables enabled members of the IETF EAP
WG to obtain access to the IEEE 802.1aa

Bell, Romascanu & Aboba Informational [Page 6]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

work-in-progress. 802.1X revision in progress.

IEEE 802 groups are duty bound to consider all comments received,

Bell, Romascanu & Aboba Informational [Page 7]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

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. Currently IEEE 802.1aa 802.1X-REV and IEEE 802.11i ballots are were
announced on the EAP WG mailing list, as are IEEE 802 interim meeting
arrangements.

Similarly, during the IEEE 802.1aa 802.1X-REV ballot process, comments have been were
received relating to [RFC2284bis], [RFC3748], [EAPSTATE], and [RFC3579]. These
comments are were tracked on the EAP WG Issues List, and are reflected 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 in
on IEEE 802.1aa 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 IEEE 802.1aa Sponsor Ballot, in order to ensure that RFC #s
numbers would be assigned in time, so as to avoid delaying
publication of IEEE 802.1aa.
publication.

Overall, despite the complex inter-dependencies between IEEE 802.1aa
[IEEE-802.1X-2004], [RFC3748] and IETF specifications, [EAPSTATE], the relationship has been relatively
successful. documents were
produced without undue delay. This is was largely due to the work of a group of
contributors who have been
joint participants in IEEE 802.1aa 802.1 and the IETF EAP WG.

3.2. IEEE 802.11i

IEEE 802.11i is was chartered with security enhancements to IEEE 802.11.
[IEEE-802.11]. Since IEEE 802.11i has chosen to utilize [IEEE-802.11i] utilized IEEE 802.1X, IEEE 802.11i
depends it depended
on the IEEE 802.1X revision-in-progress [IEEE8021aa]. [IEEE-802.1X-2004]. As a result, IEEE 802.11i and IEEE 802.1aa have in the past 802.1 held
joint meetings at IEEE 802 plenaries and have established a liason liaison
arrangement that permits permitted members of either group (as well as EAP WG
participants) access to IEEE 802.11i work-in-progress.

Since IEEE 802.11i depends [IEEE-802.11i] depended on IEEE 802.1aa, IEEE 802.11i inherits
IEEE 802.1aa [IEEE-802.lX-2004], it inherited the
dependencies on IETF work, of [IEEE-802.1X-2004], including work on EAP, EAP
methods,
methods and AAA support for EAP. In addition, since IEEE 802.11i
uses
utilized EAP for key management whereas [IEEE8021X] [IEEE-802.1X] does not, there is an
additional dependency on security requirements arose with respect to EAP Key management [EAPKey].

Bell, Romascanu & Aboba Informational [Page 7]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003 methods.

In February 2002, IEEE 802.11 sent a liason liaison letter to the IESG
[IEEE802Liaison1] 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

Bell, Romascanu & Aboba Informational [Page 8]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

2003, another liason liaison letter was presented, providing further
clarifications on requirements for EAP method work [IEEE802Liaison2].
This included a request from IEEE 802.11i for the EAP WG to consider
changing the mandatory-to-implement EAP method within [RFC2284bis], [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 Internet Draft RFC and that the EAP WG consider the
security requirements for EAP methods in various situations. These requirements were subsequently included within
[RFC2284bis]. It was
recommended not to change the mandatory-to-
implement mandatory-to-implement method, since
the EAP WG was not chartered to do work on methods. However, work on additional methods may be included in it was
decided to produce a
future version of document describing the EAP WG charter. method requirements
for WLAN usage. This document was subsequently published as
[RFC4017].

Most recently, IEEE 802.11i 802.11r has been involved in discussions relating
to fast handoff, which may potentially require RADIUS AAA extensions
[Arbaugh] as well
as changes to the EAP Key hierarchy [EAPKey]. hierarchy. However, the direction of this
work has not yet been determined so that no liason liaison request has been
formulated yet.

In April 2003 Dorothy Stanley was appointed liason liaison from IEEE 802.11
to the IETF, in order to help coordinate between IEEE 802.11 and the IETF EAP
WGs, including AAA, BMWG, CAPWAP, and AAA WGs. EAP.

3.3. IEEE 802.11f 802.11F

IEEE 802.11f is 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 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, as well
as new RADIUS commands, defined through definition of additional
values for the RADIUS Service-Type attribute. As a result, IETF

Bell, Romascanu & Aboba Informational [Page 8]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003
review was not required under the IANA considerations included in
[RFC2865]. Subsequently, the RADIUS IANA considerations were revised
so as to require IETF review [RFC3575] in most cases.

Bell, Romascanu & Aboba Informational [Page 9]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

No liason liaison arrangement was developed between IEEE 802.11f 802.11F and relevant IETF
WGs such as AAA WG or SEAMOBY WG, so as to allow IETF participants
access to the IEEE 802.11f 802.11F specifications prior to publication. Once
IEEE 802.11f 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 802.11F RADIUS extensions
were rejected.

Currently

Since IEEE 802.11F was a Recommended Practice, it was required that
the plan document be renewed by July 2004. Since that deadline passed
without ratification, IEEE 802.11F is to handle issues in now deprecated. This raises
the IEEE 802.11f RADIUS
extensions via question of whether the IEEE 802.11 interpretation process, and
subsequently, if warranted, RADIUS parameters allocated for use by a group chartered to revise
IEEE
802.11f. 802.11F should be reclaimed.

4. Summary Recent Developments

In order to improve communications between the IETF and Recommendations

Based on IEEE 802,
members of the above history, IESG and IAB (including Bert Wijnen, James Kempf and
Bernard Aboba) met with the IEEE 802 Executive Committee in
Vancouver, Canada during the IEEE 802 Plenary in January 2004. At
that meeting a number of issues were discussed and the following changes are recommended:
procedures were put in place:

[a] Increased reliance on online communication. In these times of
travel restriction it is important to be able Access to conclude IETF/IEEE IEEE 802 cooperative projects successfully without requiring physical
attendance at both IETF and archives. Access to IEEE 802 meetings. This standards more
than 12 months old is somewhat provided free of
a challenge because in charge on the past having participants attend both
standards bodies has been an important contributor to success.

[b] Development of a framework agreement. IEEE 802
website via the Get IEEE 802 Program [GetIEEE802]. Access to IEEE work-in-
progress documents
802 work-in-progress has frequently arisen as an issue in
cooperation between IETF and IEEE 802. The IEEE 802 and IETF follow very
different models with respect to document access. While IETF
Internet-Drafts are freely available, IEEE 802 keeps documents
restricted to the participants in the IEEE 802 standards process.
Within IEEE 802, a participant is required to physically attend at
least one IEEE meeting. While in the past IETF WGs have
successfully negotiated access to IEEE 802 work-in-progress, each
instance has been handled separately and may take significant time
to set up. Going forward
it would be helpful In order to develop more easily enable document access for IETF
WGs collaborating with IEEE 802, a framework agreement between liaison statement was sent to
the IETF in July 2004 by Paul Nikolich, Chair of IEEE 802 and IETF so that this
[IEEE802Liaison], describing a general process by which IETF WGs
could be concluded quickly
and a new negotiation would not be required each time cooperation
is required.

[c] Increased review of IEEE MIBs. It would be helpful obtain access to encourage
wider review of MIBs developed by IEEE 802 WGs, via liaisons with work-in-progress. IEEE 802 Chairs
have the IETF authority to grant membership in their WGs, and by permitting access can use
this authority to relevant IEEE 802 draft
documents grant membership to an IETF WG chair upon
request. The IETF WG members. Were chair will be provided with access to the
username/password for the IEEE 802 draft documents WG archives, and is permitted to be
made more readily available,
share that information with members of the IETF WG. Since it is
possible to participate in IETF without attending meetings, or even
joining a mailing list, IETF WG chairs could encourage WG will provide the information
with anyone who requests it. However, since IEEE 802 work-in-

Bell, Romascanu & Aboba Informational [Page 9] 10]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

members 1 April 2005

progress is copyrighted, incorporating material into IETF documents
or posting the username/password on mailing lists or websites is
not permitted.

[b] New work review. In order to enable IEEE 802 review the MIBs of proposed
IETF WG charters, as soon well as to enable IETF review of proposed IEEE
802 PARs, it was proposed that the drafts are considered
stable enough.

It is recommended New Work mailing list be used.
The IEEE 802 Executive Committee was subscribed to the list, so
that SNMP MIBs written in they can receive proposed IETF WG Charters. Paul Congdon,
Vice-Chair of IEEE 802.1 took on the task of posting proposed IEEE follow
802 PARs to the MIB
guidelines [GUIDELINES] and be reviewed New Work list as part well. Where a new work
announcement is of particular interest, it is also (manually)
forwarded to the SNMP quality
control process ('MIB Doctors').

[d] Increased review of relevant IETF and IEEE AAA applications. It would be helpful 802 mailing lists.

[c] MIB review. In order to encourage wider review of AAA applications MIBs developed
by IEEE 802
WGs. This can WGs, it was suggested that IEEE 802 working groups be accomplished via
allowed to request assignment of an IETF MIB Doctor to assist in a liaison with
MIB review. The MIB Doctor review process is designed to be
lighter weight than past arrangements which involved chartering of
a work item within an IETF WG. With travel budgets under pressure,
it has become increasingly difficult for companies to fund
employees to attend both IEEE 802 and IETF meetings. It is
recommended that SNMP MIBs developed in IEEE 802 follow the MIB
guidelines [GUIDELINES] and be reviewed as part of the SNMP quality
control process ('MIB Doctors'). 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 David Harrington has agreed to review IEEE
802.1 MIBs.

[d] Document review. 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.
Similarly, the IETF may request review of a document by IEEE 802.
This process has been used in several cases. As part of the IETF
CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP
Taxonomy Document [CAPARCH]; Dorothy Stanley organized an adhoc
group for this purpose. Other documents reviewed by IEEE 802.11
include [IDSEL] and [IABLINK]. Within IETF, IEEE 802 comments are
resolved using normal WG and IETF processes. It is also envisaged
that this process may be used to enable the IETF BMWG WG to review
the work of IEEE 802.11TGT.

Bell, Romascanu & Aboba Informational [Page 11]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

5. Recommendations

Based on the above history, the following changes are recommended:

[a] Increased reliance on online communication. In these times of
travel restriction it is important to be able to conclude IETF/IEEE
802 cooperative projects successfully without requiring physical
attendance at both IETF and IEEE 802 meetings. This is somewhat of
a challenge because in the past having participants attend both
standards bodies has been an important contributor to success.

[b] Earlier review of New Work. While the New Work list has been
successful in keeping IETF and IEEE 802 management appraised of new
WGs, the posting of proposed Charter and PARs has often come too
late to significantly affect the process. 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. It is therefore
recommended that IETF and IEEE 802 explore mechanisms for earlier
consultation on new work items.

[c] AAA review. In general, it is not advisable for IEEE 802 to
develop its own AAA applications, particularly when those
applications involve AAA key management [Housley56]. IEEE 802 WGs
requiring new AAA applications are encouraged to alert the IETF to
those requirements, rather than proceeding on their own. This can
be accomplished via a liaison with the IETF AAA or RADEXT WGs.
Where new attributes are required rather than a new application,
the attributes may be included in the IEEE 802 attributes draft
currently under development within the IETF RADEXT WG, or if the
attributes are not appropriate for inclusion there, an individual
submission can be prepared, and review can be requested from the
RADEXT, AAA, EAP WGs. In addition the AAA Doctors list has been
created within the IETF Operations and Management Area Directorate.
The AAA WG, Doctors serve a similar function to the MIB Doctors. While
the AAA Doctors have not yet been called upon to assist with and by permitting access
review AAA work outside of the IETF, it is conceivable that group
could be of assistance to IEEE 802 work-in-progress to IETF WGs with a demonstrated need. The newly approved RADIUS IANA
Considerations document [RFC3575] now requires such a review in
most cases.

[e] their AAA requirements.

[d] Preference for IETF standard AAA attributes, and a single IEEE
Vendor-Specific attribute format. Currently several standards
organizations, including IEEE, IEEE 802, have taken to allocating their
own vendor-specific AAA attributes. As noted in [RFC3575]:

RADIUS defines a mechanism for Vendor-Specific extensions
(Attribute 26) and the use of that should be encouraged instead

Bell, Romascanu & Aboba Informational [Page 12]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

of allocation of global attribute types, for functions specific
only to one vendor's implementation of RADIUS, where no
interoperability is deemed useful.

Since IEEE 802 vendor-specific attributes are not specific to only
one vendor's implementation of RADIUS and interoperability is
generally deemed useful, use of vendor-specific attributes
represents a last resort. For AAA attributes of general utility,
and particularly those useful in multiple potential applications,
allocation from the IETF standard attribute space is preferred.
The RADIUS IANA Considerations [RFC3575] now requires review for
many RADIUS parameter allocations. With respect to EAP, [RFC3748]
describes the procedures for IANA allocation of EAP protocol
parameters, including Type values.

Where allocation of Vendor-Specific Attributes (VSAs) is required,
it is recommended that IEEE 802 create a uniform format for all of
IEEE 802, rather than letting each IEEE 802 WG create their own
format. The format defined in IEEE 802.11f [IEEE-802.11F] is inappropriate for
this, since it only defines a single octet Type field, allowing for
only 255 attributes.

5. Now that [IEEE-802.11F] has been deprecated,
it is recommended that IEEE 802 abandon the IEEE 802.11F vendor-
specific attribute format in order to design a new vendor-specific
attribute format suitable for use by all of IEEE 802.

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

Bell, Romascanu & Aboba Informational [Page 10]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003
to be able to circulate a version of its security standard-in-
progress for review. A liason liaison between an IEEE 802 group and a
relevant IETF WG can assist in obtaining the necessary level of
review.

In addition, experience

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 [RFC2284], the process of developing the EAP state
machine specification has proven [EAPSTATE] proved useful in uncovering aspects
requiring clarification, and the joint review process has exposed by 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

Bell, Romascanu & Aboba Informational [Page 13]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

security vulnerabilities of the EAP/AAA system. As described in
[Housley56], 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.

6. IANA Considerations

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

7. References

7.1. Informative references most cases.

7. IANA Considerations

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

8. References

8.1. Informative References

[CAPARCH] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access Points
(CAPWAP)", draft-ietf-capwap-arch-06.txt, Internet draft
(work in progress), November 2004.

[IDSEL] Adrangi, F., Lortz, V., Bari, F. and P. Eronen, "Identity
selection hints for Extensible Authentication Protocol
(EAP)", draft-adrangi-eap-network-discovery-11.txt,
Internet draft (work in progress), March 2005.

[GetIEEE802] IEEE Standards Association Get IEEE 802 (R) Program,
http://standards.ieee.org/getieee802/

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

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997.

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

Bell, Romascanu & Aboba Informational [Page 14]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.

Bell, Romascanu & Aboba Informational [Page 11]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

[RFC2665] Flick, J. and J. Johnson, "Definitions of Managed Objects
for the Ethernet-Like Interface Types", RFC 2665, August
1999.

[RFC2668] Smith, A., et al., "Definitions of Managed Objects for
IEEE 802.3 Medium Attachment Units (MAUs)", RFC 2668,
August 1999.

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

[RFC3162]

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and D. Mitton, "RADIUS J. Roese,
"IEEE 802.1X RADIUS Usage Guidelines", RFC 3580,
September 2003.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and IPv6", H.
Levkowetz, "Extensible Authentication Protocol (EAP)",

Bell, Romascanu & Aboba Informational [Page 15]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

RFC
3162, August 2001. 3748, June 2004.

[RFC4017] Stanley, D., Walker, J. and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.

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

[RFC3580] Congdon, P., et al., "IEEE 802.1X RADIUS Usage
Guidelines", RFC 3580, September 2003.

[IEEE8021X]

[IEEE-802.1X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.

[IEEE8021aa]

[IEEE-802.1X-2004]
IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1aa/D7.1,

Bell, Romascanu & Aboba Informational [Page 12]

INTERNET-DRAFT IEEE 802/IETF History 23 802.1X-2004,
December 2003

November 2003. 2004.

[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
Overview and Architecture, ANSI/IEEE Std 802, 1990.

[IEEE8021D]

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

[IEEE8021Q]

[IEEE-802.1Q] IEEE Standards for Local and Metropolitan Area Networks:
Draft Standard for Virtual Bridged Local Area Networks,
P802.1Q, January 1998.

[IEEE8023]

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

[IEEE8025]

[IEEE-802.5] ISO/IEC 8802-5 Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks - Common
specifications - Part 5: Token ring access method and
physical layer specifications, (also ANSI/IEEE Std
802.5-1998), 1998.

[802.11]

Bell, Romascanu & Aboba Informational [Page 16]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

[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 Std.
802.11-1999, 1999.
802.11-2003, 2003.

[IEEE-802.11i] Institute of Electrical and Electronics Engineers,
"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 802.11i, July
2004.

[WISMIB] Heard, C., "Definitions of Managed Objects for the
Ethernet WAN Interface Sublayer", Internet draft (work in
progress), draft-ietf-hubmib-wis-mib-07.txt, March 2003.

[PETH] Berger, A., and D. Romascanu, "Power over Ethernet (DTE
Power via MDI) MIB", draft-ietf-hubmib-power-ethernet-
mib-04.txt, Internet draft (work in progress), December
2002.

[Arbaugh] Arbaugh, W. and B. Aboba, "Handoff Extension to RADIUS",
draft-irtf-aaaarch-handoff-04.txt, Internet draft (work

Bell, Romascanu & Aboba Informational [Page 13]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

in progress), November 2003.

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

[EAPSTATE] Vollbrecht, J., et al., Eronen, P., Petroni, N. and Y. Ohba,
"State Machines for EAP Peer and Authenticator", draft-ietf-eap-statemachine-01.pdf, draft-
ietf-eap-statemachine-06.pdf, Internet draft (work in
progress), December 2004.

[Housley56] Housley, R., "Key Management in AAA", Presentation to the
AAA WG at IETF 56,
http://www.ietf.org/proceedings/03mar/slides/aaa-
5/index.html, March 2003.

[IABLINK] Aboba, B., "Architectural Implications of Link
Indications", draft-iab-link-indications-01.txt, Internet
draft (work in progress), November 2003.

[EAPKey] January 2005.

[KEYFRAME] Aboba, B. , et al., "EAP Keying B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-
eap-keying-02.txt, draft-ietf-eap-keying-06.txt,
Internet draft (work in progress),
November 2003. April 2005.

Bell, Romascanu & Aboba Informational [Page 17]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

[IEEE80211Liaison1]
IEEE 802.11 liaison letter to Harald Alvestrand, February
2002, http://www.ietf.org/IESG/LIAISON/ieee802.11.txt
http://www.ietf.org/IESG/LIAISON/ieeeIEEE-802.11.txt

[IEEE80211Liaison2]
Input To IETF EAP Working Group on Methods and Key
Strength, March 2003,
http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt

[RFC3575]

[IEEE802Liaison]
IEEE 802 Liaison letter to Bert Wijnen and Bernard Aboba, B., "IANA Considerations for RADIUS", RFC 3575,
July 2003. 26, 2004,
http://www.ietf.org/IESG/LIAISON/file41.pdf

[GUIDELINES] Heard, C.M., "Guidelines for MIB Authors and Reviewers",
draft-ietf-ops-mib-review-guidelines-01.txt, Reviewers of MIB
Documents", draft-ietf-ops-mib-review-guidelines-04.txt,
Internet draft (work in progress), February 2003. 2005.

Acknowledgments

The authors would like to acknowledge Tony Jeffree, Fred Baker and
Paul Langille for contributions to this document.

Authors' Addresses

Les Bell
3Com Europe Limited
3Com Centre, Boundary Way
Hemel Hempstead Herts. HP2 7YU
UK

EMail: Les_Bell@3com.com
Phone: +44 1442 438025

Bell, Romascanu & Aboba Informational [Page 14]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

Dan Romascanu
Avaya Inc.
Atidim Technology Park, Bldg. #3
Tel Aviv, 61131
Israel

EMail: dromasca@avaya.com
Phone: +972 3 645 8414

Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052

Bell, Romascanu & Aboba Informational [Page 18]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329

Bell, Romascanu & Aboba Informational [Page 19]

INTERNET-DRAFT IEEE 802/IETF History 1 April 2005

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.

Full Copyright Statement

Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are

Bell, Romascanu & Aboba Informational [Page 15]

INTERNET-DRAFT IEEE 802/IETF History 23 December 2003

included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose

Disclaimer of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English. The limited permissions granted above are perpetual and
will not be revoked by the Internet Society or its successors or
assigns. Validity

This document and the information contained herein is 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 DISCLAIMS 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.

Expiration Date

Copyright (C) The Internet Society (2005). This memo document is filed as <draft-aboba-ieee802-rel-02.txt>, subject
to the rights, licenses and expires
June 22, 2004. restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Bell, Romascanu & Aboba Informational [Page 16] 20]

----