RFC 7241

The IEEE 802/IETF Relationship

📅 published July 2014, from ietf

RFC 7241: The IEEE 802/IETF Relationship 🎀

okay bestie, this one is the official handbook for how the IEEE 802 folks and the IETF folks work together 🫶 it's an Informational doc from the Internet Architecture Board (IAB), so it's a permanent record, not a rule you have to follow. it was published in July 2014 as ISSN 2070-1721, and it obsoletes RFC 4441. it doesn't list anything it updates. the authors are S. Dawkins (Huawei), P. Thaler (Broadcom), D. Romascanu (AVAYA), and B. Aboba, Ed. (Microsoft Corporation) 💅

Abstract

this doc describes how Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF) cooperate on standards 🌸 it obsoletes RFC 4441, so that's the old version you can forget about.

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.

ngl the note is giving "we all sat in a room and agreed on this together" energy, which is so iconic 🦋

Status of This Memo

this is not an Internet Standards Track specification. it's published just for information 🧚

this doc is a product of the Internet Architecture Board (IAB) and it's basically a record of stuff the IAB thought was worth keeping forever 📜 it reflects the consensus of the IAB. documents the IAB approves are not a candidate for any level of Internet Standard, see Section 2 of RFC 5741 💜

for the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7241 ✨

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) as they stand on the day this was published. please read those carefully, bestie, because they explain your rights and restrictions for this doc 🎀

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

the TOC is a big map of the whole doc, so you can see where everything lives 🗺️

1. Introduction ✨

this doc has a set of principles and guidelines that act as the foundation for coordination between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE 802) and the Internet Engineering Task Force (IETF) 🫶 the IETF is a program under the Internet Society (ISOC) umbrella [BCP101]. the goal is to help make timely technical specs that work maximally well with existing fixed and mobile Internet systems, devices, and protocols 💖 each org runs on its own rules and procedures, including IPR policy, spec elaboration, approval, and maintenance. no notes on that from us, they're both very capable 💅

this doc is meant to make cooperation between the two orgs better, but it doesn't change any formal practices or procedures of either one 🌈

1.1. Why Cooperate?

IEEE 802 and the IETF are independent standards orgs. they each use standards the other one makes, and they each write standards that depend on the other's. sometimes that dependency even goes as far as carrying attributes in protocols that reflect technologies the other org defined 🍓

those dependencies are the reason the two orgs cooperate. but cooperation has coordination overhead, so the benefits have to be bigger than the cost 🧁 it's a real trade-off, not a no-brainer.

the IETF gets better access to IEEE 802 expertise in the super widely deployed and used IEEE 802 Local Area Network architecture [ARCH802] 🌟

IEEE 802 gets better access to IETF expertise on IP datagram encapsulation, routing, transport, and security, plus specific applications IEEE 802 cares about 🦋 it's a whole win-win moment, honestly.

2. Organization, Participation, and Membership 🎀

IEEE 802 and IETF are similar in some ways and different in others 💜 when they work on projects they both care about, it's really important to know what's the same and what's not, bestie 👑

2.1. IEEE 802 ✨

okay so the IEEE Standards Association (IEEE-SA) is the standards-setting body of the IEEE 💅 and the IEEE-SA Standards Board is the one overseeing the whole IEEE standards development process. it's giving organized 🎀

The IEEE-SA Standards Board supervises what IEEE calls "sponsors", which are the IEEE entities that actually develop standards. The IEEE 802 LAN/MAN Standards Committee is one of those sponsors 🌸. It develops and maintains networking standards and recommended practices for local, metropolitan, and other area networks, using an open and accredited process, and it advocates for them on a global basis 🌍. Its 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) 🦋. Inside IEEE 802, each of these areas has a Working Group as its focus.

In IEEE 802, the work happens in Working Groups that operate under an Executive Committee 👑. Every Working Group is led by a Working Group Chair. Most Working Groups also have one or more Task Groups, and a Task Group is responsible for a project or a group of projects.

The Executive Committee is made up of the Executive Committee Chair, the Executive Committee Officers (e.g., Vice-Chairs, Secretaries, Treasurer), and the Working Group Chairs 🧚.

If you want to learn more, the IEEE 802 Home Page is the place to go: http://www.ieee802.org/ 💜. There's an IEEE 802 Orientation for new participants that gives an overview of the IEEE 802 process, and you can get it from that home page too.

