<?xml version="1.0" encoding="UTF-8"?>


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!ENTITY RFC2850 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2850.xml'>

					<!ENTITY RFC3575 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3575.xml'>

					<!ENTITY RFC3710 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3710.xml'>

					<!ENTITY RFC4441 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4441.xml'>

					<!ENTITY RFC4181 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml'>
					<!ENTITY RFC4663 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4663.xml'>
					<!ENTITY RFC4691 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4691.xml'>
					<!ENTITY RFC5226 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml'>
					<!ENTITY RFC5342 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5342.xml'>
					<!ENTITY RFC6733 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6733.xml'>
					<!ENTITY RFC6756 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6756.xml'>
]>


<rfc category="info" ipr="trust200902" docName="draft-iab-rfc4441rev-04.txt" obsoletes="4441" submissionType="IAB">


<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>


<?rfc toc="yes" ?>

<?rfc compact="yes" ?>

<?rfc symrefs="yes" ?>

<?rfc sortrefs="yes"?>

<?rfc iprnotified="no" ?>

	<front>

	        <title>The IEEE 802 / IETF Relationship</title>


		<author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="editor">
			<organization abbrev="Huawei">Huawei Technologies</organization>
			<address>
				<postal>
 	 				<street> 1547 Rivercrest Blvd.</street>
		  			<city> Allen</city>
					<region>TX </region>
		  			<code>75002 </code> 
					<country>USA</country> 
				</postal>
	      			<email>spencer@wonderhamster.org</email>
	 		</address>
	  	</author>

		<author initials="P." surname="Thaler" fullname="Patricia Thaler">
			<organization abbrev="Broadcom">Broadcom Corporation</organization>
			<address>
				<postal>
  					<street> 5025 Keane Drive</street>
		  			<city> Carmichael</city>
					<region>CA </region>
		  			<code>95608 </code> 
					<country>USA</country> 
				</postal>
      				<email>pthaler@broadcom.com</email>
 			</address>
  		</author>

		<author initials="D." surname="Romascanu" fullname="Dan Romascanu">
			<organization>AVAYA</organization>
			<address>
				<postal>
  					<street> Park Atidim, Bldg. #3</street>
		  			<city>Tel Aviv</city>
					<region></region>
		  			<code>61581 </code> 
					<country>Israel</country> 
				</postal>
				<phone>+972-3-6458414</phone>
      				<email>dromasca@avaya.com</email>
 			</address>
  		</author>

        	<date month="May" year="2013" />
		<workgroup>Internet Architecture Board</workgroup>

        	<abstract>
			<t>This document describes the standardization collaboration between
 				Project 802 of the Institute of Electrical and Electronic Engineers (IEEE) and the Internet Engineering Task Force (IETF). 
				This document obsoletes RFC 4441.</t>
		</abstract>

	</front>


    
	<middle>

        <section title="Introduction and Scope">
		<t>This document contains a set of principles and guidelines that serves
			as the basis for establishing collaboration between Project 802 of the 
			Institute of Electrical and Electronics Engineers
   			(IEEE 802) and the Internet Engineering Task
   			Force (IETF) of the Internet Society (ISOC), with the objective of securing timely development of technical
			specifications that facilitate maximum interoperability with existing
			(fixed and mobile) Internet systems, devices, and protocols.
			Each organization will operate according to their own rules and
			procedures including rules governing IPR policy, specification
			elaboration, approval and maintenance.</t>

		<t>This document is non-normative, and is intended to improve practices for cooperation between 
			the two organizations that are already in place.</t>

		<t>This version of the document responds to comments received during IAB Last Call. The editor believes that all comments received have
			been considered and addressed, with the exception of http://wiki.tools.ietf.org/group/iab/trac/ticket/283, which is still 
			being discussed, with a goal of providing needed descriptive text for IETF processes without providing too much text, which makes the
			document harder to read and might even conflict with normative IETF process text.</t>
	</section>

	<section title="Why Cooperate?">

		<t>Cooperation between independent standards organizations comes at a price, so the benefits of cooperation must outweigh the costs.</t>

		<t>The IETF benefits from cooperation by obtaining improved access to IEEE 802 expertise on the widely-deployed and widely-used IEEE 802 Local
			Area Network architecture <xref target="ARCH802" />.</t>

		<t>IEEE 802 benefits from cooperation by obtaining improved access to IETF expertise on IP datagram encapsulation, routing, transport, 
			security, and specific applications of interest to IEEE 802.</t>

		<t>One of the primary drivers for <xref target="RFC4441" /> was to allow effective collaboration between IEEE 802 and 
			the IETF during a time where downward pressure on travel budgets was making it increasingly difficult for the same 
			participants to attend face-to-face meetings in both organizations. That pressure has continued in the intervening years.
			</t>

		<t>Early identification of topics of mutual interest allows the two organizations to cooperate in a productive way,
			and helps each organization avoid developing specifications that overlap or conflict with specifications
			developed in the other organization.</t>
        </section>



        <section title="Guidance on Collaboration">

        	<t>This section describes how existing processes within the IETF and 
			IEEE 802 may be used to enable collaboration between the organizations.</t>


        	<section title="Organization, Participation and Membership">


        		<t>IEEE 802 and IETF are similar in some ways, but different in others. When working on projects that are of interest
				to both organizations, it's important to understand these similarities and differences.</t>
			
        		<section title="IEEE 802 Organization, Participation and Membership">

				<t>The IEEE Standards Association (IEEE-SA) is the standards setting body of the IEEE. 
					The IEEE-SA Standards Board oversees 
					the IEEE standards development process.</t>

				<t> The IEEE-SA Standards Board supervises what IEEE calls "sponsors" - IEEE entities that develop standards. 
					The IEEE 802 LAN/MAN Standards Committee is a sponsor that develops and maintains networking standards 
					and recommended practices for local, metropolitan, and other area networks, using an open and accredited process, 
					and advocates them on a global basis. The most widely used standards are for Ethernet, Bridging and Virtual Bridged 
					LANs, Wireless LAN, Wireless PAN, Wireless MAN, Wireless Coexistence, Media Independent Handover Services, and 
					Wireless RAN. An individual Working Group provides the focus for each area.</t>

				<t>In IEEE 802, work is done in Working Groups operating under an Executive Committee.  
					Each Working Group is led by a Working Group Chair. 
					Most Working Groups have one or more Task Groups.  A Task Group is responsible for a project or 
					group of projects.  </t>

				<t>The Executive Committee is comprised of the Executive Committee Chair, Executive Committee Officers 
					(e.g., Vice-Chairs, Secretaries, Treasurer) and Working Group Chairs.</t>

				<t>A good place to learn more is the IEEE 802 Home Page, at &lt;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.</t>

				<t>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, May and September. The meeting schedule can be 
					found at &lt;http://www.IEEE802.org/meeting/index.html>.</t>

				<t>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.</t>

				<t>Participation in IEEE 802 Working Groups is at the level of individuals, i.e., participants are human beings and not companies,
					and is
					open. Individuals are required to declare their affiliation (i.e., any individual or entity that 
					financially or materially supports the individual's participation in IEEE 802).</t>

				<t>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.</t>

				<t>To foster ongoing communication between IEEE 802 and IETF, it is
   					important to identify and establish contact points within each
   					organization.  IEEE 802 contact points may include:</t>

				<t><list style="hanging" hangIndent="10">
					<t hangText="IEEE 802 Working Group Chair:"> An IEEE 802 Working Group chair is an individual who is assigned to lead 
						the work of IEEE 802 in a particular area. IEEE 802 Working Group chairs are elected by the Working Group and 
						confirmed by the Executive Committee for a 2 year term. Collaboration here provides a stable contact 
						point for work between the two organizations for a given topic.</t>

					<t hangText="IEEE 802 Task Group (or Task Force) Chair:"> 
						An IEEE 802 Task Group chair is an individual who is assigned to lead the work on a specific project or 
						group of projects within a Working Group. 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.</t>

					<t hangText="IEEE 802 Study Group Chair:"> 
						An IEEE 802 Study Group Chair is an individual assigned to lead consideration of new work and development 
						of an IEEE 802 Project Authorization Request (PAR). Collaboration here provides input on the 
						scope of new work and to begin coordination.</t>

					<t hangText="IEEE 802 Liaisons:"> 
						It may be beneficial to establish liaisons as additional
             					contact points for specific topics of mutual interest.
             					These contact points should be established early in the
             					work effort. The IEEE 802 and IETF projects may select the same individual as their contact point, 
						but this is not required, so that two individuals each serve as contact points for one project 
						participating in the liaison relationship.</t>

					<t hangText="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 802 and IETF projects in an area can also aid in 
						collaboration.</t>
				</list></t>

			</section>

        		<section title="IETF Organization, Participation and Membership">

				<t>The IETF Standards Process is defined in <xref target="BCP9" />. 
					The IETF working group process is defined in <xref target="BCP25" />. </t>

				<t><xref target="BCP11" /> is a helpful description of organizations involved in the IETF standards process. 
					It can still be useful as an overview, although details have changed since 1996.</t>

				<t>In the IETF, work is done in working groups (WGs), and is mostly carried out through
					open, public mailing lists rather than face-to-face meetings. </t>

				<t>WGs are organized into areas, and each area is managed by one or more area
					directors.  Collectively, the area directors comprise the Internet
					Engineering Steering Group (IESG) <xref target="RFC3710" />.</t>

				<t>The Internet Architecture Board (IAB) charter <xref target="RFC2850" /> assigns the IAB several 
					responsibilities relevant to this document: </t>
					
					<t><list style="numbers">
						<t>IESG Appointment </t>
						<t>Architectural Oversight</t>
						<t>Standards Process Oversight and Appeal</t>
						<t>Appointment of RFC Series and Internet Assigned Number Authority (IANA) roles</t>
						<t>Oversight of External Liaisons for the IETF</t>
					</list></t>

				<t>IESG and IAB members are selected using the Nomcom process defined in <xref target="BCP10" />.
					Working group chairs serve at the pleasure of their Area Directors, as described in <xref target="BCP25" />.</t>

				<t>IETF meets in plenary session three times per year. Some working groups schedule additional interim meetings, 
					which may be either face-to-face or "virtual", but this is not true for most IETF working groups. 
					The preferred way to develop specifications
					is to do work on mailing lists, reserving face-to-face sessions for topics 
					that have not been resolved through previous mailing list discussion. </t>

				<t>Information about IETF plenary 
					meetings is available at &lt;http://www.ietf.org/meeting/upcoming.html&gt;. 
					Information about IETF working group interim meetings 
					is available on the IETF-Announce mailing list (see &lt;http://www.ietf.org/list/announcement.html&gt; for 
					archives and subscription information).</t>

				<t>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 is no concept of "IETF membership". </t>

				<t>To foster ongoing communication between IEEE 802 and IETF, it is
					important to identify and establish contact points within each
					organization.  IETF contact points may include Area Directors, Working Group Chairs, and other 
					points of contact who can help communicate between IEEE 802 and IETF working groups.</t>

				<t>The IETF is designed to be a "bottom-up" protocol
					engineering organization - the leadership steers and manages, but
					does not direct work in a top-down way. Technical agreements
					with "the IETF" are based on the consensus of working group
					participants, rather than negotiated with IETF leadership.</t>

                               	<t>A good place to learn more is the IETF Home Page, at &lt;http://www.ietf.org/>, and especially the 
					"About the IETF" page at &lt;http://www.ietf.org/about>, selectable from the IETF Home Page.</t>

                               	<t>The "Tao of the IETF" is also very helpful, especially for IEEE 802 participants who will also be participating in IETF
					working groups and attending IETF meetings. It's available from  &lt;http://www.ietf.org/tao.html.</t>

				<t>The current list of IETF area directors and working group
					chairs can be found in the IETF working group charters, at &lt;http://datatracker.ietf.org/wg/&gt;.</t>
			</section>

			<section title="Structural Differences">

				<t>IEEE 802 and IETF have similar structures, 
						but the names they use are different, and even conflicting. For example,
						both IEEE 802 and IETF use the term "Working group",
						but "working groups" means two very different things in the two organizations.</t>

				<figure>
        				<preamble>Thmbnail comparison between IETF and IEEE 802 entities</preamble>
        				<artwork>
IETF Area           is similar to  IEEE 802 Working Group 
IETF Working Group  is similar to  IEEE 802 Task Group
IETF BOF            is similar to  IEEE 802 Study Group
        				</artwork>
    				</figure>

				<t>Both IEEE 802 Working Groups and IETF Areas are large, long-lived, and 
					relatively broadly scoped, containing more narrowly chartered entities (IEEE 802 Task Groups and IETF Working Groups),
					which tend to be short-lived and narrowly chartered. IEEE 802 uses Study Groups to develop proposals for new work,
					and these are analogous to IETF BOFs.</t> 
			</section>
				

        		<section anchor="cdiff" title="Cultural Differences">

				<t>It's worth noting that IEEE 802 and IETF have cultures that are similar, but not identical. 
					Some of the differences include:</t>
				<t><list style="hanging" hangIndent="10">
					<t hangText="Consensus and Rough Consensus:"> Both organizations make decisions based on consensus, but in the IETF,
						"consensus" can mean "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 someone disagrees, they need to convince other people of their point of view. 
						If they're not able to do that, they'll be "in the rough" when "rough consensus" is declared. 
						IEEE 802 consensus is usually based on  percentage of voting approval.</t>
					<t hangText="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 while the standard is still being developed,
						whether as hardware or as software.</t>
					<t hangText="Voting:"> Both organizations use voting as a decision-making tool, but IEEE 802 uses voting within
						working groups, while IETF working groups do not use voting. Working group chairs may ask for a "show of hands" or 
						"take a hum" to judge backing for a proposal, but this is not considered to be "voting" - 
						The IESG does ballot documents when considering 
						them for publication. This balloting is a final approval for publication.</t>
					<t hangText="Balance between mailing lists and meetings:"> Both organizations make
             					use of mailing lists. IETF working groups rely heavily on mailing lists, where
				             	work is done, in addition at formal meetings.  The IETF
             					requires all working group decisions to be made (or, often
             					in practice, confirmed) on mailing lists - final decisions
             					aren't made in meetings.  IEEE 802 working groups typically meet face-to-face about twice as often as IETF
						working groups (three IEEE 802 plenaries plus three IETF 802 interim meetings each year, compared to three IETF 
						plenaries per year) and teleconferences are more common in IEEE 802 than in most IETF working groups. 
						Most major decisions in IEEE 802 are made during plenary or interim meetings,
						except for procedural decisions. 
						Attendance at meetings is critical to influencing decisions and to maintaining membership voting rights.</t>
					<t hangText="Interim meetings:"> Both organizations use interim meetings (between
						plenary meetings). IETF working groups schedule
						interim meetings on an as-needed basis.  IETF
						interim meetings may be face-to-face or virtual.
						Most IEEE 802 WGs hold regularly interim meetings three times a year in
						the middle of the interval between two Plenary meetings.
						The schedules and location of these meetings are typically
						known many months in advance. IEEE 802 interim meetings are face-to-face only. In addition to regularly scheduled
						IEEE 802 interim meetings, teleconference and ad hoc meetings are held on an as-needed basis.</t>
					<t hangText="Remote participation:"> Because the IETF doesn't make decisions at face-to-face meetings, 
						it's not absolutely necessary to attend face-to-face meetings at all. Some significant 
						contributors don't attend most face-to-face IETF meetings, although in order  
						to find collaborators on a proposal for new work, or 
						solicit backing for your ideas, that's likely 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.</t>
					<t hangText="Working group autonomy:"> Both IEEE 802 and IETF allow working groups considerable autonomy
						(within the documented process) in getting chartered work done.</t>
				</list></t>
	
				<t>EDITOR NOTE: the description of "rough consensus", including hums, may be affected by 
					http://datatracker.ietf.org/doc/draft-resnick-on-consensus/ if that draft advances. </t>
			</section>

        	</section>


        	<section title="Exchange of Information About Work Items">

        		<t>The following sections outline a process that can be used to enable
   					each organization to stay informed about the other's active and proposed work items.</t>


        		<section title="How IEEE 802 is informed about active IETF work items">
				<t>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 (&lt;http://datatracker.ietf.org/wg/&gt;).
   					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 <xref target="LS" />).</t>
			</section>

        		<section title="How IETF is informed about active IEEE 802 work items">
				<t>IEEE 802 Working Group status reports are published at the beginning and end of each plenary at 
					&lt;http://IEEE802.org/minutes> on the IEEE 802 website. 
					Each Working Group includes a list of their active projects and the status. </t>

				<t>The charter of an IEEE 802 project is defined in an approved Project Authorization Request (PAR). 
					PARs are accessible in IEEE Standards 
					myProject, at &lt;https://development.standards.ieee.org/my-site&gt;. 
					Access requires an IEEE web account which is free and has no membership requirement. </t>

				<t>In myProject, 
					a search on "View Active PARs" for 802 will bring up a list of all active IEEE 802 PARs. </t>

				<t>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.</t>

				<t>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 <xref target="LS" />).</t>

			</section>

			<section title="Overview of new work proposal notification">
				<t>These principles describe the notification process used by both organizations:</t>
				<t><list style="numbers">
					<t>For both organizations, the technical group making a proposal for new work that may conflict 
						with, overlap with, or be dependent 
						on the other organization is responsible for informing the 
						top-level coordination body in the other organizaion that coordination may be required.</t>
					<t>For both organizations, the top-level coordination body receiving that notification is responsible
						for determining whether coordination is, in fact, required, and informing the specific groups 
						within the organization who may be affected by the proposal for new work.</t>
				</list></t>
				<t>These direct notifications will be the most common way that each organization is informed about
					proposals for new work in the other organization. Several other ways of identifying proposed
					new work are described in the following sections. These additional ways act as "belt and suspenders" to 
					reduce the chances that proposals for new work in one organization escapes notice 
					in the other organization when coordination will be required.</t>
			</section>

			<section title="The New-Work mailing list">
				<t>Several standards development organizations(including IETF and IEEE 802) have 
					agreed to use a mailing list for the distribution of information
					about proposals for new work items among these SDOs. </t>

				<t>Rather than having individual IEEE 802 participants subscribe directly to New-Work, 
					a single IEEE 802 mailing list is subscribed. 
					Leadership of the IEEE 802 working groups may subscribe to this "second-level" IEEE 802 
					mailing list, which is maintained by the Executive Committee (EC).</t>

				<t>This mailing list is limited to representatives of SDOs proposing new work that may require coordination with the IETF.
					Subscription requests may be sent to the IAB Executive Director. </t>

				<t>EDITOR NOTE: the IAB has a 2013 retreat agenda item to discuss the logistics for the New-Work mailing list.
					We may be adding information about how to subscribe to that mailing list after the retreat.</t>
			</section>

        		<section title="How IEEE 802 is informed about proposed new IETF work items">
				<t>Many proposals for new IETF work 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 new and revised working
   					groups and BOF session announcements to the IETF New-Work mailing
   					list. </t>
			</section>

        		<section title="How IEEE 802 comments on proposed new IETF work items">
				<t>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.</t>

   				<t>It should be noted that the IETF turnaround time for new working
   					group charters can be as short as two weeks, although the call for comment period on work items that may require 
					coordination with IEEE 802 can be extended to allow more time
					for discussion within IEEE 802.  This places a burden on both organizations to proactively communicate and avoid
					"late surprises" to either organization. </t>

				<t>Although an IEEE 802 working group may not be able to develop a formal consensus response unless the notification arrives 
					during that working group's meeting, the IEEE 802 working group chair can informally let the IETF know that IEEE 802 
					may have concerns about a proposed work item. 
					The IETF will consider any informal comments received without waiting for a formal liaison statement.</t>
			</section>

        		<section title="How IETF is informed about proposed new IEEE 802 work items">
				<t>An IEEE 802 project is initiated by approval of a Project Authorization Request (PAR) 
					which includes a description of the scope of the work. Any IEEE 802 PARs which introduce new 
					functionality are required to be available for review no less than 30 days prior to the Monday of 
					the IEEE 802 plenary session where they will be considered.</t>

				<t>IEEE 802 considers Five Criteria when deciding whether to approve new work: 
					Broad Market Potential, Compatibility, Distinct Identity, Technical Feasibility and Economic Feasibility. 
					The criteria are defined in the IEEE 802 LAN/MAN Standards Committee (LMSC) Operations Manual. 
					The PARs are accompanied by responses on the 5 Criteria.</t>

				<t>IEEE 802 posts proposed PARs to the New-Work mailing list, prior to the IEEE 802 meetings where the PARs 
					will be discussed. The IETF coordination body will notify technical groups about PARs of interest.</t>
			</section>

        		<section title="How IETF comments on proposed new IEEE 802 work items">
				<t>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).</t>
			</section>

			<section title="Other Mechanisms for Coordination">
				<t>From time to time, IEEE 802 and IETF may agree to use additional mechanisms for coordination
					between the two groups. </t>

				<t>As examples of such mechanisms, at the time this document was written, the two organizations are holding periodic 
					conference calls between 
					representatives of the IETF and IEEE 802 
					leadership teams, and are maintaining a "living list" of shared interests between the two organizations, along with
					the status of these interests and any related action items. At the time this document was written, 
					the "living list"
					included about 20 topics being actively discussed, with more expected. These conference calls help the two organizations
					coordinate more effectively by allowing higher-bandwidth discussions than formal liaison statements would allow, and 
					permitting more timely interactions than waiting for face-to-face meetings.</t>

				<t>Minutes for these conference calls, and the "living lists" discussed on each call, are available at
					&lt;http://www.iab.org/activities/joint-activities/iab-ieee-coordination/&gt;. </t>

				<t>EDITOR NOTE: this document doesn't mention the ieee-ietf-coord mailing list. Is using that list a long-term commitment from
					both organizations? If so, we should probably include it; if not, we should leave it out.</t>
			</section>
					
		</section>

        	<section title="Document Access">

        		<t>During the course of IEEE 802 and IETF collaboration, 
				it is important to share internal documents among the technical working groups. 
				In addition, drafts of IEEE 802 standards, Internet Drafts, and RFCs may also be distributed.</t>

			
        		<section title="IEEE 802 Documentation System">
				<t>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.). </t>
		
				<t>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. </t>

				<t>In addition to allowing IETF participants to access documentation resources within IEEE 802, IEEE 802 can also
					make selected IEEE 802 documents at any stage of development available
					to the IETF by attaching them to a formal liaison statement.
   					Although a communication can point to a URL where a non-ASCII
   					document can be downloaded, attachments in proprietary
   					formats to an IETF mailing list are discouraged.</t>

	        		<section title="The role of the IEEE 802 Documentation System in document development">
					<t>In general, development of standards in IEEE 802 is contribution-driven. 
						Content for drafts of 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 of a 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.</t>
				</section>

	        		<section title="Access to internal IEEE 802 Working Group Documents">

					<t>Generally, the archives of minutes and contributions to IEEE 802 groups are publically and freely available. </t>

					<t>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: &lt;https://mentor.ieee.org/802&gt;.  	
						Mentor provides the following features:</t>

					<t><list style="numbers">
						<t>The documentation system is structured and ordered, with documentation tags and unique numbering 
							and revisioning.</t>
						<t>On-line documentation is available.</t>
						<t>Limited search functionality is provided, and publicly-available search engines index the data.</t>
						<t>The ability to submit documents to Mentor is limited but is generally available to any interested party.  
							An IEEE web account is required but can be easily and freely established using the IEEE
							Account Request page, at &lt;http://www.ieee.org/go/create_web_account&gt;.  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. </t>
						<t>Submitted documents are immediately available to the general
							public at the same instant they become available for
							consideration by the group.</t>
					</list></t>

					<t>IEEE 802.1 and IEEE 802.3 do not use Mentor. </t>
					<t>IEEE 802.1 documents are organized in folders by year at: &lt;http://www.ieee802.org/1/files/public/>.
						The file names indicate the relevant project, author, date and version. The file naming conventions and upload 
						link are at: &lt;http://www.ieee802.org/1/files/public/&gt;. Upload is moderated. </t>
					<t>IEEE 802.3 documents are accessed from 
						the home pages of the IEEE 802.3 subgroups (i.e., Task Force or Study Group) and are organized in folders by 
						meeting date. Files are uploaded by emailing to the subgroup chair. </t>
				</section>

	        		<section title="Submission of Contributions to IEEE 802 Working Groups">
					<t>IEEE 802 Working Groups are open to contributions. In many cases, a WG or subgroup will issue a 
						call for contributions with a specific technical solicitation, including deadlines and submission 
						instructions. 
						Some groups maintain specific submission procedures and specify a contribution cover sheet to clarify the 
						status of the contribution.</t>
				</section>

	        		<section title="Access to IEEE 802 Working Group Drafts">
					<t>The IEEE owns the copyright to drafts of standards developed within IEEE 802 standardization projects. 
						The IEEE-SA grants permission for an IEEE 802 
						draft to be distributed without charge to the participants for that IEEE 802 standards development 
						project.
						Typically, such distribution is on the Internet under password protection, with the password provided to 
						members of the participating WG. Requests to the relevant WG chair for access to a draft for purposes of 
						participation in the project are typically granted.</t>

					<t>An alternative access mechanism which may more easily enable document access for IETF WGs
   						collaborating with IEEE 802 was established by a liaison statement sent to the IETF
   						in July 2004 by Paul Nikolich, Chair of IEEE 802 
						(available at &lt;https://datatracker.ietf.org/documents/LIAISON/file41.pdf&gt;),
   						describing the process by which IETF WGs can obtain access to IEEE
   						802 work-in-progress.  IEEE 802 WG Chairs have the authority to grant
   						membership in their WGs, and can use this authority to grant
   						membership to an IETF WG chair upon request.  The IETF WG chair will
   						be provided with access to the username/password for the IEEE 802 WG
   						archives, and is permitted to share that information with
   						participants in the IETF WG.  Since it is possible to participate in
   						IETF without attending meetings, or even joining a mailing list, IETF
   						WG chairs will provide the information to anyone who requests it.
   						However, since IEEE 802 work-in-progress is copyrighted,
   						incorporating material into IETF documents or posting the
   						username/password on mailing lists or websites is not permitted.</t>
				</section>

	        		<section title="Access to IEEE 802 Standards">
					<t>IEEE 802 standards, once approved, are published and made available for sale. 
						They can be purchased from the IEEE Standards Store, at &lt;http://www.techstreet.com/IEEEgate.html&gt;. 
						They are also available from other outlets, including the IEEE Xplore digital library, 
						at &lt;http://IEEExplore.IEEE.org&gt;.</t>

					<t>The Get IEEE 802 program, at &lt;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.</t>
				</section>
			</section>

        		<section title="Access to IETF Documents">
				<t>IETF Internet-Drafts may be located using 
					IETF "Datatracker" interface at &lt;https://datatracker.ietf.org>, 
					or via the IETF tools site at &lt;http://tools.ietf.org&gt;.
					RFCs may be located at either of the above, or via the RFC Editor site at 
					&lt;http://www.rfc-editor.org&gt;.</t>


				<t>It should be
   					recognized that the official/athoritative versions of all IETF documents are in ASCII.</t>
			</section>
		</section>

        	<section title="Participation in Document Review and Approval">

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

			
        		<section title="IEEE 802 draft review and balloting processes and opportunities for IETF participation">
				<t>IEEE 802 drafts are reviewed and balloted at multiple stages in the
   					draft.  Any ballot comments received from non-voters before the close
   					of the ballot are required to be considered in the comment resolution
   					process. The Editors, Task Group Chairs or Working Group Chairs responsible
   					for the project will facilitate the entering of comments from non-voters.</t>

				<t>IEEE 802 draft reviews and ballots sometimes produce a large volume of comments. 
					In order to handle them efficiently, spreadsheets or a comment database tool are used. 
					It is highly recommended that balloters and others submitting comments do so with a file that can be 
					imported into these tools. A file with the correct format is normally referenced in the ballot announcement 
					or can be obtained from the Editor, Task Group Chair or Working Group Chair responsible for the project. 
					Comments on a draft should be copied to the Editor, Task Group Chair and Working Group Chair.</t>

				<section title="Task Group Review">
	
					<t>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.</t>

				</section>

				<section title="Working Group ballot">
	
					<t>Once the draft is substantially complete, Working Group ballots are conducted. Working Group voting members 
						are entitled and required to vote in Working Group ballots. Any disapprove votes are required to be 
						accompanied by comments that indicate what the objection is and a proposed resolution. Approve votes may 
						also be accompanied by comments. The comments submitted with a disapprove vote may be marked to indicate 
						which comments need to "be satisfied" to change the vote. </t>

					<t>Initial Working Group ballots are at least 30 days. Recirculation ballots to review draft changes and 
						comment resolutions are at least 10 days.</t>

					<t>In order to submit a Working Group ballot, contact the WG chair for the submission tool currently in use, 
						as the tools may change over time.</t>

				</section>


				<section title="Sponsor ballot">
	
					<t>When a draft has successfully completed Working Group ballot, it proceeds to Sponsor ballot. 
						One may participate in IEEE 802 Sponsor ballots with an individual membership in the IEEE Standards 
						Association (IEEE-SA) or by paying a per-ballot fee. Participants are also 
						required to state their affiliation and the category of their relationship to the scope of the standards 
						activity (e.g., producer, user, general interest).</t>

					<t>Information about IEEE-SA membership can be found at &lt;http://standards.ieee.org/membership/&gt;.</t>

					<t>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
						(&lt;https://development.standards.ieee.org/myproject/bp/StartPage&gt;). An IEEE web account is
						freely available, and is required for login. To select interest areas, go to the Projects tab and 
						select Manage Activity Profile and check any areas of interest. IEEE 802 projects are under 
						Computer Society; LAN/MAN Standards Committee.</t>

					<t>The Sponsor ballot pool is formed from those that accept the
   						invitation during the invitation period.</t>

   					<t>As with other ballot levels, the IETF participants who want to comment on
   						Sponsor ballots need not be members in the Sponsor ballot pool. The Editors, 
   						Task Group Chairs or Working Group Chairs responsible for the project will 
   						facilitate the entering of comments from IETF participants who are not 
   						members in the Sponsor ballot pool.</t>

					<t>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".</t>
				
					<t>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.</t>

				</section>

			</section>

        		<section title="IETF draft review and balloting processes and opportunities for IEEE 802 participation">

				<t>The IETF Working Group Process is defined in <xref target="BCP25" />. 
					The overall IETF standards process is defined in <xref target="BCP9" />.</t>
				<t>As noted in <xref target="cdiff" />, IETF working groups do not "ballot" to determine working group consensus to
					forward documents to the IESG for approval, but the IESG does, as they consider documents for approval.</t>
				<t>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.</t>
				<t><list style="numbers">
					<t>When a working group is considering adoption of an individual draft. Adoption is often signaled 
						on the working group's mailing list.</t>
					<t>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 for Internet-Drafts, 
						most IETF working groups
						do issue WGLCs for most working group documents. WGLC would be signaled on the working
						group's mailing list. </t>
					<t>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.</t>
				</list></t>

				<t>In practice, earlier input is more likely to be effective input. IEEE 802 participants who are interested in work within
					the IETF should be monitoring that work and providing input long before Working Group Last Calls and IETF Last Calls, 
					for best results.</t>

				<t>Some IETF working group charters direct the working group to communicate with relevant IEEE 802 task groups.</t>
			</section>

        	</section>

        	<section title="Solicited Review Processes">

			<t>With the number of areas of cooperation between IEEE 802 and IETF increasing, the document review process has extended beyond the
				traditional subjects of SMI MIB modules and AAA (authentication, authorization and accounting) 
				described in <xref target="RFC4441" />. 
				IESG members routinely solicit directorate reviews as a means 
				to solicit the opinion of specialized experts on specific aspects of documents in IESG review (examples include 
				security, MIB 
				doctors, or congestion management reviews). Area Directors may also require solicited reviews from IEEE 802 or 
				IEEE 802 Working Groups when it becomes clear that the Internet-Draft has implications that impact some area of IEEE 802's
				responsibility and expertise. </t>

			<t>IEEE 802 leadership can also solicit similar reviews, but these reviews are not included as part of the formal IEEE 802 process.</t>

        	</section>

        	<section title="Liaison Managers and Liaison Statements">

        		<t>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.</t>

			<t>The Internet Architecture Board (IAB) is responsible for liaison relationship oversight for the IETF.
				In IEEE 802, liaison relationship oversight is distributed, and each organization appointing liaison managers 
				is responsible for oversight of its own liaison relationships.</t>

			<t>The reader should note that the role of a liaison manager in both IEEE 802 and IETF is not to "speak for" the appointing 
				organization. A liaison manager is most helpful in ensuring that neither organization is surprised by what's happening in 
				the other organization, helping to identify the right people to be talking to in each organization, and making sure that 
				formal liaison statements don't "get lost" between the two organizations. The IAB's guidance to liaison managers is
				available in <xref target="RFC4691" />. IEEE 802 organizations appointing each liaison manager also provide 
				guidance to those liaison managers. There is no global guidance for all IEEE 802 liaison managers.</t>
			
        		<section title="Liaison Managers">
				<t>The IAB appoints IETF Liaison Managers 
					using the process described in <xref target="BCP102" />. The current list of the IETF's liaison
					relationships, and the liaison managers responsible for each of these relationships
					is available at &lt;http://www.ietf.org/liaison/managers.html&gt;.</t>
				<t>IEEE liaison managers are selected by the organizations they represent, either in an election or 
					by working group or task group chair appointment. 
					The current list of IEEE 802's liaison relationships and the liaison managers responsible for 
					each of these relationships is available at &lt;http://www.ieee802.org/liaisons.shtml&gt;.
					</t>
			</section>

        		<section anchor="LS" title="Liaison Statements">
				<t>The IEEE 802 procedure for sending and receiving liaison statements is defined by the 
					Procedure for Coordination with Other Standards Bodies in the IEEE 802 LMSC Operations Manual
					(&lt;http://ieee802.org/devdocs.shtml&gt;). </t>
				<t>The IETF process for sending and receiving liaison statements is defined in <xref target="BCP103" />.</t>
			</section>

        	</section>

        </section>


        <section title="Mailing Lists">

		<t>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.</t>

		<t>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.</t>

		<t>In IEEE 802, mailing lists are typically used for meeting logistics, ballot announcements, reports and some 
			technical discussion. Most decision making is at meetings, but in cases where a decision is needed 
			between meetings, it may be done over the mailing list. Most technical discussion occurs at meetings 
			and by generating comments on drafts which are compiled with responses in comment resolution documents.</t>

		<t>Most IEEE 802 mailing lists are open to all subscribers. For the few IEEE 802 mailing lists that are not open,
			please see the working group chair to arrange for access to the mailing list.</t>

        </section>



        <section title="Cross-Referencing Documents in IEEE 802 and IETF">
		<t>IETF and IEEE 802 each recognize the standards defined by the
   			other organization. Standards produced by each organization can be used as references in standards 
			produced by the other organization.</t>

		<t>IETF specifications may reference IEEE 802 work in progress,
			but these references would be labeled as "Work in Progress", and if the references are normative, this
			would block publication of the referring specification until the
			reference is available in a stable form. </t>

		<t>IEEE 802 standards may normatively reference non-expired Internet-Drafts, 
			but IEEE 802 prefers that this should be avoided if at all possible. </t>

		<t>Informative references in IEEE 802 Standards are placed in a bibliography, so may point to either approved IETF standards or 
			IETF Internet-Drafts, if necessary.</t>

		<t>When an IEEE 802 Standard is revised, it normally retains the same number and the date is updated. 
			Therefore,  IEEE 802 Standards are dated with the year of approval, e.g IEEE 802 Std 802.1Q-2011. 
			There are two ways of referencing IEEE 802 Standards: undated and dated references. IEEE 802 practice allows 
			undated reference to be used when referencing a whole standard. An undated reference indicates that 
			the most recent version of the standard should be used. A dated reference refers to a specific revision 
			of an IEEE 802 standard. Since clauses, subclauses, tables, figures, etc. may be renumbered when a standard 
			is revised, a dated reference should be used when citing specific items in a standard.</t>
		<t>IETF standards may be cited by RFC number, which would also be a dated reference. If an undated reference to an IETF Internet Standard
			is desired, a number is also assigned in the "STD" series <xref target="BCP9" />, and these references refer to the most recent version
			of an IETF Internet Standard.</t>
        </section>



        <section title="Protocol Parameter Allocation">

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


        	<section title="IANA">

        		<t>The IETF uses the Internet Assigned Numbering Authority (IANA) as a
				central authority that administers registries for most protocol parameter
				allocations. The overarching
				document describing this is <xref target="RFC5226" />. <xref target="RFC5342" /> 
				discusses use of IEEE 802-specific IANA parameters in
   				IETF protocols and specifies IANA considerations for allocation of
   				code points under the IANA OUI (Organizationally Unique Identifier).</t>


			<t>Requests for protocol parameter allocations from IANA are subject to assignment policies, and these policies vary from registry 
				to registry. A variety of well-known policies are described in <xref target="RFC5226"/>, but registries are not limited to
				one of the well-known choices.</t>
	
			<t>The purpose of these allocations is to manage a namespace appropriately, so unless a registry has a policy that allows something 
				like first come, first served ("FCFS") for a namespace that is effectively unbounded, requests for protocol parameter allocation
				will require some level of review. "Standards Action" is at the other extreme (an approved standards-track RFC is required
				in order to obtain an allocation). Some registries require that a request for allocation pass "expert review" - review 
				by someone knowlegeable in the technology domain, appointed by the IESG and given specific criteria to use when reviewing 
				requests.</t>
       		</section>

        	<section title="IEEE Registration Authority">

			<t>The IEEE Standards Association uses the IEEE Registration Authority as a central authority administering registries. 
				The IEEE Registration Authority Committee (IEEE RAC) provides technical oversight for the IEEE Registration Authority. </t>

			<t>The list of Registries administered by the IEEE Registration Authority can be found on the IEEE RAC website, at 
				&lt;http://standards.ieee.org/develop/regauth/general.html&gt;.</t>
	
			<t>Ethertype Allocation - Some IETF protocol specifications make use of Ethertypes.  
				Ethertypes are fairly scare resource so allocation has the following requirements.
				All Ethertype requests are subject to review by a consultant to the IEEE RA
				followed by IEEE RAC confirmation.</t>

			<t>The IEEE RAC will not assign a new Ethertype to a new IETF protocol specification until the
				IESG has approved the protocol specification for publication as an RFC.  In exceptional cases, the IEEE RA will consider 
				"early allocation" of an Ethertype for an IETF protocol that is still under development when the request comes
				from, and has been vetted by, the IESG.</t>

			<t>Note that "playpen" Ethertypes have been assigned in IEEE 802 <xref target="Etypes"/> for
				use during protocol development and experimentation. </t>

			<t>While a fee is normally charged by the IEEE Registration Authority Committee (RAC) for the allocation of an
				Ethertype, the IEEE RAC will consider waiving the fee for allocations
				relating to an IETF standards track document, based on a request from
				the IESG.</t>
        	</section>


        	<section title="IEEE 802 Registration at IEEE 802 working group level">


			<t>Each IEEE 802 working group has a registry of identifier values and a mechanism to allocate identifier values in its standards and 
				approved amendments. This includes items such as Object Identifiers for managed objects and assignment for protocols defined 
				by that 
				Working Group, such as OpCodes. Contact the IEEE 802 working group chair for the details of a given working group registry. </t>
        	</section>



        	<section title="Joint-use registries">


			<t>Because some registries are "joint-use" between IEEE 802 and IETF, it is necessary for each organization to 
				review usage of registries maintained by the other organization as part of the review and approval 
				process for standards. </t>

			<t>If an IEEE 802 document refers to IANA registries, those references should be checked prior to Sponsor balloting.
				If an IETF document refers to IEEE 802 registries, those references should be checked as part of IANA Review 
				during IETF Last Call.</t>
        	</section>

        </section>


        <section title="IANA Considerations">

        	<t>This document requests no actions by IANA.</t>
        </section>



        <section title="Security Considerations">

        	<t>This document describes cooperation procedures and has no direct Internet security implications.</t>


        </section>


        <section title="Acknowledgements">

        	<t>This document borrows a significant amount of text, and much of its structure, from <xref target="RFC6756"/>.
			Additional text was borrowed from <xref target="RFC4441"/>. We are grateful to the authors and editors 
			of both these predecessor documents.</t>


		<t>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.</t>

		<t>We also thank Adrian Farrel, Bernard Aboba, Dave Thaler, Jari Arkko and Jouni Korhonen for providing review comments.</t>
        </section>

    </middle>



    <back>

        <references title='Normative References'>
		&RFC4691;
		&RFC5342;
		&RFC5226;
		&RFC6756;
	</references>


        <references title='Informative References'>
		&RFC2850;
		&RFC3575;
		&RFC3710;
		&RFC4181;
		&RFC4441;
		&RFC4663;
		&RFC6733;

		<reference anchor='ARCH802'>
     			<front>
         			<title>IEEE 802-200(R2007) IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture</title>
         			<author >
             				<organization>IEEE 802</organization>
         			</author>
         			<date year='2007'/>
     			</front>
		</reference> 

		<reference anchor='Etypes'>
     			<front>
         			<title>IEEE 802 Std 802a-2003 (Amendment to IEEE 802 Std 802-2001).
					IEEE 802 standard for Local and Metropolitan Area Networks: Overview
					and Architecture -- Amendment 1: Ethertypes for Prototype and Vendor-
					Specific Protocol Development</title>
         			<author >
             				<organization>IEEE 802</organization>
         			</author>
         			<date year='2003'/>
     			</front>
		</reference> 


		<reference anchor='IEEE80211F'>
     			<front>
         			<title>802.11F-2003 - IEEE Trial-Use Recommended Practice for Multi-Vendor Access 
					Point Interoperability Via an Inter-Access Point Protocol Across Distribution 
					Systems Supporting IEEE 802.11 Operation</title>
         			<author >
             				<organization>IEEE 802</organization>
         			</author>
         			<date year='2003'/>
     			</front>
		</reference> 


		<reference anchor='BCP9'>
     			<front>
         			<title>Best Current Practice 9: The Internet Standards Process -- Revision 3, as updated</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='1996'/>
     			</front>
		</reference> 

		<reference anchor='BCP10'>
     			<front>
         			<title>Best Current Practice 10: IAB and IESG Selection, Confirmation, and Recall Process: 
					Operation of the Nominating and Recall Committees, as updated</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='2004'/>
     			</front>
		</reference> 



		<reference anchor='BCP11'>
     			<front>
         			<title>Best Current Practice 11: The Organizations Involved in the IETF Standards Process, as updated</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='1996'/>
     			</front>
		</reference> 

		<reference anchor='BCP25'>
     			<front>
         			<title>Best Current Practice 25: IETF Working Group Guidelines and Procedures</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='1998'/>
     			</front>
		</reference> 

		<reference anchor='BCP102'>
     			<front>
         			<title>Best Current Practice 102: IAB Processes for Management of IETF Liaison Relationships</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='2005'/>
     			</front>
		</reference> 


		<reference anchor='BCP103'>
     			<front>
         			<title>Best Current Practice 103: Procedures for Handling Liaison Statements to and from the IETF</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='2005'/>
     			</front>
		</reference> 


		<reference anchor='BCP158'>
     			<front>
         			<title>Best Current Practice 158: RADIUS Design Guidelines</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='2011'/>
     			</front>
		</reference> 

		<reference anchor='DADG'>
     			<front>
         			<title>Diameter Applications Design Guidelines (draft-ietf-dime-app-design-guide-16) (Work in progress)</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='2012'/>
     			</front>
		</reference> 

		<reference anchor='RADEXT'>
     			<front>
         			<title>Remote Authentication Dial In User Service (RADIUS) Protocol Extensions (draft-ietf-radext-radius-extensions-13) 
					(Work in progress)</title>
         			<author >
             				<organization>Internet Engineering Task Force</organization>
         			</author>
         			<date year='2013'/>
     			</front>
		</reference> 

	</references>



	<section title="Current examples of IEEE 802 and IETF Work Item Collaboration">
		<t></t>
		<section title="MIB Review">
			<t>Historically the MIB modules for IEEE 802.1 and IEEE 802.3 were developed in the IETF Bridge MIB and Hub MIB Working Groups 
				respectively. 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 <xref target="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.</t>

			<t>By standardizing IEEE 802 MIBs only within IEEE 802 while utilizing the SNMP quality control process, the IETF and IEEE 802 seek 						to 
				ensure quality while decreasing overhead. The process of transfer of the MIB work from the IETF Bridge MIB WG to IEEE 802.1 WG 
				is documented in <xref target="RFC4663"/>.</t>
		</section>

		<section title="AAA Review">
			<t>IEEE 802 WGs requiring new AAA applications should send a liaison
				request to the IETF.  Where merely new attributes definitions are sufficient rather than defining
				a new authentication, authorization and accounting logic/procedures, an Internet-Draft can be submitted and review can
				be requested from AAA-related WGs such as the RADEXT or DIME WGs. For
				attributes of general utility, and particularly those useful in
				multiple potential applications, allocation from the IETF standard
				attribute space is preferred to creation of IEEE 802 Vendor-Specific
				Attributes (VSAs).  As noted in <xref target="RFC3575" />:
				"RADIUS defines a mechanism for Vendor-Specific extensions and the use of that should be encouraged instead of allocation of
				global attribute types, for functions specific only to one vendor's
				implementation of RADIUS, where no interoperability is deemed useful".</t>

			<t>Where allocation of VSAs are required, it is recommended that IEEE
				802 create a uniform format for all of IEEE 802, rather than having
				each IEEE 802 group create their own VSA format.  The VSA format
				defined in <xref target="IEEE80211F" /> is inappropriate for this, since the Type
				field is only a single octet, allowing for only 255 attributes. It is
				recommended that IEEE groups read and follow the recommendations in 
				"RADIUS Design Guidelines" <xref target="BCP158" /> and the "Protocol Extensions" ID <xref target="RADEXT" /> 
				when designing and reviewing new extensions and attributes. </t>

			<t>The Diameter Applications Design Guidelines I-D <xref target="DADG" />
				explains and clarifies the Rules to extend the Diameter 
				base protocol <xref target="RFC6733" />. Extending Diameter can mean either the definition 
				of a completely new Diameter application  or the reuse of commands, 
				(Attribute-value pairs) AVPs and AVP values in any combination for the 
				purpose of inheriting the features of an existing Diameter application.  
				The recommendation for re-using as much  as possible existing implementations
				is meaningful as most of the requirements defined for a new application are 
				likely already fulfilled by existing applications. It is recommended that 
				IEEE groups read and follow the recommendations in <xref target="DADG" /> 
				when defining and reviewing new extensions and attributes. </t>

			<t>In addition to the RADEXT and DIME WGs, an AAA Doctors team (directorate) is 
				currently active in the OPS Area and can be consulted for more general advice
				on AAA issues that cross the limits of one or the other of the RADIUS or 
				Diameter protocols, or are more generic in nature. </t>
		
		</section>

	</section>

       	<section title="Pointers to Additional Useful Information">

       		<t>This section provides pointers to additional useful information for participants in IEEE 802 and IETF.</t>

			
       		<section title="IEEE 802 Information that may be useful to IETF participants">
			<t>IEEE 802 Home Page: &lt;http://IEEE802.org/&gt;</t>
			<t>IEEE 802 policies and procedures: &lt;http://ieee802.org/devdocs.shtml&gt;</t>
			<t>The IEEE 802 WG and TAG main page URLs follow this
				convention: They have the one or two digit numerical designation for the WG or TAG appended after 
				&lt;http://IEEE802.org/&gt;. For example the IEEE 802.1 main web page is at &lt;http://IEEE802.org/1&gt;,
				while the IEEE 802.11 main web page is at &lt;http://IEEE802.org/11&gt;.</t>
		</section>

       		<section title="IETF Information that may be of use to IEEE 802 participants">
			<t> Information on IETF procedures may be found in the documents in the
				informative references, and at the URLs below.</t>

 			<t>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.</t>

			<t>Current list and status of all IETF RFCs: &lt;ftp://ftp.ietf.org/rfc/rfc-index.txt&gt;</t>
			<t>Current list and description of all IETF Internet-Drafts: &lt;ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt&gt;</t>
			<t>Current list of IETF working groups and their Charters: &lt;http://datatracker.ietf.org/wg/&gt;
				(includes area directors and chair contacts, mailing list information, etc.)</t>
			<t>Current list of requested BOFs: &lt;http://trac.tools.ietf.org/bof/trac/&gt;</t>
			<t>RFC Editor pages about publishing RFCs: &lt;http://www.rfc-editor.org/index.html&gt; (including available tools and 
				lots of guidance)<vspace blankLines='0' /> &lt;http://www.rfc-editor.org/pubprocess.html&gt; is particularly helpful.</t>
			<t>Current list of liaison statements: &lt;https://datatracker.ietf.org/liaison/&gt;</t>
			<t>IETF Intellectual Property Rights Policy and Notices: &lt;http://www.ietf.org/ipr/&gt;</t>
			<t>The Tao of the IETF: &lt;http://www.ietf.org/tao.html&gt;; (A Novice's Guide to the Internet Engineering Task Force)</t>
		
		</section>

       	</section>

    </back>



</rfc>