Internet DRAFT - draft-iab-rfc4441rev

draft-iab-rfc4441rev









Internet Architecture Board                                   S. Dawkins
Internet-Draft                                                    Huawei
Obsoletes: 4441                                                P. Thaler
Intended Status: Informational                                  Broadcom
Expires: August 14, 2014                                    D. Romascanu
                                                                   AVAYA
                                                          B. Aboba (ed.)
                                                   Microsoft Corporation
                                                        13 February 2014


                     The IEEE 802/IETF Relationship
                        draft-iab-rfc4441rev-08

Abstract

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

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

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

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

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

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

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

   This Internet-Draft will expire on August 14, 2014.




IAB                           Informational                     [Page 1]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

























IAB                           Informational                     [Page 2]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
  1.1.  Why Cooperate?  . . . . . . . . . . . . . . . . . . . . .   4
2.  Organization, Participation and Membership  . . . . . . . . .   4
  2.1.  IEEE 802  . . . . . . . . . . . . . . . . . . . . . . . .   5
  2.2.  IETF  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
  2.3.  Structural Differences  . . . . . . . . . . . . . . . . .   8
  2.4.  Cultural Differences  . . . . . . . . . . . . . . . . . .   9
  2.5   Mailing Lists . . . . . . . . . . . . . . . . . . . . . .  11
3.  Document Access and Cross Referencing . . . . . . . . . . . .  12
  3.1.  Access to IETF Documents  . . . . . . . . . . . . . . . .  12
  3.2   Access to IEEE 802 Standards  . . . . . . . . . . . . . .  12
  3.3   Access to IEEE 802 Working Group Drafts . . . . . . . . .  12
  3.4.  Cross-Referencing   . . . . . . . . . . . . . . . . . . .  15
4.  Guidance on Cooperation . . . . . . . . . . . . . . . . . . .  15
  4.1.  Exchange of Information About Work Items  . . . . . . . .  16
  4.2.  Document Review and Approval  . . . . . . . . . . . . . .  19
  4.3.  Solicited Review Processes  . . . . . . . . . . . . . . .  22
5.  Liaison Managers and Liaison Statements . . . . . . . . . . .  23
  5.1   Liaison Managers  . . . . . . . . . . . . . . . . . . . .  23
  5.2   Liaison Statements  . . . . . . . . . . . . . . . . . . .  24
6.  Protocol Parameter Allocation . . . . . . . . . . . . . . . .  24
  6.1.  IANA  . . . . . . . . . . . . . . . . . . . . . . . . . .  24
  6.2.  IEEE Registration Authority . . . . . . . . . . . . . . .  24
  6.3.  IEEE 802 Registration at the Working Group Level  . . . .  25
  6.4.  Joint-use Registries  . . . . . . . . . . . . . . . . . .  25
7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  26
   9.1.  Normative References . . . . . . . . . . . . . . . . . .  26
   9.2.  Informative References . . . . . . . . . . . . . . . . .  26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  29
IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . . .  29
Appendix A.  Current Examples of IEEE 802 and IETF Cooperation  .  30
  A.1.  MIB Review  . . . . . . . . . . . . . . . . . . . . . . .  30
  A.2.  AAA Review  . . . . . . . . . . . . . . . . . . . . . . .  30
  A.3   EAP Review  . . . . . . . . . . . . . . . . . . . . . . .  31
Appendix B.  Pointers to Additional Information   . . . . . . . .  32
  B.1.  IEEE 802 Information  . . . . . . . . . . . . . . . . . .  32
  B.2.  IETF Information  . . . . . . . . . . . . . . . . . . . .  32
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33









IAB                           Informational                     [Page 3]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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

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

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







IAB                           Informational                     [Page 4]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


2.1.  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 and
   Wireless PAN, Wireless MAN, Wireless Coexistence, Media Independent
   Handover Services, and Wireless RAN.  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



IAB                           Informational                     [Page 5]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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 2 year term.  The Working Group Chair
             provides a stable contact point for cooperation between the
             two organizations for a given topic.

   IEEE 802 Task Group (or Task Force) Chair:  An IEEE 802 Task Group
             chair is an individual who is assigned to lead the work on
             a specific project or group of projects within a Working
             Group.  The Task Group Chair often serves for the duration
             of a project.  The Task Group chair provides a stable
             contact point for cooperation between the two organizations
             on a particular project.

   IEEE 802 Study Group Chair:  An IEEE 802 Study Group Chair is an
             individual assigned to lead consideration of new work and
             development of an IEEE 802 Project Authorization Request
             (PAR).  The Study Group chair provides a stable contact
             point for cooperation between the two organizations on a
             study group topic.

   IEEE 802 Liaisons:  It may be beneficial to establish liaisons as
             additional contact points for specific topics of mutual
             interest.  These contact points should be established early
             in the work effort.  The IEEE 802 and IETF projects may