The IEEE 802 Executive Committee and all Working Groups meet three times per year at plenary sessions 📅. The plenaries are held in March, July, and November. Most Working Groups also hold interim meetings, usually in January, May, and September. You can find the meeting schedule at http://www.ieee802.org/meeting/index.html ✨.

A Study Group is formed to consider starting a new project. If the new work turns out to be suitable, the Study Group develops an IEEE Project Authorization Request (PAR), which is 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 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. If they haven't finished their work, they must be authorized to continue at each plenary. (ngl that's a lot of paperwork, but it keeps things moving 😭)

Participation in IEEE 802 Working Groups happens at the level of individuals. Participants are human beings, not companies 🫶. Participation is open, but individuals are required to declare their affiliation, meaning any individual or entity that financially or materially supports that individual's participation in IEEE 802.

Working Groups keep membership rosters. Voting membership is earned through in-person meeting attendance. Keeping that voting membership generally requires continued attendance and responsiveness to letter ballots 🗳️. Voting members can vote on motions and on Working Group Ballots of drafts. All drafts also go through a Sponsor ballot pool before they get approved as standards. Joining a Sponsor ballot pool does not require participation in meetings, and you don't need to be eligible to vote in order to comment on drafts. The Working Group is required to consider and respond to all comments submitted during Working Group and Sponsor ballots, so your feedback gets a real answer 🙌.

To keep the conversation going between IEEE 802 and IETF, it's important to identify and establish contact points within each organization 💌. IEEE 802 contact points may include:

  • IEEE 802 Working Group Chair: An IEEE 802 Working Group chair is an individual who is assigned to lead the work of IEEE 802 in a particular area. IEEE 802 Working Group chairs are elected by the Working Group and confirmed by the Executive Committee for a two-year term. The Working Group Chair provides a stable contact point for cooperation between the two organizations for a given topic.
  • IEEE 802 Task Group (or Task Force) Chair: An IEEE 802 Task Group chair is an individual who is assigned to lead the work on a specific project or group of projects within a Working Group. The Task Group Chair often serves for the duration of a project. The Task Group Chair provides a stable contact point for cooperation between the two organizations on a particular project.
  • IEEE 802 Study Group Chair: An IEEE 802 Study Group Chair is an individual assigned to lead consideration of new work and development of an IEEE 802 Project Authorization Request (PAR). The Study Group chair provides a stable contact point for cooperation between the two organizations on a study group topic.
  • IEEE 802 Liaisons: It may be beneficial to establish liaisons as additional contact points for specific topics of mutual interest. These contact points should be established early in the work effort. The IEEE 802 and IETF projects may select the same individual as their contact point, but this is not required, so that two individuals each serve as contact points for one project participating in the liaison relationship.
  • Informal Contact points: Other informal contacts can provide useful cooperation points. These include Project Editors, who are responsible for editing the drafts and work with the Task Group Chairs to lead tracking and resolution of issues. Joint members, who are active in both the IEEE 802 and IETF projects in an area, can also aid in cooperation 🦋.

2.2. IETF 🌈

The IETF Standards Process is defined in [BCP9] 📜. [BCP11] is a helpful description of the 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 it's 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. Together, the Area Directors make up the Internet Engineering Steering Group (IESG) [RFC3710] 👑.

To keep the conversation going between IEEE 802 and IETF, it's important to identify and establish contact points within each organization. IETF contact points may include Area Directors, Working Group chairs, and other points of contact who can help communicate between IEEE 802 and IETF Working Groups 💖.

The Internet Architecture Board (IAB) charter [BCP39] assigns the IAB several responsibilities relevant to this document:

  1. IESG Appointment Confirmation [BCP10]
  2. Architectural Oversight
  3. Standards Process Oversight and Appeal
  4. Appointment of the RFC Series Editor [RFC6635] and Independent Submission Editor [RFC6548]
  5. Appointment of the Internet Assigned Number Authority (IANA) operator [RFC6220]
  6. Oversight of External Liaisons for the IETF [BCP102]

IESG and IAB members are selected using the NomCom process defined in [BCP10]. Working Group chairs serve at the pleasure of their Area Directors, as described in [BCP25] 🎀.

