Internet DRAFT - draft-dawkins-iab-rfc4441rev
draft-dawkins-iab-rfc4441rev
Internet Architecture Board S. Dawkins, Ed.
Internet-Draft Huawei
Obsoletes: 4441 (if approved) P. Thaler
Intended status: Informational Broadcom
Expires: June 22, 2013 December 19, 2012
The IEEE 802 / IETF Relationship
draft-dawkins-iab-rfc4441rev-02.txt
Abstract
This document describes the standardization collaboration between
Project 802 of the Institute of Electrical and Electronic Engineers
(IEEE 802) 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 June 22, 2013.
Copyright Notice
Copyright (c) 2012 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 & Thaler Expires June 22, 2013 [Page 1]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Guidance on Collaboration . . . . . . . . . . . . . . . . . . 5
2.1. Organization, Participation and Membership . . . . . . . . 5
2.1.1. IEEE 802 Organization, Participation and Membership . 5
2.1.2. IETF Organization, Participation and Membership . . . 7
2.1.3. Cultural Differences . . . . . . . . . . . . . . . . . 8
2.2. Exchange of Information About Work Items . . . . . . . . . 10
2.2.1. How IEEE 802 is informed about active IETF work
items . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2. How IETF is informed about active IEEE 802 work
items . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.3. How IEEE 802 is informed about proposed new IETF
work items . . . . . . . . . . . . . . . . . . . . . . 11
2.2.4. How IETF is informed about proposed new IEEE 802
work items . . . . . . . . . . . . . . . . . . . . . . 11
2.2.5. Other Mechanisms for Coordination . . . . . . . . . . 12
2.3. Document Access . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. IEEE 802 Documentation System . . . . . . . . . . . . 12
2.3.2. Access to IETF Documents . . . . . . . . . . . . . . . 15
2.4. Participation in Document Review and Approval . . . . . . 15
2.4.1. IEEE 802 draft review and balloting processes and
opportunities for IETF participation . . . . . . . . . 15
2.4.2. IETF draft review and balloting processes and
opportunities for IEEE 802 participation . . . . . . . 17
2.5. Expert Review Processes . . . . . . . . . . . . . . . . . 18
2.6. Liaison Officials/Liaison Managers and Liaison
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6.1. Liaison Officials/Liaison Managers . . . . . . . . . . 19
2.6.2. Liaison Statements . . . . . . . . . . . . . . . . . . 19
3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 20
4. Cross-Referencing Documents in IEEE 802 and IETF . . . . . . . 21
5. Protocol Parameter Allocation . . . . . . . . . . . . . . . . 22
5.1. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. IEEE Registration Authority . . . . . . . . . . . . . . . 22
5.3. IEEE Registration at IEEE working group level . . . . . . 23
5.4. Pointers to Additional Useful Information . . . . . . . . 23
5.4.1. IEEE 802 Information that may be useful to IETF
participants . . . . . . . . . . . . . . . . . . . . . 23
5.4.2. IETF Information that may be of use to IEEE 802
participants . . . . . . . . . . . . . . . . . . . . . 23
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 28
Dawkins & Thaler Expires June 22, 2013 [Page 2]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Appendix A. Current examples of this relationship . . . . . . . . 29
A.1. MIB Review . . . . . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Dawkins & Thaler Expires June 22, 2013 [Page 3]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
1. Introduction and Scope
This document provides non-normative guidance to aid in the
understanding of collaboration on standards development between
Project 802 of the Institute of Electrical and Electronics Engineers
(IEEE) and the Internet Engineering Task Force (IETF) of the Internet
Society (ISOC). Early identification of topics of mutual interest
will allow for constructive efforts between the two organizations
based on mutual respect and cooperation.
EDITOR'S NOTE: This version of the draft has references sections that
are both incomplete and bogus - I'm showing most of the references as
inline hyperlinks. I'll clean this up soon.
Dawkins & Thaler Expires June 22, 2013 [Page 4]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
2. Guidance on Collaboration
This section describes how existing processes within the IETF and
IEEE 802 may be used to enable collaboration between the
organizations.
2.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.
2.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. IEEE 802 LAN/MAN Standards Committee
is a sponsor developing standards for networking under the IEEE-SA
Standards Board.
In IEEE 802, work is done in Working Groups operating under an
Executive Committee. Most Working Groups have one or more Task
Groups. A Task Group is responsible for a project or group of
projects. Each Working Group is led by a Working Group Chair.
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 to learn more is the IEEE 802 Home Page, at
http://www.ieee802.org/. 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, April and September. The meeting schedule can be
found at http://www.ieee802.org/meeting/index.html.
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
Dawkins & Thaler Expires June 22, 2013 [Page 5]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
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. Contact points on the IEEE side may include:
IEEE Working Group Chair: An IEEE Working Group chair is an
individual who is assigned to lead the work of IEEE in a
particular area. IEEE Working Group chairs are elected by
the Working Group and confirmed by the Executive Committee
for a 2 year term. Collaboration here is provides a stable
contact point for work between the two organizations for a
given topic.
IEEE Task Group (or Task Force) Chair: An IEEE 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. Task Group Chairs often serve for the duration of a
project. Collaboration here is beneficial to ensure that
work on a particular project is coordinated.
IEEE Study Group Chair: An IEEE Study Group Chair is an individual
assigned to lead consideration of new work and development
of an IEEE Project Authorization Request (PAR).
Collaboration here is useful for providing input on the
scope of new work and to begin coordination.
Dawkins & Thaler Expires June 22, 2013 [Page 6]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
IEEE 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 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
collaboration 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 and
IETF projects in an area can also aid in collaboration.
2.1.2. IETF Organization, Participation and Membership
In the IETF, work is done in working groups (WGs), mostly through
open, public mailing lists rather than face-to-face meetings. WGs
are organized into areas, each area being managed by two co-area
directors. Collectively, the area directors comprise the Internet
Engineering Steering Group (IESG).
IETF meets in plenary session three times per year. Some working
groups have additional interim meetings, which may be either face-to-
face or "virtual", but this is not true for most IETF working groups,
at any given time. The goal 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
plenary meetings is available at
http://www.ietf.org/meeting/upcoming.html. Information about working
group interim meetings is available on the IETF-Announce mailing list
(see http://www.ietf.org/list/announcement.html) 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 are
a small number of IETF procedures that recognize organizations that
may sponsor IETF participants, but these are organizational and do
not apply to the standard specification process itself. There is no
concept of "IETF membership".
A good place to to learn more is the IETF Home Page, at
http://www.ietf.org/, and especially the "About the IETF" page at
http://www.ietf.org/about, selectable from the IETF Home Page.
Dawkins & Thaler Expires June 22, 2013 [Page 7]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
To foster ongoing communication between IEEE 802 and IETF, it is
important to identify and establish contact points within each
organization. Contact points on the IETF side may include:
IETF Area Director: An IETF area director is the individual
responsible for overseeing a major focus of activity (an
"Area"). These positions are relatively long- term (of
several years) and offer the stability of contact points
between the two organizations for a given topic.
IETF Working Group Chair: An IETF working group chair is an
individual who is assigned to lead the work on a specific
task within one particular area. These positions are
working positions (of a year or more) that typically end
when the work on a specific topic ends. Collaboration here
is very beneficial to ensure the actual work gets done.
Other Contact Points: It may be beneficial to establish additional
contact points for specific topics of mutual interest.
These contact points should be established early in the
work effort, and in some cases the contact point identified
by each organization may be the same individual.
Note: The current list of IETF area directors and working group
chairs can be found in the IETF working group charters, at
http://datatracker.ietf.org/wg/.
2.1.3. Cultural Differences
It's worth noting that IEEE 802 and IETF have cultures that are
similar, but not identical. Some of the differences include:
IEEE 802 Working Groups and IETF Working Groups: Both IEEE 802 and
IETF use the term "Working group", but "working groups"
means two very different things in the two organizations.
IEEE 802 working groups are large, long-lived, and
relatively broadly scoped. IEEE 802 working groups are
more similar to IETF Areas than to IETF working groups,
which tend to be short-lived and narrowly chartered.
Consensus and Rough Consensus: Both organizations make decisions
based on consensus, but in the IETF, "consensus" means
"rough consensus". In practice, this means that a large
part of the community being asked needs to agree. Not
everyone has to agree, but if you disagree, you'll need to
convince other people of your point of view. If you're not
able to do that, you'll be "in the rough" when "rough
consensus" is declared.
Dawkins & Thaler Expires June 22, 2013 [Page 8]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Rough Consensus and Running Code: David Clark coined the phrase "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. IEEE 802 standards may be less
amenable to one-off implementation, whether as hardware or
as software.
Voting: Both organizations use voting as a decision-making tool,
but IEEE 802 uses voting within working groups, while IETF
working groups do not. The IESG does ballot documents when
considering them for publication, and working group chairs
may ask for a "show of hands" or "take a hum" to judge
backing for a proposal, but IETF working groups don't vote.
Balance between mailing lists and meetings: Both organizations make
use of mailing lists, but IETF working groups really can't
get anything done without mailing lists, which is where
work can continue between formal meetings. The IETF
requires all decisions to be made (or, often in practice,
confirmed) on mailing lists - final decisions aren't made
in meetings. It's also worth noting that IETF working
group sessions are much shorter than IEEE 802 working group
sessions - it's not unusual for an IETF working group to
meet once or twice in a plenary meeting, for a maximum of
two and a half hours per session. Some working groups may
not meet at all in plenary, and others may have a single
one-hour session.
Interim meetings: Both organizations use interim meetings (between
plenary meetings), but this is more common for IEEE 802
working groups than for IETF working groups, which schedule
interim meetings on an as-needed basis. While the IETF
interim meetings may be face-to-face or virtual, the IEEE
802 interim meetings are face-to-face only. Many IEEE 802
WGs hold regularly interim meetings three times a year in
the middle of the intervals between the Plenary meetings.
The schedules and location of these meetings are typically
known many months in advance.
Remote participation: Because the IETF doesn't make decisions at
face-to-face meetings, it's not strictly necessary to
attend face-to-face meetings at all! Some significant
contributors don't attend most face-to-face IETF meetings,
although if you want to find collaborators on a proposal
for new work, or solicit backing for your ideas, you'll
probably find that easier in a face-to-face conversation,
Dawkins & Thaler Expires June 22, 2013 [Page 9]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
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.
Working group autonomy: Both IEEE 802 and IETF allow working groups
considerable autonomy (within the documented process) in
getting work done. It's worth noting that there may be
differences between two IEEE 802 working groups, or between
two IETF working groups, in addition to differences between
an IEEE 802 working group and an IETF working group.
2.2. Exchange of Information About Work Items
The following sections outline a process that can be used to enable
each group to be informed about the other's active and proposed new
work items.
2.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
(http://datatracker.ietf.org/wg/). 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 2.6.2).
2.2.2. How IETF is informed about active IEEE 802 work items
IEEE Working Group status reports are published at the beginning and
end of each plenary at http://ieee802.org/minutes on the IEEE 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 https://development.standards.ieee.org/my-site. 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.
The responsibility is on individual IETF working groups to
periodically review the information on the IEEE 802 web site to
Dawkins & Thaler Expires June 22, 2013 [Page 10]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
determine if there is work in progress of mutual interest.
If an IETF working group identifies a common area of work or a need
for coordination, 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 2.6.2).
2.2.3. How IEEE 802 is informed about proposed new IETF work items
The IETF maintains a mailing list for the distribution of proposed
new work items among standards development organizations. Many such
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 all new and revised working
groups and BOF session announcements to the IETF new-work mailing
list. An IEEE 802 mailing list is subscribed to this list.
Leadership of the IEEE working groups may subscribe to this IEEE 802
mailing list, which is maintained by the Executive Committee (EC).
Each IEEE 802 Working Group will delegate at least one expert to
subscribe to this list and be ready to dispatch any information
relevant for their activity. This will enable the IEEE 802 working
groups to monitor the new work items for possible overlap or interest
to their IEEE 802 working group. It is expected that this mailing
list will see a few messages per month.
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. Plain-text email is preferred on the
IESG mailing list.
It should be noted that the IETF turnaround time for new working
group charters can be as short as two weeks. As a result, the IETF
Announce mailing list should be monitored consistently.
2.2.4. How IETF is informed about proposed new IEEE 802 work items
An IEEE project is initiated by approval of a Project Authorization
Request (PAR) which includes a description of the scope 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 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
Dawkins & Thaler Expires June 22, 2013 [Page 11]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Manual. The PARs are accompanied by responses on the 5 Criteria.
Each Area Director shall ensure that at least one person is
designated to periodically review relevant PAR and 5 Criteria
information to determine if there is proposed work of mutual
interest.
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).
2.2.5. Other Mechanisms for Coordination
From time to time, IEEE 802 and IETF may agree to use additional
mechanisms for coordination between the two groups.
Examples of such mechanism are periodic conference calls between the
representatives of the IETF and IEEE 802 leadership teams, and
working documents that list the areas of shared interests between the
two organizations, status and action items relative to these areas.
At the time of writing, such a document was maintained and included
about 20 topics being actively discussed, with more expected. Such
documentation helps focusing on principles and not trying to design a
complete process for each topic.
2.3. Document Access
During the course of IEEE 802 and IETF collaboration, it is important
to share internal documents among the technical working groups. In
addition, draft standards, Internet Drafts, and RFCs may also be
distributed.
2.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
Dawkins & Thaler Expires June 22, 2013 [Page 12]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
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 (e.g.,
Word) can be downloaded, attachments in proprietary formats to an
IETF mailing list are discouraged.
2.3.1.1. The role of the IEEE 802 Documentation System in document
development
In general, development of standards is IEEE 802 is contribution-
driven. Content toward draft 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 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.
2.3.1.2. Access to internal IEEE 802 Working Group Documents
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: https://mentor.ieee.org/802". Mentor has some
particularly notable aspects:
EDITOR'S NOTE: We had a suggestion to trim some of this information.
Pat to consider and provide revised text.
1. The documentation system is structured and ordered, with
documentation tags and unique numbering and revisioning.
2. On-line documentation is available.
3. Generally speaking, the archives are publicly and freely
available.
4. Limited search functionality is provided, and publicly-available
search engines index the data.
5. The ability to submit documents to Mentor is limited but is
generally available to any interested party. An IEEE Account is
Dawkins & Thaler Expires June 22, 2013 [Page 13]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
required but can be easily and freely established using the IEEE
Account Request page, at
http://www.ieee.org/go/create_web_account. 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.
6. Submitted documents are immediately available to the general
public at the same instant they become available for
consideration by the group.
In most cases, WGs that use the Mentor system use it exclusively, so
that any substantive document will be available through the system.
In a few cases (for example, the IEEE 802 Executive Committee),
document distribution is by multiple means (including an email
reflector), so it may be difficult to compile a complete set of
documents.
Some WGs do not use the Mentor system. In this case, documents are
nevertheless generally publically available and indexed. Typically,
the index may be presented via a human-managed web site. In such
cases, the contributions may be submitted via email to a document
manager, so they may not be immediately available to the public. For
WGs not using the Mentor system, it should be relatively
straightforward to find documents of interest by reviewing the
group's main web page. These web page addresses follow this
convention: the IEEE 802.1 main web page is at http://ieee802.org/1,
while the IEEE 802.11 main web page is at http://ieee802.org/11 - in
other words, the one-digit or two- digit numerical desigation for the
WG or TAG appears as the "path" in the URL.
In some cases, links to documents may be available only by reviewing
the WG or subgroup meeting minutes.
2.3.1.3. Submission of Contributions to IEEE 802 Working Groups
IEEE 802 Working Groups are open to contribution. 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.
2.3.1.4. Access to IEEE 802 Working Group Drafts
The IEEE owns the copyright to draft standards developed within IEEE
standardization projects. As a result, such drafts are never made
Dawkins & Thaler Expires June 22, 2013 [Page 14]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
publicly available. The IEEE-SA grants permission for an IEEE draft
standard to be distributed without charge to the participants for
that IEEE 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 relevent WG chair for access to a draft for purposes of
participation in the project are typically granted.
2.3.1.5. Access to IEEE 802 Standards
IEEE standards, once approved, are published and made available for
sale. They can be purchased from the IEEE Standards Store, at
http://www.techstreet.com/ieeegate.html. They are also available
from other outlets, including the IEEE Xplore digital library, at
http://ieeexplore.ieee.org.
The Get IEEE 802 program, at http://standards.ieee.org/about/get,
grants public access to download individual IEEE 802 standards at no
charge. IEEE 802 standards are added to the Get IEEE 802 program six
months after publication.
2.3.2. Access to IETF Documents
IETF Internet-Drafts may be located using IETF "Datatracker" inteface
at https://datatracker.ietf.org, or via the IETF tools site at
http://tools.ietf.org. RFCs may be located at either of the above,
or at via the RFC Editor site at http://www.rfc-editor.org.
It should be recognized that the official/athoritative versions of
all IETF documents are in ASCII.
2.4. Participation in Document Review and Approval
EDITOR'S NOTE: we discussed moving part of this section to Expert
Review. That's not a small change, so I'll wait until people have a
chance to think about it, before proposing text.
During the course of IEEE 802 and IETF collaboration, 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.
2.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
Dawkins & Thaler Expires June 22, 2013 [Page 15]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
process.
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.
2.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.
2.4.1.2. Working Group ballot
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 "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.
2.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. (See IEEE-SA
membership.) 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).
Note to the reader: The yearly cost of membership in the IEEE-SA is
generally about the same or less as the per-ballot fee, so it is
generally more economical to join the IEEE-SA.
Information about IEEE-SA membership can be found at
Dawkins & Thaler Expires June 22, 2013 [Page 16]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
http://standards.ieee.org/membership/
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
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.
Editor's note: add URL for myProject is
development.standards.ieee.org to references.
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.
Editor's note: check that all groups accept the same file format and
try to find a place to post a blank .CSV file for download. Pat's
action
2.4.2. IETF draft review and balloting processes and opportunities for
IEEE 802 participation
The IETF Working Group Process is defined in BCP-25. The overall
IETF standards process is defined in BCP-9.
As noted in <cultdiff>, IETF working groups do not "ballot", but the
IESG does, as part of considering documents 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 signaled on the working group's mailing
list.
Dawkins & Thaler Expires June 22, 2013 [Page 17]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
2. When a working group issues a "Working Group Last Call" ("WGLC")
for a draft. 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 signaled on the working group's mailing
list.
3. When the Internet Engineering Steering Group issues an "IETF Last
Call" ("Last Call") for a draft. This is similar in spirit to
WGLC, but is a request for review and approval that is addressed
to the larger IETF community. 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.
2.5. Expert 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 described in
[RFC4441]. The IESG members use expert 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 expert reviews
from IEEE 802 or IEEE 802 Working Groups when it becomes clear that
the Internet-Draft has implications for some area of IEEE 802's
responsibility and expertise.
IETF participants can comment as part of the IEEE 802 ballot process,
regardless of their voting status within IEEE 802. Comments must be
composed in the format specified for the ballot, and submitted by the
ballot deadline.
2.6. Liaison Officials/Liaison Managers and Liaison Statements
EDITOR'S NOTE: This section is written mostly from an IETF
perspective. If there are helpful things to say about IEEE 802
liaison processes, that would be great to add. :-)
Both IEEE 802 and IETF work best when people participate directly in
work of mutual interest, but that's not always possible, and
Dawkins & Thaler Expires June 22, 2013 [Page 18]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
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.
The reader should note that the role of a liaison official (called a
"Liaison Manager" in the IETF) in both IEEE 802 and IETF is not to
"speak for" the appointing organization. A liaison official is most
helpful in insuring 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 http://tools.ietf.org/html/rfc4691.
2.6.1. Liaison Officials/Liaison Managers
The IAB appoints IETF Liaison Managers using the process described in
http://tools.ietf.org/html/rfc4052. The current list of the IETF's
liaison relationships, and the liaison officials responsible for each
of these relationships is available at
http://www.ietf.org/liaison/managers.html.
2.6.2. Liaison Statements
The IETF process for sending and receiving liaison statements is
defined at http://tools.ietf.org/html/rfc4053.
Dawkins & Thaler Expires June 22, 2013 [Page 19]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
3. 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.
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, it 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.
Dawkins & Thaler Expires June 22, 2013 [Page 20]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
4. Cross-Referencing Documents in IEEE 802 and IETF
IETF and IEEE 802 each recognize the standards defined by the other
and therefore do not have issues with cross-referencing each other's
standards.
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 standards may reference non-expired Internet-Drafts, but this
should be avoided if at all possible.
EDITOR'S NOTE: The plan used to be that IETF Internet-Drafts expired
after 6 months, AND WERE NO LONGER RETRIEVABLE - but now, expired
drafts are still available without a subpoena. Do we think Internet-
Drafts now qualify for IEEE 802 use? We'll talk ...
When an IEEE Standard is revised, it normally retains the same number
and the date is updated. Therefore, IEEE Standards are dated with
the year of approval, e.g IEEE Std 802.1Q-2011. There are two ways
of referencing IEEE Standards: undated and dated references. IEEE
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 reference refers to
a specific revision of an IEEE 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.
Informative references in IEEE Standards are placed in a bibliograpy,
so may point to either approved IETF standards or IETF Internet-
Drafts, if necessary.
Dawkins & Thaler Expires June 22, 2013 [Page 21]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
5. 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.
5.1. IANA
The IETF uses the Internet Assigned Numbering Authority (IANA) as a
central authority that administers registries for protocol parameter
allocations. The overarching document describing this is RFC 5226.
RFC 5342 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).
5.2. IEEE Registration Authority
EDITOR'S NOTE: This section is focused on one (important) specific
example - we need text that describes the RAC and general operation
first. We have asked Glenn Parson to provide text here.
EtherType Allocation - The IEEE Registration Authority (IEEE RA)
assigns Ethertypes with oversight from the IEEE Registration
Authority Committee (IEEE RAC). (See
http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF
protocol specification make use of Ethertypes. All Ethertype
requests are subject to review by a consultant to the IEEE RA
followed by IEEE RAC confirmation.
Since Ethertypes are a fairly scarce resource, 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 is willing to consider "early
allocation" of an Ethertype for an IETF protocol that is still under
development as long as the request comes from, and has been vetted
by, the IESG.
To let the IEEE RAC know that the IESG has approved the request for
an Ethernet assignment for an IETF protocol, all future requests for
assignment of Ethertypes for IETF protocols will be made by the IESG.
Note that playpen Ethertypes have been assigned in IEEE 802 [1] for
use during protocol development and experimentation.
[1] IEEE Std 802a-2003 (Amendment to IEEE Std 802-2001). IEEE
standard for Local and Metropolitan Area Networks: Overview and
Architecture -- Amendment 1: Ethertypes for Prototype and Vendor-
Dawkins & Thaler Expires June 22, 2013 [Page 22]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Specific Protocol Development.
While a fee is normally charged by IEEE 802 for the allocation of an
EtherType, IEEE 802 will consider waiving the fee for allocations
relating to an IETF standards track document, based on a request from
the IESG.
5.3. IEEE Registration at IEEE working group level
Need text here - don't need to say much about this, but do need to
say that these registrations exist.
5.4. Pointers to Additional Useful Information
This section provides pointers to additional useful information for
paricipants in IEEE 802 and IETF.
5.4.1. IEEE 802 Information that may be useful to IETF participants
IEEE Home Page: http://ieee802.org/
IEEE 802 policies and procedures: http://ieee802.org/devdocs.shtml"
5.4.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 URLs below.
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:
ftp://ftp.ietf.org/rfc/rfc-index.txt
Current list and description of all IETF Internet-Drafts:
ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt
Current list of IETF working groups and their Charters:
http://www.ietf.org/dyn/wg/charter.html (includes area directors and
chair contacts, mailing list information, etc.)
Current list of registered BOFs: http://trac.tools.ietf.org/bof/trac/
RFC Editor pages about publishing RFCs:
http://www.rfc-editor.org/index.html (including available tools and
lots of guidance) http://www.rfc-editor.org/pubprocess.html is
particularly helpful.
Dawkins & Thaler Expires June 22, 2013 [Page 23]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Current list of liaison statements:
https://datatracker.ietf.org/liaison/
IETF Intellectual Property Rights Policy and Notices:
http://www.ietf.org/ipr/
The Tao of the IETF: http://www.ietf.org/tao.html (A Novice's Guide
to the Internet Engineering Task Force)
Dawkins & Thaler Expires June 22, 2013 [Page 24]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
6. IANA Considerations
This document requests no actions by IANA.
Dawkins & Thaler Expires June 22, 2013 [Page 25]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
7. Security Considerations
Documents that describe cooperation procedures, like this one, have
no direct Internet security implications.
Dawkins & Thaler Expires June 22, 2013 [Page 26]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
8. Acknowledgements
This document borrows massive amounts of text, including 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 Bernard Aboba for providing review comments.
Dawkins & Thaler Expires June 22, 2013 [Page 27]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
9. References
9.1. Normative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6756] Trowbridge, S., Lear, E., Fishman, G., and S. Bradner,
"Internet Engineering Task Force and International
Telecommunication Union - Telecommunication
Standardization Sector Collaboration Guidelines",
RFC 6756, September 2012.
9.2. Informative References
[RFC4441] Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441,
March 2006.
Dawkins & Thaler Expires June 22, 2013 [Page 28]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Appendix A. Current examples of this relationship
A.1. MIB Review
Historically the MIB modules for IEEE 802.1 and IEEE 802.3 were
developped 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 to IEEE 802 is documented in [RFC4663] and
in [I-D ETHERNET-MIB-TRANSFER].
Dawkins & Thaler Expires June 22, 2013 [Page 29]
Internet-Draft The IEEE 802 / IETF Relationship December 2012
Authors' Addresses
Spencer Dawkins (editor)
Huawei Technologies
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Email: spencer@wonderhamster.org
Patricia Thaler
Broadcom Corporation
5025 Keane Drive
Carmichael, CA 95608
USA
Email: pthaler@broadcom.com
Dawkins & Thaler Expires June 22, 2013 [Page 30]