IAB                           Informational                     [Page 6]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


             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.

2.2.  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 [RFC2850] assigns the
   IAB several responsibilities relevant to this document:

      1.  IESG Appointment Confirmation [BCP10]
      2.  Architectural Oversight
      3.  Standards Process Oversight and Appeal
      4.  Appointment of 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].



IAB                           Informational                     [Page 7]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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 session 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
   the IETF-Announce mailing list (see
   <http://www.ietf.org/list/announcement.html> for archives and
   subscription information).

   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 e-mail sufficient to allow subscription to one or more IETF
   mailing lists).  All IETF participants act as individuals.  There is
   no concept of "IETF membership".

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

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








IAB                           Informational                     [Page 8]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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.

2.4.  Cultural Differences

   IEEE 802 and IETF have cultures that are similar, but not identical.
   Some of the differences include:

   Consensus and Rough Consensus:  Both organizations make decisions
             based on consensus, but in the IETF, "consensus" can mean
             "rough consensus, as determined by Working Group chairs".
             In practice, this means that a large part of the community
             being asked needs to agree.  Not everyone has to agree, but
             if someone disagrees, they need to convince other people of
             their point of view.  If they're not able to do that,
             they'll be "in the rough" when "rough consensus" is
             declared.  Although IEEE Working Groups ultimately rely on
             voting for decision making, they vary widely in their use
             of consensus versus voting in the course of a meeting, and
             in their attention to Robert's Rules [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.



IAB                           Informational                     [Page 9]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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 [draft-resnick-on-consensus].

   Balance between mailing lists and meetings:  Both organizations make
             use of mailing lists.  IETF Working Groups rely heavily on
             mailing lists, where work is done, in addition at formal
             meetings.  The IETF requires all working group decisions to
             be made (or, often in practice, confirmed) on mailing lists
             - final decisions aren't made in meetings.  IEEE 802
             Working Groups typically meet face-to-face about twice as
             often as IETF Working Groups (three IEEE 802 plenaries plus
             three IETF 802 interim meetings each year, compared to
             three IETF plenaries per year) and teleconferences are more
             common in IEEE 802 than in most IETF Working Groups.  Most
             major decisions in IEEE 802 are made during plenary or
             interim meetings, except for procedural decisions.
             Attendance at meetings is critical to influencing decisions
             and to maintaining membership voting rights.

   Interim meetings:  Both organizations use interim meetings (between
             plenary meetings).  IETF Working Groups schedule interim
             meetings on an as-needed basis.  IETF interim meetings may
             be face-to-face or virtual.  Most IEEE 802 WGs hold
             regularly interim meetings three times a year in the middle
             of the interval between two Plenary meetings.  The
             schedules and location of these meetings are typically
             known many months in advance.  IEEE 802 interim meetings
             are face-to-face only.  In addition to regularly scheduled
             IEEE 802 interim meetings, teleconference and ad hoc
             meetings are held on an as-needed basis.

   Remote participation:  Because the IETF doesn't make decisions at
             face-to-face meetings, 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



IAB                           Informational                    [Page 10]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


             meetings is a condition for WG membership.

   Lifetime of Standards:  IEEE 802 periodically reviews existing
             standards.  IETF standards-track documents may be updated
             or obsoleted by newer standards-track documents, but there
             is no formal periodic review for existing standards-track
             documents.  The status of specific IETF standards is
             available through [DATATRACKER].  Because these status
             changes happen independently, standards from each
             organization may refer to documents that are no longer
             standards in the other organization.

   Overlapping terminology:  As two independent standards development
             organizations, IEEE 802 and IETF have developed
             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.

2.5.  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, this may be done over the mailing list.
   Most technical discussion occurs at meetings and by generating
   comments on drafts which are compiled with responses in comment
   resolution documents.

   Most IEEE 802 mailing lists are open to all subscribers.  For the few
   IEEE 802 mailing lists that are not open, please see the working



