Difference between revisions of "RFC7241"

From RFC-Wiki
imported>Admin
 
Line 1: Line 1:
 
 
 
 
 
 
 
Internet Architecture Board (IAB)                            S. Dawkins
 
Internet Architecture Board (IAB)                            S. Dawkins
 
Request for Comments: 7241                                        Huawei
 
Request for Comments: 7241                                        Huawei
Line 14: Line 8:
 
                                                 Microsoft Corporation
 
                                                 Microsoft Corporation
 
                                                             July 2014
 
                                                             July 2014
 
  
 
                   The IEEE 802/IETF Relationship
 
                   The IEEE 802/IETF Relationship
  
Abstract
+
'''Abstract'''
  
 
This document describes the standardization cooperation between
 
This document describes the standardization cooperation between
Line 25: Line 18:
 
obsoletes [[RFC4441|RFC 4441]].
 
obsoletes [[RFC4441|RFC 4441]].
  
'''Note:''' This document was collaboratively developed by authors from
+
Note: This document was collaboratively developed by authors from
 
both the IEEE 802 and IETF leadership and was reviewed and approved
 
both the IEEE 802 and IETF leadership and was reviewed and approved
 
by the IEEE 802 Executive Committee prior to publication.
 
by the IEEE 802 Executive Committee prior to publication.
  
Status of This Memo
+
'''Status of This Memo'''
  
 
This document is not an Internet Standards Track specification; it is
 
This document is not an Internet Standards Track specification; it is
Line 45: Line 38:
 
http://www.rfc-editor.org/info/rfc7241.
 
http://www.rfc-editor.org/info/rfc7241.
  
 
+
'''Copyright Notice'''
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Copyright Notice
 
  
 
Copyright (c) 2014 IETF Trust and the persons identified as the
 
Copyright (c) 2014 IETF Trust and the persons identified as the
Line 70: Line 50:
 
to this document.
 
to this document.
  
 +
11. IEEE 802 Executive Committee Members at the Time of Approval ..31
  
 +
== Introduction ==
  
 +
This document contains a set of principles and guidelines that serve
 +
as the basis for 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 [BCP101].  The objective is to
 +
encourage 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.
  
 +
While this document is intended to improve cooperation between the
 +
two organizations, it does not change any of the formal practices or
 +
procedures of either organization.
  
 +
=== Why Cooperate? ===
  
 +
IEEE 802 and the IETF are independent standards organizations that
 +
each use standards produced by the other organization and develop
 +
standards dependent on those produced by the other organization.
 +
This dependency may extend to carrying attributes in protocols that
 +
reflect technologies defined by the other organization.
  
 +
The dependencies between IEEE 802 and IETF standards are a motivation
 +
for cooperation between the organizations.  However, since the
 +
benefits of cooperation come at the cost of coordination overhead,
 +
the benefits of coordination must outweigh the cost.
  
 +
The IETF benefits from coordination by obtaining improved access to
 +
IEEE 802 expertise in the widely deployed and widely used IEEE 802
 +
Local Area Network architecture [ARCH802].
  
 +
IEEE 802 benefits from coordination by obtaining improved access to
 +
IETF expertise on IP datagram encapsulation, routing, transport, and
 +
security, as well as specific applications of interest to IEEE 802.
  
 +
== Organization, Participation, and Membership ==
  
 +
IEEE 802 and IETF are similar in some ways but different in others.
 +
When working on projects of interest to both organizations, it is
 +
important to understand the similarities and differences.
  
 +
=== IEEE 802 ===
  
 +
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, while
 +
advocating for them on a global basis.  Areas of standardization work
 +
include Ethernet, Bridging and Virtual Bridged LANs, Wireless LAN
 +
(Local Area Network), Wireless PAN (Personal Area Network), Wireless
 +
MAN (Metropolitan Area Network), Wireless Coexistence, Media
 +
Independent Handover Services, and Wireless RAN (Regional Access
 +
Network).  Within IEEE 802, a Working Group provides the focus for
 +
each of these areas.
  
 +
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.
  
 +
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
 +
<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, May, 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
 +
plenary if they have not completed their work.
  
 +
Participation in IEEE 802 Working Groups is at the level of
 +
individuals -- participants are human beings and not companies.
 +
While participation 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.  It is not necessary to be eligible to
 +
vote in order 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:
  
 +
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 two-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.
  
 +
=== IETF ===
  
 +
The IETF Standards Process is defined in [BCP9].  [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.
  
 +
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.  The IETF Working Group process is defined in [BCP25].
  
 +
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]].
  
 +
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 Internet Architecture Board (IAB) charter [BCP39] 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 the RFC Series Editor [[RFC6635]] and Independent
 +
      Submission Editor [[RFC6548]]
 +
  5.  Appointment of the Internet Assigned Number Authority (IANA)
 +
      operator [[RFC6220]]
 +
  6.  Oversight of External Liaisons for the IETF [BCP102]
  
 +
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].
  
 +
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.
  
 +
IETF meets in plenary sessions three times per year.  Some Working
 +
Groups schedule additional interim meetings, which may be either
 +
face-to-face or "virtual".  Information about IETF meetings is
 +
available at <http://www.ietf.org/meeting/upcoming.html>.
 +
Information about IETF Working Group interim meetings is available on
 +
<http://www.ietf.org/meeting/interim-meetings.html>.
  
 +
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.
  
 +
Participation in the IETF is open to anyone (technically, anyone with
 +
access to email sufficient to allow subscription to one or more IETF
 +
mailing lists).  All IETF participants act as individuals.  There is
 +
no concept of "IETF membership".
  
 +
A good place 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.
  
 +
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 is available at
 +
<http://www.ietf.org/tao.html>.
  
== Introduction ==
+
The current list of IETF Area Directors and Working Group chairs can
 
+
be found in the IETF Working Group charters, at
This document contains a set of principles and guidelines that serve
+
<http://datatracker.ietf.org/wg/>.
as the basis for 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 [BCP101].  The objective is to
 
encourage 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.
 
 
 
While this document is intended to improve cooperation between the
 
two organizations, it does not change any of the formal practices or
 
procedures of either organization.
 
 
 
=== Why Cooperate? ===
 
 
 
IEEE 802 and the IETF are independent standards organizations that
 
each use standards produced by the other organization and develop
 
standards dependent on those produced by the other organization.
 
This dependency may extend to carrying attributes in protocols that
 
reflect technologies defined by the other organization.
 
 
 
The dependencies between IEEE 802 and IETF standards are a motivation
 
for cooperation between the organizations.  However, since the
 
benefits of cooperation come at the cost of coordination overhead,
 
the benefits of coordination must outweigh the cost.
 
 
 
The IETF benefits from coordination by obtaining improved access to
 
IEEE 802 expertise in the widely deployed and widely used IEEE 802
 
Local Area Network architecture [ARCH802].
 
  
IEEE 802 benefits from coordination by obtaining improved access to
+
=== Structural Differences ===
IETF expertise on IP datagram encapsulation, routing, transport, and
 
security, as well as specific applications of interest to IEEE 802.
 
  
== Organization, Participation, and Membership ==
+
IEEE 802 and IETF have similar structures, but the terms they use are
 
+
different, and even conflicting.  For example, both IEEE 802 and IETF
IEEE 802 and IETF are similar in some ways but different in others.
+
use the term "Working Group", but this means very different things in
When working on projects of interest to both organizations, it is
+
the two organizations.
important to understand the similarities and differences.
 
  
 +
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
 +
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
 +
<http://www.ietf.org/iesg/directorate.html>.  IEEE 802 does not have
 +
a corresponding organizational entity.
  
 +
=== 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
 +
      [RONR].
  
 +
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.  IEEE 802 considers both
 +
      technical and economic feasibility when deciding whether to
 +
      approve new work, as noted in Section 4.1.7.
 +
 +
Decision-making: 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 percent
 +
      vote to decide technical issues, and a 50 percent +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".
 +
      IETF consensus and humming is discussed further in [[RFC7282]].
  
=== IEEE 802 ===
+
Balance between mailing lists and meetings:  Both organizations make
 
+
      use of mailing lists.  IETF Working Groups rely heavily on
The IEEE Standards Association (IEEE-SA) is the standards-setting
+
      mailing lists, where work is done, in addition to formal
body of the IEEE.  The IEEE-SA Standards Board oversees the IEEE
+
      meetings.  The IETF requires all Working Group decisions to be
standards development process.
+
      made (or, often in practice, confirmed) on mailing lists --
 
+
      final decisions aren't made in meetings.  IEEE 802 Working
The IEEE-SA Standards Board supervises what IEEE calls "sponsors" --
+
      Groups typically meet face-to-face about twice as often as IETF
IEEE entities that develop standardsThe IEEE 802 LAN/MAN Standards
+
      Working Groups (three IEEE 802 plenaries plus three IETF 802
Committee is a sponsor that develops and maintains networking
+
      interim meetings each year, compared to three IETF plenaries
standards and recommended practices for local, metropolitan, and
+
      per year), and teleconferences are more common in IEEE 802 than
other area networks, using an open and accredited process, while
+
      in most IETF Working GroupsMost major decisions in IEEE 802
advocating for them on a global basis.  Areas of standardization work
+
      are made during plenary or interim meetings, except for
include Ethernet, Bridging and Virtual Bridged LANs, Wireless LAN
+
      procedural decisions.  Attendance at meetings is critical to
(Local Area Network), Wireless PAN (Personal Area Network), Wireless
+
      influencing decisions and to maintaining membership voting
MAN (Metropolitan Area Network), Wireless Coexistence, Media
+
      rights.
Independent Handover Services, and Wireless RAN (Regional Access
 
Network)Within IEEE 802, a Working Group provides the focus for
 
each of these areas.
 
  
In IEEE 802, work is done in Working Groups operating under an
+
Interim meetings:  Both organizations use interim meetings (between
Executive CommitteeEach Working Group is led by a Working Group
+
      plenary meetings).  IETF Working Groups schedule interim
ChairMost Working Groups have one or more Task GroupsA Task
+
      meetings on an as-needed basis.  IETF interim meetings may be
Group is responsible for a project or group of projects.
+
      face-to-face or virtualMost IEEE 802 WGs hold regularly
 +
      interim meetings three times a year in the middle of the
 +
      interval between two plenary meetings.  The schedules and
 +
      locations of these meetings are typically known many months in
 +
      advanceIEEE 802 interim meetings are face-to-face onlyIn
 +
      addition to regularly scheduled IEEE 802 interim meetings,
 +
      teleconference and ad hoc meetings are held on an as-needed
 +
      basis.
  
The Executive Committee is comprised of the Executive Committee
+
Remote participation:  Because the IETF doesn't make decisions at
Chair, Executive Committee Officers (e.g., Vice-Chairs, Secretaries,
+
      face-to-face meetings, attendance is not absolutely necessary,
Treasurer), and Working Group Chairs.
+
      and some significant contributors do not attend most face-to-
 +
      face IETF meetings. However, finding people interested in a
 +
      proposal for new work, or soliciting backing for ideas, is
 +
      often more easily accomplished face-to-face, such as in a
 +
      hallway or bar.  Significant contributors to IEEE 802 almost
 +
      always attend face-to-face meetings;  participation in IEEE 802
 +
      meetings is a condition for WG membership.
  
A good place to learn more is the IEEE 802 Home Page, at
+
Lifetime of Standards:  IEEE 802 periodically reviews existing
<http://www.ieee802.org/>An IEEE 802 Orientation for new
+
      standards.  IETF Standards Track documents may be updated or