The IETF is designed to be a "bottom-up" protocol engineering organization. The leadership steers and manages, but it doesn't direct the work in a top-down way 🫶. Technical agreements with "the IETF" are based on the consensus of Working Group participants, rather than being negotiated with IETF leadership. this is the most democratic energy ever 🍓.

The 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". You can find information about IETF meetings at http://www.ietf.org/meeting/upcoming.html, and information about IETF Working Group interim meetings at http://www.ietf.org/meeting/interim-meetings.html 🗓️.

The preferred way to develop specifications is to do the work on mailing lists, and to reserve face-to-face sessions for topics that haven't been resolved through previous mailing list discussion 📬.

Participation in the IETF is open to anyone. Technically, that means anyone with access to email sufficient to subscribe to one or more IETF mailing lists 💌. All IETF participants act as individuals. There is no concept of "IETF membership", so no membership card, no vibes-based gatekeeping 🙅‍♀️.

If you want to learn more, the IETF Home Page is at http://www.ietf.org/. The "About the IETF" page at http://www.ietf.org/about is especially good, and you can select it from the IETF Home Page ✨.

The "Tao of the IETF" is also super helpful, especially for IEEE 802 participants who will also be joining IETF Working Groups and attending IETF meetings. You can find it 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 sometimes even conflicting 🙈. For example, both IEEE 802 and IETF use the term "Working Group", but it means very different things in the two organizations.

Thumbnail comparison between IETF and IEEE 802 entities:

IETF Area           is similar to  IEEE 802 Working Group
IETF Working Group  is similar to  IEEE 802 Task Group
IETF BOF            is similar to  IEEE 802 Study Group

Both IEEE 802 Working Groups and IETF Areas are large, long-lived, and relatively broadly scoped. They contain 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, and 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, so this one's a unique IETF vibe 🌸.

2.4. Cultural Differences 🌸

okay so IEEE 802 and IETF have cultures that are super similar but not identical, bestie 🫶 here are some of the differences ✨

Consensus and Rough Consensus: both orgs make decisions based on consensus, but in the IETF, "consensus" can mean "rough consensus, as determined by Working Group chairs" 💅 in practice that means a big chunk of the community being asked has to agree. not everyone has to agree, but if someone disagrees, they need to convince other people of their point of view. if they can't do that, they'll be "in the rough" when "rough consensus" gets declared 💀 IEEE Working Groups ultimately rely on voting for decision-making, though they vary a LOT in how much they use consensus versus voting during a meeting, and in how much attention they pay 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 👑 it's not always true today, but "running code" as proof that a proposal is feasible often carries a ton of weight in technical discussions 🔥 IEEE 802 considers both technical and economic feasibility when deciding whether to approve new work, as noted in Section 4.1.7 💜

Decision-making: IEEE 802 Working Groups vary in how much they rely on voting versus consensus, and in how broad the coverage of an individual motion is 🌈 but ultimately, they all rely on 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 ✨ instead, chairs may ask for a "show of hands" or "take a hum" to gauge backing for a proposal and spot technical concerns and objections. but that is not considered "voting" 🫠 IETF consensus and humming is discussed further in [RFC7282] 🦋

Balance between mailing lists and meetings: both orgs use mailing lists 📬 IETF Working Groups rely heavily on mailing lists, where the work actually gets done, plus 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, bestie 🙅‍♀️ 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 IEEE 802 decisions happen during plenary or interim meetings, except for procedural decisions. and attendance at meetings is critical to influencing decisions and to keeping membership voting rights 🗳️

Interim meetings: both orgs use interim meetings (the ones between plenary meetings) 🗓️ IETF Working Groups schedule interim meetings on an as-needed basis, and those can be face-to-face or virtual 💻 most IEEE 802 WGs hold regular interim meetings three times a year, in the middle of the interval between two plenary meetings. the schedules and locations are typically known many months in advance 📅 IEEE 802 interim meetings are face-to-face only. on top of the regularly scheduled ones, 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 isn't absolutely necessary, and some significant contributors don't attend most face-to-face IETF meetings 🧚 still, finding people who are interested in a proposal for new work, or soliciting backing for ideas, is often easier face-to-face, like in a hallway or bar 🍻 significant IEEE 802 contributors almost always attend face-to-face meetings, since participation in IEEE 802 meetings is a condition for WG membership 💼

