| Internet Architecture Board | S. Dawkins, Ed. |
| Internet-Draft | Huawei |
| Obsoletes: 4441 (if approved) | P. Thaler |
| Intended status: Informational | Broadcom |
| Expires: July 29, 2013 | D. Romascanu |
| AVAYA | |
| January 25, 2013 |
The IEEE 802 / IETF Relationship
draft-iab-rfc4441rev-00.txt
This document describes the standardization collaboration between Project 802 of the Institute of Electrical and Electronic Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 29, 2013.
Copyright (c) 2013 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.
This document provides non-normative guidance to aid in the understanding of collaboration on standards development between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE 802) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). Early identification of topics of mutual interest will allow for constructive efforts between the two organizations based on mutual respect and cooperation.
One of the primary drivers for [RFC4441] was to allow effective collaboration between IEEE 802 and the IETF during a time where downward pressure on travel budgets was making it increasingly difficult for the same participants to attend face-to-face meetings in both organizations. That pressure has continued in the intervening years. This document is intended to improve the mechanisms already in place.
This section describes how existing processes within the IETF and IEEE 802 may be used to enable collaboration between the organizations.
IEEE 802 and IETF are similar in some ways, but different in others. When working on projects that are of interest to both organizations, it's important to understand these similarities and differences.
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 standards for networking.
In IEEE 802, work is done in Working Groups operating under an Executive Committee. Most Working Groups have one or more Task Groups. A Task Group is responsible for a project or group of projects. Each Working Group is led by a Working Group Chair.
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 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, April and September. The meeting schedule can be found at http://www.IEEE802.org/meeting/index.html.
A Study Group is a group formed to consider starting a new project and, if new work is found to be suitable, to develop an IEEE Project Authorization Request (PAR - similar in purpose to an IETF working group charter). A Study Group may operate under a Working Group or under the Executive Committee depending on whether the new work under consideration falls within the scope of an existing Working Group. Study Groups are expected to exist for a limited time, usually for one or two plenary cycles, and must be authorized to continue at each plenary if they have not completed their work.
Participation in IEEE 802 Working Groups is at the level of individuals, i.e. participants are human beings and not companies, and 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. One does not need to be a voter 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. Contact points on the IEEE 802 side may include:
In the IETF, work is done in working groups (WGs), mostly through open, public mailing lists rather than face-to-face meetings. WGs are organized into areas, each area being managed by two co-area directors. Collectively, the area directors comprise the Internet Engineering Steering Group (IESG).
IETF meets in plenary session three times per year. Some working groups have additional interim meetings, which may be either face-to-face or "virtual", but this is not true for most IETF working groups, at any given time. 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. Information about IETF plenary meetings is available at http://www.ietf.org/meeting/upcoming.html. Information about IETF working group interim meetings is available on the IETF-Announce mailing list (see http://www.ietf.org/list/announcement.html for archives and subscription information).
The IETF Standards Process is defined in [BCP9]. The IETF working group process is defined in [BCP25].
Participation in the IETF is open to anyone (technically, anyone with access to e-mail sufficient to allow subscription to one or more IETF mailing lists). All IETF participants act as individuals. There are a small number of IETF procedures that recognize organizations that may sponsor IETF participants, but these are organizational and do not apply to the standard specification process itself. There is no concept of "IETF membership".
To foster ongoing communication between IEEE 802 and IETF, it is important to identify and establish contact points within each organization. Contact points on the IETF side may include:
We cannot emphasize too much that the IETF is a "bottom-up" protocol engineering organization - the leadership steers and manages, but does not direct work in a top-down way. This means that agreements with "the IETF" must be based on the consensus of working group participants, not negotiated through IETF leadership.
A good place to 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.
Note: 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/.
It's worth noting that IEEE 802 and IETF have cultures that are similar, but not identical. Some of the differences include:
The following sections outline a process that can be used to enable each organization to stay informed about the other's active and proposed new work items.
The responsibility is on individual IEEE 802 working groups to review the current IETF working groups to determine if there are any topics of mutual interest. Working group charters and active Internet-Drafts can be found on the IETF web site (http://datatracker.ietf.org/wg/). If an IEEE 802 working group identifies a common area of work, the IEEE 802 working group leadership should contact both the IETF working group chair and the area director(s) responsible. This may be accompanied by a formal liaison statement (see Section 2.6.2).
IEEE 802 Working Group status reports are published at the beginning and end of each plenary at http://IEEE802.org/minutes on the IEEE 802 website. 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/my-site. Access requires an IEEE web account which is free and has no membership requirement.
In myProject, a search on "View Active PARs" for 802 will bring up a list of all active IEEE 802 PARs.
The responsibility is on individual IETF working groups to periodically review the information on the IEEE 802 web site to determine if there is work in progress of mutual interest.
If an IETF working group identifies a common area of work or a need for coordination, 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 2.6.2).
EDITOR'S NOTE: Dan points out that Section 2.6.2 needs material from the IEEE 802 side as well - the current version of the draft includes only material from the IETF side.
The IETF maintains a mailing list for the distribution of proposed new work items among standards development organizations. Many such 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 all new and revised working groups and BOF session announcements to the IETF new-work mailing list. An IEEE 802 mailing list is subscribed to this list. Leadership of the IEEE 802 working groups may subscribe to this IEEE 802 mailing list, which is maintained by the Executive Committee (EC).
Each IEEE 802 Working Group will delegate at least one expert to subscribe to this list and be ready to dispatch any information relevant for their activity. This will enable the IEEE 802 working groups to monitor the new work items for possible overlap or interest to their IEEE 802 working group. It is expected that this mailing list will see a few messages per month.
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. Plain-text email is preferred on the IESG mailing list.
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 coordination 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.
The IETF Announce mailing list should be monitored consistently. In addition, proposed IETF work items that require coordination may be brought directly to the attention of IEEE 802 working group chairs.
Although the 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 comments received without waiting for a formal liaison statement, and can respond to this informal feedback appropriately.
An IEEE 802 project is initiated by approval of a Project Authorization Request (PAR) which includes a description of the scope of the work. Any IEEE 802 PARs which introduce new functionality are required to be available for review no less than 30 days prior to the Monday of the IEEE 802 plenary session where they will be considered.
IEEE 802 considers Five Criteria when deciding whether to approve new work: Broad Market Potential, Compatibility, Distinct Identity, Technical Feasibility and Economic Feasibility. The criteria are defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations Manual. The PARs are accompanied by responses on the 5 Criteria.
Each Area Director shall ensure that at least one person is designated to periodically review relevant PAR and 5 Criteria information to determine if there is proposed work of mutual interest.
Any comments on proposed PARs should be submitted to the Working Group chair and copied to the Executive Committee chair by e-mail not later than 5:00 PM Tuesday of the plenary session (in the time zone where the plenary is located).
From time to time, IEEE 802 and IETF may agree to use additional mechanisms for coordination between the two groups.
As examples of such mechanisms, the two organizations are holding periodic conference calls between representatives of the IETF and IEEE 802 leadership teams, and are maintaining a "living list" of shared interests between the two organizations, along with the status of these interests and any related action items. At the time this document was written, the "living list" included about 20 topics being actively discussed, with more expected. These conference calls help the two organizations coordinate more effectively by allowing higher-bandwidth discussions than formal liaison statements would allow, and permitting more timely interactions than waiting for face-to-face meetings.
Minutes for these conference calls, and the "living lists" discussed on each call, are available at http://www.iab.org/activities/joint-activities/iab-ieee-coordination/.
During the course of IEEE 802 and IETF collaboration, it is important to share internal documents among the technical working groups. In addition, draft standards, Internet Drafts, and RFCs may also be distributed.
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 detail. 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.
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 (e.g., Word) can be downloaded, attachments in proprietary formats to an IETF mailing list are discouraged.
In general, development of standards in IEEE 802 is contribution-driven. Content toward draft 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 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.
Generally, the archives of minutes and contributions to IEEE 802 groups are publically and freely available.
Many IEEE 802 groups use a documentation system provided by IEEE and known as "Mentor". The list of these groups is available at the IEEE 802 Mentor Home Page: https://mentor.ieee.org/802". Mentor provides:
IEEE 802.1 and IEEE 802.3 do not use Mentor.
IEEE 802.1 documents are organized in folders by year at: http://www.ieee802.org/1/files/public/ The file names indicate the relevant project, author, date and version. The file naming conventions and upload link are at: http://www.ieee802.org/1/files/public/. Upload is moderated.
IEEE 802.3 documents are accessed from the home pages of the IEEE 802.3 subgroups (i.e. Task Force or Study Group) and are organized in folders by meeting date. Files are uploaded by emailing to the subgroup chair.
IEEE 802 Working Groups are open to contributions. 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.
The IEEE owns the copyright to draft standards developed within IEEE 802 standardization projects. As a result, such drafts are never made publicly available. The IEEE-SA grants permission for an IEEE 802 draft standard to be distributed without charge to the participants for that IEEE 802 standards development project. Typically, such distribution is on the Internet under password protection, with the password provided to members of the participating WG. Requests to the relevent WG chair for access to a draft for purposes of participation in the project are typically granted.
An alternative access mechanism which may more easily enable document access for IETF WGs collaborating 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, incorporating material into IETF documents or posting the username/password on mailing lists or websites is not permitted.
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. IEEE 802 standards are added to the Get IEEE 802 program six months after publication.
IETF Internet-Drafts may be located using IETF "Datatracker" inteface at https://datatracker.ietf.org, or via the IETF tools site at http://tools.ietf.org. RFCs may be located at either of the above, or at via the RFC Editor site at http://www.rfc-editor.org.
It should be recognized that the official/athoritative versions of all IETF documents are in ASCII.
During the course of IEEE 802 and IETF collaboration, it is important for technical experts to review documents of mutual interest and, when appropriate, to provide review comments to the approving body as the document moves through the approval process.
IEEE 802 drafts are reviewed and balloted at multiple stages in the draft. Any ballot comments received from non-voters before the close of the ballot are required to be considered in the comment resolution process. The Editors, Task Group Chairs or Working Group Chairs responsible for the project will facilitate the entering of comments 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.
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.
Once the draft is substantially complete, Working Group ballots are conducted. Working Group voting members are entitled and required to vote in Working Group ballots. Any disapprove votes are required to be accompanied by comments that indicate what the objection is and a proposed resolution. Approve votes may also be accompanied by comments. The comments submitted with a disapprove vote may be marked to indicate which comments need to "be satisfied" to change the vote.
Initial Working Group ballots are at least 30 days. Recirculation ballots to review draft changes and comment resolutions are at least 10 days.
In order to submit a Working Group ballot, contact the WG chair for the submission tool currently in use, as the tools may change over time.
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/myproject/bp/StartPage). An IEEE web account is freely available, and is required for login. To select interest areas, go to the Projects tab and select Manage Activity Profile and check any areas of interest. IEEE 802 projects are under Computer Society; LAN/MAN Standards Committee.
The Sponsor Ballot pool is formed from those that accept the invitation during the invitation period.
As with other ballot levels, the IETF participants who want to comment on Sponsor Ballots need not be members in the Sponsor Ballot pool. The Editors, Task Group Chairs or Working Group Chairs responsible for the project will facilitate the entering of comments from IETF participants who are not members in the Sponsor Ballot pool.
Any "disapprove" votes are required to be accompanied by comments that indicate what the objection is, along with a proposed resolution. Approve votes may also be accompanied by comments. The comments submitted with a disapprove vote may be marked to indicate which comments need to "be satisfied" for the commenter to change the vote from "disapprove".
Initial Sponsor ballot are open for at least 30 days. Recirculation ballots to review draft changes and proposed comment resolutions are at least 10 days.
The IETF Working Group Process is defined in BCP-25. The overall IETF standards process is defined in BCP-9.
As noted in Section 2.1.3, IETF working groups do not "ballot", but the IESG does, as part of considering documents 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.
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.
With the number of areas of cooperation between IEEE 802 and IETF increasing, the document review process has extended beyond the traditional subjects of SMI MIB modules and AAA described in [RFC4441]. The IESG members use expert reviews as a means to solicit the opinion of specialized experts on specific aspects of documents in IESG review (examples include security, MIB doctors, or congestion management reviews). Area Directors may also require expert reviews from IEEE 802 or IEEE 802 Working Groups when it becomes clear that the Internet-Draft has implications for some area of IEEE 802's responsibility and expertise.
IETF participants can comment as part of the IEEE 802 ballot process, regardless of their voting status within IEEE 802. Comments must be composed in the format specified for the ballot, and submitted by the ballot deadline.
EDITOR'S NOTE: This section is written mostly from an IETF perspective. If there are helpful things to say about IEEE 802 liaison processes, web pages that contain a list of liaison managers, etc. that would be great to add. :-)
Both IEEE 802 and IETF work best when people participate directly in work of mutual interest, but that's 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.
The reader should note that the role of a liaison official (called a "Liaison Manager" in the IETF) in both IEEE 802 and IETF is not to "speak for" the appointing organization. A liaison official is most helpful in insuring that neither organization is surprised by what's happening in the other organization, helping to identify the right people to be talking to in each organization, and making sure that formal liaison statements don't "get lost" between the two organizations. The IAB's guidance to liaison managers is available in [RFC4691].
The IAB appoints IETF Liaison Managers using the process described in [RFC4052]. The current list of the IETF's liaison relationships, and the liaison officials responsible for each of these relationships is available at http://www.ietf.org/liaison/managers.html.
The IETF process for sending and receiving liaison statements is defined in [RFC4053].
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 which are compiled with responses in comment resolution documents.
Most IEEE 802 mailing lists are open to all subscribers. For the few IEEE 802 mailing lists that are not open, please see the working group chair to arrange for access to the mailing list.
IETF and IEEE 802 each recognize the standards defined by the other and therefore do not have issues with cross-referencing each other's standards.
IETF specifications may reference IEEE 802 work in progress, but these references would be labeled as "Work in Progress", and if the references are normative, this would 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 should be avoided if at all possible.
Informative references in IEEE 802 Standards are placed in a bibliograpy, so may point to either approved IETF standards or IETF Internet-Drafts, if necessary.
When an IEEE 802 Standard is revised, it normally retains the same number and the date is updated. Therefore, IEEE 802 Standards are dated with the year of approval, e.g IEEE 802 Std 802.1Q-2011. There are two ways of referencing IEEE 802 Standards: undated and dated references. IEEE 802 practice allows undated reference to be used when referencing a whole standard. An undated reference indicates that the most recent version of the standard should be used. A dated reference refers to a specific revision of an IEEE 802 standard. Since clauses, subclauses, tables, figures, etc. may be renumbered when a standard is revised, a dated reference should be used when citing specific items in a standard.
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.
The IETF uses the Internet Assigned Numbering Authority (IANA) as a central authority that administers registries for protocol parameter allocations. The overarching document describing this is [RFC5226]. [RFC5342] 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).
EDITOR'S NOTE: This section is focused on one (important) specific example - we need text that describes the RAC and general operation first. We have asked Glenn Parson to provide text here - Pat will follow up with Glenn.
EtherType Allocation - The IEEE Registration Authority (IEEE RA) assigns Ethertypes with oversight from the IEEE Registration Authority Committee (IEEE RAC). (See http://standards.ieee.org/develop/regauth/ethertype/.) Some IETF protocol specification make use of Ethertypes. All Ethertype requests are subject to review by a consultant to the IEEE RA followed by IEEE RAC confirmation.
Since Ethertypes are a fairly scarce resource, 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 is willing to consider "early allocation" of an Ethertype for an IETF protocol that is still under development as long as the request comes from, and has been vetted by, the IESG.
To let the IEEE RAC know that the IESG has approved the request for an Ethernet assignment for an IETF protocol, all future requests for assignment of Ethertypes for IETF protocols will be made by the IESG.
Note that "playpen" Ethertypes have been assigned in IEEE 802 [Etypes] for use during protocol development and experimentation.
While a fee is normally charged by IEEE 802 for the allocation of an EtherType, IEEE 802 will consider waiving the fee for allocations relating to an IETF standards track document, based on a request from the IESG.
Each IEEE 802 working group has registry of identifier values and a mechanism to allocate identifier values in its standards and approved amendments. Contact the IEEE 802 working group chair for the details of a given working group registry.
This document requests no actions by IANA.
Documents that describe cooperation procedures, like this one, have no direct Internet security implications.
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.
This document was assembled by a drafting team of participants from both IEEE 802 and IETF. The drafting team members were Dan Romascanu, Dorothy Stanley, Eric Gray, Patricia Thaler, Roger Marks, Ross Callon, Spencer Dawkins, and Subir Das.
We also thank Bernard Aboba and Jari Arkko for providing review comments.
| [RFC4052] | Daigle, L., Internet Architecture Board, "IAB Processes for Management of IETF Liaison Relationships", BCP 102, RFC 4052, April 2005. |
| [RFC4053] | Trowbridge, S., Bradner, S. and F. Baker, "Procedures for Handling Liaison Statements to and from the IETF", BCP 103, RFC 4053, April 2005. |
| [RFC4691] | Andersson, L., "Guidelines for Acting as an IETF Liaison to Another Organization", RFC 4691, October 2006. |
| [RFC5342] | Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. |
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [RFC6756] | Trowbridge, S., Lear, E., Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunication Standardization Sector Collaboration Guidelines", RFC 6756, September 2012. |
| [RFC4181] | Heard, C., "Guidelines for Authors and Reviewers of MIB Documents", BCP 111, RFC 4181, September 2005. |
| [RFC4441] | Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441, March 2006. |
| [RFC4663] | Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG to IEEE 802.1 WG", RFC 4663, September 2006. |
| [Etypes] | IEEE 802 Std 802a-2003 (Amendment to IEEE 802 Std 802-2001). IEEE 802 standard for Local and Metropolitan Area Networks: Overview and Architecture -- Amendment 1: Ethertypes for Prototype and Vendor- Specific Protocol Development", 2003. | , "
| [BCP9] | Internet Engineering Task Force, "Best Current Practice 9: The Internet Standards Process -- Revision 3, as updated", . |
| [BCP25] | Internet Engineering Task Force, "Best Current Practice 25: IETF Working Group Guidelines and Procedures, as updated", . |
Historically the MIB modules for IEEE 802.1 and IEEE 802.3 were developped 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 by transferring the work to IEEE 802 with expert support for MIB review from the IETF. 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 [RFC4181]. 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.
By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the SNMP quality control process, the IETF and IEEE 802 seek to ensure quality while decreasing overhead. The process of transfer of the MIB work from the IETF Bridge MIB WG to IEEE 802.1 WG is documented in [RFC4663].
This section provides pointers to additional useful information for paricipants in IEEE 802 and IETF.
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.
Information on IETF procedures may be found in the documents in the informative references, and at the URLs below.
Note: RFCs do not change after they are published. Rather, they are either obsoleted or updated by other RFCs. Such updates are tracked in the rfc-index.txt file.
Current list and status of all IETF RFCs: ftp://ftp.ietf.org/rfc/rfc-index.txt
Current list and description of all IETF Internet-Drafts: ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt
Current list of IETF working groups and their Charters: http://www.ietf.org/dyn/wg/charter.html (includes area directors and chair contacts, mailing list information, etc.)
Current list of registered BOFs: http://trac.tools.ietf.org/bof/trac/
RFC Editor pages about publishing RFCs: http://www.rfc-editor.org/index.html (including available tools and lots of guidance) http://www.rfc-editor.org/pubprocess.html is particularly helpful.
Current list of liaison statements: https://datatracker.ietf.org/liaison/
IETF Intellectual Property Rights Policy and Notices: http://www.ietf.org/ipr/
The Tao of the IETF: http://www.ietf.org/tao.html (A Novice's Guide to the Internet Engineering Task Force)