participants that gives an overview of IEEE 802 process is available
+
      obsoleted by newer Standards Track documents, but there is no
from the home page.
+
      formal periodic review for existing Standards Track documents.
 +
      The status of specific IETF standards is available through the
 +
      IETF "Datatracker" [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 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.  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.
  
The IEEE 802 Executive Committee and all Working Groups meet three
+
=== Mailing Lists ===
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 <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
 
plenary if they have not completed their work.
 
  
 +
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 that 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.
  
Participation in IEEE 802 Working Groups is at the level of
+
Some IEEE 802 participants refer to mailing lists as "reflectors".
individuals -- participants are human beings and not companies.
 
While participation 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
+
== Document Access and Cross-Referencing ==
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.  It is not necessary to be eligible to
 
vote in order 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
+
During the course of IEEE 802 and IETF cooperation, it is important
important to identify and establish contact points within each
+
to share internal documents among the technical Working GroupsIn
organization.  IEEE 802 contact points may include:
+
addition, drafts of IEEE 802 standards, Internet-Drafts, and RFCs may
 +
also be distributed.
 +
 
 +
=== Access to IETF Documents ===
  
IEEE 802 Working Group Chair:  An IEEE 802 Working Group chair is an
+
IETF Internet-Drafts may be located using the IETF Datatracker
      individual who is assigned to lead the work of IEEE 802 in a
+
interface (see [DATATRACKER]) or via the IETF tools site at
      particular areaIEEE 802 Working Group chairs are elected by
+
<http://tools.ietf.org>RFCs may be found at either of the above
      the Working Group and confirmed by the Executive Committee for
+
sites, or via the RFC Editor web site at <http://www.rfc-editor.org>.
      a two-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
+
=== Access to IEEE 802 Standards ===
      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 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 (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.
  
 +
=== 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, access is provided over 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 <https://datatracker.ietf.org/
 +
documents/LIAISON/file41.pdf>), 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.
  
 +
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, sending attachments in proprietary formats to an IETF
 +
mailing list is discouraged.
  
 +
==== 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 their details.  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 Liaisons:  It may be beneficial to establish liaisons as
+
IEEE 802 also supports Technical Advisory Groups (TAGs) that conduct
      additional contact points for specific topics of mutual
+
business and develop documents, although not standardsReferences
      interest.  These contact points should be established early in
+
here to WGs apply to TAGs as well.
      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.
 
  
=== IETF ===
+
==== Access to Internal IEEE 802 Working Group Documents ====
  
The IETF Standards Process is defined in [BCP9].  [BCP11] is a
+
Generally, the archives of minutes and contributions to IEEE 802
helpful description of organizations involved in the IETF standards
+
groups are publicly and freely available.
process.  It can still be useful as an overview, although details
 
have changed since 1996.
 
  
In the IETF, work is done in Working Groups (WGs) and is mostly
+
Many IEEE 802 groups use a documentation system provided by IEEE and
carried out through open, public mailing lists rather than face-to-
+
known as "Mentor".  The list of these groups is available at the IEEE
face meetings.  The IETF Working Group process is defined in [BCP25].
+
802 Mentor Home Page: <https://mentor.ieee.org/802>.  Mentor provides
 +
the following features:
  
WGs are organized into areas, and each area is managed by one or more
+
1The documentation system is structured and ordered, with
Area DirectorsCollectively, the Area Directors constitute the
+
    documentation tags and unique numbering and versioning.
Internet Engineering Steering Group (IESG) [RFC3710].
 
  
To foster ongoing communication between IEEE 802 and IETF, it is
+
2Online documentation is available.
important to identify and establish contact points within each
 
organizationIETF 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 Internet Architecture Board (IAB) charter [BCP39] assigns the IAB
+
3.  Limited search functionality is provided, and publicly available
several responsibilities relevant to this document:
+
    search engines index the data.
 
 
  1.  IESG Appointment Confirmation [BCP10]
 
  2.  Architectural Oversight
 
  3.  Standards Process Oversight and Appeal
 
  4.  Appointment of the RFC Series Editor [RFC6635] and Independent
 
      Submission Editor [RFC6548]
 
  5.  Appointment of the Internet Assigned Number Authority (IANA)
 
      operator [RFC6220]
 
  6. Oversight of External Liaisons for the IETF [BCP102]
 
  
 +
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
 +
    <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.
  
 +
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
 +
<http://www.ieee802.org/1/files/public/>.  The file names indicate
 +
the relevant project, author, date, and version.  The file-naming
 +
conventions and upload link are at
 +
<http://www.ieee802.org/1/filenaming.html>.  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 <http://www.ieee802.org/3/>.  Files are
 +
uploaded by emailing to the subgroup chair.
  
IESG and IAB members are selected using the NomCom process defined in
+
==== Contributions to IEEE 802 Working Groups ====
[BCP10].  Working Group chairs serve at the pleasure of their Area
 
Directors, as described in [BCP25].
 
  
The IETF is designed to be a "bottom-up" protocol engineering
+
In general, development of standards in IEEE 802 is contribution
organization -- the leadership steers and manages but does not direct
+
driven.  In many cases, a WG or subgroup will issue a call for
work in a top-down way.  Technical agreements with "the IETF" are
+
contributions with a specific technical solicitation, including
based on the consensus of Working Group participants, rather than
+
deadlines and submission instructions.  Some groups maintain specific
negotiated with IETF leadership.
+
submission procedures and specify a contribution cover sheet to
 +
clarify the status of the contribution.
  
IETF meets in plenary sessions three times per yearSome Working
+
Content for drafts of standards is submitted to WGs by individual
Groups schedule additional interim meetings, which may be either
+
participants or groups of participantsContent toward other group
face-to-face or "virtual"Information about IETF meetings is
+
documents (such as, for example, external communication statements or
available at <http://www.ietf.org/meeting/upcoming.html>.
+
foundation documents underlying a draft of a standard) might also be
Information about IETF Working Group interim meetings is available on
+
contribution driven.  At some point, the group assembles contributed
<http://www.ietf.org/meeting/interim-meetings.html>.
+
material to develop group documents, and revision takes place within
 +
group meetings or by assignment to EditorsFor the most part, the
 +
contributions toward discussion as well as the group documents
 +
(including minutes and other reports) are openly available to the
 +
public.
  
The preferred way to develop specifications is to do work on mailing
+
=== Cross-Referencing ===
lists, reserving face-to-face sessions for topics that have not been
 
resolved through previous mailing list discussion.
 
  
Participation in the IETF is open to anyone (technically, anyone with
+
IETF and IEEE 802 each recognize the standards defined by the other
access to email sufficient to allow subscription to one or more IETF
+
organizationStandards produced by each organization can be used as
mailing lists)All IETF participants act as individuals.  There is
+
references in standards produced by the other organization.
no concept of "IETF membership".
 
  
A good place to learn more is the IETF Home Page, at
+
IETF specifications may reference IEEE 802 work in progress, but
<http://www.ietf.org/>, and especially the "About the IETF" page at
+
these references should be labeled "Work in Progress". If the
<http://www.ietf.org/about>, selectable from the IETF Home Page.
+
references are normative, this will block publication of the
 +
referring specification until the reference is available in a stable
 +
form.
  
The "Tao of the IETF" is also very helpful, especially for IEEE 802
+
IEEE 802 standards may normatively reference non-expired Internet-
participants who will also be participating in IETF Working Groups
+
Drafts, but IEEE 802 prefers that this be avoided if at all possible.
and attending IETF meetings.  It is available at
 
<http://www.ietf.org/tao.html>.
 
  
The current list of IETF Area Directors and Working Group chairs can
+
Informative references in IEEE 802 standards are placed in a
be found in the IETF Working Group charters, at
+
bibliography, so they may point to either approved IETF standards or
<http://datatracker.ietf.org/wg/>.
+
IETF Internet-Drafts, if necessary.
  
=== Structural Differences ===
+
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 Std 802.1Q(TM)-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 reference refers to a specific revision of an IEEE 802
 +
standard.  Since clauses, subclauses, tables, figures, etc., may be
  
IEEE 802 and IETF have similar structures, but the terms they use are
+
renumbered when a standard is revised, a dated reference should be
different, and even conflicting.  For example, both IEEE 802 and IETF
+
used when citing specific items in a standard.
use the term "Working Group", but this means very different things in
 
the two organizations.
 
  
 +
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.
  
 +
== Guidance on Cooperation ==
  
 +
This section describes how existing processes within the IETF and
 +
IEEE 802 may be used to enable cooperation between the organizations.
  
 +
Historically, much of the work of coordination has fallen on
 +
individuals attending meetings of both organizations.  However, as
 +
noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1
 +
WG" [[RFC4663]], downward pressure on travel budgets has made it
 +
increasingly difficult for participants to attend face-to-face
 +
meetings in both organizations.  That pressure has continued in the
 +
intervening years.  As a result, the coordination mechanisms
 +
described in this section typically do not require meeting
 +
attendance.
  
 +
=== 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.
  
 +
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.  Where
 +
individuals notice a potential conflict or need for coordination, the
 +
issue should be brought to the attention of the relevant Working
 +
Group chairs and/or Area Directors.
  
Thumbnail comparison between IETF and IEEE 802 entities
+
==== How IEEE 802 Is Informed about Active IETF Work Items ====
 
 
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,
+
The responsibility is on IEEE 802 Working Groups to review current
and relatively broadly scoped, containing more narrowly chartered
+
IETF Working Groups to determine if there are any topics of mutual
entities (IEEE 802 Task Groups and IETF Working Groups), which tend
+
interest.  Working Group charters and active Internet-Drafts can be
to be short-lived and narrowly chartered.  IEEE 802 uses Study Groups
+
found in the IETF Datatracker [DATATRACKER]If an IEEE 802 Working
to develop proposals for new work, and these are analogous to IETF
+
Group identifies a common area of work, the IEEE 802 Working Group
Birds of a Feather ("BOF") sessions.
+
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 5.2).
  
Several IETF Areas also have one or more directorates to support the
+
==== How IETF Is Informed about Active IEEE 802 Work Items ====
work of the Area Directors.  Area Directors often ask directorate
 
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
 
<http://www.ietf.org/iesg/directorate.html>.  IEEE 802 does not have
 
a corresponding organizational entity.
 
  
=== Cultural Differences ===
+
It is the responsibility of IETF Working Groups to periodically
 +
review the IEEE 802 web site to determine if there is work in
 +
progress of mutual interest.
  
IEEE 802 and IETF have cultures that are similar but not identical.
+
IEEE 802 Working Group status reports are published at the beginning
Some of the differences include:
+
and end of each plenary at <http://ieee802.org/minutes>. Each
 +
Working Group includes a list of their active projects and the
 +
status.
  
Consensus and Rough Consensus:  Both organizations make decisions
+
The charter of an IEEE 802 project is defined in an approved Project
      based on consensus, but in the IETF, "consensus" can mean
+
Authorization Request (PAR)PARs are accessible in IEEE Standards
      "rough consensus, as determined by Working Group chairs".  In
+
myProject, at <https://development.standards.ieee.org>Access
      practice, this means that a large part of the community being
+
requires an IEEE web account, which is free and has no membership
      asked needs to agree.  Not everyone has to agree, but if