Lifetime of Standards: IEEE 802 periodically reviews existing standards 🔁 IETF Standards Track documents may be updated or obsoleted by newer Standards Track documents, but there is no formal periodic review for existing Standards Track documents 🤷‍♀️ the status of specific IETF standards is available through the IETF "Datatracker" [DATATRACKER] 🔍 because these status changes happen independently, standards from each organization may refer to documents that are no longer standards in the other organization 😭

Overlapping terminology: as two independent standards development organizations, IEEE 802 and IETF have developed vocabularies that overlap 👯 for instance, IEEE 802 "ballots" at several levels of the organization during document approval, while IETF documents are only "balloted" during IESG review 🗳️ the IESG uses "ballots" to indicate that all technical concerns have been addressed, not to show 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 have mailing lists too, 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 who are interested in particular IETF Working Group topics subscribe to and participate in these lists 🫶 IETF WG mailing lists are open to all subscribers, and the subscription and archive info for each Working Group is noted on that 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 happens at meetings, but if a decision is needed between meetings, it may be done over the mailing list 🕰️ most technical discussion happens at meetings and through comments on drafts, which get compiled with responses in comment resolution documents 📝

most IEEE 802 mailing lists are open to all subscribers. for the few that aren't, please see the Working Group chair to arrange access to the mailing list 🔐

some IEEE 802 participants call mailing lists "reflectors" 🪞

3. Document Access and Cross-Referencing 🗂️

during IEEE 802 and IETF cooperation, it's important to share internal documents among the technical Working Groups 🤝 on top of that, drafts of IEEE 802 standards, Internet-Drafts, and RFCs may also be distributed 📄

3.1. Access to IETF Documents 🔎

IETF Internet-Drafts can be found using the IETF Datatracker interface (see [DATATRACKER]) or via the IETF tools site at http://tools.ietf.org. RFCs can 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 💳

once approved, IEEE 802 standards are published and made available for sale 🛍️ you can purchase them from the IEEE Standards Store, at http://www.techstreet.com/IEEEgate.html. they're 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, gives public access to download individual IEEE 802 standards at no charge (though registration is required) 🎉 IEEE 802 standards are added to the Get IEEE 802 program six months after publication. the program is approved year by year, but it's been around 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 in that IEEE 802 standards development project. typically, access is provided over the Internet under password protection, with the password given to members of the participating WG 🗝️ requests to the relevant WG Chair for access to a draft, for purposes of participating in the project, are typically granted 🥰

an alternative access mechanism that may more easily enable document access for IETF WGs cooperating with IEEE 802 was set up by a liaison statement sent to the IETF in July 2004 by Paul Nikolich, Chair of IEEE 802 ✨ it's available at https://datatracker.ietf.org/documents/LIAISON/file41.pdf and describes how IETF WGs can get access to IEEE 802 work in progress 🧾 IEEE 802 WG Chairs have the authority to grant membership in their WGs, and they can use that authority to grant membership to an IETF WG chair on request 👑 the IETF WG chair then gets access to the username/password for the IEEE 802 WG archives and is allowed to share that info with participants in the IETF WG 🔑 since it's possible to participate in the IETF without attending meetings, or even joining a mailing list, IETF WG chairs will give 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 🚫©️

heads up, bestie: even with access, copyright restrictions prohibit incorporating IEEE 802 work-in-progress material into IETF documents or postings 🚨

beyond letting IETF participants into IEEE 802's documentation resources, IEEE 802 can also make selected documents at any stage of development available to the IETF by attaching them to a formal liaison statement 📎 a communication can point to a URL where a non-ASCII document can be downloaded, but 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 where 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 too 🧑‍🤝‍🧑 prior to project authorization, or on topics not directly related to developing a standard, the WG may consider and develop documents itself or use 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 🎀

okay so the good news first: generally, the archives of minutes and contributions to IEEE 802 groups are publicly and freely available 🦋✨

Lots of IEEE 802 groups use a documentation system from IEEE called "Mentor" 💻 You can find the list of those groups on the IEEE 802 Mentor Home Page: https://mentor.ieee.org/802. Mentor gives you:

  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 💌 You need an IEEE web account, and it's easy and free to make one with the IEEE Account Request page, at http://www.ieee.org/go/create_web_account. If submission is protected, you can request the privilege through the Mentor system (using the "Join group" link on each WG Mentor page), and the WG documentation manager would typically grant it with 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 🙈 So they have their own setups.

