The IEEE 802 / IETF Relationship
draft-dawkins-iab-rfc4441rev-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Spencer Dawkins | ||
| Last updated | 2012-10-15 | ||
| Replaced by | draft-iab-rfc4441rev, draft-iab-rfc4441rev, RFC 7241 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dawkins-iab-rfc4441rev-00
Internet Architecture Board S. Dawkins, Ed.
Internet-Draft Huawei
Obsoletes: 4441 (if approved) October 15, 2012
Intended status: Informational
Expires: April 18, 2013
The IEEE 802 / IETF Relationship
draft-dawkins-iab-rfc4441rev-00.txt
Abstract
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 ...
Status of this Memo
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 18, 2013.
Copyright Notice
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
Dawkins Expires April 18, 2013 [Page 1]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Guidance on Collaboration . . . . . . . . . . . . . . . . . . 5
2.1. Organization, Participation and Membership . . . . . . . . 5
2.1.1. IEEE 802 Organization, Participation and Membership . 5
2.1.2. IETF Organization, Participation and Membership . . . 5
2.2. Exchange of information about new Work Items . . . . . . . 6
2.2.1. How IEEE 802 is informed about active IETF work
items . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2. How IETF is informed about active IEEE 802 work
items . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.3. How IEEE 802 is informed about proposed new IETF
work items . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4. How IETF is informed about proposed new IEEE 802
work items . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Document Access . . . . . . . . . . . . . . . . . . . . . 8
2.3.1. IEEE 802 Documentation System . . . . . . . . . . . . 8
2.3.2. Access to IETF Documents . . . . . . . . . . . . . . . 11
2.4. Participation in Document Review and Approval . . . . . . 11
2.4.1. IEEE 802 balloting processes and opportunities for
IETF participation . . . . . . . . . . . . . . . . . . 11
2.4.2. IETF balloting processes and opportunities for
IEEE 802 participation . . . . . . . . . . . . . . . . 11
2.5. Expert Review Processes . . . . . . . . . . . . . . . . . 12
2.6. Liaison Officials and Liaison Statements . . . . . . . . . 12
2.6.1. Liaison Officials . . . . . . . . . . . . . . . . . . 12
2.6.2. Liaison Statements . . . . . . . . . . . . . . . . . . 12
3. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Cross-Referencing . . . . . . . . . . . . . . . . . . . . . . 14
5. Protocol Parameter Allocation . . . . . . . . . . . . . . . . 15
5.1. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. IEEE Registration Authority . . . . . . . . . . . . . . . 15
5.3. IEEE Registration at IEEE working group level . . . . . . 15
5.4. Pointers to Additional Useful Information . . . . . . . . 15
5.4.1. IEEE 802 Information that may be useful to IETF
participants . . . . . . . . . . . . . . . . . . . . . 15
5.4.2. IETF Information that may be of use to IEEE 802
participants . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Dawkins Expires April 18, 2013 [Page 2]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Changes since RFC4441 . . . . . . . . . . . . . . . . 22
Appendix B. Current examples of this relationship . . . . . . . . 23
B.1. MIB Review . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix C. History of the IEEE 802 / IETF relationship . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
Dawkins Expires April 18, 2013 [Page 3]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
1. Introduction and Scope
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.
Dawkins Expires April 18, 2013 [Page 4]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
2. Guidance on Collaboration
This section describes how the existing processes within the IETF and
IEEE 802 may be utilized to enable collaboration between the
organizations.
2.1. Organization, Participation and Membership
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.
2.1.1. IEEE 802 Organization, Participation and Membership
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: [1]
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.
2.1.2. IETF Organization, Participation and Membership
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
Dawkins Expires April 18, 2013 [Page 5]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
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: [2]
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:
IETF Area Director: An IETF area director is the individual
responsible for overseeing a major focus of activity (an
"Area"). These positions are relatively long- term (of
several years) and offer the stability of contact points
between the two organizations for a given topic.
IETF Working Group Chair: An IETF working group chair is an
individual who is assigned to lead the work on a specific
task within one particular area. These positions are
working positions (of a year or more) that typically end
when the work on a specific topic ends. Collaboration here
is very beneficial to ensure the actual work gets done.
Other Contact Points: It may be beneficial to establish additional
contact points for specific topics of mutual interest.
These contact points should be established early in the
work effort, and in some cases the contact point identified
by each organization may be the same individual.
Note: The current list of IETF area directors and working group
chairs can be found in the IETF working group charters.
2.2. Exchange of information about new Work Items
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.
2.2.1. How IEEE 802 is informed about active IETF 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
Dawkins Expires April 18, 2013 [Page 6]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
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).
2.2.2. How IETF is informed about active IEEE 802 work items
IEEE Working Group status reports are published at the beginning and
end of each plenary at on the IEEE802 website: [3]. 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: [4]. 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).
2.2.3. How IEEE 802 is informed about proposed new IETF work items
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.
Dawkins Expires April 18, 2013 [Page 7]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
2.2.4. How IETF is informed about proposed new IEEE 802 work items
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).
2.3. Document Access
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.
2.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 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.
2.3.1.1. IEEE 802 Documentation System
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
Dawkins Expires April 18, 2013 [Page 8]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
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.
2.3.1.2. Access to internal IEEE 802 Working Group Documents
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: [5]. Mentor has some particularly notable aspects:
1. The documentation system is structured and ordered, with
documentation tags and unique numbering and revisioning.
2. On-line documentation is available.
3. Generally speaking, the archives are publicly and freely
available.
4. Limited search functionality is provided, and publicly-available
search engines index the data.
5. The ability to submit documents to Mentor is limited but is
generally available to any interested party. An IEEE Account is
required but can be easily and freely established IEEE Account
Request: [6]. If submission is protected, the privilege can be
requested via the Mentor system (using the "Join group" link on
each WG Mentor page) and would typically be granted by the WG
documentation manager in a manual approval.
6. Submitted documents are immediately available to the general
public at the same instant they become available for
consideration by the group.
Dawkins Expires April 18, 2013 [Page 9]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
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: [7], 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.
2.3.1.3. Submission of Contributions to IEEE 802 Working Groups
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.
2.3.1.4. Access to IEEE 802 Working Group Drafts
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.
2.3.1.5. Access to IEEE 802 Standards
IEEE standards, once approved, are published and made available for
sale. They can be purchased from the IEEE Standards Store: [8].
They are also available from other outlets, including the IEEE Xplore
Dawkins Expires April 18, 2013 [Page 10]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
digital library: [9] . The Get IEEE 802 program: [10] 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.
2.3.2. Access to IETF Documents
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.
2.4. Participation in Document Review and Approval
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.
2.4.1. IEEE 802 balloting processes and opportunities for IETF
participation
Need text here.
2.4.2. IETF balloting processes and opportunities for IEEE 802
participation
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 signaled on the working group's mailing
list.
2. When a working group issues a "Working Group Last Call" ("WGLC")
for a draft. Although this is not a mandatory step in the
document review and approval process, most IETF working groups do
issue WGLCs for most working group documents. WGLC would be
signaled on the working group's mailing list.
3. When the Internet Engineering Steering Group issues an "IETF Last
Call" ("Last Call") for a draft. This is similar in spirit to
WGLC, but is a request for review and approval that is addressed
Dawkins Expires April 18, 2013 [Page 11]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
to the larger IETF community. IETF Last Call is signaled on the
IETF-Announce Mailing List, and comments and feedback are
ordinarily directed to the IETF Discussion Mailing List.
2.5. Expert Review Processes
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.
2.6. Liaison Officials and Liaison Statements
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.
2.6.1. Liaison Officials
Need text here.
2.6.2. Liaison Statements
Need text here.
Dawkins Expires April 18, 2013 [Page 12]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
3. Mailing Lists
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.
Dawkins Expires April 18, 2013 [Page 13]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
4. Cross-Referencing
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.
Dawkins Expires April 18, 2013 [Page 14]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
5. Protocol Parameter Allocation
Both IEEE 802 and IETF maintain registries of assigned protocol
parameters, and some protocol parameters assigned in one organization
are of interest to the other organization. This section describes
the way each organization registers protocol parameters.
5.1. IANA
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).
5.2. IEEE Registration Authority
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.
5.3. IEEE Registration at IEEE working group level
Need text here.
5.4. Pointers to Additional Useful Information
This section provides pointers to additional useful information for
paricipants in IEEE 802 and IETF.
5.4.1. IEEE 802 Information that may be useful to IETF participants
IEEE 802 home page: [11]
IEEE 802 policies and procedures: [12]
Dawkins Expires April 18, 2013 [Page 15]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
5.4.2. IETF Information that may be of use to IEEE 802 participants
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: [13]
Current list and description of all IETF Internet-Drafts: [14]
Current list of IETF working groups and their Charters: [15]
(includes area directors and chair contacts, mailing list
information, etc.)
Current list of registered BOFs: [16]
RFC Editor pages about publishing RFCs: [11], including available
tools and lots of guidance
IEEE 802 home page: [17]
Current list of liaison statements: [18]
IETF Intellectual Property Rights Policy and Notices: [19]
The Tao of the IETF: [20] - A Novice's Guide to the Internet
Engineering Task Force
Dawkins Expires April 18, 2013 [Page 16]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
6. IANA Considerations
This document requests no actions by IANA.
RFC EDITOR: Please remove this section upon publication.
Dawkins Expires April 18, 2013 [Page 17]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
7. Security Considerations
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.
Dawkins Expires April 18, 2013 [Page 18]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
8. Acknowledgements
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.
Dawkins Expires April 18, 2013 [Page 19]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
9. References
9.1. Normative References
[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.
9.2. Informative References
[RFC4441] Aboba, B., "The IEEE 802/IETF Relationship", RFC 4441,
March 2006.
Dawkins Expires April 18, 2013 [Page 20]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
URIs
[1] <http://www.ieee802.org/>
[2] <http://www.ietf.org/>
[3] <http://ieee802.org/minutes>
[4] <https://development.standards.ieee.org/my-site>
[5] <https://mentor.ieee.org/802>
[6] <http://www.ieee.org/go/create_web_account>
[7] <http://ieee802.org/[i]>
[8] <http://www.techstreet.com/ieeegate.html>
[9] <http://ieeexplore.ieee.org>
[10] <http://standards.ieee.org/about/get>
[11] <http://ieee802.org/>
[12] <http://ieee802.org/devdocs.shtml>
[13] <ftp://ftp.ietf.org/rfc/rfc-index.txt>
[14] <ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt>
[15] <http://www.ietf.org/dyn/wg/charter.html>
[16] <http://trac.tools.ietf.org/bof/trac/>
[17] <http://www.rfc-editor.org/pubprocess.html>
[18] <https://datatracker.ietf.org/liaison/>
[19] <http://www.ietf.org/ipr/>
[20] <http://www.ietf.org/tao.html/>
Dawkins Expires April 18, 2013 [Page 21]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
Appendix A. Changes since RFC4441
Dawkins Expires April 18, 2013 [Page 22]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
Appendix B. Current examples of this relationship
B.1. MIB Review
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].
Dawkins Expires April 18, 2013 [Page 23]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
Appendix C. History of the IEEE 802 / IETF relationship
MIB review, EAP review, and AAA review should be here, along with an
updated version of Appendix A from 4441
Dawkins Expires April 18, 2013 [Page 24]
Internet-Draft The IEEE 802 / IETF Relationship October 2012
Author's Address
Spencer Dawkins (editor)
Huawei Technologies
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Email: spencer@wonderhamster.org
Dawkins Expires April 18, 2013 [Page 25]