+
requirement.
      someone disagrees, they need to convince other people of their
 
      point of viewIf 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
 
      [RONR].
 
 
 
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 cultureAlthough
 
      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 considers both
 
      technical and economic feasibility when deciding whether to
 
      approve new work, as noted in Section 4.1.7.
 
  
 +
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 5.2).
  
 +
==== Overview of Notifications of New Work Proposals ====
  
 +
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.
  
Decision-making: IEEE 802 Working Groups vary in their reliance upon
+
2.  For both organizations, the top-level coordination body receiving
      voting versus consensus, and in the breadth of coverage of an
+
    that notification is responsible for determining whether
      individual motion, but ultimately, all rely upon a 75 percent
+
    cooperation is, in fact, required, and informing the specific
      vote to decide technical issues, and a 50 percent +1 vote to
+
    groups within the organization who may be affected by the
      decide other issues.  IETF Working Groups do not use voting.
+
    proposal for new work.
      Working Group chairs may ask for a "show of hands" or "take a
+
 
      hum" to judge backing for a proposal and identify technical
+
These direct notifications will be the most common way that each
      concerns and objections, but this is not considered "voting".
+
organization is informed about proposals for new work in the other
      IETF consensus and humming is discussed further in [RFC7282].
+
organization. Several other ways of identifying proposed new work
 +
are described in the following sections. These additional ways act
  
Balance between mailing lists and meetings:  Both organizations make
+
as "belt and suspenders" to reduce the chances that proposals for new
      use of mailing lists.  IETF Working Groups rely heavily on
+
work in one organization escape notice in the other organization when
      mailing lists, where work is done, in addition to formal
+
cooperation will be required.
      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
+
==== The New-Work Mailing List ====
      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
 
      locations 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
+
Several standards development organizations (SDOs), including IETF
      face-to-face meetings, attendance is not absolutely necessary,
+
and IEEE 802, have agreed to use a mailing list for the distribution
      and some significant contributors do not attend most face-to-
+
of information about proposals for new work items among these SDOs.
      face IETF meetings.  However, finding people interested in a
 
      proposal for new work, or soliciting backing for ideas, is
 
      often more easily accomplished face-to-face, such as in a
 
      hallway or bar.  Significant contributors to IEEE 802 almost
 
      always attend face-to-face meetings;  participation in IEEE 802
 
      meetings is a condition for WG membership.
 
  
 +
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.
  
 +
==== 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.
  
 +
==== How IEEE 802 Comments on Proposed New IETF Work Items ====
  
Lifetime of Standards:  IEEE 802 periodically reviews existing
+
Each IEEE 802 Working Group Chair, or designated representative, may
      standards.  IETF Standards Track documents may be updated or
+
provide comments on these charters by responding to the IESG mailing
      obsoleted by newer Standards Track documents, but there is no
+
list at iesg@ietf.org clearly indicating their IEEE 802 position and
      formal periodic review for existing Standards Track documents.