IEEE 802.1 documents are organized in folders by year at http://www.ieee802.org/1/files/public/. The file names tell you 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 they're organized in folders by meeting date 🗓️ You can find those subgroup home pages from the IEEE 802.3 home page, at http://www.ieee802.org/3/. Files are uploaded by emailing them to the subgroup chair 💌

3.3.3. Contributions to IEEE 802 Working Groups 🌸

in general, development of standards in IEEE 802 is contribution driven 💅 Often a WG or subgroup will put out a call for contributions with a specific technical solicitation, including deadlines and submission instructions 📣 Some groups have their own submission procedures and ask for a contribution cover sheet so everyone can see the status of the contribution 📝

Content for drafts of standards gets submitted to WGs by individual participants or groups of participants 🧚 Content toward other group documents (like, for example, external communication statements or foundation documents underlying a draft of a standard) might be contribution driven too. At some point, the group pulls the contributed material together to develop group documents, and revision happens 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 🤝 That means standards from each org can be used as references in standards from the other org 🔥

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 go 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 keeps the same number and the date gets updated 📅 That's why IEEE 802 standards are dated with the year of approval, e.g., IEEE Std 802.1Q(TM)-2011. There are two ways to reference IEEE 802 standards: undated and dated references. IEEE 802 practice allows an undated reference to be used when referencing a whole standard. An undated reference means 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 get 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 you want an undated reference to an IETF Internet Standard, a number is also assigned in the "STD" series [BCP9], and those references refer to the most recent version of an IETF Internet Standard 💖

4. Guidance on Cooperation 🦋

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

Historically, a lot of the coordination work has fallen on individuals attending meetings of both organizations 😭 But, 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 hard for participants to attend face-to-face meetings in both organizations 💸 That pressure has continued in the years since. So the coordination mechanisms described in this section typically don't 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 lets the two organizations 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 and figure out 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 spots a common area of work, the IEEE 802 Working Group leadership should contact both the IETF Working Group chair and the responsible Area Director(s) 📬 This may be accompanied by a formal liaison statement (see Section 5.2) 💅

4.1.2. How IETF Is Informed about Active IEEE 802 Work Items 🌷

It's the responsibility of IETF Working Groups to periodically review the IEEE 802 web site and see if there's 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 of each 📋

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 spots 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 both organizations use:

  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 for 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 each organization hears about proposals for new work in the other organization 💬 Several other ways of identifying proposed new work are described in the following sections. These additional ways act as "belt and suspenders" 🩳 to reduce the chances that proposals for new work in one organization slip past 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 distributing 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 instead. 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 🌟

Lots of proposals for new IETF work items can be spotted in proposed Birds of a Feather (BOF) sessions, as well as in draft charters for Working Groups 🧐 The IETF forwards all of those draft charters for new and revised Working Groups, plus 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 😬 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, though. This puts a burden on both organizations to communicate proactively and avoid "late surprises" to either side 🫠

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

4.1.7. How IETF Is Informed about Proposed New IEEE 802 Work Items 📣

An IEEE 802 project kicks off when a Project Authorization Request (PAR) gets approved, and that PAR includes a description of the scope of the work. 💖 Any IEEE 802 PARs that bring in new functionality are required to be available for review no less than 30 days before the Monday of the IEEE 802 plenary session where they'll be considered. Plan ahead, bestie! 🗓️

IEEE 802 looks at "Five Criteria" when it decides 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 come with responses on the "Five Criteria", so you get the receipts. 🧾

IEEE 802 posts proposed PARs to the New-Work mailing list before the IEEE 802 meetings where they'll 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). ⏰ Don't be the one who's late, okay? 💀

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. It's giving teamwork. 🌈

As examples of these mechanisms, at the time this document was written, the two organizations were holding periodic conference calls between representatives of the IETF and IEEE 802 leadership teams. They were also maintaining a "living list" of shared interests between the two organizations, along with the status of those 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 because they allow higher-bandwidth discussions than formal liaison statements would, and they permit more timely interactions than waiting for face-to-face meetings. Literally so efficient. 🦋

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's important for technical experts to review documents of mutual interest. When appropriate, they should provide review comments to the approving body as the document moves through the approval process. Main character energy for the reviewers! 👑

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. 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 it 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. Some Working Groups call these "ballots", but the focus is on collecting and resolving comments on the draft rather than on trying to achieve a specific voting result. 🎀