IAB                           Informational                    [Page 11]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   group chair to arrange for access to the mailing list.

   Some IEEE 802 participants refer to mailing lists as "reflectors".

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

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

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

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



IAB                           Informational                    [Page 12]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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.

3.3.1.  IEEE 802 Documentation System

   Each IEEE 802 standardization project is assigned to a Working Group
   (WG) for development.  In IEEE 802, the working methods of the WGs
   vary in 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.

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



IAB                           Informational                    [Page 13]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   1.  The documentation system is structured and ordered, with
       documentation tags and unique numbering and versioning.

   2.  On-line documentation is available.

   3.  Limited search functionality is provided, and publicly-available
       search engines index the data.

   4.  The ability to submit documents to Mentor is limited but is
       generally available to any interested party.  An IEEE web account
       is required but can be easily and freely established using the
       IEEE Account Request page, at <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/files/
   public/>.  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.

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



IAB                           Informational                    [Page 14]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   contribution-driven.  At some point, the group assembles contributed
   material to develop group documents, and revision takes place within
   group meetings or by assignment to editors.  For the most part, the
   contributions toward discussion as well as the group documents
   (including minutes and other reports) are openly available to the
   public.

3.4.  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 may point to either approved IETF standards or IETF
   Internet-Drafts, if necessary.

   When an IEEE 802 Standard is revised, it normally retains the same
   number and the date is updated.  Therefore, IEEE 802 Standards are
   dated with the year of approval, e.g IEEE 802 Std 802.1Q-2011.  There
   are two ways of referencing IEEE 802 Standards: undated and dated
   references.  IEEE 802 practice allows undated reference to be used
   when referencing a whole standard.  An undated reference indicates
   that the most recent version of the standard should be used.  A dated
   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.

4.  Guidance on Cooperation

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



IAB                           Informational                    [Page 15]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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.

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

