[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-iab-rfc4441rev

Internet Architecture Board                              S. Dawkins, Ed.
Internet-Draft                                                    Huawei
Obsoletes: 4441 (if approved)                                  P. Thaler
Intended status: Informational                                  Broadcom
Expires: May 19, 2013                                  November 15, 2012


                    The IEEE 802 / IETF Relationship
                  draft-dawkins-iab-rfc4441rev-01.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).  It is an almost complete
   rewrite of, and is intended to replace, RFC 4441.  The updates
   reflect changes in the IETF and IEEE, and in the relationship between
   the two organizations, since RFC 4441 was written.

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 May 19, 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
   carefully, as they describe your rights and restrictions with respect
   to this document.



Dawkins & Thaler          Expires May 19, 2013                  [Page 1]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


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  . . .  7
       2.1.3.  Cultural Differences . . . . . . . . . . . . . . . . .  8
     2.2.  Exchange of information about new Work Items . . . . . . . 10
       2.2.1.  How IEEE 802 is informed about active IETF work
               items  . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.2.2.  How IETF is informed about active IEEE 802 work
               items  . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.2.3.  How IEEE 802 is informed about proposed new IETF
               work items . . . . . . . . . . . . . . . . . . . . . . 11
       2.2.4.  How IETF is informed about proposed new IEEE 802
               work items . . . . . . . . . . . . . . . . . . . . . . 11
       2.2.5.  Other Mechanisms for Coordination  . . . . . . . . . . 12
     2.3.  Document Access  . . . . . . . . . . . . . . . . . . . . . 12
       2.3.1.  IEEE 802 Documentation System  . . . . . . . . . . . . 12
       2.3.2.  Access to IETF Documents . . . . . . . . . . . . . . . 15
     2.4.  Participation in Document Review and Approval  . . . . . . 15
       2.4.1.  IEEE 802 draft review and balloting processes and
               opportunities for IETF participation . . . . . . . . . 15
       2.4.2.  IETF draft review and balloting processes and
               opportunities for IEEE 802 participation . . . . . . . 17
     2.5.  Expert Review Processes  . . . . . . . . . . . . . . . . . 18
     2.6.  Liaison Officials and Liaison Statements . . . . . . . . . 18
       2.6.1.  Liaison Officials  . . . . . . . . . . . . . . . . . . 19
       2.6.2.  Liaison Statements . . . . . . . . . . . . . . . . . . 19
   3.  Mailing Lists  . . . . . . . . . . . . . . . . . . . . . . . . 20
   4.  Cross-Referencing Documents in IEEE 802 and IETF . . . . . . . 21
   5.  Protocol Parameter Allocation  . . . . . . . . . . . . . . . . 22
     5.1.  IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.2.  IEEE Registration Authority  . . . . . . . . . . . . . . . 22
     5.3.  IEEE Registration at IEEE working group level  . . . . . . 22
     5.4.  Pointers to Additional Useful Information  . . . . . . . . 22
       5.4.1.  IEEE 802 Information that may be useful to IETF
               participants . . . . . . . . . . . . . . . . . . . . . 23
       5.4.2.  IETF Information that may be of use to IEEE 802
               participants . . . . . . . . . . . . . . . . . . . . . 23
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 24
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 25
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Changes since RFC4441 . . . . . . . . . . . . . . . . 28



Dawkins & Thaler          Expires May 19, 2013                  [Page 2]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   Appendix B.  Current examples of this relationship . . . . . . . . 29
     B.1.  MIB Review . . . . . . . . . . . . . . . . . . . . . . . . 29
   Appendix C.  History of the IEEE 802 / IETF relationship . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31















































Dawkins & Thaler          Expires May 19, 2013                  [Page 3]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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 and cooperation.

   EDITOR'S NOTE: This version of the draft is still very rough,
   although we're getting closer.  The references sections are both
   incomplete and bogus - I'm showing most of the references as inline
   hyperlinks.  I'll clean this up soon.





































Dawkins & Thaler          Expires May 19, 2013                  [Page 4]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