4.2.1.2. Working Group Ballot 💜

Once the draft is substantially complete, Working Group ballots are conducted. Working Group voting members are entitled and required to vote in Working Group ballots. Any "disapprove" votes are required to be accompanied by comments that indicate what the objection is and a proposed resolution. "Approve" votes may also be accompanied by comments. The comments submitted with a "disapprove" vote may be marked to indicate which comments need to "be satisfied" to change the vote. 🙈

Initial Working Group ballots are at least 30 days. Recirculation ballots, which review draft changes and comment resolutions, are open at least 10 days. ⏳

To submit a WG ballot, contact the WG Chair for the submission tool currently in use, since 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. You can 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. You can indicate interest in IEEE myProject at 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, 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, IETF participants who want to comment on Sponsor ballots don't need to be members of 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 aren't members of the Sponsor ballot pool. Everyone gets a seat at the table! 🪑💖

Any "disapprove" votes are required to be accompanied by comments that indicate what the objection is, along with a proposed resolution. "Approve" votes may also be accompanied by comments. The comments submitted with a "disapprove" vote may be marked to indicate which comments need to "be satisfied" for the commenter to change the vote from "disapprove". 🧐

Initial Sponsor ballots are open for at least 30 days. Recirculation ballots, which 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 examines the ballot comments and determines their disposition. The Task Group handles TG ballots, and the Working Group handles WG and Sponsor ballots. 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. The vibes are very structured here, periodt. 💅

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 don't "ballot" to determine Working Group consensus for forwarding 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 isn't 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. It is addressed to the larger IETF community and is often the first time the entire community has looked at the document. IETF Last Call is signaled on the IETF-Announce Mailing List, and comments and feedback are ordinarily directed to the IETF Discussion Mailing List. 🔥

In practice, earlier input is more likely to be effective input. IEEE 802 participants who are interested in work within the IETF should be monitoring that work and providing input long before Working Group Last Calls and IETF Last Calls, for the best results. Start early, slay later! ⏰✨

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), as 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 ✨

okay so bestie, IEEE 802 and IETF work best when people actually show up and work on stuff together 🫶 but that's not always doable, and when individuals just talk as individuals it can be kinda messy for communicating between the two SDOs. 💅 So sometimes a technical body in one SDO needs to talk to a technical body in the other SDO as a body. This section is about the formal channels for that, if it ever becomes necessary 🦋

The Internet Architecture Board (IAB) is in charge of overseeing liaison relationships for the IETF 👑 In IEEE 802, that oversight is spread out, and each organization that appoints liaison managers is responsible for overseeing its own liaison relationships 🌸

Here's the tea 🍓 A liaison manager in either org is NOT there to "speak for" the org that appointed them. lol no. Their actual vibe is making sure neither org gets blindsided by what's happening in the other, helping everyone find the right people to talk to on the other side, and making sure formal liaison statements don't get lost in transit between the two orgs 💖 The IAB's guidance for liaison managers lives in [RFC4691] ✨ IEEE 802 orgs that appoint each liaison manager also give them their own guidance, and there is no global guidance for all IEEE 802 liaison managers. Each one is its own thing 🧚

5.1. Liaison Managers

The IAB appoints IETF liaison managers using the process described in [BCP102] 💜 You can find the current list of IETF liaison relationships and who's managing each one at <http://www.ietf.org/liaison/managers.html> 🌈

IEEE liaison managers are picked by the orgs they represent, either through an election or through appointment by a Working Group or Task Group Chair 🎀 The current list of IEEE 802 liaison relationships and their managers is 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, which lives at <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 keep registries of assigned protocol parameters, and some parameters assigned by one org are super relevant to the other 👀 This section walks through how each org registers them, bestie 💅

6.1. IANA

The IETF uses the Internet Assigned Numbers Authority (IANA) as a central authority that runs registries for most protocol parameter allocations 🌸 The big-picture doc for this is [BCP26] ✨ [BCP141] covers using IEEE 802-specific IANA parameters in IETF protocols, and it sets the IANA considerations for handing out code points under the IANA OUI (Organizationally Unique Identifier) 🔥