4.1.1.  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 on the IETF web site (<http:// datatracker.ietf.org/wg/>).  If
   an IEEE 802 working group identifies a common area of work, the IEEE
   802 Working Group leadership should contact both the IETF Working
   Group chair and the Area Director(s) responsible.  This may be
   accompanied by a formal liaison statement (see Section 5.2).

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



IAB                           Informational                    [Page 16]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   myProject, at <https://development.standards.ieee.org/my-site>.
   Access requires an IEEE web account which is free and has no
   membership requirement.

   In myProject, a search on "View Active PARs" for 802 will bring up a
   list of all active IEEE 802 PARs.

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

4.1.3.  Overview of New Work Proposal Notification

   These principles describe the notification process used by both
   organizations:

   1.  For both organizations, the technical group making a proposal for
       new work that may conflict with, overlap with, or be dependent on
       the other organization is responsible for informing the top-level
       coordination body in the other organization that cooperation may
       be required.

   2.  For both organizations, the top-level coordination body receiving
       that notification is responsible for determining whether
       cooperation is, in fact, required, and informing the specific
       groups within the organization who may be affected by the
       proposal for new work.

   These direct notifications will be the most common way that each
   organization is informed about proposals for new work in the other
   organization.  Several other ways of identifying proposed new work
   are described in the following sections.  These additional ways act
   as "belt and suspenders" to reduce the chances that proposals for new
   work in one organization escapes notice in the other organization
   when cooperation will be required.

4.1.4.  The New-Work Mailing List

   Several standards development organizations ("SDOs"), including IETF
   and IEEE 802, have agreed to use a mailing list for the distribution
   of information about proposals for new work items among these SDOs.

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



IAB                           Informational                    [Page 17]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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.

4.1.5.  How IEEE 802 is Informed About Proposed New IETF Work Items

   Many proposals for new IETF work items can be identified in proposed
   Birds-of-a-Feather (BOF) sessions, as well as draft charters for
   Working Groups.  The IETF forwards all such draft charters for new
   and revised Working Groups and BOF session announcements to the IETF
   New-Work mailing list.

4.1.6.  How IEEE 802 Comments on Proposed New IETF Work Items

   Each IEEE 802 Working Group chair, or designated representative, may
   provide comments on these charters by responding to the IESG mailing
   list at iesg@ietf.org clearly indicating their IEEE 802 position and
   the nature of their concern.

   It should be noted that the IETF turnaround time for new Working
   Group charters can be as short as two weeks, although the call for
   comment period on work items that may require cooperation with IEEE
   802 can be extended to allow more time for discussion within IEEE
   802.  This places a burden on both organizations to proactively
   communicate and avoid "late surprises" to either organization.

   Although an IEEE 802 Working Group may not be able to develop a
   formal consensus response unless the notification arrives during that
   Working Group's meeting, the IEEE 802 Working Group chair can
   informally let the IETF know that IEEE 802 may have concerns about a
   proposed work item.  The IETF will consider any informal comments
   received without waiting for a formal liaison statement.

4.1.7.  How IETF is Informed About Proposed New IEEE 802 Work Items

   An IEEE 802 project is initiated by approval of a Project
   Authorization Request (PAR) which includes a description of the scope
   of the work.  Any IEEE 802 PARs which introduce new functionality are
   required to be available for review no less than 30 days prior to the
   Monday of the IEEE 802 plenary session where they will be considered.

   IEEE 802 considers Five Criteria when deciding whether to approve new
   work: Broad Market Potential, Compatibility, Distinct Identity,
   Technical Feasibility and Economic Feasibility.  The criteria are
   defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations
   Manual.  The PARs are accompanied by responses on the 5 Criteria.

   IEEE 802 posts proposed PARs to the New-Work mailing list, prior to



IAB                           Informational                    [Page 18]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   the IEEE 802 meetings where the PARs will be discussed.  The IETF
   coordination body will notify technical groups about PARs of
   interest.

4.1.8.  How IETF Comments on Proposed New IEEE 802 Work Items

   Any comments on proposed PARs should be submitted to the Working
   Group chair and copied to the Executive Committee chair by e-mail not
   later than 5:00 PM Tuesday of the plenary session (in the time zone
   where the plenary is located).

4.1.9.  Other Mechanisms for Coordination

   From time to time, IEEE 802 and IETF may agree to use additional
   mechanisms for coordination between the two groups.  The details of
   these mechanisms may vary over time, but the overarching goal is to
   communicate effectively as needed.

   As examples of such mechanisms, at the time this document was
   written, the two organizations are holding periodic conference calls
   between representatives of the IETF and IEEE 802 leadership teams,
   and are maintaining a "living list" of shared interests between the
   two organizations, along with the status of these interests and any
   related action items.  At the time this document was written, the
   "living list" included about 20 topics being actively discussed, with
   more expected.  These conference calls help the two organizations
   coordinate more effectively by allowing higher-bandwidth discussions
   than formal liaison statements would allow, and permitting more
   timely interactions than waiting for face-to-face meetings.

   Minutes for these conference calls, and the "living lists" discussed
   on each call, are available at <http://www.iab.org/activities/joint-
   activities/iab-ieee-coordination/>.

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

4.2.1.  IEEE 802 Draft Review and Balloting Processes

   IEEE 802 drafts are reviewed and balloted at multiple stages in the
   draft.  Any ballot comments received from non-voters before the close
   of the ballot are required to be considered in the comment resolution
   process.  The Editors, Task Group Chairs or Working Group Chairs
   responsible for the project will facilitate the entering of comments



IAB                           Informational                    [Page 19]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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

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

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




IAB                           Informational                    [Page 20]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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/myproject/bp/StartPage>).  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 ballot are open for at least 30 days.  Recirculation
   ballots to review draft changes and proposed comment resolutions are
   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.

4.2.2.  IETF Draft Review and Approval Processes

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




IAB                           Informational                    [Page 21]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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.

4.3.  Solicited Review Processes

   With the number of areas of cooperation between IEEE 802 and IETF
   increasing, the document review process has extended beyond the
   traditional subjects of SMI MIB modules and AAA (authentication,
   authorization and accounting) described in [RFC4441].  IESG members
   routinely solicit directorate reviews as a means to solicit the
   opinion of specialized experts on specific aspects of documents in
   IESG review (examples include security, MIB doctors, or congestion
   management reviews).  Area Directors may also require solicited
   reviews from IEEE 802 or IEEE 802 Working Groups when it becomes
   clear that the Internet-Draft has implications that impact some area



IAB                           Informational                    [Page 22]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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.

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

5.1.  Liaison Managers

   The IAB appoints IETF Liaison Managers using the process described in
   [BCP102].  The current list of the IETF's liaison relationships, and
   the liaison managers responsible for each of these relationships is
   available at <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>.




IAB                           Informational                    [Page 23]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