2.  Guidance on Collaboration

   This section describes how the existing processes within the IETF and
   IEEE 802 may be used 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 projects that are of interest to both organizations,
   it's important to understand these differences.

2.1.1.  IEEE 802 Organization, Participation and Membership

   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 by individual 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).



Dawkins & Thaler          Expires May 19, 2013                  [Page 5]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   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 side may include:

   EDITOR'S NOTE: I see that Pat starts her list at the working group
   level, while the IETF list starts with the area directors.  Am I
   remembering Pat saying that these are roughly equivalent, so IEEE 802
   working groups are NOT the peers of IETF working groups?  If so, we
   should probably point that out in the "Cultural Differences" section.

   IEEE Working Group Chair:  An IEEE Working Group chair is an
             individual who is assigned to lead the work of IEEE in a
             particular area.  IEEE Working Group chairs are elected by
             the Working Group and confirmed by the Executive Committee
             for a 2 year term.  Collaboration here is provides a stable
             contact point for work between the two organizations for a
             given topic.

   IEEE Task Group (or Task Force) Chair:  An IEEE Task Group chair is
             an individual who is assigned to lead the work on a
             specific project or group of projects within a Working
             Group.  Task Group Chairs often serve for the duration of a
             project.  Collaboration here is beneficial to ensure that
             work on a particular project is coordinated.

   IEEE Study Group Chair:  An IEEE Study Group Chair is an individual
             assigned to lead consideration of new work and development
             of an IEEE Project Authorization Request (PAR).
             Collaboration here is useful for providing input on the
             scope of new work and to begin coordination.

   IEEE Liaisons:  It may be beneficial to establish lisisons as
             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.



Dawkins & Thaler          Expires May 19, 2013                  [Page 6]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   Informal Contact points:  Other informal contacts can provide useful
             collaboration points.  These include project editors who
             are responsible for editing the drafts and work with the
             Task Group Chairs to lead tracking and resolution of
             issues.  Joint members who are active in both the IEEE and
             IETF projects in an area can also aid in collaboration.

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).

   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 goal 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
   plenary meetings is available at
   http://www.ietf.org/meeting/upcoming.html.  Information about 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).

   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, at
   http://www.ietf.org/, and especially the "About the IETF" page at
   http://www.ietf.org/about, selectable from 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:

   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.



Dawkins & Thaler          Expires May 19, 2013                  [Page 7]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   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, at
   http://datatracker.ietf.org/wg/.

2.1.3.  Cultural Differences

   EDITOR'S NOTE: What else do we need to mention here?

   It's worth noting that IEEE 802 and IETF have cultures that are
   similar, but not identical.  Some of the differences include:

   Consensus and Rough Consensus:  Both organizations make decisions
             based on consensus, but in the IETF, "consensus" means
             "rough consensus".  In practice, this means that a large
             part of the community being asked needs to agree.  Not
             everyone has to agree, but if you disagree, you'll need to
             convince other people of your point of view.  If you're not
             able to do that, you'll be "in the rough" when "rough
             consensus" is declared.

   Rough Consensus and Running Code:  David Clark coined the phrase "we
             believe in rough consensus and running code" in 1992, to
             explain IETF culture.  Although that's not always true
             today, the existence of "running code" as a proof of
             feasibility for a proposal often carries weight during
             technical discussions.  IEEE 802 standards may be less
             amenable to one-off implementation, whether as hardware or
             as software.

   Voting:   Both organizations use voting as a decision-making tool,
             but IEEE 802 uses voting within working groups, while IETF
             does not.  The IESG DOES ballot documents when considering
             them for publication, and working group chairs may ask for
             a "show of hands" or "take a hum" to judge backing for a
             proposal, but IETF working groups don't vote.



