GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7241

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.

Dawkins, et al. Informational [Page 1] RFC 7241 IEEE 802/IETF Relationship July 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.

Dawkins, et al. Informational [Page 2] RFC 7241 IEEE 802/IETF Relationship July 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 ........................................16
    4.1. Exchange of Information about Work Items ..................16
    4.2. Document Review and Approval ..............................20
    4.3. Solicited Review Processes ................................23
 5. Liaison Managers and Liaison Statements ........................23
    5.1. Liaison Managers ..........................................24
    5.2. Liaison Statements ........................................24
 6. Protocol Parameter Allocation ..................................24
    6.1. IANA ......................................................24
    6.2. IEEE Registration Authority ...............................25
    6.3. IEEE 802 Registration at the Working Group Level ..........26
    6.4. Joint-Use Registries ......................................26
 7. Security Considerations ........................................26
 8. References .....................................................26
    8.1. Normative References ......................................26
    8.2. Informative References ....................................26
 9. Acknowledgments ................................................30
 10. IAB Members at the Time of Approval ...........................31
 11. IEEE 802 Executive Committee Members at the Time of Approval ..31
 Appendix A.  Current Examples of IEEE 802 and IETF Cooperation ....32
   A.1. MIB Review .................................................32
   A.2. AAA Review .................................................32
   A.3  EAP Review .................................................33
 Appendix B.  Pointers to Additional Information ...................34
   B.1. IEEE 802 Information .......................................34
   B.2. IETF Information ...........................................34

Dawkins, et al. Informational [Page 3] RFC 7241 IEEE 802/IETF Relationship July 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.

Dawkins, et al. Informational [Page 4] RFC 7241 IEEE 802/IETF Relationship July 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
 (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.

Dawkins, et al. Informational [Page 5] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

Dawkins, et al. Informational [Page 6] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

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

Dawkins, et al. Informational [Page 7] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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.

Dawkins, et al. Informational [Page 8] RFC 7241 IEEE 802/IETF Relationship July 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.

Dawkins, et al. Informational [Page 9] RFC 7241 IEEE 802/IETF Relationship July 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 [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.

Dawkins, et al. Informational [Page 10] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

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

Dawkins, et al. Informational [Page 11] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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

Dawkins, et al. Informational [Page 12] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

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.

Dawkins, et al. Informational [Page 13] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

Dawkins, et al. Informational [Page 14] RFC 7241 IEEE 802/IETF Relationship July 2014

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

Dawkins, et al. Informational [Page 15] RFC 7241 IEEE 802/IETF Relationship July 2014

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

Dawkins, et al. Informational [Page 16] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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

Dawkins, et al. Informational [Page 17] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

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

Dawkins, et al. Informational [Page 18] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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 email 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 by permitting more
 timely interactions than waiting for face-to-face meetings.

Dawkins, et al. Informational [Page 19] RFC 7241 IEEE 802/IETF Relationship July 2014

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

Dawkins, et al. Informational [Page 20] RFC 7241 IEEE 802/IETF Relationship July 2014

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

Dawkins, et al. Informational [Page 21] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

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

Dawkins, et al. Informational [Page 22] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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

Dawkins, et al. Informational [Page 23] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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

Dawkins, et al. Informational [Page 24] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

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

Dawkins, et al. Informational [Page 25] RFC 7241 IEEE 802/IETF Relationship July 2014

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.

7. Security Considerations

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

8. References

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

8.2. Informative References

 [ARCH802]  IEEE 802, "IEEE Standard for Local and Metropolitan Area
            Networks: Overview and Architecture", IEEE 802 Std
            802(TM)-2014, 2014.

Dawkins, et al. Informational [Page 26] RFC 7241 IEEE 802/IETF Relationship July 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.

Dawkins, et al. Informational [Page 27] RFC 7241 IEEE 802/IETF Relationship July 2014

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

Dawkins, et al. Informational [Page 28] RFC 7241 IEEE 802/IETF Relationship July 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>.
 [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.

Dawkins, et al. Informational [Page 29] RFC 7241 IEEE 802/IETF Relationship July 2014

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

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

Dawkins, et al. Informational [Page 30] RFC 7241 IEEE 802/IETF Relationship July 2014

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

Dawkins, et al. Informational [Page 31] RFC 7241 IEEE 802/IETF Relationship July 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 (Attribute 26) for functions
 specific only to one vendor's implementation of RADIUS, where no

Dawkins, et al. Informational [Page 32] RFC 7241 IEEE 802/IETF Relationship July 2014

 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.

Dawkins, et al. Informational [Page 33] RFC 7241 IEEE 802/IETF Relationship July 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 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/>

Dawkins, et al. Informational [Page 34] RFC 7241 IEEE 802/IETF Relationship July 2014

 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: 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
 EMail: dromasca@avaya.com
 Bernard Aboba (editor)
 Microsoft Corporation
 One Microsoft Way
 Redmond, WA  98052
 USA
 EMail: bernard_aboba@hotmail.com

Dawkins, et al. Informational [Page 35]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7241.txt · Last modified: 2014/07/17 18:56 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki