diff options
Diffstat (limited to 'doc/rfc/rfc7241.txt')
| -rw-r--r-- | doc/rfc/rfc7241.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc7241.txt b/doc/rfc/rfc7241.txt new file mode 100644 index 0000000..f939a44 --- /dev/null +++ b/doc/rfc/rfc7241.txt @@ -0,0 +1,1963 @@ + + + + + + +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] + |