Dawkins & Thaler          Expires May 19, 2013                  [Page 8]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   Balance between mailing lists and meetings:  Both organizations make
             use of mailing lists, but IETF working groups really can't
             get anything done without mailing lists, which is where
             work can continue between formal meetings.  The IETF
             requires all decisions to be made (or, often in practice,
             confirmed) on mailing lists - final decisions aren't made
             in meetings.  It's also worth noting that IETF working
             group sessions are much shorter than IEEE 802 working group
             sessions - it's not unusual for an IETF working group to
             meet once or twice in a plenary meeting, for a maximum of
             two and a half hours per session.  Some working groups may
             not meet at all in plenary, and others may have a single
             one-hour session.

   Interim meetings:  Both organizations use interim meetings (between
             plenary meetings), but this is more common for IEEE 802
             working groups than for IETF working groups, which schedule
             interim meetings on an as-needed basis.  While the IETF
             interim meetings may be face-to-face or virtual, the IEEE
             802 interim meetings are face-to-face only.  Many IEEE 802
             WGs hold regularly interim meetings three times a year in
             the middle of the intervals between the Plenary meetings.
             The schedules and location of these meetings are typically
             known many months in advance.

   Remote participation:  Because the IETF doesn't make decisions at
             face-to-face meetings, it's not strictly necessary to
             attend face-to-face meetings at all!  Some significant
             contributors don't attend most face-to-face IETF meetings,
             although if you want to find collaborators on a proposal
             for new work, or solicit backing for your ideas, you'll
             probably find that easier in a face-to-face conversation,
             often in a hallway and sometimes in a bar.  IEEE 802
             significant contributors almost always attend face-to-face
             meetings.  Participation in IEEE 802 meetings is a
             condition for WG membership.

   Working group autonomy:  Both IEEE 802 and IETF allow working groups
             considerable autonomy (within the documented process) in
             getting work done.  It's worth noting that there may be
             differences between two IEEE 802 working groups, or between
             two IETF working groups, in addition to differences between
             an IEEE 802 working group and an IETF working group.








Dawkins & Thaler          Expires May 19, 2013                  [Page 9]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


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
   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).

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 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.

   EDITORIAL NOTE: I have text from Pat that says MyProject is free, and
   from Eric that says it requires IEEE and IEEE SA membership, and both
   involve paying a fee.  Pat and Roger are investigating how much you
   can do with a login, without membership - I'll update when they
   report back ...

   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).



Dawkins & Thaler          Expires May 19, 2013                 [Page 10]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


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 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.  As a result, the IETF
   Announce mailing list should be monitored consistently.

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.

   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.




Dawkins & Thaler          Expires May 19, 2013                 [Page 11]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   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.2.5.  Other Mechanisms for Coordination

   From time to time, IEEE 802 and IETF may agree to use additional
   mechanisms for coordination between the two groups.  We mention that
   here, so that readers will know to ask about this.

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 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.

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
   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.



Dawkins & Thaler          Expires May 19, 2013                 [Page 12]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


2.3.1.2.  Access to internal IEEE 802 Working Group Documents

   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 has some
   particularly notable aspects:

   EDITOR'S NOTE: We had a suggestion to trim some of this information.
   Pat to consider and provide revised text.

   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 using the IEEE
       Account Request page, at
       http://www.ieee.org/go/create_web_account.  If submission is
       protected, the privilege can be requested via the Mentor system
       (using the "Join group" link on each WG Mentor page) and would
       typically be granted by the WG documentation manager in a manual
       approval.

   6.  Submitted documents are immediately available to the general
       public at the same instant they become available for
       consideration by the group.

   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



Dawkins & Thaler          Expires May 19, 2013                 [Page 13]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   straightforward to find documents of interest by reviewing the
   group's main web page.  These web page addresses follow this
   convention: 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 - in
   other words, the one-digit or two- digit numerical desigation for the
   WG or TAG appears as the "path" in the URL.

   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 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, 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.





Dawkins & Thaler          Expires May 19, 2013                 [Page 14]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


2.3.2.  Access to IETF Documents

   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.

   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/athoritative versions
   of all IETF documents are in ASCII.

2.4.  Participation in Document Review and Approval

   EDITOR'S NOTE: we discussed moving part of this section to Expert
   Review.  That's not a small change, so I'll wait until people have a
   chance to think about it, before proposing text.

   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 draft review and balloting processes and opportunities
        for IETF participation

   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.

   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 .csv 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.







Dawkins & Thaler          Expires May 19, 2013                 [Page 15]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


2.4.1.1.  Task Group Review

   During draft development, informal task group reviews (task group
   ballots) are conducted.  Though these are called "ballots" by some
   Working Groups, the focus is on collecting and resolving comments on
   the draft rather than on trying to achieve a specific voting result.

2.4.1.2.  Working Group ballot

   Once the draft is substantially complete, Working Group ballots are
   conducted.  Working Group voting members are entitled and required to
   vote in Working Group ballots.  Any disapprove votes are required to
   be accompanied by comments that indicate what the objection is and a
   proposed resolution.  Approve votes may also be accompanied by
   comments.  The comments submitted with a disapprove vote may be
   marked to indicate which comments "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.

2.4.1.3.  Sponsor Ballot

   When a draft has successfully completed Working Group ballot, it
   proceeds to Sponsor ballot.  One may participate in IEEE 802 Sponsor
   Ballots with an individual membership in the IEEE Standards
   Association (IEEE-SA) or by paying a per-ballot fee.  (See IEEE-SA
   membership.)  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).

   Note to the reader: The yearly cost of membership in the IEEE-SA is
   generally about the same or less as the per-ballot fee, so it is
   generally more economical to join the IEEE-SA.

   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.  An IEEE web account
   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.



Dawkins & Thaler          Expires May 19, 2013                 [Page 16]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   Editor's note: add URL for myProject is
   development.standards.ieee.org to references.

   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.

   Editor's note: check that all groups accept the same file format and
   try to find a place to post a blank .CSV file for download.  Pat's
   action

2.4.2.  IETF draft review and balloting processes and opportunities for
        IEEE 802 participation

   The IETF Working Group Process is defined in BCP-25.  The overall
   IETF standards process is defined in BCP-9.

   As noted in <cultdiff>, 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.

   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
       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.




Dawkins & Thaler          Expires May 19, 2013                 [Page 17]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   In practice, earlier input is more likely to be effective input.  The
   IETF Liaison Manager should provide early notification of upcoming
   Working Group Last Calls and IETF Last Calls, for best results.

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.

   EDITOR'S NOTE: the previous text is cut-and-pasted out of 4441.  We
   could reasonably point out that we're moving beyond 4441 in the same
   way that we moved beyond SNMP MIBs and AAA, but Spencer would be more
   comfortable if we weren't calling out names in this way, even if we
   write that text.  Spencer suggests just saying "we've moved on".

   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

   EDITOR'S NOTE: This section is written mostly from an IETF
   perspective.  If there are helpful things to say about IEEE 802
   liaison processes, 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 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



Dawkins & Thaler          Expires May 19, 2013                 [Page 18]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


   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
   http://tools.ietf.org/html/rfc4691.

2.6.1.  Liaison Officials

   IETF Liaison Officials (called "Liaison Managers" in the IETF) are
   appointed by the IAB, using the process described in
   http://tools.ietf.org/html/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.

2.6.2.  Liaison Statements

   The IETF process for sending and receiving liaison statements is
   defined at http://tools.ietf.org/html/rfc4053.
































Dawkins & Thaler          Expires May 19, 2013                 [Page 19]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


3.  Mailing Lists

   All IETF working groups and all IEEE 802 Working Groups have
   associated mailing lists.  Most IEEE 802 Task Groups also have
   mailing lists, but in some cases, e.g.the IEEE 802.1 Working Group,
   the Working Group mailing list is used for any Task Group matters.

   In the IETF, the mailing list is the primary vehicle for discussion
   and decision-making.  It is recommended that IEEE 802 experts
   interested in particular IETF working group topics subscribe to and
   participate in these lists.  IETF WG mailing lists are open to all
   subscribers.  The IETF working group mailing list subscription and
   archive information are noted in each working group's charter page.

   In IEEE 802, mailing lists are typically used for meeting logistics,
   ballot announcements, reports and some technical discussion.  Most
   decision making is at meetings, but in cases where a decision is
   needed between meetings, it may be done over the mailing list.  Most
   technical discussion occurs at meeting and by generating comments on
   drafts which are compiled with responses in comment resolution
   documents.

   EDITOR'S NOTE: IEEE 802 is considering making mailing list
   participation more uniform, but that will be discussed at the IEEE
   802 plenary in November


