5.2.  Liaison Statements

   The IEEE 802 procedure for sending and receiving liaison statements
   is defined by the Procedure for Coordination with Other Standards
   Bodies in the IEEE 802 LMSC Operations Manual (<http://ieee802.org/
   devdocs.shtml>).

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

6.  Protocol Parameter Allocation

   Both IEEE 802 and IETF maintain registries of assigned protocol
   parameters, and some protocol parameters assigned in one organization
   are of interest to the other organization.  This section describes
   the way each organization registers protocol parameters.

6.1.  IANA

   The IETF uses the Internet Assigned Numbering Authority (IANA) as a
   central authority that administers registries for most protocol
   parameter allocations.  The overarching document describing this is
   [RFC5226].  [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
   [RFC5226], but registries are not limited to one of the well-known
   choices.

   The purpose of these allocations is to manage a namespace
   appropriately, so unless a registry has a policy that allows
   something like first come, first served ("FCFS") for a namespace that
   is effectively unbounded, requests for protocol parameter allocation
   will require some level of review.  "Standards Action" is at the
   other extreme (an approved standards-track RFC is required in order
   to obtain an allocation).  Some registries require that a request for
   allocation pass "expert review" - review by someone knowledgeable in
   the technology domain, appointed by the IESG and given specific
   criteria to use when reviewing requests.

6.2.  IEEE Registration Authority

   The IEEE Standards Association uses the IEEE Registration Authority
   as a central authority administering registries.  The IEEE



IAB                           Informational                    [Page 24]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   Registration Authority Committee (IEEE RAC) provides technical
   oversight for the IEEE Registration Authority.

   The list of Registries administered by the IEEE Registration
   Authority can be found on the IEEE RAC website, at <http://
   standards.ieee.org/develop/regauth/general.html>.

   Ethertype Allocation - Some IETF protocol specifications make use of
   Ethertypes.  Ethertypes are fairly scare resource so allocation has
   the following requirements.  All Ethertype requests are subject to
   review by a consultant to the IEEE RA followed by IEEE RAC
   confirmation.

   The IEEE RAC will not assign a new Ethertype to a new IETF protocol
   specification until the IESG has approved the protocol specification
   for publication as an RFC.  In exceptional cases, the IEEE RA will
   consider "early allocation" of an Ethertype for an IETF protocol that
   is still under development when the request comes from, and has been
   vetted by, the IESG.

   Note that "playpen" Ethertypes have been assigned in IEEE 802
   [Etypes] for use during protocol development and experimentation.

   While a fee is normally charged by the IEEE Registration Authority
   Committee (RAC) for the allocation of an Ethertype, the IEEE RAC will
   consider waiving the fee for allocations relating to an IETF
   standards track document, based on a request from the IESG.

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

6.4.  Joint-use Registries

   Because some registries are "joint-use" between IEEE 802 and IETF, it
   is necessary for each organization to review usage of registries
   maintained by the other organization as part of the review and
   approval process for standards.

   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.



IAB                           Informational                    [Page 25]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


7.  Security Considerations

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

8.  IANA Considerations

   [RFC Editor: please remove this section prior to publication.]

   This document has no IANA Actions.

9.  References

   RFC-Editor: please correct the BCP references in the Normative and
   Informative reference sections below, i.e. [BCP9], [BCP141], etc.
   Then please remove this note prior to publication as an RFC.

9.1.  Normative References

[BCP141]  Internet Engineering Task Force, "Best Current Practice 141:
          IANA Considerations and Documentation Usage for IEEE 802
          Parameters", 2013

[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison to
          Another Organization", RFC 4691, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.

9.2.  Informative References

[ARCH802] IEEE 802, "IEEE 802-200(R2007) IEEE Standard for Local and
          Metropolitan Area Networks: Overview and Architecture", 2007.

[draft-resnick-on-consensus]
          Resnick, P., "On Consensus and Humming in the IETF", Internet
          draft (work in progress), draft-resnick-on-consensus-06,
          November, 2013.

[BCP9]    Internet Engineering Task Force, "Best Current Practice 9: The
          Internet Standards Process -- Revision 3, as updated", 1996.

[BCP10]   Internet Engineering Task Force, "Best Current Practice 10:
          IAB and IESG Selection, Confirmation, and Recall Process:
          Operation of the Nominating and Recall Committees, as
          updated", 2004.





IAB                           Informational                    [Page 26]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


[BCP11]   Internet Engineering Task Force, "Best Current Practice 11:
          The Organizations Involved in the IETF Standards Process, as
          updated", 1996.

[BCP25]   Internet Engineering Task Force, "Best Current Practice 25:
          IETF Working Group Guidelines and Procedures", 1998.

[BCP101]  Internet Engineering Task Force, "Structure of the IETF
          Administrative Support Activity (IASA)", 2005.

[BCP102]  Internet Engineering Task Force, "Best Current Practice 102:
          IAB Processes for Management of IETF Liaison Relationships",
          2005.

[BCP103]  Internet Engineering Task Force, "Best Current Practice 103:
          Procedures for Handling Liaison Statements to and from the
          IETF", 2005.

[BCP111]  Internet Engineering Task Force, "Guidelines for Authors and
          Reviewers of MIB Documents", 2005.

[BCP132]  "Guidance for Authentication, Authorization and Accounting
          (AAA) Key Management", 2007.

[BCP158]  Internet Engineering Task Force, "Best Current Practice 158:
          RADIUS Design Guidelines", 2011.

[DADG]    Morand, L., Fajardo, V. and H. Tschofenig, "Diameter
          Applications Design Guidelines", Internet draft (work in
          progress),  draft-ietf-dime-app-design-guide-21, December,
          2013.

[DATATRACKER]
          Internet Engineering Task Force, "IETF Datatracker (https:
          //datatracker.ietf.org/)", 2013.

[Etypes]  IEEE 802, "IEEE 802 Std 802a-2003 (Amendment to IEEE 802 Std
          802-2001).  IEEE 802 standard for Local and Metropolitan Area
          Networks: Overview and Architecture -- Amendment 1: Ethertypes
          for Prototype and Vendor- Specific Protocol Development",
          2003.

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




IAB                           Informational                    [Page 27]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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

[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of the
          Internet Architecture Board (IAB)", BCP 39, RFC 2850, May
          2000.

[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
          Authentication Dial In User Service)", RFC 3575, July 2003.

[RFC3710] Alvestrand, H., "An IESG charter", RFC 3710, February 2004.

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

[RFC4137] Volbrecht, J., Eronen, P., Petroni, N. and Y. Ohba, "State
          Machines for EAP Peer and Authenticator", RFC 4137, August
          2005.

[RFC4441] Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441, March
          2006.

[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG
          to IEEE 802.1 WG", RFC 4663, September 2006.

[RFC5247] Aboba, B., Simon, D. and P. Eronen, "EAP Key Management
          Framework", RFC 5247, August 2008.

[RFC6220] McPherson, D., Kolkman, O., Klensin, J., Huston, G., Internet
          Architecture Board, "Defining the Role and Function of IETF
          Protocol Parameter Registry Operators", RFC 6220, April 2011.

[RFC6548] Brownlee, N. IAB, "Independent Submission Editor Model", RFC
          6548, June 2012.

[RFC6635] Kolkman, O., Halpern, J., IAB, "RFC Editor Model (Version 2)",
          RFC 6635, June 2012.

[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter
          Base Protocol", RFC 6733, October 2012.





IAB                           Informational                    [Page 28]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


[RFC6756] Trowbridge, S., Lear, E., Fishman, G., and S. Bradner,
          "Internet Engineering Task Force and International
          Telecommunication Union - Telecommunication Standardization
          Sector Collaboration Guidelines", RFC 6756, September 2012.

[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User
          Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.

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

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








IAB                           Informational                    [Page 29]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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 and the use of that should
   be encouraged instead of allocation of global attribute types, for
   functions specific only to one vendor's implementation of RADIUS,
   where no interoperability is deemed useful".




IAB                           Informational                    [Page 30]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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










IAB                           Informational                    [Page 31]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


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 IETF RFCs: <ftp://ftp.ietf.org/rfc/
   rfc-index.txt>

   Current list and description of all IETF Internet-Drafts: <ftp://
   ftp.ietf.org/internet-drafts/1id-abstracts.txt>

   Current list of IETF Working Groups and their Charters: <http://
   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/
   index.html> (including available tools and lots of 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/>



IAB                           Informational                    [Page 32]

Internet-Draft         IEEE 802/IETF Relationship       13 February 2014


   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: spencerdawkins.ietf@gmail.com

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

   Email: pthaler@broadcom.com

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

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

   Email: bernard_aboba@hotmail.com

















IAB                           Informational                    [Page 33]