Internet Architecture Board S. Dawkins, Ed.
Internet-Draft Huawei
Obsoletes: 4441 (if approved) P. Thaler
Intended status: Informational Broadcom
Expires: April 20, 2014 D. Romascanu
AVAYA
October 17, 2013
The IEEE 802 / IETF Relationship
draft-iab-rfc4441rev-05.txt
Abstract
This document describes the standardization cooperation between
Project 802 of the Institute of Electrical and Electronic Engineers
(IEEE) and the Internet Engineering Task Force (IETF). This document
obsoletes RFC 4441.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 20, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Dawkins, et al. Expires April 20, 2014 [Page 1]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Why Cooperate? . . . . . . . . . . . . . . . . . . . . . . . 3
3. Guidance on Cooperation . . . . . . . . . . . . . . . . . . . 4
3.1. Organization, Participation and Membership . . . . . . . 4
3.1.1. IEEE 802 Organization, Participation and Membership . 4
3.1.2. IETF Organization, Participation and Membership . . . 6
3.1.3. Structural Differences . . . . . . . . . . . . . . . 8
3.1.4. Cultural Differences . . . . . . . . . . . . . . . . 9
3.2. Exchange of Information About Work Items . . . . . . . . 11
3.2.1. How IEEE 802 is informed about active IETF work items 11
3.2.2. How IETF is informed about active IEEE 802 work items 11
3.2.3. Overview of new work proposal notification . . . . . 12
3.2.4. The New-Work mailing list . . . . . . . . . . . . . . 12
3.2.5. How IEEE 802 is informed about proposed new IETF work
items . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.6. How IEEE 802 comments on proposed new IETF work items 13
3.2.7. How IETF is informed about proposed new IEEE 802 work
items . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.8. How IETF comments on proposed new IEEE 802 work items 14
3.2.9. Other Mechanisms for Coordination . . . . . . . . . . 14
3.3. Document Access . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. IEEE 802 Documentation System . . . . . . . . . . . . 15
3.3.2. Access to IETF Documents . . . . . . . . . . . . . . 18
3.4. Participation in Document Review and Approval . . . . . . 18
3.4.1. IEEE 802 draft review and balloting processes and
opportunities for IETF participation . . . . . . . . 18
3.4.2. IETF draft review and approval processes and
opportunities for IEEE 802 participation . . . . . . 20
3.5. Solicited Review Processes . . . . . . . . . . . . . . . 21
3.6. Liaison Managers and Liaison Statements . . . . . . . . . 21
3.6.1. Liaison Managers . . . . . . . . . . . . . . . . . . 22
3.6.2. Liaison Statements . . . . . . . . . . . . . . . . . 22
4. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 22
5. Cross-Referencing Documents in IEEE 802 and IETF . . . . . . 23
6. Protocol Parameter Allocation . . . . . . . . . . . . . . . . 24
6.1. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. IEEE Registration Authority . . . . . . . . . . . . . . . 24
6.3. IEEE 802 Registration at IEEE 802 working group level . . 25
6.4. Joint-use registries . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Current examples of IEEE 802 and IETF Work Item
Dawkins, et al. Expires April 20, 2014 [Page 2]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Cooperation . . . . . . . . . . . . . . . . . . . . 29
A.1. MIB Review . . . . . . . . . . . . . . . . . . . . . . . 29
A.2. AAA Review . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Pointers to Additional Useful Information . . . . . 30
B.1. IEEE 802 Information that may be useful to IETF
participants . . . . . . . . . . . . . . . . . . . . . . 30
B.2. IETF Information that may be of use to IEEE 802
participants . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction and Scope
This document contains a set of principles and guidelines that serves
as the basis for establishing coordination between Project 802 of the
Institute of Electrical and Electronics Engineers (IEEE 802) and the
Internet Engineering Task Force (IETF), a program under the Internet
Society (ISOC) organizational umbrella [RFC4071], with the objective
of securing timely development of technical specifications that
facilitate maximum interoperability with existing (fixed and mobile)
Internet systems, devices, and protocols. Each organization will
operate according to their own rules and procedures including rules
governing IPR policy, specification elaboration, approval and
maintenance.
This document is intended to improve practices for cooperation
between the two organizations that are already in place, but does not
change any of the formal practices or procedures of either
organization.
This version of the document responds to comments received during the
IAB Call for Comments.
2. Why Cooperate?
IETF 802 and the IETF cooperate because each organization uses
standards produced by the other organization, and produces standards
that are dependent on standards produced by the other organization.
This dependency may extend to carrying attributes in protocols that
reflect technologies defined by the other organization.
IETF 802 and the IETF are independent standards organizations, and
the benefits of cooperation come at the cost of coordination
overhead, so the benefits of coordination must outweigh the cost.
The IETF benefits from coordination by obtaining improved access to
IEEE 802 expertise on the widely-deployed and widely-used IEEE 802
Local Area Network architecture [ARCH802].
Dawkins, et al. Expires April 20, 2014 [Page 3]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
IEEE 802 benefits from coordination by obtaining improved access to
IETF expertise on IP datagram encapsulation, routing, transport,
security, and specific applications of interest to IEEE 802.
One of the primary drivers for [RFC4441] was to allow effective
cooperation between IEEE 802 and the IETF during a time where
downward pressure on travel budgets was making it increasingly
difficult for the same participants to attend face-to-face meetings
in both organizations. That pressure has continued in the
intervening years.
Early identification of topics of mutual interest allows the two
organizations to cooperate in a productive way, and helps each
organization avoid developing specifications that overlap or conflict
with specifications developed in the other organization.
3. Guidance on Cooperation
This section describes how existing processes within the IETF and
IEEE 802 may be used to enable cooperation between the organizations.
3.1. Organization, Participation and Membership
IEEE 802 and IETF are similar in some ways, but different in others.
When working on projects that are of interest to both organizations,
it's important to understand these similarities and differences.
3.1.1. IEEE 802 Organization, Participation and Membership
The IEEE Standards Association (IEEE-SA) is the standards setting
body of the IEEE. The IEEE-SA Standards Board oversees the IEEE
standards development process.
The IEEE-SA Standards Board supervises what IEEE calls "sponsors" -
IEEE entities that develop standards. The IEEE 802 LAN/MAN Standards
Committee is a sponsor that develops and maintains networking
standards and recommended practices for local, metropolitan, and
other area networks, using an open and accredited process, and
advocates them on a global basis. The most widely used standards are
for Ethernet, Bridging and Virtual Bridged LANs, Wireless LAN,
Wireless PAN, Wireless MAN, Wireless Coexistence, Media Independent
Handover Services, and Wireless RAN. An individual Working Group
provides the focus for each area.
In IEEE 802, work is done in Working Groups operating under an
Executive Committee. Each Working Group is led by a Working Group
Chair. Most Working Groups have one or more Task Groups. A Task
Group is responsible for a project or group of projects.
Dawkins, et al. Expires April 20, 2014 [Page 4]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
The Executive Committee is comprised of the Executive Committee
Chair, Executive Committee Officers (e.g., Vice-Chairs, Secretaries,
Treasurer) and Working Group Chairs.
A good place to learn more is the IEEE 802 Home Page, at . An IEEE 802 Orientation for new participants that
gives an overview of IEEE 802 process is available from the home
page.
The IEEE 802 Executive Committee and all Working Groups meet three
times per year at plenary sessions. Plenary sessions are held in
March, July and November. Most Working Groups hold interim meetings,
usually in January, May and September. The meeting schedule can be
found at .
A Study Group is a group formed to consider starting a new project
and, if new work is found to be suitable, to develop an IEEE Project
Authorization Request (PAR - similar in purpose to an IETF working
group charter). A Study Group may operate under a Working Group or
under the Executive Committee depending on whether the new work under
consideration falls within the scope of an existing Working Group.
Study Groups are expected to exist for a limited time, usually for
one or two plenary cycles, and must be authorized to continue at each
plenary if they have not completed their work.
Participation in IEEE 802 Working Groups is at the level of
individuals, i.e., participants are human beings and not companies,
and is open. Individuals are required to declare their affiliation
(i.e., any individual or entity that financially or materially
supports the individual's participation in IEEE 802).
Working Groups maintain membership rosters, with voting membership
attained on the basis of in-person meeting attendance. Retention of
voting membership generally requires continued attendance and
responsiveness to letter ballots. Voting membership allows one to
vote on motions and on Working Group Ballots of drafts. All drafts
are also balloted by a Sponsor ballot pool before approval as
standards. Joining a Sponsor ballot pool does not require
participation in meetings. One does not need to be a voter to
comment on drafts and the Working Group is required to consider and
respond to all comments submitted during Working Group and Sponsor
ballots.
To foster ongoing communication between IEEE 802 and IETF, it is
important to identify and establish contact points within each
organization. IEEE 802 contact points may include:
Dawkins, et al. Expires April 20, 2014 [Page 5]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
IEEE 802 Working Group Chair: An IEEE 802 Working Group chair is an
individual who is assigned to lead the work of IEEE 802 in
a particular area. IEEE 802 Working Group chairs are
elected by the Working Group and confirmed by the Executive
Committee for a 2 year term. The Working Group Chair
provides a stable contact point for cooperation between the
two organizations for a given topic.
IEEE 802 Task Group (or Task Force) Chair: An IEEE 802 Task Group
chair is an individual who is assigned to lead the work on
a specific project or group of projects within a Working
Group. The Task Group Chair often serves for the duration
of a project. The Task Group chair provides a stable
contact point for cooperation between the two organizations
on a particular project.
IEEE 802 Study Group Chair: An IEEE 802 Study Group Chair is an
individual assigned to lead consideration of new work and
development of an IEEE 802 Project Authorization Request
(PAR). The Study Group chair provides a stable contact
point for cooperation between the two organizations on a
study group topic.
IEEE 802 Liaisons: It may be beneficial to establish liaisons as
additional contact points for specific topics of mutual
interest. These contact points should be established early
in the work effort. The IEEE 802 and IETF projects may
select the same individual as their contact point, but this
is not required, so that two individuals each serve as
contact points for one project participating in the liaison
relationship.
Informal Contact points: Other informal contacts can provide useful
cooperation points. These include project editors who are
responsible for editing the drafts and work with the Task
Group Chairs to lead tracking and resolution of issues.
Joint members who are active in both the IEEE 802 and IETF
projects in an area can also aid in cooperation.
3.1.2. IETF Organization, Participation and Membership
The IETF Standards Process is defined in [BCP9]. The IETF working
group process is defined in [BCP25].
[BCP11] is a helpful description of organizations involved in the
IETF standards process. It can still be useful as an overview,
although details have changed since 1996.
Dawkins, et al. Expires April 20, 2014 [Page 6]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
In the IETF, work is done in working groups (WGs), and is mostly
carried out through open, public mailing lists rather than face-to-
face meetings.
WGs are organized into areas, and each area is managed by one or more
area directors. Collectively, the area directors constitute the
Internet Engineering Steering Group (IESG) [RFC3710].
The Internet Architecture Board (IAB) charter [RFC2850] assigns the
IAB several responsibilities relevant to this document:
1. IESG Appointment Confirmation ([BCP10])
2. Architectural Oversight
3. Standards Process Oversight and Appeal
4. Appointment of RFC Series ([RFC6635], [RFC6548]) and Internet
Assigned Number Authority (IANA) roles ([RFC6220])
5. Oversight of External Liaisons for the IETF
IESG and IAB members are selected using the Nomcom process defined in
[BCP10]. Working group chairs serve at the pleasure of their Area
Directors, as described in [BCP25].
IETF meets in plenary session three times per year. Some working
groups schedule additional interim meetings, which may be either
face-to-face or "virtual", but this is not true for most IETF working
groups. The preferred way to develop specifications is to do work on
mailing lists, reserving face-to-face sessions for topics that have
not been resolved through previous mailing list discussion.
Information about IETF plenary meetings is available at . Information about IETF working
group interim meetings is available on the IETF-Announce mailing list
(see for archives and
subscription information).
Participation in the IETF is open to anyone (technically, anyone with
access to e-mail sufficient to allow subscription to one or more IETF
mailing lists). All IETF participants act as individuals. There is
no concept of "IETF membership".
Dawkins, et al. Expires April 20, 2014 [Page 7]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
To foster ongoing communication between IEEE 802 and IETF, it is
important to identify and establish contact points within each
organization. IETF contact points may include Area Directors,
Working Group Chairs, and other points of contact who can help
communicate between IEEE 802 and IETF working groups.
The IETF is designed to be a "bottom-up" protocol engineering
organization - the leadership steers and manages, but does not direct
work in a top-down way. Technical agreements with "the IETF" are
based on the consensus of working group participants, rather than
negotiated with IETF leadership.
A good place to learn more is the IETF Home Page, at , and especially the "About the IETF" page at , selectable from the IETF Home Page.
The "Tao of the IETF" is also very helpful, especially for IEEE 802
participants who will also be participating in IETF working groups
and attending IETF meetings. It's available from .
3.1.3. Structural Differences
IEEE 802 and IETF have similar structures, but the names they use are
different, and even conflicting. For example, both IEEE 802 and IETF
use the term "Working group", but "working groups" means two very
different things in the two organizations.
Thumbnail comparison between IETF and IEEE 802 entities
IETF Area is similar to IEEE 802 Working Group
IETF Working Group is similar to IEEE 802 Task Group
IETF BOF is similar to IEEE 802 Study Group
Both IEEE 802 Working Groups and IETF Areas are large, long-lived,
and relatively broadly scoped, containing more narrowly chartered
entities (IEEE 802 Task Groups and IETF Working Groups), which tend
to be short-lived and narrowly chartered. IEEE 802 uses Study Groups
to develop proposals for new work, and these are analogous to IETF
Birds of a Feather ("BOF") sessions.
Several IETF Areas also have one or more directorates to support the
work of the area directors. Area directors often ask directorate
Dawkins, et al. Expires April 20, 2014 [Page 8]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
members to review documents or provide input on technical questions.
These directorates are often a source of expertise on specific
topics. The list of area directorates is at: .
IEEE 802 does not have a corresponding organizational entity.
3.1.4. Cultural Differences
IEEE 802 and IETF have cultures that are similar, but not identical.
Some of the differences include:
Consensus and Rough Consensus: Both organizations make decisions
based on consensus, but in the IETF, "consensus" can mean
"rough consensus, as determined by working group chairs".
In practice, this means that a large part of the community
being asked needs to agree. Not everyone has to agree, but
if someone disagrees, they need to convince other people of
their point of view. If they're not able to do that,
they'll be "in the rough" when "rough consensus" is
declared. Although IEEE Working Groups ultimately rely on
voting for decision making, they vary widely in their use
of consensus versus voting in the course of a meeting, and
in their attention to Robert's Rules.
Rough Consensus and Running Code: David Clark coined the phrase "We
reject kings, presidents and voting. We believe in rough
consensus and running code" in 1992, to explain IETF
culture. Although that's not always true today, the
existence of "running code" as a proof of feasibility for a
proposal often carries weight during technical discussions.
Some IEEE 802 standards may be amenable to prototype
implementation while the standard is still being developed,
while others are less so.
Voting: IEEE 802 Working Groups vary in their reliance upon voting
versus consensus, and in the breadth of coverage of an
individual motion, but ultimately, all rely upon a 75% vote
to decide technical issues, and a 50%+1 vote to decide
other issues. IETF working groups do not use voting.
Working group chairs may ask for a "show of hands" or "take
a hum" to judge backing for a proposal and identify
technical concerns and objections, but this is not
considered "voting".
Balance between mailing lists and meetings: Both organizations make
use of mailing lists. IETF working groups rely heavily on
mailing lists, where work is done, in addition at formal
Dawkins, et al. Expires April 20, 2014 [Page 9]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
meetings. The IETF requires all working group decisions to
be made (or, often in practice, confirmed) on mailing lists
- final decisions aren't made in meetings. IEEE 802
working groups typically meet face-to-face about twice as
often as IETF working groups (three IEEE 802 plenaries plus
three IETF 802 interim meetings each year, compared to
three IETF plenaries per year) and teleconferences are more
common in IEEE 802 than in most IETF working groups. Most
major decisions in IEEE 802 are made during plenary or
interim meetings, except for procedural decisions.
Attendance at meetings is critical to influencing decisions
and to maintaining membership voting rights.
Interim meetings: Both organizations use interim meetings (between
plenary meetings). IETF working groups schedule interim
meetings on an as-needed basis. IETF interim meetings may
be face-to-face or virtual. Most IEEE 802 WGs hold
regularly interim meetings three times a year in the middle
of the interval between two Plenary meetings. The
schedules and location of these meetings are typically
known many months in advance. IEEE 802 interim meetings
are face-to-face only. In addition to regularly scheduled
IEEE 802 interim meetings, teleconference and ad hoc
meetings are held on an as-needed basis.
Remote participation: Because the IETF doesn't make decisions at
face-to-face meetings, it's not absolutely necessary to
attend face-to-face meetings at all. Some significant
contributors don't attend most face-to-face IETF meetings.
Finding people interested in a proposal for new work, or
soliciting backing for your ideas is likely easier in a
face-to-face conversation, often in a hallway and sometimes
in a bar. IEEE 802 significant contributors almost always
attend face-to-face meetings. Participation in IEEE 802
meetings is a condition for WG membership.
Lifetime of Standards: IEEE 802 periodically reviews existing
standards. IETF standards-track documents may be updated
or obsoleted by newer standards-track documents, but there
is no formal periodic review for existing standards-track
documents. The status of specific IETF standards is
available through [DATATRACKER]. Because these status
changes happen independently, standards from each
organization may refer to documents that are no longer
standards in the other organization.
Overlapping terminology: As two independent standards development
organizations, IEEE 802 and IETF have developed
Dawkins, et al. Expires April 20, 2014 [Page 10]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
vocabularies that overlap. For instance, IEEE 802
"ballots" at several levels of the organization during
document approval, while IETF documents are only "balloted"
during IESG review, and the IESG uses "ballots" to indicate
that all technical concerns have been addressed, not to
indicate that the IESG agrees with a document - the
intention is to "discuss" technical issues with a document,
and "no" is not one of the choices on an IESG ballot.
EDITOR NOTE: the description of "rough consensus", including hums,
may be affected by discussions on http://datatracker.ietf.org/doc/
draft-resnick-on-consensus/, currently in IETF Last Call.
3.2. Exchange of Information About Work Items
The following sections outline a process that can be used to enable
each organization to stay informed about the other's active and
proposed work items.
EDITOR NOTE: Bernard has commented (a few times, most recently in
http://wiki.tools.ietf.org/group/iab/trac/ticket/337) about the
challenges of finding out about the need for coooperation early
enough to avoid problems. What improvements could we make to help
with that?
EDITOR NOTE: need to point out that individuals need to tell working
groups when they see need for coordination.
3.2.1. How IEEE 802 is informed about active IETF work items
The responsibility is on individual IEEE 802 working groups to review
the current IETF working groups to determine if there are any topics
of mutual interest. Working group charters and active Internet-
Drafts can be found on the IETF web site (). If an IEEE 802 working group identifies
a common area of work, the IEEE 802 working group leadership should
contact both the IETF working group chair and the area director(s)
responsible. This may be accompanied by a formal liaison statement
(see Section 3.6.2).
3.2.2. How IETF is informed about active IEEE 802 work items
The responsibility is on individual IETF working groups to
periodically review the information on the IEEE 802 web site to
determine if there is work in progress of mutual interest.
IEEE 802 Working Group status reports are published at the beginning
and end of each plenary at on the IEEE
Dawkins, et al. Expires April 20, 2014 [Page 11]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
802 website. Each Working Group includes a list of their active
projects and the status.
The charter of an IEEE 802 project is defined in an approved Project
Authorization Request (PAR). PARs are accessible in IEEE Standards
myProject, at .
Access requires an IEEE web account which is free and has no
membership requirement.
In myProject, a search on "View Active PARs" for 802 will bring up a
list of all active IEEE 802 PARs.
If an IETF working group identifies a common area of work or a need
for cooperation, the working group leadership should contact the IEEE
802 Working Group chair and Task Group chair. This may be
accompanied by a formal liaison statement (see Section 3.6.2).
3.2.3. Overview of new work proposal notification
These principles describe the notification process used by both
organizations:
1. For both organizations, the technical group making a proposal for
new work that may conflict with, overlap with, or be dependent on
the other organization is responsible for informing the top-level
coordination body in the other organization that cooperation may
be required.
2. For both organizations, the top-level coordination body receiving
that notification is responsible for determining whether
cooperation is, in fact, required, and informing the specific
groups within the organization who may be affected by the
proposal for new work.
These direct notifications will be the most common way that each
organization is informed about proposals for new work in the other
organization. Several other ways of identifying proposed new work
are described in the following sections. These additional ways act
as "belt and suspenders" to reduce the chances that proposals for new
work in one organization escapes notice in the other organization
when cooperation will be required.
3.2.4. The New-Work mailing list
Several standards development organizations ("SDOs"), including IETF
and IEEE 802, have agreed to use a mailing list for the distribution
of information about proposals for new work items among these SDOs.
Dawkins, et al. Expires April 20, 2014 [Page 12]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Rather than having individual IEEE 802 participants subscribe
directly to New-Work, a single IEEE 802 mailing list is subscribed.
Leadership of the IEEE 802 working groups may subscribe to this
"second-level" IEEE 802 mailing list, which is maintained by the
Executive Committee (EC).
This mailing list is limited to representatives of SDOs proposing new
work that may require cooperation with the IETF. Subscription
requests may be sent to the IAB Executive Director.
EDITOR NOTE: the IAB has a 2013 retreat agenda item to discuss the
logistics for the New-Work mailing list. We may be adding
information about how to subscribe to that mailing list after the
retreat.
3.2.5. How IEEE 802 is informed about proposed new IETF work items
Many proposals for new IETF work items can be identified in proposed
Birds-of-a-Feather (BOF) sessions, as well as draft charters for
working groups. The IETF forwards all such draft charters for new
and revised working groups and BOF session announcements to the IETF
New-Work mailing list.
3.2.6. How IEEE 802 comments on proposed new IETF work items
Each IEEE 802 working group chair, or designated representative, may
provide comments on these charters by responding to the IESG mailing
list at iesg@ietf.org clearly indicating their IEEE 802 position and
the nature of their concern.
It should be noted that the IETF turnaround time for new working
group charters can be as short as two weeks, although the call for
comment period on work items that may require cooperation with IEEE
802 can be extended to allow more time for discussion within IEEE
802. This places a burden on both organizations to proactively
communicate and avoid "late surprises" to either organization.
Although an IEEE 802 working group may not be able to develop a
formal consensus response unless the notification arrives during that
working group's meeting, the IEEE 802 working group chair can
informally let the IETF know that IEEE 802 may have concerns about a
proposed work item. The IETF will consider any informal comments
received without waiting for a formal liaison statement.
3.2.7. How IETF is informed about proposed new IEEE 802 work items
An IEEE 802 project is initiated by approval of a Project
Authorization Request (PAR) which includes a description of the scope
Dawkins, et al. Expires April 20, 2014 [Page 13]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
of the work. Any IEEE 802 PARs which introduce new functionality are
required to be available for review no less than 30 days prior to the
Monday of the IEEE 802 plenary session where they will be considered.
IEEE 802 considers Five Criteria when deciding whether to approve new
work: Broad Market Potential, Compatibility, Distinct Identity,
Technical Feasibility and Economic Feasibility. The criteria are
defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations
Manual. The PARs are accompanied by responses on the 5 Criteria.
IEEE 802 posts proposed PARs to the New-Work mailing list, prior to
the IEEE 802 meetings where the PARs will be discussed. The IETF
coordination body will notify technical groups about PARs of
interest.
3.2.8. How IETF comments on proposed new IEEE 802 work items
Any comments on proposed PARs should be submitted to the Working
Group chair and copied to the Executive Committee chair by e-mail not
later than 5:00 PM Tuesday of the plenary session (in the time zone
where the plenary is located).
3.2.9. Other Mechanisms for Coordination
From time to time, IEEE 802 and IETF may agree to use additional
mechanisms for coordination between the two groups. The details of
these mechanisms may vary over time, but the overarching goal is to
communicate effectively as needed.
As examples of such mechanisms, at the time this document was
written, the two organizations are holding periodic conference calls
between representatives of the IETF and IEEE 802 leadership teams,
and are maintaining a "living list" of shared interests between the
two organizations, along with the status of these interests and any
related action items. At the time this document was written, the
"living list" included about 20 topics being actively discussed, with
more expected. These conference calls help the two organizations
coordinate more effectively by allowing higher-bandwidth discussions
than formal liaison statements would allow, and permitting more
timely interactions than waiting for face-to-face meetings.
Minutes for these conference calls, and the "living lists" discussed
on each call, are available at .
3.3. Document Access
Dawkins, et al. Expires April 20, 2014 [Page 14]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
During the course of IEEE 802 and IETF cooperation, it is important
to share internal documents among the technical working groups. In
addition, drafts of IEEE 802 standards, Internet Drafts, and RFCs may
also be distributed.
3.3.1. IEEE 802 Documentation System
Each IEEE 802 standardization project is assigned to a Working Group
(WG) for development. In IEEE 802, the working methods of the WGs
vary in detail. The documentation system is one area in which WG
operations differ, based on varying needs and traditions. In some
cases, the WGs assign the core development to a subgroup (typically
known as a Task Group or Task Force), and the documentation
procedures may vary among the subgroups as well. Prior to project
authorization, or on topics not directly related to development of a
standard, the WG may consider and develop documents itself, or using
other subgroups (standing committees, ad hocs, etc.).
IEEE 802 also supports Technical Advisory Groups (TAGs) that conduct
business and develop documents, although not standards. References
here to WGs apply to TAGs as well.
In addition to allowing IETF participants to access documentation
resources within IEEE 802, IEEE 802 can also make selected IEEE 802
documents at any stage of development available to the IETF by
attaching them to a formal liaison statement. Although a
communication can point to a URL where a non-ASCII document can be
downloaded, attachments in proprietary formats to an IETF mailing
list are discouraged.
3.3.1.1. The role of the IEEE 802 Documentation System in document
development
In general, development of standards in IEEE 802 is contribution-
driven. Content for drafts of standards is submitted to WGs by
individual participants, or groups of participants. Content toward
other group documents (such as, for example, external communication
statements or foundation documents underlying a draft of a standard)
might also be contribution-driven. At some point, the group
assembles contributed material to develop group documents, and
revision takes place within group meetings or by assignment to
editors. For the most part, the contributions toward discussion as
well as the group documents (including minutes and other reports) are
openly available to the public.
3.3.1.2. Access to internal IEEE 802 Working Group Documents
Dawkins, et al. Expires April 20, 2014 [Page 15]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Generally, the archives of minutes and contributions to IEEE 802
groups are publicly and freely available.
Many IEEE 802 groups use a documentation system provided by IEEE and
known as "Mentor". The list of these groups is available at the IEEE
802 Mentor Home Page: . Mentor provides
the following features:
1. The documentation system is structured and ordered, with
documentation tags and unique numbering and versioning.
2. On-line documentation is available.
3. Limited search functionality is provided, and publicly-available
search engines index the data.
4. The ability to submit documents to Mentor is limited but is
generally available to any interested party. An IEEE web account
is required but can be easily and freely established using the
IEEE Account Request page, at . If submission is protected, the privilege
can be requested via the Mentor system (using the "Join group"
link on each WG Mentor page) and would typically be granted by
the WG documentation manager in a manual approval.
5. Submitted documents are immediately available to the general
public at the same instant they become available for
consideration by the group.
IEEE 802.1 and IEEE 802.3 do not use Mentor.
IEEE 802.1 documents are organized in folders by year at: . The file names indicate the
relevant project, author, date and version. The file naming
conventions and upload link are at: . Upload is moderated.
IEEE 802.3 documents are accessed from the home pages of the IEEE
802.3 subgroups (i.e., Task Force or Study Group) and are organized
in folders by meeting date. These home pages are available from the
IEEE 802.3 home page, at: . Files are
uploaded by emailing to the subgroup chair.
Dawkins, et al. Expires April 20, 2014 [Page 16]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
3.3.1.3. Submission of Contributions to IEEE 802 Working Groups
IEEE 802 Working Groups are open to contributions. In many cases, a
WG or subgroup will issue a call for contributions with a specific
technical solicitation, including deadlines and submission
instructions. Some groups maintain specific submission procedures
and specify a contribution cover sheet to clarify the status of the
contribution.
3.3.1.4. Access to IEEE 802 Working Group Drafts
The IEEE owns the copyright to drafts of standards developed within
IEEE 802 standardization projects. The IEEE-SA grants permission for
an IEEE 802 draft to be distributed without charge to the
participants for that IEEE 802 standards development project.
Typically, such distribution is on the Internet under password
protection, with the password provided to members of the
participating WG. Requests to the relevant WG chair for access to a
draft for purposes of participation in the project are typically
granted.
An alternative access mechanism which may more easily enable document
access for IETF WGs cooperating with IEEE 802 was established by a
liaison statement sent to the IETF in July 2004 by Paul Nikolich,
Chair of IEEE 802 (available at ), 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, copyright restrictions prohibit incorporating
material into IETF documents or postings.
3.3.1.5. Access to IEEE 802 Standards
IEEE 802 standards, once approved, are published and made available
for sale. They can be purchased from the IEEE Standards Store, at
. They are also available
from other outlets, including the IEEE Xplore digital library, at
.
The Get IEEE 802 program, at ,
grants public access to download individual IEEE 802 standards at no
Dawkins, et al. Expires April 20, 2014 [Page 17]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
charge (although registration is required). IEEE 802 standards are
added to the Get IEEE 802 program six months after publication. This
program is approved year-by-year, but has been in place for several
years.
3.3.2. Access to IETF Documents
IETF Internet-Drafts may be located using IETF "Datatracker"
interface (see [DATATRACKER]), or via the IETF tools site at . RFCs may be located at either of the above, or via
the RFC Editor site at .
3.4. Participation in Document Review and Approval
During the course of IEEE 802 and IETF cooperation, it is important
for technical experts to review documents of mutual interest and,
when appropriate, to provide review comments to the approving body as
the document moves through the approval process.
3.4.1. IEEE 802 draft review and balloting processes and opportunities
for IETF participation
IEEE 802 drafts are reviewed and balloted at multiple stages in the
draft. Any ballot comments received from non-voters before the close
of the ballot are required to be considered in the comment resolution
process. The Editors, Task Group Chairs or Working Group Chairs
responsible for the project will facilitate the entering of comments
from non-voters.
IEEE 802 draft reviews and ballots sometimes produce a large volume
of comments. In order to handle them efficiently, spreadsheets or a
comment database tool are used. It is highly recommended that
balloters and others submitting comments do so with a file that can
be imported into these tools. A file with the correct format is
normally referenced in the ballot announcement or can be obtained
from the Editor, Task Group Chair or Working Group Chair responsible
for the project. Comments on a draft should be copied to the Editor,
Task Group Chair and Working Group Chair.
3.4.1.1. Task Group Review
During draft development, informal task group reviews (task group
ballots) are conducted. Though these are called "ballots" by some
Working Groups, the focus is on collecting and resolving comments on
the draft rather than on trying to achieve a specific voting result.
3.4.1.2. Working Group ballot
Dawkins, et al. Expires April 20, 2014 [Page 18]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Once the draft is substantially complete, Working Group ballots are
conducted. Working Group voting members are entitled and required to
vote in Working Group ballots. Any disapprove votes are required to
be accompanied by comments that indicate what the objection is and a
proposed resolution. Approve votes may also be accompanied by
comments. The comments submitted with a disapprove vote may be
marked to indicate which comments need to "be satisfied" to change
the vote.
Initial Working Group ballots are at least 30 days. Recirculation
ballots to review draft changes and comment resolutions are at least
10 days.
In order to submit a Working Group ballot, contact the WG chair for
the submission tool currently in use, as the tools may change over
time.
3.4.1.3. Sponsor ballot
When a draft has successfully completed Working Group ballot, it
proceeds to Sponsor ballot. One may participate in IEEE 802 Sponsor
ballots with an individual membership in the IEEE Standards
Association (IEEE-SA) or by paying a per-ballot fee. Participants
are also required to state their affiliation and the category of
their relationship to the scope of the standards activity (e.g.,
producer, user, general interest).
Information about IEEE-SA membership can be found at .
Sponsor ballot is a public review. An invitation is sent to any
parties known to be interested in the subject matter of the ballot.
One can indicate interest in IEEE myProject (). An IEEE web
account is freely available, and is required for login. To select
interest areas, go to the Projects tab and select Manage Activity
Profile and check any areas of interest. IEEE 802 projects are under
Computer Society; LAN/MAN Standards Committee.
The Sponsor ballot pool is formed from those that accept the
invitation during the invitation period.
As with other ballot levels, the IETF participants who want to
comment on Sponsor ballots need not be members in the Sponsor ballot
pool. The Editors, Task Group Chairs or Working Group Chairs
responsible for the project will facilitate the entering of comments
from IETF participants who are not members in the Sponsor ballot
pool.
Dawkins, et al. Expires April 20, 2014 [Page 19]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Any "disapprove" votes are required to be accompanied by comments
that indicate what the objection is, along with a proposed
resolution. Approve votes may also be accompanied by comments. The
comments submitted with a disapprove vote may be marked to indicate
which comments need to "be satisfied" for the commenter to change the
vote from "disapprove".
Initial Sponsor ballot are open for at least 30 days. Recirculation
ballots to review draft changes and proposed comment resolutions are
at least 10 days.
3.4.1.4. IEEE 802 Ballot resolution
At each level, the relevant group (Task Group for TG ballots, Working
Group for WG and Sponsor ballots) examines the ballot comments and
determines their disposition. The editor (or editorial team) may
prepare proposed dispositions. Task Group procedures vary, but at
the Working Group level, the Working Group must vote 75% to approve
the final ballot disposition in order to advance the document.
3.4.2. IETF draft review and approval processes and opportunities for
IEEE 802 participation
The IETF Working Group Process is defined in [BCP25]. The overall
IETF standards process is defined in [BCP9].
As noted in Section 3.1.4, IETF working groups do not "ballot" to
determine working group consensus to forward documents to the IESG
for approval.
Technical contributions are welcome at any point in the IETF document
review and approval process, but there are some points where
contribution is more likely to be effective.
1. When a working group is considering adoption of an individual
draft. Adoption is often announced on the working group's
mailing list.
2. When working group chairs issue a "Working Group Last Call"
("WGLC") for a draft, to confirm that the working group has
consensus to request publication. Although this is not a
mandatory step in the document review and approval process for
Internet-Drafts, most IETF working groups do issue WGLCs for most
working group documents. WGLC would be announced on the working
group's mailing list.
3. When the Internet Engineering Steering Group issues an "IETF Last
Call" ("Last Call") for a draft. IETF Last Call is a formal and
Dawkins, et al. Expires April 20, 2014 [Page 20]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
required part of the review and approval process, is addressed to
the larger IETF community, and is often the first time the entire
community has looked at the document. IETF Last Call is signaled
on the IETF-Announce Mailing List, and comments and feedback are
ordinarily directed to the IETF Discussion Mailing List.
In practice, earlier input is more likely to be effective input.
IEEE 802 participants who are interested in work within the IETF
should be monitoring that work and providing input long before
Working Group Last Calls and IETF Last Calls, for best results.
Some IETF working group charters direct the working group to
communicate with relevant IEEE 802 task groups.
3.5. Solicited Review Processes
With the number of areas of cooperation between IEEE 802 and IETF
increasing, the document review process has extended beyond the
traditional subjects of SMI MIB modules and AAA (authentication,
authorization and accounting) described in [RFC4441]. IESG members
routinely solicit directorate reviews as a means to solicit the
opinion of specialized experts on specific aspects of documents in
IESG review (examples include security, MIB doctors, or congestion
management reviews). Area Directors may also require solicited
reviews from IEEE 802 or IEEE 802 Working Groups when it becomes
clear that the Internet-Draft has implications that impact some area
of IEEE 802's responsibility and expertise.
IEEE 802 leadership can also solicit similar reviews, but these
reviews are not included as part of the formal IEEE 802 process.
3.6. Liaison Managers and Liaison Statements
Both IEEE 802 and IETF work best when people participate directly in
work of mutual interest, but that's not always possible, and
individuals speaking as individuals may not provide effective
communication between the two SDOs. From time to time, it may be
appropriate for a technical body in one SDO to communicate as a body
with a technical body in the other SDO. This section describes the
mechanisms used to provide formal communication between the two
organizations, should that become necessary.
The Internet Architecture Board (IAB) is responsible for liaison
relationship oversight for the IETF. In IEEE 802, liaison
relationship oversight is distributed, and each organization
appointing liaison managers is responsible for oversight of its own
liaison relationships.
Dawkins, et al. Expires April 20, 2014 [Page 21]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
The reader should note that the role of a liaison manager in both
IEEE 802 and IETF is not to "speak for" the appointing organization.
A liaison manager is most helpful in ensuring that neither
organization is surprised by what's happening in the other
organization, helping to identify the right people to be talking to
in each organization, and making sure that formal liaison statements
don't "get lost" between the two organizations. The IAB's guidance
to liaison managers is available in [RFC4691]. IEEE 802
organizations appointing each liaison manager also provide guidance
to those liaison managers. There is no global guidance for all IEEE
802 liaison managers.
3.6.1. Liaison Managers
The IAB appoints IETF Liaison Managers using the process described in
[BCP102]. The current list of the IETF's liaison relationships, and
the liaison managers responsible for each of these relationships is
available at .
IEEE liaison managers are selected by the organizations they
represent, either in an election or by working group or task group
chair appointment. The current list of IEEE 802's liaison
relationships and the liaison managers responsible for each of these
relationships is available at .
3.6.2. Liaison Statements
The IEEE 802 procedure for sending and receiving liaison statements
is defined by the Procedure for Coordination with Other Standards
Bodies in the IEEE 802 LMSC Operations Manual ().
The IETF process for sending and receiving liaison statements is
defined in [BCP103].
4. Mailing Lists
All IETF working groups and all IEEE 802 Working Groups have
associated mailing lists. Most IEEE 802 Task Groups also have
mailing lists, but in some cases, e.g., the IEEE 802.1 Working Group,
the Working Group mailing list is used for any Task Group matters.
Dawkins, et al. Expires April 20, 2014 [Page 22]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
In the IETF, the mailing list is the primary vehicle for discussion
and decision-making. It is recommended that IEEE 802 experts
interested in particular IETF working group topics subscribe to and
participate in these lists. IETF WG mailing lists are open to all
subscribers. The IETF working group mailing list subscription and
archive information are noted in each working group's charter page.
In IEEE 802, mailing lists are typically used for meeting logistics,
ballot announcements, reports and some technical discussion. Most
decision making is at meetings, but in cases where a decision is
needed between meetings, this may be done over the mailing list.
Most technical discussion occurs at meetings and by generating
comments on drafts which are compiled with responses in comment
resolution documents.
Most IEEE 802 mailing lists are open to all subscribers. For the few
IEEE 802 mailing lists that are not open, please see the working
group chair to arrange for access to the mailing list.
Some IEEE 802 participants refer to mailing lists as "reflectors".
5. Cross-Referencing Documents in IEEE 802 and IETF
IETF and IEEE 802 each recognize the standards defined by the other
organization. Standards produced by each organization can be used as
references in standards produced by the other organization.
IETF specifications may reference IEEE 802 work in progress, but
these references would be labeled as "Work in Progress", and if the
references are normative, this would block publication of the
referring specification until the reference is available in a stable
form.
IEEE 802 standards may normatively reference non-expired Internet-
Drafts, but IEEE 802 prefers that this should be avoided if at all
possible.
Informative references in IEEE 802 Standards are placed in a
bibliography, so may point to either approved IETF standards or IETF
Internet-Drafts, if necessary.
When an IEEE 802 Standard is revised, it normally retains the same
number and the date is updated. Therefore, IEEE 802 Standards are
dated with the year of approval, e.g IEEE 802 Std 802.1Q-2011. There
are two ways of referencing IEEE 802 Standards: undated and dated
references. IEEE 802 practice allows undated reference to be used
when referencing a whole standard. An undated reference indicates
that the most recent version of the standard should be used. A dated
Dawkins, et al. Expires April 20, 2014 [Page 23]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
reference refers to a specific revision of an IEEE 802 standard.
Since clauses, subclauses, tables, figures, etc. may be renumbered
when a standard is revised, a dated reference should be used when
citing specific items in a standard.
IETF standards may be cited by RFC number, which would also be a
dated reference. If an undated reference to an IETF Internet
Standard is desired, a number is also assigned in the "STD" series
[BCP9], and these references refer to the most recent version of an
IETF Internet Standard.
6. Protocol Parameter Allocation
Both IEEE 802 and IETF maintain registries of assigned protocol
parameters, and some protocol parameters assigned in one organization
are of interest to the other organization. This section describes
the way each organization registers protocol parameters.
6.1. IANA
The IETF uses the Internet Assigned Numbering Authority (IANA) as a
central authority that administers registries for most protocol
parameter allocations. The overarching document describing this is
[RFC5226]. [RFC5342] discusses use of IEEE 802-specific IANA
parameters in IETF protocols and specifies IANA considerations for
allocation of code points under the IANA OUI (Organizationally Unique
Identifier).
Requests for protocol parameter allocations from IANA are subject to
assignment policies, and these policies vary from registry to
registry. A variety of well-known policies are described in
[RFC5226], but registries are not limited to one of the well-known
choices.
The purpose of these allocations is to manage a namespace
appropriately, so unless a registry has a policy that allows
something like first come, first served ("FCFS") for a namespace that
is effectively unbounded, requests for protocol parameter allocation
will require some level of review. "Standards Action" is at the
other extreme (an approved standards-track RFC is required in order
to obtain an allocation). Some registries require that a request for
allocation pass "expert review" - review by someone knowlegable in
the technology domain, appointed by the IESG and given specific
criteria to use when reviewing requests.
6.2. IEEE Registration Authority
Dawkins, et al. Expires April 20, 2014 [Page 24]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
The IEEE Standards Association uses the IEEE Registration Authority
as a central authority administering registries. The IEEE
Registration Authority Committee (IEEE RAC) provides technical
oversight for the IEEE Registration Authority.
The list of Registries administered by the IEEE Registration
Authority can be found on the IEEE RAC website, at .
Ethertype Allocation - Some IETF protocol specifications make use of
Ethertypes. Ethertypes are fairly scare resource so allocation has
the following requirements. All Ethertype requests are subject to
review by a consultant to the IEEE RA followed by IEEE RAC
confirmation.
The IEEE RAC will not assign a new Ethertype to a new IETF protocol
specification until the IESG has approved the protocol specification
for publication as an RFC. In exceptional cases, the IEEE RA will
consider "early allocation" of an Ethertype for an IETF protocol that
is still under development when the request comes from, and has been
vetted by, the IESG.
Note that "playpen" Ethertypes have been assigned in IEEE 802
[Etypes] for use during protocol development and experimentation.
While a fee is normally charged by the IEEE Registration Authority
Committee (RAC) for the allocation of an Ethertype, the IEEE RAC will
consider waiving the fee for allocations relating to an IETF
standards track document, based on a request from the IESG.
6.3. IEEE 802 Registration at IEEE 802 working group level
Each IEEE 802 working group has a registry of identifier values and a
mechanism to allocate identifier values in its standards and approved
amendments. This includes items such as Object Identifiers for
managed objects and assignment for protocols defined by that Working
Group, such as OpCodes. Contact the IEEE 802 working group chair for
the details of a given working group registry.
EDITOR NOTE: We've been asked if we can provide more direct pointers
to these registries. Can we get text from IEEE 802 team members?
6.4. Joint-use registries
Because some registries are "joint-use" between IEEE 802 and IETF, it
is necessary for each organization to review usage of registries
maintained by the other organization as part of the review and
approval process for standards.
Dawkins, et al. Expires April 20, 2014 [Page 25]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
If an IEEE 802 document refers to IANA registries, those references
should be checked prior to Sponsor balloting. If an IETF document
refers to IEEE 802 registries, those references should be checked as
part of IANA Review during IETF Last Call.
7. IANA Considerations
This document requests no actions by IANA.
8. Security Considerations
This document describes cooperation procedures and has no direct
Internet security implications.
9. Acknowledgements
This document borrows a significant amount of text, and much of its
structure, from [RFC6756]. Additional text was borrowed from
[RFC4441]. We are grateful to the authors and editors of both these
predecessor documents.
This document was assembled by a drafting team of participants from
both IEEE 802 and IETF. The drafting team members were Dan
Romascanu, Dorothy Stanley, Eric Gray, Patricia Thaler, Roger Marks,
Ross Callon, Spencer Dawkins, and Subir Das.
We also thank Abdussalam Baryun, Adrian Farrel, Bernard Aboba, Dave
Thaler, Jari Arkko, Jouni Korhonen, Max Riegel, Norm Finn, Pete
Resnick, Peter Yee, S. Moonesamy, and Stephen Farrell for providing
review comments.
10. References
10.1. Normative References
[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison
to Another Organization", RFC 4691, October 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters", BCP 141, RFC 5342, September
2008.
[RFC6756] Trowbridge, S., Lear, E., Fishman, G., and S. Bradner,
"Internet Engineering Task Force and International
Dawkins, et al. Expires April 20, 2014 [Page 26]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Telecommunication Union - Telecommunication
Standardization Sector Collaboration Guidelines", RFC
6756, September 2012.
10.2. Informative References
[ARCH802] IEEE 802, "IEEE 802-200(R2007) IEEE Standard for Local and
Metropolitan Area Networks: Overview and Architecture",
2007.
[BCP102] Internet Engineering Task Force, "Best Current Practice
102: IAB Processes for Management of IETF Liaison
Relationships", 2005.
[BCP103] Internet Engineering Task Force, "Best Current Practice
103: Procedures for Handling Liaison Statements to and
from the IETF", 2005.
[BCP10] Internet Engineering Task Force, "Best Current Practice
10: IAB and IESG Selection, Confirmation, and Recall
Process: Operation of the Nominating and Recall
Committees, as updated", 2004.
[BCP11] Internet Engineering Task Force, "Best Current Practice
11: The Organizations Involved in the IETF Standards
Process, as updated", 1996.
[BCP158] Internet Engineering Task Force, "Best Current Practice
158: RADIUS Design Guidelines", 2011.
[BCP25] Internet Engineering Task Force, "Best Current Practice
25: IETF Working Group Guidelines and Procedures", 1998.
[BCP9] Internet Engineering Task Force, "Best Current Practice 9:
The Internet Standards Process -- Revision 3, as updated",
1996.
[DADG] Internet Engineering Task Force, "Diameter Applications
Design Guidelines (draft-ietf-dime-app-design-guide-20)
(Work in progress)", 2012.
[DATATRACKER]
Internet Engineering Task Force, "IETF Datatracker (https:
//datatracker.ietf.org/)", 2013.
[Etypes] IEEE 802, "IEEE 802 Std 802a-2003 (Amendment to IEEE 802
Std 802-2001). IEEE 802 standard for Local and
Metropolitan Area Networks: Overview and Architecture --
Dawkins, et al. Expires April 20, 2014 [Page 27]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Amendment 1: Ethertypes for Prototype and Vendor- Specific
Protocol Development", 2003.
[IEEE80211F]
IEEE 802, "802.11F-2003 - IEEE Trial-Use Recommended
Practice for Multi-Vendor Access Point Interoperability
Via an Inter-Access Point Protocol Across Distribution
Systems Supporting IEEE 802.11 Operation", 2003.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575, July
2003.
[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February
2004.
[RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", BCP 101, RFC
4071, April 2005.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
Documents", BCP 111, RFC 4181, September 2005.
[RFC4441] Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441,
March 2006.
[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge
MIB WG to IEEE 802.1 WG", RFC 4663, September 2006.
[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G.,
Internet Architecture Board, "Defining the Role and
Function of IETF Protocol Parameter Registry Operators",
RFC 6220, April 2011.
[RFC6548] Brownlee, N. IAB, "Independent Submission Editor Model",
RFC 6548, June 2012.
[RFC6635] Kolkman, O., Halpern, J., IAB, "RFC Editor Model (Version
2)", RFC 6635, June 2012.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
Dawkins, et al. Expires April 20, 2014 [Page 28]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
Service (RADIUS) Protocol Extensions", RFC 6929, April
2013.
Appendix A. Current examples of IEEE 802 and IETF Work Item Cooperation
A.1. MIB Review
Historically the MIB modules for IEEE 802.1 and IEEE 802.3 were
developed in the IETF Bridge MIB and Hub MIB Working Groups
respectively. 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 was found to
past arrangements that involved chartering MIB work items within an
IETF WG by transferring the work to IEEE 802 with expert support for
MIB review from the IETF. In order to encourage wider review of MIBs
developed by IEEE 802 WGs, it is recommended that MIB modules
developed in IEEE 802 follow the MIB guidelines [RFC4181]. An IEEE
802 group may request assignment of a 'MIB Doctor' to assist in a MIB
review by contacting the IETF Operations and Management Area
Director.
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing
the SNMP quality control process, the IETF and IEEE 802 seek to
ensure quality while decreasing overhead. The process of transfer of
the MIB work from the IETF Bridge MIB WG to IEEE 802.1 WG is
documented in [RFC4663].
A.2. AAA Review
IEEE 802 WGs requiring new AAA applications should send a liaison
request to the IETF. Where merely new attributes definitions are
sufficient rather than defining a new authentication, authorization
and accounting logic/procedures, an Internet-Draft can be submitted
and review can be requested from AAA-related WGs such as the RADEXT
or DIME WGs. For attributes of general utility, and particularly
those useful in multiple potential applications, allocation from the
IETF standard attribute space is preferred to creation of IEEE 802
Vendor-Specific Attributes (VSAs). As noted in [RFC3575]: "RADIUS
defines a mechanism for Vendor-Specific extensions and the use of
that should be encouraged instead of allocation of global attribute
types, for functions specific only to one vendor's implementation of
RADIUS, where no interoperability is deemed useful".
Where allocation of VSAs are required, it is recommended that IEEE
802 create a uniform format for all of IEEE 802, rather than having
each IEEE 802 group create their own VSA format. The VSA format
defined in [IEEE80211F] is inappropriate for this, since the Type
Dawkins, et al. Expires April 20, 2014 [Page 29]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
field is only a single octet, allowing for only 255 attributes. It
is recommended that IEEE groups read and follow the recommendations
in "RADIUS Design Guidelines" [BCP158] and the "Protocol Extensions"
ID [RFC6929] when designing and reviewing new extensions and
attributes.
The Diameter Applications Design Guidelines I-D [DADG] explains and
clarifies the Rules to extend the Diameter base protocol [RFC6733].
Extending Diameter can mean either the definition of a completely new
Diameter application or the reuse of commands, (Attribute-value
pairs) AVPs and AVP values in any combination for the purpose of
inheriting the features of an existing Diameter application. The
recommendation for re-using as much as possible existing
implementations is meaningful as most of the requirements defined for
a new application are likely already fulfilled by existing
applications. It is recommended that IEEE groups read and follow the
recommendations in [DADG] when defining and reviewing new extensions
and attributes.
In addition to the RADEXT and DIME WGs, an AAA Doctors team
(directorate) is currently active in the OPS Area and can be
consulted for more general advice on AAA issues that cross the limits
of one or the other of the RADIUS or Diameter protocols, or are more
generic in nature.
Appendix B. Pointers to Additional Useful Information
This section provides pointers to additional useful information for
participants in IEEE 802 and IETF.
B.1. IEEE 802 Information that may be useful to IETF participants
IEEE 802 Home Page:
IEEE 802 policies and procedures:
The IEEE 802 WG and TAG main page URLs follow this convention: They
have the one or two digit numerical designation for the WG or TAG
appended after . For example the IEEE 802.1
main web page is at , while the IEEE 802.11
main web page is at .
B.2. IETF Information that may be of use to IEEE 802 participants
Information on IETF procedures may be found in the documents in the
informative references, and at the URLs below.
Dawkins, et al. Expires April 20, 2014 [Page 30]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Note: RFCs do not change after they are published. Rather, they are
either obsoleted or updated by other RFCs. Such updates are tracked
in the rfc-index.txt file.
Current list and status of all IETF RFCs:
Current list and description of all IETF Internet-Drafts:
Current list of IETF working groups and their Charters: (includes area directors and chair
contacts, mailing list information, etc.)
Current list of requested BOFs:
RFC Editor pages about publishing RFCs: (including available tools and lots of guidance)
is particularly helpful.
Current list of liaison statements:
IETF Intellectual Property Rights Policy and Notices:
The Tao of the IETF: ; (A Novice's
Guide to the Internet Engineering Task Force)
Authors' Addresses
Spencer Dawkins (editor)
Huawei Technologies
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Email: spencerdawkins.ietf@gmail.com
Patricia Thaler
Broadcom Corporation
5025 Keane Drive
Carmichael, CA 95608
USA
Email: pthaler@broadcom.com
Dawkins, et al. Expires April 20, 2014 [Page 31]
Internet-Draft The IEEE 802 / IETF Relationship October 2013
Dan Romascanu
AVAYA
Park Atidim, Bldg. #3
Tel Aviv 61581
Israel
Phone: +972-3-6458414
Email: dromasca@avaya.com
Dawkins, et al. Expires April 20, 2014 [Page 32]