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


<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
 	<!ENTITY RFC4441 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4441.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 RFC6756 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6756.xml'>
]>


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


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


<?rfc toc="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>

        <date month="November" year="2012" />
	<workgroup>Internet Architecture Board</workgroup>

        <abstract>
		<t>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.</t>
	</abstract>


    </front>


    
	<middle>

        <section title="Introduction and Scope">
		<t>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.</t>

		<t>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.</t>

        </section>



        <section title="Guidance on Collaboration">

        	<t>This section describes how the 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 differences.</t>
			
        		<section title="IEEE 802 Organization, Participation and Membership">

				<t>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. </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 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.</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, April and September. The meeting schedule can be 
					found at 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 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).</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.  Contact points on the IEEE side may include:</t>

				<t>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.</t>

				<t><list style="hanging" hangIndent="10">
					<t hangText="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.</t>

					<t hangText="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.</t>

					<t hangText="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.</t>

					<t hangText="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.</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 and IETF projects in an area can also aid in 
						collaboration.</t>
				</list></t>
			</section>

        		<section title="IETF Organization, Participation and Membership">

				<t>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).</t>

				<t>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).</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 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". </t>

                               	<t>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.</t>

				<t>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:</t>

				<t><list style="hanging" hangIndent="10">
					<t hangText="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.</t>

					<t hangText="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.</t>

					<t hangText="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.</t>
				</list></t>

				<t>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/.</t>
			</section>

        		<section anchor="cultdiff" title="Cultural Differences">


				<t>EDITOR'S NOTE: What else do we need to mention here?</t>

				<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" 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.</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,
						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 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.</t>
					<t hangText="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.</t>
					<t hangText="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.</t>
					<t hangText="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.</t>
					<t hangText="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.</t>
				</list></t>
			</section>

        	</section>


        	<section title="Exchange of information about new Work Items">

        		<t>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.</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 (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 <xref target="LS" />).</t>
			</section>
        		<section title="How IETF is informed about active IEEE 802 work items">
				<t>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. </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 https://development.standards.ieee.org/my-site. 
					Access requires an IEEE web account which is free and has no membership requirement. </t>

				<t>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 ... </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="How IEEE 802 is informed about proposed new IETF work items">
				<t>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). </t>

				<t>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.</t>
				
				<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.  Plain-text email is preferred on the IESG mailing
   					list. </t>

   				<t>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.</t>
			</section>
        		<section title="How IETF is informed about proposed new IEEE 802 work items">
				<t>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.</t>

				<t>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.</t>

				<t>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.</t>

				<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. We mention that here, so that readers will know to ask about this.</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, draft 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>

	        		<section title="IEEE 802 Documentation System">
					<t>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.</t>
				</section>

	        		<section title="Access to internal IEEE 802 Working Group Documents">

					<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:
						https://mentor.ieee.org/802". 
						Mentor has some particularly notable aspects:</t>
						<t>EDITOR'S NOTE: We had a suggestion to trim some of this information. Pat to consider 
							and provide revised text.</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>Generally speaking, the archives are publicly and freely 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 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.</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>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.</t>

					<t>Some WGs do not use the Mentor system. In this case, documents are nevertheless generally publically 
						available and indexed. Typically, the index may be presented via a human-managed web site. 
						In such cases, the contributions may be submitted via email to a document manager, 
						so they may not be immediately available to the public. For WGs not using the Mentor system, 
						it should be relatively straightforward to find documents of interest by reviewing the group's 
						main web page. 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.</t>

					<t>In some cases, links to documents may be available only 
						by reviewing the WG or subgroup meeting minutes.</t>
				</section>

	        		<section title="Submission of Contributions to IEEE 802 Working Groups">
					<t>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.</t>
				</section>

	        		<section title="Access to IEEE 802 Working Group Drafts">
					<t>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.</t>
				</section>

	        		<section title="Access to IEEE 802 Standards">
					<t>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.</t>

					<t>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.</t>
				</section>
			</section>

        		<section title="Access to IETF Documents">
				<t>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.</t>

				<t>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.</t>
				<t>It should also 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>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.</t>

        		<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.</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 .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.</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 "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>

				</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. (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).</t>

					<t>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. </t>

					<t>Information about IEEE-SA membership can be found at http://standards.ieee.org/membership/</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. 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.</t>

					<t>The Sponsor Ballot pool is formed from those that accept the invitation during the invitation period. </t>

					<t>Editor's note: add URL for myProject is development.standards.ieee.org to references.</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>

					<t>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</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 BCP-25. The overall IETF standards process is defined in BCP-9.</t>
				<t>As noted in <eref target="cultdiff" />, IETF working groups do not "ballot", but the IESG does, as 
					part of considering 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, 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. 
					The IETF Liaison Manager should provide early notification
					of upcoming Working Group Last Calls and IETF Last Calls, for best results.</t>
			</section>

        	</section>

        	<section title="Expert Review Processes">

			<t>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.</t>

			<t>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".</t>

   			<t>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.</t>

        	</section>

        	<section title="Liaison Officials and Liaison Statements">

			<t>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. :-)</t>

        		<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.</t>

			<t>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 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.</t>
			
        		<section title="Liaison Officials">
				<t>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.</t>
			</section>

        		<section anchor="LS" title="Liaison Statements">
				<t>The IETF process for sending and receiving liaison statements is defined at http://tools.ietf.org/html/rfc4053.</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 meeting 
			and by generating comments on drafts which are compiled with responses in comment resolution documents.</t>

		<t>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</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 and therefore do not have issues with cross-referencing each other's standards.</t>

		<t>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. </t>

		<t>IEEE standards may reference draft standards that are dated, readily available and retrievable, 
			but this should be avoided if at all possible. </t>

		<t>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 ... </t>

		<t>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.</t>

		<t>Informative references in IEEE Standards are placed in a bibliograpy, so may point to either approved IETF standards or 
			IETF Internet-Drafts, if necessary.</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 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).</t>

       		</section>

        	<section title="IEEE Registration Authority">

        		<t>EDITOR'S NOTE: This section is on one (important) specific example - do we need text that describes 
				the RAC and general operation first?</t>

			<t>EDITOR'S NOTE: Eric suggested asking Glenn Parson to provide text here.</t>

			<t>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].</t>

			<t>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.</t>


			<t>EDITOR'S NOTE: Need to mention OUIs, and that IANA has only one?</t>
        	</section>

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

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

        	</section>



        	<section title="Pointers to Additional Useful Information">

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

			
        		<section title="IEEE 802 Information that may be useful to IETF participants">
				<t>IEEE Home Page: http://ieee802.org/</t>
				<t>IEEE 802 policies and procedures: http://ieee802.org/devdocs.shtml"</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 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: ftp://ftp.ietf.org/rfc/rfc-index.txt</t>
				<t>Current list and description of all IETF Internet-Drafts: ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt</t>
				<t>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.)</t>
				<t>Current list of registered BOFs: http://trac.tools.ietf.org/bof/trac/</t>
				<t>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.</t>
				<t>Current list of liaison statements: https://datatracker.ietf.org/liaison/</t>
				<t>IETF Intellectual Property Rights Policy and Notices: http://www.ietf.org/ipr/</t>
				<t>The Tao of the IETF: http://www.ietf.org/tao.html (A Novice's Guide to the Internet Engineering Task Force)</t>
		
			</section>

        	</section>
        </section>


        <section title="IANA Considerations">

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



        <section title="Security Considerations">

        	<t>Documents that describe cooperation procedures, like this one does,
   			have no direct Internet security implications.</t>

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


        <section title="Acknowledgements">

        	<t>This document borrows massive amounts of text, including 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>
        </section>



    </middle>

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


        <references title='Informative References'>
		&RFC4441;
	</references>



	<section title="Changes since RFC4441">
		<t></t>
	</section>

	<section title="Current examples of this relationship">
		<t></t>
		<section title="MIB Review">
			<t>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.</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 to IEEE 802 is documented in 
				[RFC4663] and in [I-D ETHERNET-MIB-TRANSFER].</t>
		</section>
	</section>

	<section title="History of the IEEE 802 / IETF relationship">
		<t>MIB review, EAP review, and AAA review should be here, along with an updated version of Appendix A from 4441</t>

	</section>

    </back>



</rfc>