| Internet Architecture Board | S. Dawkins, Ed. |
| Internet-Draft | Huawei |
| Obsoletes: 4441 (if approved) | October 2012 |
| Intended status: Informational | |
| Expires: April 02, 2013 |
The IEEE 802 / IETF Relationship
draft-dawkins-iab-rfc4441rev-00.txt
This document provides guidance to aid in the understanding of collaboration on standards development between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 4441 The updates reflect changes in the IETF and IEEE since RFC 4441 was written.
EDITOR NOTE: I cloned this text from RFC 6756, but ... "updates AND obsoletes"??? Awesome ...
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 April 02, 2013.
Copyright (c) 2012 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) 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.
EDITOR'S NOTE: This version of the draft is very rough, and is being submitted so we have something concrete to talk about.
This section describes how the existing processes within the IETF and IEEE 802 may be utilized to enable collaboration between the organizations.
IEEE 802 and IETF are similar in some ways, but different in others. When working on project that's of interest to both organizations, it's important to understand these differences.
Standardization in IEEE 802 takes place within 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. The IEEE 802 Executive Committee and Working Groups meet at plenary sessions in March, July and November. Most Working Groups hold interim meetings, usually in January, April and September. An IEEE 802 Orientation for new participants that gives an overview of IEEE 802 process is available.
A good place to to learn more is the IEEE 802 Home Page:
Participation in IEEE 802 Working Groups is by individual and is open. Individuals are required to declare their affiliation. Working Groups maintain membership rosters, with voting membership attained and retained on the basis of in-person meeting attendance.
EDITOR'S NOTE: Do we need to explain "affiliation"? An individual is deemed "affiliated" with any individual or entity that has been, or will be, financially or materially supporting that individual's participation in a particular IEEE standards activity. This includes, but is not limited to, his or her employer and any individual or entity that has or will have, either directly or indirectly, requested, paid for, or otherwise sponsored his or her participation.
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).
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".
A good place to to learn more is the IETF Home Page:
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:
Note: The current list of IETF area directors and working group chairs can be found in the IETF working group charters.
The following sections outline a process that can be used to enable each group to be 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 X.X).
IEEE Working Group status reports are published at the beginning and end of each plenary at on the IEEE802 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:. Access requires an IEEE web account which is free and has no membership requirement. In myProject, a search on "View Active PARs" for 802 will bring up a list of all active IEEE 802 PARs. If an IETF working group identifies a common area of work or a need for 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 xx).
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 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 chairman, 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. As a result, the mailing list should be consistently monitored.
An IEEE 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 considers Five Criteria when deciding whether to approve new work: Broad Market Potential, Compatibility, Distinct Identity and Technical 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.
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).
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 he 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 general, development of standards is 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.
In general, development of standards is 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.
Many IEEE 802 groups use a documentation system provided by IEEE and known as "Mentor". The list of these groups is available at IEEE 802 Mentor Home Page:. Mentor has some particularly notable aspects:
In most cases, WGs that use the Mentor system use it exclusively, so that any substantive document will be available through the system. In a few cases (for example, the IEEE 802 Executive Committee), document distribution is by multiple means (including an email reflector), so it may be difficult to compile a complete set of documents.
Some WGs do not use the Mentor system. In this case, documents are nevertheless generally publically available and indexed. Typically, the index may be presented via a human-managed web site. In such cases, the contributions may be submitted via email to a document manager, so they may not be immediately available to the public. For WGs not using the Mentor system, it should be relatively straightforward to find documents of interest by reviewing the group's main web page, at IEEE 802 working group pages:, where [i] is the one-digit or two-digit numerical desigation for the WG or TAG. In some cases, links to documents may be available only by reviewing the WG or subgroup meeting minutes.
IEEE 802 Working Groups are open to contribution. 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 standardization projects. As a result, such drafts are never made publicly available. The IEEE-SA grants permission for an IEEE draft standard to be distributed without charge to the participants for that IEEE standards development project. Typically, such distribution is on the Internet under password protection, with the password provided to the 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. In some cases, under an organizational agreement, the IEEE-SA allows for ready document exchange with other entities. No such agreement currently exists to cover exchanges between IEEE-SA and IETF.
IEEE standards, once approved, are published and made available for sale. They can be purchased from the IEEE Standards Store: . They are also available from other outlets, including the IEEE Xplore digital library: . The Get IEEE 802 program: 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.
Internet-Drafts are available on the IETF web site. IEEE 802 can 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. It should also be recognized that the official 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.
Need text here.
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.
With the areas of cooperation between IEEE 802 and IETF increasing, the document review process has extended beyond the traditional subjects of SNMP MIBs and AAA. For example, as part of the IETF CAPWAP WG charter, IEEE 802.11 was asked to review the CAPWAP Taxonomy Document [RFC4118]; Dorothy Stanley organized an ad hoc group for this purpose. IEEE 802.11 has also reviewed [IDSEL] and [IABLINK]. Within IETF, IEEE 802 comments are resolved using normal WG and IETF processes.
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.
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.
Need text here.
Need text here.
EDITOR NOTE: This section is hacked out of RFC 6756, so needs IEEE-side attention.
All IETF working groups and all ITU-T study group Questions have associated mailing lists.
In the IETF, the mailing list is the primary vehicle for discussion and decision-making. It is recommended that the ITU-T 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. In the ITU-T, the TSB has set up formal mailing lists for Questions, working parties, and other topics within study groups (more detail can be found on the ITU-T web site). These mailing lists are typically used for ITU-T correspondence, including technical discussion, meeting logistics, reports, etc.
IETF participants may subscribe to ITU-T focus group email lists if they are individuals from a country that is a member of ITU-T.
Need text here.
EDITOR NOTE: http://tools.ietf.org/html/rfc6756#section-2.6 is primarily from the ITU-T side; I don't think IETF requires anything special (except document availability and stability) to reference documents from another SDO, so I don't think IETF needs to say anything here.
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 registry for protocol parameter allocation. The overarching document describing this is RFC 5226. RFC 5342 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 on one (important) specific example - do we need text that describes general operation first?
EtherType Allocation - The EtherType field is very limited, so that allocations are made solely on an "as needed" basis. For related uses, a single EtherType should be requested, with additional fields serving as sub-protocol identifiers, rather than applying for multiple EtherTypes. EtherType allocation policy is described in [TYPE-TUT].
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.
Need text here.
This section provides pointers to additional useful information for paricipants in IEEE 802 and IETF.
IEEE 802 policies and procedures:
Information on IETF procedures may be found in the documents in the informative references, and 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:
Current list and description of all IETF Internet-Drafts:
Current list of IETF working groups and their Charters: (includes area directors and chair contacts, mailing list information, etc.)
Current list of registered BOFs:
RFC Editor pages about publishing RFCs:, including available tools and lots of guidance
Current list of liaison statements:
IETF Intellectual Property Rights Policy and Notices:
The Tao of the IETF: - A Novice's Guide to the Internet Engineering Task Force
This document requests no actions by IANA.
RFC EDITOR: Please remove this section upon publication.
Documents that describe cooperation procedures, like this one does, have no direct Internet security implications.
EDITOR NOTE: This text was taken from RFC 6756, and it's probably defensible. RFC 4441 called out a lot of specifics (the need for security review when working with RADIUS, EAP, etc.). We could do the same here, if we had to, and if someone provided text.
This document borrows massive amounts of text, including 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, Pat Thaler, Roger Marks, Ross Callon, Spencer Dawkins, and Subir Das.
| [RFC5226] | Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. |
| [RFC5342] | Eastlake, D., "IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 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. |
| [RFC4441] | Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441, March 2006. |
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 to IEEE 802 is documented in [RFC4663] and in [I-D ETHERNET-MIB-TRANSFER].
MIB review, EAP review, and AAA review should be here, along with an updated version of Appendix A from 4441