+
the nature of their concern.
      The status of specific IETF standards is available through the
 
      IETF "Datatracker" [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
+
It should be noted that the IETF turnaround time for new Working
      organizations, IEEE 802 and IETF have developed vocabularies
+
Group charters can be as short as two weeks, although the call-for-
      that overlap.  For instance, IEEE 802 "ballots" at several
+
comment period on work items that may require cooperation with IEEE
      levels of the organization during document approval, while IETF
+
802 can be extended to allow more time for discussion within IEEE
      documents are only "balloted" during IESG review.  The IESG
+
802This places a burden on both organizations to proactively
      uses "ballots" to indicate that all technical concerns have
+
communicate and avoid "late surprises" to either organization.
      been addressed, not to indicate that the IESG agrees with a
 
      documentThe intention is to "discuss" technical issues with
 
      a document, and "no" is not one of the choices on an IESG
 
      ballot.
 
  
=== Mailing Lists ===
+
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.
  
All IETF Working Groups and all IEEE 802 Working Groups have
+
==== How IETF Is Informed about Proposed New IEEE 802 Work Items ====
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
+
An IEEE 802 project is initiated by approval of a Project
and decision-makingIt is recommended that IEEE 802 experts
+
Authorization Request (PAR), which includes a description of the
interested in particular IETF Working Group topics subscribe to and
+
scope of the workAny IEEE 802 PARs that introduce new
participate in these lists.  IETF WG mailing lists are open to all
+
functionality are required to be available for review no less than 30
subscribers.  The IETF Working Group mailing list subscription and
+
days prior to the Monday of the IEEE 802 plenary session where they
archive information are noted in each Working Group's charter page.
+
will be considered.
  
In IEEE 802, mailing lists are typically used for meeting logistics,
+
IEEE 802 considers "Five Criteria" when deciding whether to approve
ballot announcements, reports, and some technical discussionMost
+
new work: Broad Market Potential, Compatibility, Distinct Identity,
decision-making is at meetings, but in cases where a decision is
+
Technical Feasibility, and Economic FeasibilityThe criteria are
needed between meetings, it may be done over the mailing listMost
+
defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations
technical discussion occurs at meetings and by generating comments on
+
ManualThe PARs are accompanied by responses on the "Five
drafts that are compiled with responses in comment resolution
+
Criteria".
documents.
 
  
 +
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.
  
 +
==== 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 email not
 +
later than 5:00 PM Tuesday of the plenary session (in the time zone
 +
where the plenary is located).
  
 +
==== 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 by 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 <http://www.iab.org/activities/
 +
joint-activities/iab-ieee-coordination/>.
  
 +
=== 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.
  
 +
==== IEEE 802 Draft Review and Balloting Processes ====
  
Most IEEE 802 mailing lists are open to all subscribersFor the few
+
IEEE 802 drafts are reviewed and balloted at multiple stages of the
IEEE 802 mailing lists that are not open, please see the Working
+
draftAny ballot comments received from non-voters before the close
Group chair to arrange for access to the mailing list.
+
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.
  
Some IEEE 802 participants refer to mailing lists as "reflectors".
+
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.
  
== Document Access and Cross-Referencing ==
+
===== Task Group Review =====
  
During the course of IEEE 802 and IETF cooperation, it is important
+
During draft development, informal task group reviews (task group
to share internal documents among the technical Working GroupsIn
+
ballots) are conductedThough these are called "ballots" by some
addition, drafts of IEEE 802 standards, Internet-Drafts, and RFCs may
+
Working Groups, the focus is on collecting and resolving comments on
also be distributed.
+
the draft rather than on trying to achieve a specific voting result.
 +
 
 +
===== Working Group Ballot =====
  
=== Access to IETF Documents ===
+
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.
  
IETF Internet-Drafts may be located using the IETF Datatracker
+
Initial Working Group ballots are at least 30 daysRecirculation
interface (see [DATATRACKER]) or via the IETF tools site at
+
ballots to review draft changes and comment resolutions are open at
<http://tools.ietf.org>RFCs may be found at either of the above
+
least 10 days.
sites, or via the RFC Editor web site at <http://www.rfc-editor.org>.
 
  
=== Access to IEEE 802 Standards ===
+
In order to submit a WG ballot, contact the WG Chair for the
 +
submission tool currently in use, as the tools may change over time.
  
IEEE 802 standards, once approved, are published and made available
+
===== Sponsor Ballot =====
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>,
+
When a draft has successfully completed Working Group ballot, it
grants public access to download individual IEEE 802 standards at no
+
proceeds to Sponsor ballot.  One may participate in IEEE 802 Sponsor
charge (although registration is required).  IEEE 802 standards are
+
ballots with an individual membership in the IEEE Standards
added to the Get IEEE 802 program six months after publication. This
+
Association (IEEE-SA) or by paying a per-ballot feeParticipants
program is approved year by year, but has been in place for several
+
are also required to state their affiliation and the category of
years.
+
their relationship to the scope of the standards activity (e.g.,
 +
producer, user, general interest).
  
=== Access to IEEE 802 Working Group Drafts ===
+
Information about IEEE-SA membership can be found at
 +
<http://standards.ieee.org/membership/>.
  
The IEEE owns the copyright to drafts of standards developed within
+
Sponsor ballot is a public reviewAn invitation is sent to any
IEEE 802 standardization projectsThe IEEE-SA grants permission for
+
parties known to be interested in the subject matter of the ballot.
an IEEE 802 draft to be distributed without charge to the
+
One can indicate interest in IEEE myProject
participants for that IEEE 802 standards development project.
+
(<https://development.standards.ieee.org>).  An IEEE web account is
Typically, access is provided over the Internet under password
+
freely available and is required for login.  To select interest
protection, with the password provided to members of the
+
areas, go to the Projects tab and select "Manage Activity Profile"
participating WGRequests to the relevant WG Chair for access to a
+
and check any areas of interestIEEE 802 projects are under
draft for purposes of participation in the project are typically
+
Computer Society; LAN/MAN Standards Committee.
granted.
 
  
 +
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.
  
 +
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 ballots are open for at least 30 days.  Recirculation
 +
ballots to review draft changes and proposed comment resolutions are
 +
open at least 10 days.
  
 +
===== 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 percent to
 +
approve the final ballot disposition in order to advance the
 +
document.
 +
 +
==== IETF Draft Review and Approval Processes ====
  
An alternative access mechanism which may more easily enable document
+
The IETF Working Group Process is defined in [BCP25]The overall
access for IETF WGs cooperating with IEEE 802 was established by a
+
IETF standards process is defined in [BCP9].
liaison statement sent to the IETF in July 2004 by Paul Nikolich,
 
Chair of IEEE 802 (available at <https://datatracker.ietf.org/
 
documents/LIAISON/file41.pdf>), 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 WGSince 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.
 
 
 
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, sending attachments in proprietary formats to an IETF
 
mailing list is discouraged.
 
  
==== IEEE 802 Documentation System ====
+
As noted in Section 2.4, IETF Working Groups do not "ballot" to
 +
determine Working Group consensus to forward documents to the IESG
 +
for approval.
  
Each IEEE 802 standardization project is assigned to a Working Group
+
Technical contributions are welcome at any point in the IETF document
(WG) for development.  In IEEE 802, the working methods of the WGs
+
review and approval process, but there are some points where
vary in their details.  The documentation system is one area in which
+
contribution is more likely to be effective.
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
+
1.  When a Working Group is considering adoption of an individual
business and develop documents, although not standardsReferences
+
    draftAdoption is often announced on the Working Group's
here to WGs apply to TAGs as well.
+
    mailing list.
  
==== Access to Internal IEEE 802 Working Group Documents ====
+
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.
  
Generally, the archives of minutes and contributions to IEEE 802
+
3.  When the Internet Engineering Steering Group issues an "IETF Last
groups are publicly and freely available.
+
    Call" ("Last Call") for a draft.  IETF Last Call is a formal and
 +
    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.
  
 +
=== 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 (Structure of Management Information) MIB
 +
modules and AAA (Authentication, Authorization, and Accounting)
 +
described in [[RFC4441]].  IESG members routinely solicit directorate
 +
reviews as a means to request 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.
  
 +
== Liaison Managers and Liaison Statements ==
  
Many IEEE 802 groups use a documentation system provided by IEEE and
+
Both IEEE 802 and IETF work best when people participate directly in
known as "Mentor"The list of these groups is available at the IEEE
+
work of mutual interest, but that is not always possible, and
802 Mentor Home Page: <https://mentor.ieee.org/802>Mentor provides
+
individuals speaking as individuals may not provide effective
the following features:
+
communication between the two SDOsFrom time to time, it may be
 
+
appropriate for a technical body in one SDO to communicate as a body
1.  The documentation system is structured and ordered, with
+
with a technical body in the other SDOThis section describes the
    documentation tags and unique numbering and versioning.
+
mechanisms used to provide formal communication between the two
 +
organizations, should that become necessary.
  
2Online documentation is available.
+
The Internet Architecture Board (IAB) is responsible for liaison
 +
relationship oversight for the IETFIn IEEE 802, liaison
 +
relationship oversight is distributed, and each organization
 +
appointing liaison managers is responsible for oversight of its own
 +
liaison relationships.
  
3. Limited search functionality is provided, and publicly available
+
The reader should note that the role of a liaison manager in both
    search engines index the data.
+
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
  
4.  The ability to submit documents to Mentor is limited but is
+
in each organization, and making sure that formal liaison statements
    generally available to any interested partyAn IEEE web account
+
don't "get lost" between the two organizations.  The IAB's guidance
    is required but can be easily and freely established using the
+
to liaison managers is available in [[RFC4691]].  IEEE 802
    IEEE Account Request page, at
+
organizations appointing each liaison manager also provide guidance
    <http://www.ieee.org/go/create_web_account>If submission is
+
to those liaison managersThere is no global guidance for all IEEE
    protected, the privilege can be requested via the Mentor system
+
802 liaison managers.
    (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
+
=== Liaison Managers ===
    public at the same instant they become available for
 
    consideration by the group.
 
  
IEEE 802.1 and IEEE 802.3 do not use Mentor.
+
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 <http://www.ietf.org/liaison/managers.html>.
  
IEEE 802.1 documents are organized in folders by year at
+
IEEE liaison managers are selected by the organizations they
<http://www.ieee802.org/1/files/public/>.  The file names indicate
+
represent, either in an election or by Working Group or Task Group
the relevant project, author, date, and version.  The file-naming
+
Chair appointment.  The current list of IEEE 802's liaison
conventions and upload link are at
+
relationships and the liaison managers responsible for each of these
<http://www.ieee802.org/1/filenaming.html>.  Upload is moderated.
+
relationships is available at
 
+
<http://www.ieee802.org/liaisons.shtml>.
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 <http://www.ieee802.org/3/>.  Files are
 
uploaded by emailing to the subgroup chair.
 
  
 +
=== 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
 +
(<http://ieee802.org/devdocs.shtml>).
  
 +
The IETF process for sending and receiving liaison statements is
 +
defined in [BCP103].
  
 +
== 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.
  
 +
=== IANA ===
  
 +
The IETF uses the Internet Assigned Numbers Authority (IANA) as a
 +
central authority that administers registries for most protocol
 +
parameter allocations.  The overarching document describing this is
 +
[BCP26].  [BCP141] 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 [BCP26],
 +
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 knowledgeable in
 +
the technology domain, appointed by the IESG and given specific
 +
criteria to use when reviewing requests.
  
 +
=== IEEE Registration Authority ===
  
 +
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 web site, at
 +
<http://standards.ieee.org/develop/regauth/general.html>.
  
==== Contributions to IEEE 802 Working Groups ====
+
Regarding Ethertype allocation:
 
+
Some IETF protocol specifications make use of EthertypesEthertypes
In general, development of standards in IEEE 802 is contribution
+
are a fairly scarce resource so allocation has the following
drivenIn many cases, a WG or subgroup will issue a call for
+
requirementsAll Ethertype requests are subject to review by a
contributions with a specific technical solicitation, including
+
consultant to the IEEE RA, followed by IEEE RAC confirmation.
deadlines and submission instructionsSome groups maintain specific
 
submission procedures and specify a contribution cover sheet to
 
clarify the status of the contribution.
 
  
Content for drafts of standards is submitted to WGs by individual
+
The IEEE RAC will not assign a new Ethertype to a new IETF protocol
participants or groups of participantsContent toward other group
+
specification until the IESG has approved the protocol specification
documents (such as, for example, external communication statements or
+
for publication as an RFCIn exceptional cases, the IEEE RA will
foundation documents underlying a draft of a standard) might also be
+
consider "early allocation" of an Ethertype for an IETF protocol that
contribution driven.  At some point, the group assembles contributed
+
is still under development when the request comes from, and has been
material to develop group documents, and revision takes place within
+
vetted by, the IESG.
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.
 
  
=== Cross-Referencing ===
+
Note that "playpen" Ethertypes have been assigned in IEEE 802
 +
[ARCH802] for use during protocol development and experimentation.
  
IETF and IEEE 802 each recognize the standards defined by the other
+
While a fee is normally charged by the IEEE Registration Authority
organization.  Standards produced by each organization can be used as
+
Committee (RAC) for the allocation of an Ethertype, the IEEE RAC will
references in standards produced by the other organization.
+
consider waiving the fee for allocations relating to an IETF
 +
Standards Track document, based on a request from the IESG.
  
IETF specifications may reference IEEE 802 work in progress, but
+
=== IEEE 802 Registration at the Working Group Level ===
these references should be labeled "Work in Progress".  If the
 
references are normative, this will block publication of the
 
referring specification until the reference is available in a stable
 
form.
 
  
IEEE 802 standards may normatively reference non-expired Internet-
+
Each IEEE 802 Working Group has a registry of identifier values and a
Drafts, but IEEE 802 prefers that this be avoided if at all possible.
+
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.
  
Informative references in IEEE 802 standards are placed in a
+
=== Joint-Use Registries ===
bibliography, so they 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
+
Because some registries are "joint-use" between IEEE 802 and IETF, it
number and the date is updated.  Therefore, IEEE 802 standards are
+
is necessary for each organization to review usage of registries
dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011.
+
maintained by the other organization as part of the review and
There are two ways of referencing IEEE 802 standards: undated and
+
approval process for standards.
dated references.  IEEE 802 practice allows undated reference to be
+
 
used when referencing a whole standard.  An undated reference
+
If an IEEE 802 document refers to IANA registries, those references
indicates that the most recent version of the standard should be
+
should be checked prior to Sponsor ballotingIf an IETF document
usedA dated reference refers to a specific revision of an IEEE 802
+
refers to IEEE 802 registries, those references should be checked as
standard. Since clauses, subclauses, tables, figures, etc., may be
+
part of IANA Review during IETF Last Call.
  
 +
== Security Considerations ==
  
 +
This document describes cooperation procedures and has no direct
 +
Internet security implications.
  
 +
== References ==
  
 +
=== Normative References ===
  
renumbered when a standard is revised, a dated reference should be
+
[BCP26]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
used when citing specific items in a standard.
+
          IANA Considerations Section in RFCs", [[BCP26|BCP 26]], [[RFC5226|RFC 5226]],
 +
          May 2008.
  
IETF standards may be cited by RFC number, which would also be a
+
[BCP141]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and
dated reference.  If an undated reference to an IETF Internet
+
          IETF Protocol and Documentation Usage for IEEE 802
Standard is desired, a number is also assigned in the "STD" series
+
          Parameters", [[BCP141|BCP 141]], [[RFC7042|RFC 7042]], October 2013.
[BCP9], and these references refer to the most recent version of an
 
IETF Internet Standard.
 
  
== Guidance on Cooperation ==
+
[[RFC4691]]  Andersson, L., Ed., "Guidelines for Acting as an IETF
 +
          Liaison to Another Organization", [[RFC4691|RFC 4691]], October 2006.
  
This section describes how existing processes within the IETF and
+
=== Informative References ===
IEEE 802 may be used to enable cooperation between the organizations.
 
 
 
Historically, much of the work of coordination has fallen on
 
individuals attending meetings of both organizations.  However, as
 
noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1
 
WG" [RFC4663], downward pressure on travel budgets has made it
 
increasingly difficult for participants to attend face-to-face
 
meetings in both organizations.  That pressure has continued in the
 
intervening years.  As a result, the coordination mechanisms
 
described in this section typically do not require meeting
 
attendance.
 
 
 
=== 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.
 
 
 
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.  Where
 
individuals notice a potential conflict or need for coordination, the
 
issue should be brought to the attention of the relevant Working
 
Group chairs and/or Area Directors.
 
 
 
==== How IEEE 802 Is Informed about Active IETF Work Items ====
 
 
 
The responsibility is on IEEE 802 Working Groups to review current
 
IETF Working Groups to determine if there are any topics of mutual
 
interest.  Working Group charters and active Internet-Drafts can be
 
found in the IETF Datatracker [DATATRACKER].  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 5.2).
 
 
 
 
 
 
 
 
 
 
 
==== How IETF Is Informed about Active IEEE 802 Work Items ====
 
 
 
It is the responsibility of IETF Working Groups to periodically
 
review 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 <http://ieee802.org/minutes>.  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>.  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 5.2).
 
 
 
==== Overview of Notifications of New Work Proposals ====
 
 
 
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 escape notice in the other organization when
 
cooperation will be required.
 
 
 
==== 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.
 
 
 
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.
 
 
 
==== 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.
 
 
 
==== 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 [email protected] 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.
 
 
 
 
 
 
 
 
 
 
 
==== 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 of the work.  Any IEEE 802 PARs that 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 "Five
 
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.
 
 
 
==== 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 email not
 
later than 5:00 PM Tuesday of the plenary session (in the time zone
 
where the plenary is located).
 
 
 
==== 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 by 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 <http://www.iab.org/activities/
 
joint-activities/iab-ieee-coordination/>.
 
 
 
=== 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.
 
 
 
==== IEEE 802 Draft Review and Balloting Processes ====
 
 
 
IEEE 802 drafts are reviewed and balloted at multiple stages of 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.
 
 
 
4.2.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.
 
 
 
4.2.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 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 open at
 
least 10 days.
 
 
 
In order to submit a WG ballot, contact the WG Chair for the
 
submission tool currently in use, as the tools may change over time.
 
 
 
4.2.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
 
<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
 
(<https://development.standards.ieee.org>).  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.
 
 
 
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 ballots are open for at least 30 days.  Recirculation
 
ballots to review draft changes and proposed comment resolutions are
 
open at least 10 days.
 
 
 
4.2.1.4.  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 percent to
 
approve the final ballot disposition in order to advance the
 
document.
 
 
 
==== IETF Draft Review and Approval Processes ====
 
 
 
The IETF Working Group Process is defined in [BCP25].  The overall
 
IETF standards process is defined in [BCP9].
 
 
 
As noted in Section 2.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
 
    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.
 
 
 
=== 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 (Structure of Management Information) MIB
 
modules and AAA (Authentication, Authorization, and Accounting)
 
described in [RFC4441].  IESG members routinely solicit directorate
 
reviews as a means to request 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.
 
 
 
== Liaison Managers and Liaison Statements ==
 
 
 
Both IEEE 802 and IETF work best when people participate directly in
 
work of mutual interest, but that is 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.
 
 
 
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.
 
 
 
=== 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 <http://www.ietf.org/liaison/managers.html>.
 
 
 
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
 
<http://www.ieee802.org/liaisons.shtml>.
 
 
 
=== 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
 
(<http://ieee802.org/devdocs.shtml>).
 
 
 
The IETF process for sending and receiving liaison statements is
 
defined in [BCP103].
 
 
 
== 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.
 
 
 
=== IANA ===
 
 
 
The IETF uses the Internet Assigned Numbers Authority (IANA) as a
 
central authority that administers registries for most protocol
 
parameter allocations.  The overarching document describing this is
 
[BCP26].  [BCP141] 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 [BCP26],
 
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 knowledgeable in
 
the technology domain, appointed by the IESG and given specific
 
criteria to use when reviewing requests.
 
 
 
=== IEEE Registration Authority ===
 
 
 
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 web site, at
 
<http://standards.ieee.org/develop/regauth/general.html>.
 
 
 
Regarding Ethertype allocation:
 
Some IETF protocol specifications make use of Ethertypes.  Ethertypes
 
are a fairly scarce 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
+
[ARCH802]  IEEE 802, "IEEE Standard for Local and Metropolitan Area
specification until the IESG has approved the protocol specification
+
          Networks: Overview and Architecture", IEEE 802 Std
for publication as an RFC.  In exceptional cases, the IEEE RA will
+
          802(TM)-2014, 2014.
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
 
[ARCH802] for use during protocol development and experimentation.
 
  
While a fee is normally charged by the IEEE Registration Authority
+
[BCP9]    Bradner, S., "The Internet Standards Process -- Revision
Committee (RAC) for the allocation of an Ethertype, the IEEE RAC will
+
          3", [[BCP9|BCP 9]], [[RFC2026|RFC 2026]], October 1996.
consider waiving the fee for allocations relating to an IETF
 
Standards Track document, based on a request from the IESG.
 
  
 +
          Dusseault, L. and R. Sparks, "Guidance on Interoperation
 +
          and Implementation Reports for Advancement to Draft
 +
          Standard", [[BCP9|BCP 9]], [[RFC5657|RFC 5657]], September 2009.
  
 +
          Housley, R., Crocker, D., and E. Burger, "Reducing the
 +
          Standards Track to Two Maturity Levels", [[BCP9|BCP 9]], [[RFC6410|RFC 6410]],
 +
          October 2011.
  
 +
          Resnick, P., "Retirement of the "Internet Official
 +
          Protocol Standards" Summary Document", [[BCP9|BCP 9]], [[RFC7100|RFC 7100]],
 +
          December 2013.
  
 +
          Kolkman, O., Bradner, S., and S. Turner, "Characterization
 +
          of Proposed Standards", [[BCP9|BCP 9]], [[RFC7127|RFC 7127]], January 2014.
  
 +
[BCP10]    Galvin, J., Ed., "IAB and IESG Selection, Confirmation,
 +
          and Recall Process: Operation of the Nominating and Recall
 +
          Committees", [[BCP10|BCP 10]], [[RFC3777|RFC 3777]], June 2004.
  
=== IEEE 802 Registration at the Working Group Level ===
+
          Dawkins, S., Ed., "Nominating Committee Process: Earlier
 +
          Announcement of Open Positions and Solicitation of
 +
          Volunteers", [[BCP10|BCP 10]], [[RFC5633|RFC 5633]], August 2009.
  
Each IEEE 802 Working Group has a registry of identifier values and a
+
          Dawkins, S., Ed., "The Nominating Committee Process: Open
mechanism to allocate identifier values in its standards and approved
+
          Disclosure of Willing Nominees", [[BCP10|BCP 10]], [[RFC5680|RFC 5680]], October
amendments. This includes items such as Object Identifiers for
+
          2009.
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.
 
  
=== Joint-Use Registries ===
+
          Leiba, B., "Update to [[RFC3777|RFC 3777]] to Clarify Nominating
 +
          Committee Eligibility of IETF Leadership", [[BCP10|BCP 10]], RFC
 +
          6859, January 2013.
  
Because some registries are "joint-use" between IEEE 802 and IETF, it
+
[BCP11]    Hovey, R. and S. Bradner, "The Organizations Involved in
is necessary for each organization to review usage of registries
+
          the IETF Standards Process", [[BCP11|BCP 11]], [[RFC2028|RFC 2028]], October
maintained by the other organization as part of the review and
+
          1996.
approval process for standards.
 
  
If an IEEE 802 document refers to IANA registries, those references
+
[BCP25]    Bradner, S., "IETF Working Group Guidelines and
should be checked prior to Sponsor balloting. If an IETF document
+
          Procedures", [[BCP25|BCP 25]], [[RFC2418|RFC 2418]], September 1998.
refers to IEEE 802 registries, those references should be checked as
 
part of IANA Review during IETF Last Call.
 
  
== Security Considerations ==
+
          Wasserman, M., "Updates to [[RFC2418|RFC 2418]] Regarding the
 +
          Management of IETF Mailing Lists", [[BCP25|BCP 25]], [[RFC3934|RFC 3934]],
 +
          October 2004.
  
This document describes cooperation procedures and has no direct
+
[BCP39]    Internet Architecture Board and B. Carpenter, Ed.,
Internet security implications.
+
          "Charter of the Internet Architecture Board (IAB)", BCP
 +
          39, [[RFC2850|RFC 2850]], May 2000.
  
== References ==
+
[BCP101]  Austein, R., Ed., and B. Wijnen, Ed., "Structure of the
 +
          IETF Administrative Support Activity (IASA)", [[BCP101|BCP 101]], RFC
 +
          4071, April 2005.
  
=== Normative References ===
+
          Carpenter, B., Ed., and L. Lynch, Ed., "[[BCP101|BCP 101]] Update for
 +
          IPR Trust", [[BCP101|BCP 101]], [[RFC4371|RFC 4371]], January 2006.
  
[BCP26]   Narten, T. and H. Alvestrand, "Guidelines for Writing an          IANA Considerations Section in RFCs", [[BCP26|BCP 26]], [[RFC5226|RFC 5226]],          May 2008.
+
[BCP102]   Daigle, L., Ed., and Internet Architecture Board, "IAB
[BCP141]  Eastlake 3rd, D. and J. Abley, "IANA Considerations and          IETF Protocol and Documentation Usage for IEEE 802          Parameters", [[BCP141|BCP 141]], [[RFC7042|RFC 7042]], October 2013.
+
          Processes for Management of IETF Liaison Relationships",
[RFC4691] Andersson, L., Ed., "Guidelines for Acting as an IETF          Liaison to Another Organization", [[RFC4691|RFC 4691]], October 2006.
+
          [[BCP102|BCP 102]], [[RFC4052|RFC 4052]], April 2005.
=== Informative References ===
 
  
[ARCH802] IEEE 802, "IEEE Standard for Local and Metropolitan Area          Networks: Overview and Architecture", IEEE 802 Std          802(TM)-2014, 2014.
+
[BCP103]   Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
 +
          Handling Liaison Statements to and from the IETF", BCP
 +
          103, [[RFC4053|RFC 4053]], April 2005.
  
 +
[BCP111]  Heard, C., Ed., "Guidelines for Authors and Reviewers of
 +
          MIB Documents", [[BCP111|BCP 111]], [[RFC4181|RFC 4181]], September 2005.
  
 +
          Heard, C., Ed., "[[RFC4181|RFC 4181]] Update to Recognize the IETF
 +
          Trust", [[BCP111|BCP 111]], [[RFC4841|RFC 4841]], March 2007.
  
 +
[BCP132]  Housley, R. and B. Aboba, "Guidance for Authentication,
 +
          Authorization, and Accounting (AAA) Key Management", BCP
 +
          132, [[RFC4962|RFC 4962]], July 2007.
  
 +
[BCP158]  DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",
 +
          [[BCP158|BCP 158]], [[RFC6158|RFC 6158]], March 2011.
  
 +
[DADG]    Morand, L., Ed., Fajardo, V. and H. Tschofenig, "Diameter
 +
          Applications Design Guidelines", Work in Progress, June
 +
          2014.
  
[BCP9]     Bradner, S., "The Internet Standards Process -- Revision          3", [[BCP9|BCP 9]], [[RFC2026|RFC 2026]], October 1996.
+
[DATATRACKER]
          Dusseault, L. and R. Sparks, "Guidance on Interoperation          and Implementation Reports for Advancement to Draft          Standard", [[BCP9|BCP 9]], [[RFC5657|RFC 5657]], September 2009.
+
           Internet Engineering Task Force, "IETF Datatracker",
           Housley, R., Crocker, D., and E. Burger, "Reducing the          Standards Track to Two Maturity Levels", [[BCP9|BCP 9]], [[RFC6410|RFC 6410]],          October 2011.
+
           <https://datatracker.ietf.org>.
          Resnick, P., "Retirement of the "Internet Official          Protocol Standards" Summary Document", [[BCP9|BCP 9]], [[RFC7100|RFC 7100]],          December 2013.
 
          Kolkman, O., Bradner, S., and S. Turner, "Characterization          of Proposed Standards", [[BCP9|BCP 9]], [[RFC7127|RFC 7127]], January 2014.
 
[BCP10]    Galvin, J., Ed., "IAB and IESG Selection, Confirmation,          and Recall Process: Operation of the Nominating and Recall          Committees", [[BCP10|BCP 10]], [[RFC3777|RFC 3777]], June 2004.
 
           Dawkins, S., Ed., "Nominating Committee Process: Earlier          Announcement of Open Positions and Solicitation of          Volunteers", [[BCP10|BCP 10]], [[RFC5633|RFC 5633]], August 2009.
 
          Dawkins, S., Ed., "The Nominating Committee Process: Open          Disclosure of Willing Nominees", [[BCP10|BCP 10]], [[RFC5680|RFC 5680]], October          2009.
 
          Leiba, B., "Update to [[RFC3777|RFC 3777]] to Clarify Nominating          Committee Eligibility of IETF Leadership", [[BCP10|BCP 10]], RFC          6859, January 2013.
 
[BCP11]    Hovey, R. and S. Bradner, "The Organizations Involved in          the IETF Standards Process", [[BCP11|BCP 11]], [[RFC2028|RFC 2028]], October          1996.
 
[BCP25]    Bradner, S., "IETF Working Group Guidelines and          Procedures", [[BCP25|BCP 25]], [[RFC2418|RFC 2418]], September 1998.
 
          Wasserman, M., "Updates to [[RFC2418|RFC 2418]] Regarding the          Management of IETF Mailing Lists", [[BCP25|BCP 25]], [[RFC3934|RFC 3934]],          October 2004.
 
[BCP39]    Internet Architecture Board and B. Carpenter, Ed.,          "Charter of the Internet Architecture Board (IAB)", BCP          39, [[RFC2850|RFC 2850]], May 2000.
 
  
 +
[IEEE80211F]
 +
          IEEE, "IEEE Trial-Use Recommended Practice for Multi-
 +
          Vendor Access Point Interoperability Via an Inter-Access
 +
          Point Protocol Across Distribution Systems Supporting IEEE
 +
          802.11 Operation", IEEE 802 Std 802.11F(TM)-2003, 2003.
  
 +
[IEEE-802.16-Liaison1]
 +
          Liaison letter from IEEE 802.16 to Bernard Aboba, March
 +
          17, 2005,
 +
          <http://ieee802.org/16/liaison/docs/L80216-05_025.pdf>.
  
 +
[IEEE-802.16-Liaison2]
 +
          Liaison letter from IEEE 802.16 to Bernard Aboba, May 5,
 +
          2005,
 +
          <http://ieee802.org/16/liaison/docs/L80216-05_039.pdf>.
  
[BCP101]  Austein, R., Ed., and B. Wijnen, Ed., "Structure of the          IETF Administrative Support Activity (IASA)", [[BCP101|BCP 101]], RFC          4071, April 2005.
+
[[RFC3575]] Aboba, B., "IANA Considerations for RADIUS (Remote
          Carpenter, B., Ed., and L. Lynch, Ed., "[[BCP101|BCP 101]] Update for           IPR Trust", [[BCP101|BCP 101]], [[RFC4371|RFC 4371]], January 2006.
+
           Authentication Dial In User Service)", [[RFC3575|RFC 3575]], July
[BCP102]  Daigle, L., Ed., and Internet Architecture Board, "IAB          Processes for Management of IETF Liaison Relationships",          [[BCP102|BCP 102]], [[RFC4052|RFC 4052]], April 2005.
+
          2003.
[BCP103]  Trowbridge, S., Bradner, S., and F. Baker, "Procedures for          Handling Liaison Statements to and from the IETF", BCP          103, [[RFC4053|RFC 4053]], April 2005.
 
[BCP111]  Heard, C., Ed., "Guidelines for Authors and Reviewers of          MIB Documents", [[BCP111|BCP 111]], [[RFC4181|RFC 4181]], September 2005.
 
           Heard, C., Ed., "[[RFC4181|RFC 4181]] Update to Recognize the IETF          Trust", [[BCP111|BCP 111]], [[RFC4841|RFC 4841]], March 2007.
 
[BCP132]  Housley, R. and B. Aboba, "Guidance for Authentication,          Authorization, and Accounting (AAA) Key Management", BCP          132, [[RFC4962|RFC 4962]], July 2007.
 
[BCP158]  DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",          [[BCP158|BCP 158]], [[RFC6158|RFC 6158]], March 2011.
 
[DADG]    Morand, L., Ed., Fajardo, V. and H. Tschofenig, "Diameter          Applications Design Guidelines", Work in Progress, June          2014.
 
[DATATRACKER]          Internet Engineering Task Force, "IETF Datatracker",          <https://datatracker.ietf.org>.
 
[IEEE80211F]          IEEE, "IEEE Trial-Use Recommended Practice for Multi-          Vendor Access Point Interoperability Via an Inter-Access          Point Protocol Across Distribution Systems Supporting IEEE          802.11 Operation", IEEE 802 Std 802.11F(TM)-2003, 2003.
 
  
 +
[[RFC3710]]  Alvestrand, H., "An IESG charter", [[RFC3710|RFC 3710]], February
 +
          2004.
  
 +
[[RFC3748]]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
 +
          Levkowetz, Ed., "Extensible Authentication Protocol
 +
          (EAP)", [[RFC3748|RFC 3748]], June 2004.
  
 +
[[RFC4137]]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
 +
          "State Machines for Extensible Authentication Protocol
 +
          (EAP) Peer and Authenticator", [[RFC4137|RFC 4137]], August 2005.
  
 +
[[RFC4441]]  Aboba, B., Ed., "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", [[RFC4663|RFC 4663]], September 2006.
  
 +
[[RFC5247]]  Aboba, B., Simon, D., and P. Eronen, "Extensible
 +
          Authentication Protocol (EAP) Key Management Framework",
 +
          [[RFC5247|RFC 5247]], August 2008.
  
 +
[[RFC6220]]  McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,
 +
          Huston, G., Ed., and Internet Architecture Board,
 +
          "Defining the Role and Function of IETF Protocol Parameter
 +
          Registry Operators", [[RFC6220|RFC 6220]], April 2011.
  
 +
[[RFC6548]]  Brownlee, N., Ed., and IAB, "Independent Submission Editor
 +
          Model", [[RFC6548|RFC 6548]], June 2012.
  
 +
[[RFC6635]]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
 +
          Model (Version 2)", [[RFC6635|RFC 6635]], June 2012.
  
 +
[[RFC6733]]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
 +
          Ed., "Diameter Base Protocol", [[RFC6733|RFC 6733]], October 2012.
  
[IEEE-802.16-Liaison1]          Liaison letter from IEEE 802.16 to Bernard Aboba, March          17, 2005,          <http://ieee802.org/16/liaison/docs/L80216-05_025.pdf>.
+
[[RFC6756]]  Trowbridge, S., Ed., Lear, E., Ed., Fishman, G., Ed., and
[IEEE-802.16-Liaison2]           Liaison letter from IEEE 802.16 to Bernard Aboba, May 5,          2005,          <http://ieee802.org/16/liaison/docs/L80216-05_039.pdf>.
+
          S. Bradner, Ed., "Internet Engineering Task Force and
[RFC3575Aboba, B., "IANA Considerations for RADIUS (Remote          Authentication Dial In User Service)", [[RFC3575|RFC 3575]], July          2003.
+
          International Telecommunication Union - Telecommunication
[RFC3710]  Alvestrand, H., "An IESG charter", [[RFC3710|RFC 3710]], February          2004.
+
          Standardization Sector Collaboration Guidelines", RFC
[RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.           Levkowetz, Ed., "Extensible Authentication Protocol          (EAP)", [[RFC3748|RFC 3748]], June 2004.
+
          6756, September 2012.
[RFC4137]  Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,          "State Machines for Extensible Authentication Protocol          (EAP) Peer and Authenticator", [[RFC4137|RFC 4137]], August 2005.
 
[RFC4441]  Aboba, B., Ed., "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", [[RFC4663|RFC 4663]], September 2006.
 
[RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible          Authentication Protocol (EAP) Key Management Framework",          [[RFC5247|RFC 5247]], August 2008.
 
[RFC6220]  McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,          Huston, G., Ed., and Internet Architecture Board,          "Defining the Role and Function of IETF Protocol Parameter          Registry Operators", [[RFC6220|RFC 6220]], April 2011.
 
[RFC6548]  Brownlee, N., Ed., and IAB, "Independent Submission Editor          Model", [[RFC6548|RFC 6548]], June 2012.
 
[RFC6635]  Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor          Model (Version 2)", [[RFC6635|RFC 6635]], June 2012.
 
[RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,          Ed., "Diameter Base Protocol", [[RFC6733|RFC 6733]], October 2012.
 
  
 +
[[RFC6929]]  DeKok, A. and A. Lior, "Remote Authentication Dial In User
 +
          Service (RADIUS) Protocol Extensions", [[RFC6929|RFC 6929]], April
 +
          2013.
  
 +
[[RFC7282]]  Resnick, P., "On Consensus and Humming in the IETF", RFC
 +
          7282, June 2014.
  
 +
[RONR]    Robert, H., et al., "Robert's Rules of Order Newly
 +
          Revised", 11th ed., Da Capo Press, 2011,
 +
          <http://www.robertsrules.com/>.
  
[RFC6756]  Trowbridge, S., Ed., Lear, E., Ed., Fishman, G., Ed., and          S. Bradner, Ed., "Internet Engineering Task Force and          International Telecommunication Union - Telecommunication          Standardization Sector Collaboration Guidelines", RFC          6756, September 2012.
 
[RFC6929]  DeKok, A. and A. Lior, "Remote Authentication Dial In User          Service (RADIUS) Protocol Extensions", [[RFC6929|RFC 6929]], April          2013.
 
[RFC7282]  Resnick, P., "On Consensus and Humming in the IETF", RFC          7282, June 2014.
 
[RONR]    Robert, H., et al., "Robert's Rules of Order Newly          Revised", 11th ed., Da Capo Press, 2011,          <http://www.robertsrules.com/>.
 
 
== Acknowledgments ==
 
== Acknowledgments ==
  
 
This document borrows a significant amount of text, and much of its
 
This document borrows a significant amount of text, and much of its
structure, from [RFC6756].  Additional text was borrowed from
+
structure, from [[RFC6756]].  Additional text was borrowed from
[RFC4441].  We are grateful to the authors and editors of both these
+
[[RFC4441]].  We are grateful to the authors and editors of both these
 
predecessor documents.
 
predecessor documents.
  
Line 1,396: Line 1,307:
 
review comments.
 
review comments.
  
 
+
10.  IAB Members at the Time of Approval
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
== IAB Members at the Time of Approval ==
 
  
 
Bernard Aboba
 
Bernard Aboba
Line 1,431: Line 1,323:
 
Hannes Tschofenig
 
Hannes Tschofenig
  
== IEEE 802 Executive Committee Members at the Time of Approval ==
+
11.  IEEE 802 Executive Committee Members at the Time of Approval
  
 
Radhakrishna Canchi
 
Radhakrishna Canchi
Line 1,452: Line 1,344:
 
Pat Thaler
 
Pat Thaler
 
Geoff Thompson
 
Geoff Thompson
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  
 
Appendix A.  Current Examples of IEEE 802 and IETF Cooperation
 
Appendix A.  Current Examples of IEEE 802 and IETF Cooperation
Line 1,482: Line 1,359:
 
work was transferred to IEEE 802 with expert support for MIB review
 
work was transferred to IEEE 802 with expert support for MIB review
 
from the IETF.  The process of transfer of the MIB work from the IETF
 
from the IETF.  The process of transfer of the MIB work from the IETF
Bridge MIB WG to IEEE 802.1 WG is documented in [RFC4663].
+
Bridge MIB WG to IEEE 802.1 WG is documented in [[RFC4663]].
  
 
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing
 
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing
Line 1,511: Line 1,388:
 
multiple potential applications, allocation from the IETF standard
 
multiple potential applications, allocation from the IETF standard
 
attribute space is preferred to creation of IEEE 802 Vendor-Specific
 
attribute space is preferred to creation of IEEE 802 Vendor-Specific
Attributes (VSAs).  As noted in [RFC3575]: "RADIUS defines a
+
Attributes (VSAs).  As noted in [[RFC3575]]: "RADIUS defines a
 
mechanism for Vendor-Specific extensions (Attribute 26) for functions
 
mechanism for Vendor-Specific extensions (Attribute 26) for functions
 
specific only to one vendor's implementation of RADIUS, where no
 
specific only to one vendor's implementation of RADIUS, where no
 
 
 
 
 
 
  
 
interoperability is deemed useful.  For functions specific only to
 
interoperability is deemed useful.  For functions specific only to
Line 1,532: Line 1,403:
 
It is recommended that IEEE 802 Working Groups read and follow the
 
It is recommended that IEEE 802 Working Groups read and follow the
 
recommendations in "RADIUS Design Guidelines" [BCP158] and "Protocol
 
recommendations in "RADIUS Design Guidelines" [BCP158] and "Protocol
Extensions" [RFC6929] when designing and reviewing new extensions and
+
Extensions" [[RFC6929]] when designing and reviewing new extensions and
 
attributes.
 
attributes.
  
 
"Diameter Applications Design Guidelines" [DADG] explains and
 
"Diameter Applications Design Guidelines" [DADG] explains and
clarifies the rules to extend the Diameter base protocol [RFC6733].
+
clarifies the rules to extend the Diameter base protocol [[RFC6733]].
 
Extending Diameter can mean either the definition of a completely new
 
Extending Diameter can mean either the definition of a completely new
 
Diameter application or the reuse of commands, Attribute-Value Pairs
 
Diameter application or the reuse of commands, Attribute-Value Pairs
Line 1,550: Line 1,421:
 
A.3.  EAP Review
 
A.3.  EAP Review
  
The Extensible Authentication Protocol (EAP), defined in [RFC3748],
+
The Extensible Authentication Protocol (EAP), defined in [[RFC3748]],
 
provides a framework within which authentication mechanisms, known as
 
provides a framework within which authentication mechanisms, known as
 
methods, can be defined.  In addition to supporting authentication,
 
methods, can be defined.  In addition to supporting authentication,
EAP also provides for key derivation as described in [RFC5247].
+
EAP also provides for key derivation as described in [[RFC5247]].
State machines for EAP are described in [RFC4137].
+
State machines for EAP are described in [[RFC4137]].
  
As noted in [BCP132] and [RFC5247], security issues can arise in
+
As noted in [BCP132] and [[RFC5247]], security issues can arise in
 
integration of EAP within lower layers.  Therefore, it is recommended
 
integration of EAP within lower layers.  Therefore, it is recommended
 
that IEEE 802 WGs looking to incorporate support for EAP send a
 
that IEEE 802 WGs looking to incorporate support for EAP send a
Line 1,566: Line 1,437:
 
be submitted and review can be requested from WGs such as the EAP
 
be submitted and review can be requested from WGs such as the EAP
 
Method Update (EMU) WG.
 
Method Update (EMU) WG.
 
 
 
 
 
 
 
  
 
Appendix B.  Pointers to Additional Information
 
Appendix B.  Pointers to Additional Information
Line 1,597: Line 1,461:
 
informative references and at the URLs below.
 
informative references and at the URLs below.
  
'''Note:''' RFCs do not change after they are published.  Rather, they are
+
Note: RFCs do not change after they are published.  Rather, they are
 
either obsoleted or updated by other RFCs.  Such updates are tracked
 
either obsoleted or updated by other RFCs.  Such updates are tracked
 
in the rfc-index.txt file.
 
in the rfc-index.txt file.
Line 1,620: Line 1,484:
 
Current list of liaison statements:
 
Current list of liaison statements:
 
<https://datatracker.ietf.org/liaison/>
 
<https://datatracker.ietf.org/liaison/>
 
 
 
 
 
 
  
 
IETF Intellectual Property Rights Policy and Notices:
 
IETF Intellectual Property Rights Policy and Notices:
Line 1,642: Line 1,500:
  
  
 
  
 
Patricia Thaler
 
Patricia Thaler
Line 1,651: Line 1,508:
  
  
 
  
 
Dan Romascanu
 
Dan Romascanu
Line 1,660: Line 1,516:
  
  
 
  
 
Bernard Aboba (editor)
 
Bernard Aboba (editor)
Line 1,669: Line 1,524:
  
  
 
 
 
 
 
 
 
 
  
 
[[Category:Informational]]
 
[[Category:Informational]]

Latest revision as of 03:48, 2 October 2020

Internet Architecture Board (IAB) S. Dawkins Request for Comments: 7241 Huawei Obsoletes: 4441 P. Thaler Category: Informational Broadcom ISSN: 2070-1721 D. Romascanu

                                                               AVAYA
                                                       B. Aboba, Ed.
                                               Microsoft Corporation
                                                           July 2014
                 The IEEE 802/IETF Relationship

Abstract

This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.

Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.

This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7241.

Copyright Notice

Copyright (c) 2014 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.

11. IEEE 802 Executive Committee Members at the Time of Approval ..31

Contents

Introduction

This document contains a set of principles and guidelines that serve as the basis for 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 [BCP101]. The objective is to encourage 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.

While this document is intended to improve cooperation between the two organizations, it does not change any of the formal practices or procedures of either organization.

Why Cooperate?

IEEE 802 and the IETF are independent standards organizations that each use standards produced by the other organization and develop standards dependent on those produced by the other organization. This dependency may extend to carrying attributes in protocols that reflect technologies defined by the other organization.

The dependencies between IEEE 802 and IETF standards are a motivation for cooperation between the organizations. However, since the benefits of cooperation come at the cost of coordination overhead, the benefits of coordination must outweigh the cost.

The IETF benefits from coordination by obtaining improved access to IEEE 802 expertise in the widely deployed and widely used IEEE 802 Local Area Network architecture [ARCH802].

IEEE 802 benefits from coordination by obtaining improved access to IETF expertise on IP datagram encapsulation, routing, transport, and security, as well as specific applications of interest to IEEE 802.

Organization, Participation, and Membership

IEEE 802 and IETF are similar in some ways but different in others. When working on projects of interest to both organizations, it is important to understand the similarities and differences.

IEEE 802

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, while advocating for them on a global basis. Areas of standardization work include Ethernet, Bridging and Virtual Bridged LANs, Wireless LAN (Local Area Network), Wireless PAN (Personal Area Network), Wireless MAN (Metropolitan Area Network), Wireless Coexistence, Media Independent Handover Services, and Wireless RAN (Regional Access Network). Within IEEE 802, a Working Group provides the focus for each of these areas.

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.

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 <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, May, 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 plenary if they have not completed their work.

Participation in IEEE 802 Working Groups is at the level of individuals -- participants are human beings and not companies. While participation 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. It is not necessary to be eligible to vote in order 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:

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

IETF

The IETF Standards Process is defined in [BCP9]. [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.

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. The IETF Working Group process is defined in [BCP25].

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.

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 Internet Architecture Board (IAB) charter [BCP39] 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 the RFC Series Editor RFC6635 and Independent
      Submission Editor RFC6548
  5.  Appointment of the Internet Assigned Number Authority (IANA)
      operator RFC6220
  6.  Oversight of External Liaisons for the IETF [BCP102]

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

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.

IETF meets in plenary sessions three times per year. Some Working Groups schedule additional interim meetings, which may be either face-to-face or "virtual". Information about IETF meetings is available at <http://www.ietf.org/meeting/upcoming.html>. Information about IETF Working Group interim meetings is available on <http://www.ietf.org/meeting/interim-meetings.html>.

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.

Participation in the IETF is open to anyone (technically, anyone with access to email sufficient to allow subscription to one or more IETF mailing lists). All IETF participants act as individuals. There is no concept of "IETF membership".

A good place 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.

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 is available at <http://www.ietf.org/tao.html>.

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

Structural Differences

IEEE 802 and IETF have similar structures, but the terms they use are different, and even conflicting. For example, both IEEE 802 and IETF use the term "Working Group", but this means 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 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 <http://www.ietf.org/iesg/directorate.html>. IEEE 802 does not have a corresponding organizational entity.

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

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.  IEEE 802 considers both
     technical and economic feasibility when deciding whether to
     approve new work, as noted in Section 4.1.7.

Decision-making: 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 percent
     vote to decide technical issues, and a 50 percent +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".
     IETF consensus and humming is discussed further in RFC7282.

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 to formal
     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
     locations 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, attendance is not absolutely necessary,
     and some significant contributors do not attend most face-to-
     face IETF meetings.  However, finding people interested in a
     proposal for new work, or soliciting backing for ideas, is
     often more easily accomplished face-to-face, such as in a
     hallway or bar.  Significant contributors to IEEE 802 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 the
     IETF "Datatracker" [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 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.  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.

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

Document Access and Cross-Referencing

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.

Access to IETF Documents

IETF Internet-Drafts may be located using the IETF Datatracker interface (see [DATATRACKER]) or via the IETF tools site at <http://tools.ietf.org>. RFCs may be found at either of the above sites, or via the RFC Editor web site at <http://www.rfc-editor.org>.

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

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, access is provided over 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 <https://datatracker.ietf.org/ documents/LIAISON/file41.pdf>), 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.

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, sending attachments in proprietary formats to an IETF mailing list is discouraged.

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

Access to Internal IEEE 802 Working Group Documents

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: <https://mentor.ieee.org/802>. Mentor provides the following features:

1. The documentation system is structured and ordered, with

   documentation tags and unique numbering and versioning.

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

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 <http://www.ieee802.org/1/files/public/>. The file names indicate the relevant project, author, date, and version. The file-naming conventions and upload link are at <http://www.ieee802.org/1/filenaming.html>. 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 <http://www.ieee802.org/3/>. Files are uploaded by emailing to the subgroup chair.

Contributions to IEEE 802 Working Groups

In general, development of standards in IEEE 802 is contribution driven. 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.

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.

Cross-Referencing

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 should be labeled "Work in Progress". If the references are normative, this will 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 be avoided if at all possible.

Informative references in IEEE 802 standards are placed in a bibliography, so they 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 Std 802.1Q(TM)-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 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.

Guidance on Cooperation

This section describes how existing processes within the IETF and IEEE 802 may be used to enable cooperation between the organizations.

Historically, much of the work of coordination has fallen on individuals attending meetings of both organizations. However, as noted in "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG" RFC4663, downward pressure on travel budgets has made it increasingly difficult for participants to attend face-to-face meetings in both organizations. That pressure has continued in the intervening years. As a result, the coordination mechanisms described in this section typically do not require meeting attendance.

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.

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. Where individuals notice a potential conflict or need for coordination, the issue should be brought to the attention of the relevant Working Group chairs and/or Area Directors.

How IEEE 802 Is Informed about Active IETF Work Items

The responsibility is on IEEE 802 Working Groups to review current IETF Working Groups to determine if there are any topics of mutual interest. Working Group charters and active Internet-Drafts can be found in the IETF Datatracker [DATATRACKER]. 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 5.2).

How IETF Is Informed about Active IEEE 802 Work Items

It is the responsibility of IETF Working Groups to periodically review 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 <http://ieee802.org/minutes>. 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>. 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 5.2).

Overview of Notifications of New Work Proposals

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 escape notice in the other organization when cooperation will be required.

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.

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.

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.

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 [email protected] 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.

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 of the work. Any IEEE 802 PARs that 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 "Five 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.

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 email not later than 5:00 PM Tuesday of the plenary session (in the time zone where the plenary is located).

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 by 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 <http://www.iab.org/activities/ joint-activities/iab-ieee-coordination/>.

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.

IEEE 802 Draft Review and Balloting Processes

IEEE 802 drafts are reviewed and balloted at multiple stages of 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.

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.

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 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 open at least 10 days.

In order to submit a WG ballot, contact the WG Chair for the submission tool currently in use, as the tools may change over time.

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 <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 (<https://development.standards.ieee.org>). 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.

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 ballots are open for at least 30 days. Recirculation ballots to review draft changes and proposed comment resolutions are open at least 10 days.

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 percent to approve the final ballot disposition in order to advance the document.

IETF Draft Review and Approval Processes

The IETF Working Group Process is defined in [BCP25]. The overall IETF standards process is defined in [BCP9].

As noted in Section 2.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
   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.

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 (Structure of Management Information) MIB modules and AAA (Authentication, Authorization, and Accounting) described in RFC4441. IESG members routinely solicit directorate reviews as a means to request 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.

Liaison Managers and Liaison Statements

Both IEEE 802 and IETF work best when people participate directly in work of mutual interest, but that is 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.

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.

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 <http://www.ietf.org/liaison/managers.html>.

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 <http://www.ieee802.org/liaisons.shtml>.

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 (<http://ieee802.org/devdocs.shtml>).

The IETF process for sending and receiving liaison statements is defined in [BCP103].

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.

IANA

The IETF uses the Internet Assigned Numbers Authority (IANA) as a central authority that administers registries for most protocol parameter allocations. The overarching document describing this is [BCP26]. [BCP141] 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 [BCP26], 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 knowledgeable in the technology domain, appointed by the IESG and given specific criteria to use when reviewing requests.

IEEE Registration Authority

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 web site, at <http://standards.ieee.org/develop/regauth/general.html>.

Regarding Ethertype allocation: Some IETF protocol specifications make use of Ethertypes. Ethertypes are a fairly scarce 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 [ARCH802] 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.

IEEE 802 Registration at the 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.

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.

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.

Security Considerations

This document describes cooperation procedures and has no direct Internet security implications.

References

Normative References

[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an

          IANA Considerations Section in RFCs", BCP 26, RFC 5226,
          May 2008.

[BCP141] Eastlake 3rd, D. and J. Abley, "IANA Considerations and

          IETF Protocol and Documentation Usage for IEEE 802
          Parameters", BCP 141, RFC 7042, October 2013.

RFC4691 Andersson, L., Ed., "Guidelines for Acting as an IETF

          Liaison to Another Organization", RFC 4691, October 2006.

Informative References

[ARCH802] IEEE 802, "IEEE Standard for Local and Metropolitan Area

          Networks: Overview and Architecture", IEEE 802 Std
          802(TM)-2014, 2014.

[BCP9] Bradner, S., "The Internet Standards Process -- Revision

          3", BCP 9, RFC 2026, October 1996.
          Dusseault, L. and R. Sparks, "Guidance on Interoperation
          and Implementation Reports for Advancement to Draft
          Standard", BCP 9, RFC 5657, September 2009.
          Housley, R., Crocker, D., and E. Burger, "Reducing the
          Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
          October 2011.
          Resnick, P., "Retirement of the "Internet Official
          Protocol Standards" Summary Document", BCP 9, RFC 7100,
          December 2013.
          Kolkman, O., Bradner, S., and S. Turner, "Characterization
          of Proposed Standards", BCP 9, RFC 7127, January 2014.

[BCP10] Galvin, J., Ed., "IAB and IESG Selection, Confirmation,

          and Recall Process: Operation of the Nominating and Recall
          Committees", BCP 10, RFC 3777, June 2004.
          Dawkins, S., Ed., "Nominating Committee Process: Earlier
          Announcement of Open Positions and Solicitation of
          Volunteers", BCP 10, RFC 5633, August 2009.
          Dawkins, S., Ed., "The Nominating Committee Process: Open
          Disclosure of Willing Nominees", BCP 10, RFC 5680, October
          2009.
          Leiba, B., "Update to RFC 3777 to Clarify Nominating
          Committee Eligibility of IETF Leadership", BCP 10, RFC
          6859, January 2013.

[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in

          the IETF Standards Process", BCP 11, RFC 2028, October
          1996.

[BCP25] Bradner, S., "IETF Working Group Guidelines and

          Procedures", BCP 25, RFC 2418, September 1998.
          Wasserman, M., "Updates to RFC 2418 Regarding the
          Management of IETF Mailing Lists", BCP 25, RFC 3934,
          October 2004.

[BCP39] Internet Architecture Board and B. Carpenter, Ed.,

          "Charter of the Internet Architecture Board (IAB)", BCP
          39, RFC 2850, May 2000.

[BCP101] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the

          IETF Administrative Support Activity (IASA)", BCP 101, RFC
          4071, April 2005.
          Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for
          IPR Trust", BCP 101, RFC 4371, January 2006.

[BCP102] Daigle, L., Ed., and Internet Architecture Board, "IAB

          Processes for Management of IETF Liaison Relationships",
          BCP 102, RFC 4052, April 2005.

[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for

          Handling Liaison Statements to and from the IETF", BCP
          103, RFC 4053, April 2005.

[BCP111] Heard, C., Ed., "Guidelines for Authors and Reviewers of

          MIB Documents", BCP 111, RFC 4181, September 2005.
          Heard, C., Ed., "RFC 4181 Update to Recognize the IETF
          Trust", BCP 111, RFC 4841, March 2007.

[BCP132] Housley, R. and B. Aboba, "Guidance for Authentication,

          Authorization, and Accounting (AAA) Key Management", BCP
          132, RFC 4962, July 2007.

[BCP158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines",

          BCP 158, RFC 6158, March 2011.

[DADG] Morand, L., Ed., Fajardo, V. and H. Tschofenig, "Diameter

          Applications Design Guidelines", Work in Progress, June
          2014.

[DATATRACKER]

          Internet Engineering Task Force, "IETF Datatracker",
          <https://datatracker.ietf.org>.

[IEEE80211F]

          IEEE, "IEEE Trial-Use Recommended Practice for Multi-
          Vendor Access Point Interoperability Via an Inter-Access
          Point Protocol Across Distribution Systems Supporting IEEE
          802.11 Operation", IEEE 802 Std 802.11F(TM)-2003, 2003.

[IEEE-802.16-Liaison1]

          Liaison letter from IEEE 802.16 to Bernard Aboba, March
          17, 2005,
          <http://ieee802.org/16/liaison/docs/L80216-05_025.pdf>.

[IEEE-802.16-Liaison2]

          Liaison letter from IEEE 802.16 to Bernard Aboba, May 5,
          2005,
          <http://ieee802.org/16/liaison/docs/L80216-05_039.pdf>.

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.

RFC3748 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.

          Levkowetz, Ed., "Extensible Authentication Protocol
          (EAP)", RFC 3748, June 2004.

RFC4137 Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,

          "State Machines for Extensible Authentication Protocol
          (EAP) Peer and Authenticator", RFC 4137, August 2005.

RFC4441 Aboba, B., Ed., "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.

RFC5247 Aboba, B., Simon, D., and P. Eronen, "Extensible

          Authentication Protocol (EAP) Key Management Framework",
          RFC 5247, August 2008.

RFC6220 McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed.,

          Huston, G., Ed., and Internet Architecture Board,
          "Defining the Role and Function of IETF Protocol Parameter
          Registry Operators", RFC 6220, April 2011.

RFC6548 Brownlee, N., Ed., and IAB, "Independent Submission Editor

          Model", RFC 6548, June 2012.

RFC6635 Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor

          Model (Version 2)", RFC 6635, June 2012.

RFC6733 Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,

          Ed., "Diameter Base Protocol", RFC 6733, October 2012.

RFC6756 Trowbridge, S., Ed., Lear, E., Ed., Fishman, G., Ed., and

          S. Bradner, Ed., "Internet Engineering Task Force and
          International Telecommunication Union - Telecommunication
          Standardization Sector Collaboration Guidelines", RFC
          6756, September 2012.

RFC6929 DeKok, A. and A. Lior, "Remote Authentication Dial In User

          Service (RADIUS) Protocol Extensions", RFC 6929, April
          2013.

RFC7282 Resnick, P., "On Consensus and Humming in the IETF", RFC

          7282, June 2014.

[RONR] Robert, H., et al., "Robert's Rules of Order Newly

          Revised", 11th ed., Da Capo Press, 2011,
          <http://www.robertsrules.com/>.

Acknowledgments

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.

The initial draft of this document was assembled by a team of participants from both IEEE 802 and IETF. Team members included Dan Romascanu, Dorothy Stanley, Eric Gray, Patricia Thaler, Roger Marks, Ross Callon, Spencer Dawkins, and Subir Das.

We also thank Abdussalam Baryun, Adrian Farrel, Dave Thaler, Jari Arkko, Russ Housley, Jouni Korhonen, Max Riegel, Norm Finn, Pete Resnick, Peter Yee, S. Moonesamy, and Stephen Farrell for providing review comments.

10. IAB Members at the Time of Approval

Bernard Aboba Jari Arkko Marc Blanchet Ross Callon Alissa Cooper Joel Halpern Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Hannes Tschofenig

11. IEEE 802 Executive Committee Members at the Time of Approval

Radhakrishna Canchi Clint Chaplin John D'Ambrosia Subir Das James Gilb Bob Heile Tony Jeffree Bruce Kraemer David Law John Lemon Mike Lynch Roger Marks Apurva Mody Paul Nikolich Max Riegel Jon Rosdahl Steve Shellhammer Pat Thaler Geoff Thompson

Appendix A. Current Examples of IEEE 802 and IETF 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. Instead, the work was transferred to IEEE 802 with expert support for MIB review from the IETF. The process of transfer of the MIB work from the IETF Bridge MIB WG to IEEE 802.1 WG is documented in RFC4663.

By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the IETF SNMP quality control process, the IETF and IEEE 802 seek to ensure quality while decreasing overhead. 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 [BCP111]. 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.

A.2. AAA Review

IEEE 802 WGs requiring new AAA applications should send a liaison request to the IETF. Where new attribute definitions are sufficient, rather than defining new authentication, authorization, and accounting logic and procedures, an Internet-Draft can be submitted and review can be requested from AAA-related WGs such as the RADEXT or DIME WGs.

In addition to the RADEXT and DIME WGs, a "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.

For attributes of general utility, particularly those useful in multiple potential applications, allocation from the IETF standard attribute space is preferred to creation of IEEE 802 Vendor-Specific Attributes (VSAs). As noted in RFC3575: "RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) for functions specific only to one vendor's implementation of RADIUS, where no

interoperability is deemed useful. For functions specific only to one vendor's implementation of RADIUS, the use of that should be encouraged instead of the allocation of global attribute types."

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 Working Group create their own VSA format. The VSA format defined in [IEEE80211F] is inappropriate for this, since the Type field is only a single octet, allowing for only 255 attributes. It is recommended that IEEE 802 Working Groups read and follow the recommendations in "RADIUS Design Guidelines" [BCP158] and "Protocol Extensions" RFC6929 when designing and reviewing new extensions and attributes.

"Diameter Applications Design Guidelines" [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 reusing existing applications as much as possible is meaningful as most of the requirements defined for a new application are likely already fulfilled by existing applications. It is recommended that IEEE 802 Working Groups read and follow the recommendations in [DADG] when defining and reviewing new extensions and attributes.

A.3. EAP Review

The Extensible Authentication Protocol (EAP), defined in RFC3748, provides a framework within which authentication mechanisms, known as methods, can be defined. In addition to supporting authentication, EAP also provides for key derivation as described in RFC5247. State machines for EAP are described in RFC4137.

As noted in [BCP132] and RFC5247, security issues can arise in integration of EAP within lower layers. Therefore, it is recommended that IEEE 802 WGs looking to incorporate support for EAP send a liaison request to the IETF, requesting assistance in carrying out a security review. As an example, a security review of IEEE 802.16 was carried out by the EAP WG, at the request of IEEE 802.16 [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2]. Where development of new EAP authentication methods is sufficient, an Internet-Draft can be submitted and review can be requested from WGs such as the EAP Method Update (EMU) WG.

Appendix B. Pointers to Additional Information

This section provides pointers to additional useful information for participants in IEEE 802 and IETF.

B.1. IEEE 802 Information

IEEE 802 Home Page: <http://ieee802.org/>

IEEE 802 policies and procedures: <http://ieee802.org/devdocs.shtml>

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 <http://ieee802.org/>. For example 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>.

B.2. IETF Information

Information on IETF procedures may be found in the documents in the informative references and at the 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 RFCs: <http://www.rfc-editor.org/rfc-index.html>

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://datatracker.ietf.org/wg/> (includes Area Directors and chair contacts, mailing list information, etc.)

Current list of requested BOFs: <http://trac.tools.ietf.org/bof/trac/>

RFC Editor pages about publishing RFCs: <http://www.rfc-editor.org> (including available tools and guidance) <http://www.rfc-editor.org/pubprocess.html> is particularly helpful.

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)

Authors' Addresses

Spencer Dawkins Huawei Technologies 1547 Rivercrest Blvd. Allen, TX 75002 USA

EMail: [email protected]

Patricia Thaler Broadcom Corporation 5025 Keane Drive Carmichael, CA 95608 USA

EMail: [email protected]

Dan Romascanu AVAYA Park Atidim, Bldg. #3 Tel Aviv 61581 Israel

EMail: [email protected]

Bernard Aboba (editor) Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA

EMail: [email protected]