Requests for protocol parameter allocations from IANA are subject to assignment policies, and those policies vary from registry to registry 🧚 [BCP26] describes a bunch of well-known policies, but registries aren't locked into just those choices 🌈

Here's the deal with namespaces 💀 The whole point is to manage a namespace properly. 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 allocation are going to need some level of review 👑 "Standards Action" sits at the other extreme, where an approved Standards Track RFC is required before you get an allocation 💜 Some registries require that a request pass "Expert Review", which means review by someone who knows the technology domain, appointed by the IESG and given specific criteria to review requests with 🫶

6.2. IEEE Registration Authority

The IEEE Standards Association uses the IEEE Registration Authority as a central authority that administers 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 is on the IEEE RAC website at <http://standards.ieee.org/develop/regauth/general.html> 🌸

Regarding Ethertype allocation:

Some IETF protocol specifications use Ethertypes. Ethertypes are a pretty scarce resource, so allocation comes with its own set of requirements 😭 Every Ethertype request is reviewed by a consultant to the IEEE RA, followed by IEEE RAC confirmation 💅

The IEEE RAC won't assign a new Ethertype to a new IETF protocol specification until the IESG has approved that spec for publication as an RFC 🔥 In exceptional cases, the IEEE RA will consider "early allocation" of an Ethertype for an IETF protocol that's still under development, but only when the request comes from the IESG and has been vetted by it 🦋

Also, "playpen" Ethertypes have been assigned in IEEE 802 [ARCH802] for use during protocol development and experimentation 🧚

A fee is normally charged by the IEEE Registration Authority Committee (RAC) for allocating an Ethertype, but the IEEE RAC will consider waiving it for allocations tied to an IETF Standards Track document, if the IESG asks 🎀

6.3. IEEE 802 Registration at the Working Group Level

Each IEEE 802 Working Group has a registry of identifier values and a way to allocate identifier values in its standards and approved amendments 🌈 That covers stuff like Object Identifiers for managed objects, and assignments for protocols defined by that Working Group, such as OpCodes 💜 For the details of any given Working Group registry, contact the IEEE 802 Working Group Chair ✨

6.4. Joint-Use Registries

Some registries are "joint-use" between IEEE 802 and IETF, so each org needs to review how the other org uses registries as part of its review and approval process for standards 🫶

If an IEEE 802 document refers to IANA registries, those references should be checked before 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. No cap, nothing to panic about here 🫶🌸

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.

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

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

[BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.

[BCP25] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. Wasserman, M., "Updates to RFC 2418 Regarding the Management of IETF Mailing Lists", BCP 25, RFC 3934, October 2004.

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

[BCP101] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005. Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, January 2006.

[BCP102] Daigle, L., Ed., and Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005.

[BCP103] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005.

[BCP111] Heard, C., Ed., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. Heard, C., Ed., "RFC 4181 Update to Recognize the IETF Trust", BCP 111, RFC 4841, March 2007.

[BCP132] Housley, R. and B. Aboba, "Guidance for Authentication, Authorization, and Accounting (AAA) Key Management", BCP 132, RFC 4962, July 2007.

[BCP158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.

[DADG] Morand, L., Ed., Fajardo, V. and H. Tschofenig, "Diameter Applications Design Guidelines", Work in Progress, June 2014.

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

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

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

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

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

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

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

[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, August 2005.

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

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

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

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

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

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

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

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

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

[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, June 2014.

[RONR] Robert, H., et al., "Robert's Rules of Order Newly Revised", 11th ed., Da Capo Press, 2011, <http://www.robertsrules.com/>.

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
  • Subir Das

We also thank the following for providing review comments: 🌸

  • Abdussalam Baryun
  • Adrian Farrel
  • Dave Thaler
  • Jari Arkko
  • Russ Housley
  • Jouni Korhonen
  • Max Riegel
  • Norm Finn
  • Pete Resnick
  • Peter Yee
  • S. Moonesamy
  • Stephen Farrell

10. IAB Members at the Time of Approval 👑

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

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

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

Appendix A. Current Examples of IEEE 802 and IETF Cooperation 🦋

A.1. MIB Review 🧚

Okay so, 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. Then travel budgets got squeezed, and it became super hard for companies to pay for employees to attend both IEEE 802 and IETF meetings. 😭

So the crew came up with a new arrangement instead of the old way of chartering MIB work items inside an IETF WG. The work got transferred to IEEE 802, with expert support for MIB review coming from the IETF. You can read all about how the Bridge MIB work moved from the IETF Bridge MIB WG to IEEE 802.1 WG in [RFC4663]. 🎀

By standardizing IEEE 802 MIBs only within IEEE 802 while still using the IETF SNMP quality control process, the IETF and IEEE 802 are aiming for quality without all the extra overhead. ✨ To get wider review of MIBs developed by IEEE 802 WGs, it's recommended that those MIB modules follow the MIB guidelines in [BCP111]. And if an IEEE 802 group wants a "MIB Doctor" to help with a MIB review, they can ask the IETF Operations and Management Area Director for one. 💅

A.2. AAA Review 🎀

okay so if an IEEE 802 WG needs a brand new AAA application, the move is to send a liaison request to the IETF first 💌 🦋 But if all you need is new attribute definitions, you don't have to invent new authentication, authorization, and accounting logic from scratch 🙅‍♀️ You can write an Internet-Draft and ask for review from AAA-related WGs like RADEXT or DIME ✨

Besides RADEXT and DIME, there's an "AAA doctors" team (a directorate) active in the OPS Area 🧚 It's the place to go for more general AAA advice, especially stuff that crosses between RADIUS and Diameter or is just more generic in nature 💜

For attributes that are generally useful, especially ones that could show up in lots of different applications, grabbing an attribute from the IETF standard attribute space is preferred over making an IEEE 802 Vendor-Specific Attribute (VSA) 🌸 RFC3575 says it best, so here's the quote:

"RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. For functions specific only to one vendor's implementation of RADIUS, the use of that should be encouraged instead of the allocation of global attribute types."

If you do end up needing VSAs, it's recommended that IEEE 802 create one uniform format for all of IEEE 802, instead of every WG cooking up its own 🍓 The VSA format in [IEEE80211F] isn't a good fit, though, because its Type field is only a single octet, which caps you at 255 attributes 😭 IEEE 802 WGs are also encouraged to 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] is the guide to the rules for extending the Diameter base protocol [RFC6733] 🔥 Extending Diameter can mean either defining a completely new Diameter application, or reusing commands, Attribute-Value Pairs (AVPs), and AVP values in any combination so you inherit the features of an existing Diameter application 💅 Reusing existing applications as much as possible makes sense because most of the requirements for a new application are probably already covered by existing ones 🫶 IEEE 802 WGs are recommended to read and follow the recommendations in [DADG] when defining and reviewing new extensions and attributes too 🌈

A.3. EAP Review ✨

The Extensible Authentication Protocol (EAP), defined in [RFC3748], gives you a framework for defining authentication mechanisms, which are called methods 🦋 EAP also supports authentication and handles key derivation, as described in [RFC5247] 🔑 The state machines for EAP are described in [RFC4137] 🌸

As noted in [BCP132] and [RFC5247], security issues can pop up when you integrate EAP with lower layers 😱 So it's recommended that IEEE 802 WGs that want to add EAP support send a liaison request to the IETF, asking for help with a security review 🛡️ For example, the EAP WG did a security review of IEEE 802.16 at IEEE 802.16's request [IEEE-802.16-Liaison1] [IEEE-802.16-Liaison2] 👑 If developing new EAP authentication methods is what you need, you can submit an Internet-Draft and ask for review from WGs like the EAP Method Update (EMU) WG 💖

Appendix B. Pointers to Additional Information 🧚

This section is a little treasure map of extra info for anyone participating in IEEE 802 and the 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 a simple pattern 🎀 Take the WG or TAG's one- or two-digit number and append it after <http://ieee802.org/>. For example, the IEEE 802.1 main web page is at <http://ieee802.org/1>, and the IEEE 802.11 main web page is at <http://ieee802.org/11> 💜

B.2. IETF Information 🌈

Information on IETF procedures can 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/> (this includes Area Directors and chair contacts, mailing list info, etc.) 🫶

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

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

Current list of liaison statements: <https://datatracker.ietf.org/liaison/> 💌

IETF Intellectual Property Rights Policy and Notices: <http://www.ietf.org/ipr/> ⭐

The Tao of the IETF: <http://www.ietf.org/tao.html> (A Novice's Guide to the Internet Engineering Task Force) 🎀 bookmark this one, bestie 🔥

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
📦 where this page comes from