Dawkins & Thaler          Expires May 19, 2013                 [Page 20]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


4.  Cross-Referencing Documents in IEEE 802 and IETF

   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 IEEE 802 reference work in progress, but
   these references would be labeled as "Work in Progress", and would
   block publication of the referring specification until the reference
   is available in a stable form.

   IEEE standards may reference draft standards that are dated, readily
   available and retrievable, but this should be avoided if at all
   possible.

   EDITOR'S NOTE: The plan used to be that IETF Internet-Drafts expired
   after 6 months, AND WERE NO LONGER RETRIEVABLE - but now, expired
   drafts are still available without a subpoena.  Do we think Internet-
   Drafts now qualify for IEEE 802 use?  We'll talk ...

   When an IEEE Standard is revised, it normally retains the same number
   and the date is updated.  Therefore, IEEE Standards are dated with
   the year of approval, e.g IEEE Std 802.1Q-2011.  There are two ways
   of referencing IEEE Standards: undated and dated references.  IEEE
   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 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.

   Informative references in IEEE Standards are placed in a bibliograpy,
   so may point to either approved IETF standards or IETF Internet-
   Drafts, if necessary.
















Dawkins & Thaler          Expires May 19, 2013                 [Page 21]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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 the RAC and general operation first?

   EDITOR'S NOTE: Eric suggested asking Glenn Parson to provide text
   here.

   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.

   EDITOR'S NOTE: Need to mention OUIs, and that IANA has only one?

5.3.  IEEE Registration at IEEE working group level

   Need text here - don't need to say much about this, but do need to
   say that these registrations exist.

5.4.  Pointers to Additional Useful Information

   This section provides pointers to additional useful information for
   paricipants in IEEE 802 and IETF.




Dawkins & Thaler          Expires May 19, 2013                 [Page 22]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


5.4.1.  IEEE 802 Information that may be useful to IETF participants

   IEEE Home Page: http://ieee802.org/

   IEEE 802 policies and procedures: http://ieee802.org/devdocs.shtml"

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:
   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)











Dawkins & Thaler          Expires May 19, 2013                 [Page 23]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


6.  IANA Considerations

   This document requests no actions by IANA.
















































Dawkins & Thaler          Expires May 19, 2013                 [Page 24]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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.), but RFC 4441
   only identified five areas of cooperation - we're at something like
   20 now, and I'd prefer not to try to have a security considerations
   section that is the union of the security considerations sections
   from each area of cooperation.







































Dawkins & Thaler          Expires May 19, 2013                 [Page 25]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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, Patricia Thaler, Roger Marks,
   Ross Callon, Spencer Dawkins, and Subir Das.








































Dawkins & Thaler          Expires May 19, 2013                 [Page 26]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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 & Thaler          Expires May 19, 2013                 [Page 27]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


Appendix A.  Changes since RFC4441


















































Dawkins & Thaler          Expires May 19, 2013                 [Page 28]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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 & Thaler          Expires May 19, 2013                 [Page 29]


Internet-Draft      The IEEE 802 / IETF Relationship       November 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 & Thaler          Expires May 19, 2013                 [Page 30]


Internet-Draft      The IEEE 802 / IETF Relationship       November 2012


Authors' Addresses

   Spencer Dawkins (editor)
   Huawei Technologies
   1547 Rivercrest Blvd.
   Allen, TX  75002
   USA

   Email: spencer@wonderhamster.org


   Patricia Thaler
   Broadcom Corporation
   5025 Keane Drive
   Carmichael, CA  95608
   USA

   Email: pthaler@broadcom.com

































Dawkins & Thaler          Expires May 19, 2013                 [Page 31]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/