One document matched: draft-crocker-id-adoption-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline="yes"?>
<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc category="info" docName="draft-crocker-id-adoption-06" ipr="trust200902">
<front>
<title abbrev="Handling of I-Ds by WGs">Handling of Internet Drafts by IETF Working
Group</title>
<author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Juniper Networks</organization>
<address>
<email>adrian@olddog.co.uk</email>
</address>
</author>
<author fullname="Dave Crocker" initials="D." role="editor" surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<date year="2014" />
<area>General</area>
<workgroup />
<keyword>IETF process working group internet draft adoption handling creation</keyword>
<abstract>
<t>The productive output of an IETF working group is documents, as mandated by the working
group's charter. When a working group is ready to develop a particular document, the
most common mechanism is for it to "adopt" an existing document as a starting point. The
document that a working group adopts and then develops further is based on initial input
at varying levels of maturity. An initial working group draft might be a document
already in wide use, or it might be a blank sheet, wholly created by the working group,
or it might represent any level of maturity in between. This document discusses how a
working group typically handles the formal documents that it targets for publication.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>The productive output of an IETF working group is documents, as mandated by the working
group's charter. Working groups develop these documents based on initial input of
varying levels of maturity. An initial working group draft might be a document already
in wide use, or it might be a blank sheet, wholly created by the working group, or it
might represent any level of maturity in between. This document discusses how a working
group typically handles the formal documents that it targets for publication. The
discussion applies only to the IETF and does not cover IRTF groups, where practices vary
widely.</t>
<t>Within the general constraints of formal IETF process and the specific constraints of a
working group's charter, there can be considerable freedom in the adoption and
development of drafts. As with most IETF activities, the ultimate arbiter of such
choices is working group agreement, within the constraints of its charter. As with most
working group management, this agreement might be explicit or implicit, depending upon
the efficiencies that the group deems appropriate.</t>
<t><list style="hanging">
<t hangText="NOTE: ">This draft is intentionally non-normative. It is meant as a
guide to common practice, rather than as a formal definition of what is
permissible.</t>
</list></t>
<section anchor="WhatIs" title="What is a Working Group Draft?">
<t>Working Group drafts are documents that are subject to IETF Working Group revision
control, with advancement for publication as an RFC requiring rough consensus in the
working group. Creation or adoption of a draft by a working group -- as well as
substantive changes to the document -- need to represent working group rough
consensus.</t>
<t>Documents under development in the IETF community are distributed as Internet Drafts
(I-D) <xref target="RFC2026" />, <xref target="ID-Info" />. Working groups use this
mechanism for producing their official output, per Section 7.2 of <xref
target="RFC2418" /> and Section 6.3 of <xref target="Tao" />. The common
convention for identifying an I-D formally under the ownership of a working group is
by the inclusion of "ietf" in the second field of the I-D filename and the working
group name in the third field, per Section 7 of <xref target="ID-Guidelines" />. That
is: <figure>
<artwork align="center"><![CDATA[draft-ietf-<wgname>-...]]></artwork>
</figure></t>
<t>Individual submissions are drafts being created and pursued outside of a working
group, although a working group might choose to adopt the draft later, as discussed
below. Anyone is free to create an individual submission at any time. Such documents
are typically distinguished through the use of the author's last name, in the style
of: <figure>
<artwork align="center"><![CDATA[draft-<lastname>-...]]> </artwork>
</figure></t>
<t>Responsibility for direct revision of a working group I-D is assigned to its editors
and authors. See <xref target="authedit" /> for discussion about their selection and
role.</t>
</section>
<section title="Working Group Authority and Consensus">
<t>A premise of the IETF is that a working group has final authority over the content of
its documents, within the constraints of the working group charter. No individual has
special authority for the content. The chairs assign document authors/editors and can
formulate design teams, but the content of working group documents is always,
ultimately, subject to working group approval. Approval is described in terms of the
IETF's "rough consensus" construct, which is the prime example of the IETF's
preference for pragmatics over niceties. Unanimous agreement is always desirable, but
more approximate (rough) agreement will suffice, as long as it is clear and strong.
Further discussion of the nature of rough consensus can be found in <xref
target="Consensus" />.</t>
<t>Other than for selection of document authors/editors, as discussed in <xref
target="authedit" />, working group decision-making about document management is
subject to normal IETF process rules. Useful descriptions of this process for a
working group are in Section 3.3 of <xref target="RFC2418" /> and Section 4.2 of
<xref target="Tao" />.</t>
<t>In terms of the IETF's formal rough consensus processes, the working group raises and
discusses an item of document content and then determines its rough consensus. For
difficult topics and/or difficult working group dynamics, this laborious process
really is essential, because its diligence validates progress at each step along the
way. However working groups often handle simpler matters more simply, such as having
a Chair assert the likely agreement and merely call for objections. Ultimately, the
mode of working group decision making is determined by the comfort of the working
group with the way the decisions are being made.</t>
<t> At times, a document author/editor can appear to have considerable authority over
content, but this is (merely) for efficiency. That is, the chairs can permit authors
and editors to proceed with an implied (default) working group agreement, as long as
the working group is comfortable with that mode. Of course the benefit in the mode is
efficiency, but its risk is failure to retain or verify actual consensus among the
working group participants. When a working group is operating in the mode of active,
direct author content development, an easy validation method is simply to have chairs
query the working group when a new document version appears, asking for comments and
concerns.</t>
<t>In general when it is not completely obvious what the opinion of the working group
is, working group chairs can poll the working group to find out. As with any other
consensus question, the form in which it is asked can make a difference. In
particular, a general 'yes/no' question often is not as helpful as asking supporters
and detractors of a draft -- or of the decision under consideration -- to provide
their reasons, not merely their preferences. In effect, this treats the matter of
consensus as an on-going discussion. Ideally the discussion can produce changes in
the document or in participant views, or both.</t>
</section>
<section title="Questions Considered in This Document">
<t>The purpose of this document is to discuss the criteria and sequence typically
followed when adopting and developing a formal IETF working group document.
Therefore, this document considers the following questions that are particularly
relevant to working group chairs who are charged with running the process: <list>
<t><list style="symbols">
<t>How do working group chairs decide which drafts to adopt and when? </t>
<t>Is it necessary to poll the working group explicitly, and what does a
working group poll look like?</t>
<t>How do working group chairs make the decision?</t>
<t>What are the process steps the working group will choose to use, for an
I-D to become a WG I-D?</t>
<t>Are there any special cases?</t>
<t>Can a document be created as a WG I-D from scratch?</t>
<t>How can competing drafts be handled?</t>
<t>Can an Individual I-D be under the care of a WG?</t>
<t>Can a WG I-D become an Individual I-D?</t>
</list></t>
</list>
</t>
</section>
</section>
<section title="Adoption Sequence">
<section title="Typical Steps">
<t>When there is an existing document and the chairs want to propose adopting it as a
new working group document, the chairs often: <list>
<t><list style="numbers">
<t>Remind current draft owners that they are transferring change control for
the document to the IETF.</t>
<t>Inform the working group of the intent.</t>
<t>Check for known IPR that needs to be disclosed, using some technique like
those described in <xref target="RFC6702" /></t>
<t>Obtain working group rough consensus.</t>
<t>Choose document editors.</t>
<t>Chairs instruct authors to post WG I-D.</t>
<t>Chairs approve posting.<xref target="Approval" /></t>
<t>Chairs ensure that the non-working group version of the draft is marked
as being replaced by this working group version.</t>
<t>Everyone enjoys the ensuing working group discussion...</t>
</list></t>
</list></t>
</section>
<section title="Criteria for Adoption">
<t>No formal specification for working group 'adoption' of a draft exists; the current
document is meant to provide a description of common activities for this, but again
note that it is not normative.</t>
<t>There are some basic considerations when deciding to adopt a draft:<list>
<t><list style="symbols">
<t>Is there a charter milestone that explicitly calls for such a
document?</t>
<t>Is the topic of the I-D within scope for the working group?</t>
<t>Is the purpose of the draft sufficiently clear?</t>
<t>Does the document provide an acceptable platform for continued effort by
the working group?</t>
<t>What are the process or technical objections to adoption of the
draft?</t>
<t>Is the draft likely to be completed in a timely manner?</t>
<t>Does the intended status of the document seem reasonable to the working
group? </t>
<t>If not already in scope, is a simple modification to the charter feasible
and warranted?</t>
<t>Does the draft carry known intellectual property rights issues?</t>
<t>Is there strong working group support for working on the draft?</t>
</list></t>
</list></t>
<t>Adoption has some basic pragmatics:<list>
<t><list style="hanging">
<t hangText="Rough consensus: ">Working group agreement to adopt is not
required to be unanimous.</t>
<t hangText="Initial, not final: ">The writing quality is not required to be
ready-for-publication, although writing quality can be a problem and does
need explicit attention; although not mandatory, it is good practice to
check whether a new working group draft passes <xref target="IDNITS"
/>.</t>
<t hangText="Adoption, not approval: ">The document is not required to
already contain a complete and/or sufficient solution, although of course
this can be helpful. Equally, adoption by a working group does not
guarantee publication of the document as an RFC.</t>
<t hangText="Group, not chairs: ">Concerning the draft, the position of the
working group chairs has no special authority, except to assess working
group consensus.</t>
</list></t>
</list></t>
<t><list style="hanging">
<t hangText="REMINDER: ">Once a working group adopts a draft, the document is
owned by the working group and can be changed however the working group
decides, within the bounds of IETF process and the working group charter.
Absent explicit agreement, adopting a document does not automatically mean that
the working group has agreed to all of its content. So a working group (or its
charter) might explicitly dictate the basis for retaining, removing or
modifying some or all of a draft's content, technical details, or the like.
However in the absence of such constraints, it is worth having the adoption
process include a sub-process of gathering working group concerns about the
existing draft and flagging them explicitly.</t>
</list></t>
</section>
</section>
<section anchor="authedit" title="Authors/Editors">
<t>Document authors/editors are chosen by the working group chairs. Authors are described
in Section 6.3 of <xref target="RFC2418" />. <list style="hanging">
<t hangText="NOTE: ">The distinction between an 'author' and an 'editor' is, at
best, subjective. A simplistic rule of thumb is that editors tend to do the
mechanics of incorporating working group detail, whereas authors tend to create
the detail, subject to working group approval. That is, one role is more active
with the content and the other is more passive. It is a responsibility of the
working group chairs to ensure that document authors make modifications in accord
with working group rough consensus. Authors serve at the pleasure of the working
group chairs, and are subject to replacement for a variety of reasons.</t>
</list></t>
<t>For existing documents that are being adopted by a working group, there is a special
challenge in the selection of document editors: The document has already had editors. So
the question is whether the same people are appropriate for continuing the task?
Sometimes the answer is yes, but this is not automatic. The process within an IETF
working group can be quite different from the process that created previous versions.
This well might make it appropriate to select one or more new editors, either as
additions to the editor team or as primary pen-holders (effectively re-classifying the
previous team as co-authors). </t>
<t>If the original editors are to continue in their role, the chairs might want to ensure
that the editors understand IETF working group process; it is likely to be quite
different from the process that developed earlier versions of the document. If
additional or new editors are assigned, the transition can be discussed, including its
reasons; this is best done as soon as possible.</t>
</section>
<section title="Document History and Stability">
<t>Working group charters sometimes specify an initial set of existing documents to use as
a basis of the working group's activities. That 'basis' can vary considerably, from
simple input to working group discussion, all the way to an advanced draft adopted by
the working group and subject only to minimal changes. The role of a document should be
explicitly stated in the charter.</t>
<t>Absent charter restrictions, a working group is free to create new documents. It is not
required that all drafts start as the effort of an individual. Of course the criteria
for brand new documents are likely to be the same as for those imported into the working
group with the additional and obvious requirement that the working group chairs will
need to appoint authors/editors before any work can progress. Note that from time to
time a working group will form a design team to produce the first version of a working
group draft. Design teams are discussed in Section 6.5 of <xref target="RFC2418" />.</t>
<t>Work that is brought to the IETF has different levels of completeness and maturity, and
different timings for having achieved those levels. When the IETF charters a group and
includes existing material, the charter can cast the role of that material in very
different ways: <list>
<t><list style="symbols">
<t>It can treat it as no more than a set of ideas, to be used or ignored;</t>
<t>It can treat it as a basic design, with all of the actual details still
fluid;</t>
<t>It can treat it as a rough draft, subject to extensive revision;</t>
<t>It can treat it as a solid specification that merely needs review,
refinement and maybe enhancement;</t>
<t>It can treat it as a deployed technology that is best served by trying to
protect its installed base, but with some tolerance for changes that affect
interoperability;</t>
<t>It can treat it as a deployed technology for which protecting the installed
base is essential, including retention of core interoperability.</t>
</list></t>
</list>These suggest a wide range of possible constraints on working group effort.</t>
<t> Equally, those bringing technology to the IETF do so at different points in the
maturity of their work. Any of the above might make sense, depending upon that maturity,
the extent of deployment, and the timing of the investment made by the installed
base.</t>
<t> When technology is brand new, with at most some prototypes done as proofs of concept,
then significant changes to the specification will not necessarily add much to the
development and deployment costs. However when the technology is part of a mature,
well-deployed market, incompatible changes are likely to be problematic for that market,
which can hinder adoption of the changes.</t>
<t> For example, immediately after the development investment is made -- and especially
when there has been considerable initial deployment -- but still room for quite a bit
more -- the installed and potential base might not take kindly to disruptive standards
work that undermines their recent investment. </t>
<t>In reflecting upon the basis for adopting an existing draft, it is important to consider
the document's place in its lifecycle and the needs of any installed base when deciding
on the constraints to impose on document development.</t>
</section>
<section title="Some Issues for Consideration">
<section title="Individual I-Ds Under WG Care">
<t>Sometimes, a working group facilitates a draft, but does not own it or formally adopt
it. These are "individual" drafts <xref target="Individual" />.</t>
<t>As noted in <xref target="WhatIs" /> and reinforced in <xref target="ID-Guidelines"
/>, the convention for identifying an I-D formally under the ownership of a working
group is by following the naming convention: <figure>
<artwork align="center"><![CDATA[draft-ietf-<wgname>-...]]></artwork>
</figure> By contrast, documents that are still under the control of their authors
are known as "individual" I-Ds. When these documents are intended for consideration
by a specific working group, the convention is that the document uses the naming
convention as follows where the second element is the last name of one of the
principal authors.<figure>
<artwork align="center"><![CDATA[draft-<lastname>-<wgname>...]]></artwork>
</figure>Having the working group name following the personal name allows tools to
associate these drafts with the working group, even though the filename identifies
them as the work of individuals.</t>
<t>Such documents can be handled according to normal, internal working group process
management. However matters of ownership, working group final approval, and the like
are all subject to negotiation amongst the document authors, working group and area
directors.</t>
<t>This is a rare situation and working group chairs can be assured that the Area
Directors will want to understand why the document could not be adopted and owned by
the working group. </t>
</section>
<section title="WG Drafts Can become Individual Drafts">
<t>A working group is not obligated to retain documents it has adopted. Sometimes
working group efforts conclude that a draft is no longer appropriate for working
group effort. If an individual wishes to pursue the document outside of the working
group, the document can be released to them.</t>
</section>
<section title="Competing Drafts">
<t>Engineering for interesting topics often produces competing, interesting proposals.
The reasons can be technical aesthetics, engineering tradeoffs, architectural
differences, company economics and the like. Although it is far more comfortable to
entertain only one proposal, a working group is free to pursue more than one. Often
this is necessary until a clear preference develops. Sometimes, multiple versions are
formally published, absent consensus among the alternatives.</t>
<t>It is appealing to ask authors of competing proposals to find a way to merge their
work. Where it makes sense to do this, it can produce a single, strong specification.
The detailed discussions to merge are often better held in a design team than amidst
the dynamics of an open working group mailing list. The working group has ultimate
authority over any decisions, but it is not required that it be involved in all the
discussions.</t>
<t>On the other hand, some differences cannot be resolved and attempting a merge can
produce a weaker result, as discussed in <xref target="Heli-Sub" />.</t>
<t>Various management efforts can facilitate the handling of competing proposals. Some
examples include: <list>
<t><list style="symbols">
<t>Develop a requirements document that is independent of specific
proposals; this can highlight features that are deemed essential, from
those that are of secondary importance, and facilitate a discussion about
features without reference to specific proposals.</t>
<t>Develop a comparison table of the proposals; this can aid understanding
of their differences.</t>
<t>Discuss the relative importance and effects of having one proposal,
versus multiple; this can focus people's efforts at compromise and
encourage a willingness to choose a single proposal.</t>
</list></t>
</list></t>
<t>The problem of competing drafts can be particularly painful when it arises in either
of two circumstances: <list>
<t><list style="symbols">
<t>If a second proposal appears as a new draft, just as the chairs were
ready to poll the working group on adoption of the draft containing the
first proposal, then the authors of the first proposal could feel
affronted. It does not follow that the second draft was written to be
difficult or derail the first: it might even include better ideas. So it
is best not to disregard it. However, automatically asking the authors to
merge their work will not necessarily produce a more solid solution and
will not guarantee faster progress. This situation will be a judgement
call in each case, and it might help to ask the working group for their
opinion: shall the working group adopt one document as a starting point
and fold in the ideas from the second under the control of consensus, or
shall the working group wait until the authors of both documents have
reached agreement? </t>
<t>If the working group has already adopted an I-D on a specific topic, the
posting of a new individual I-D on the same topic could be seen as an
attack on the working group processes or decisions. However, posting an
I-D is often a good way to put new ideas into concrete form, for public
consideration and discussion. The working group chairs will want to
encourage the working group to consider the new proposal. Shall it be
adopted and entirely replace the current working group draft? Shall the
new ideas be incorporated into the work of the working group through the
normal editorial process? Shall the working group adopt a second
competing solution? Or shall the new draft be rejected and not adopted by
the working group?</t>
</list></t>
</list></t>
</section>
</section>
<section title="Security Considerations">
<t>Beyond the credibility of the IETF, this document raises no security concerns.</t>
</section>
<section title="Acknowledgements">
<t>This draft was developed from an IETF tutorial given by A. Farrel. L. Anderson
contributed useful comments.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor="Farrel-Chairs">
<front>
<title>What is a Working Group ID (and when to adopt one)</title>
<author fullname="A. Farrel" initials="A." surname="Farrel">
<organization>Huawei</organization>
<address>
<email>adrian.farrel@huawei.com</email>
</address>
</author>
<date month="July" year="2010" />
</front>
<seriesInfo name="Web" value="http://wiki.tools.ietf.org/group/edu/wiki/IETF78#" />
</reference>
<reference anchor="RFC2026">
<front>
<title abbrev="Internet Standards Process">The Internet Standards Process -- Revision
3</title>
<author fullname="Scott O. Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address>
</author>
<date month="October" year="1996" />
<abstract>
<t>This memo documents the process used by the Internet community for the
standardization of protocols and procedures. It defines the stages in the
standardization process, the requirements for moving a document between stages
and the types of documents used during this process. It also addresses the
intellectual property rights and copyright issues associated with the standards
process.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="9" />
<seriesInfo name="RFC" value="2026" />
<format octets="86731" target="http://www.rfc-editor.org/rfc/rfc2026.txt" type="TXT" />
</reference>
<reference anchor="RFC2418">
<front>
<title abbrev="IETF Guidelines">IETF Working Group Guidelines and Procedures</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass Ave.</street>
<street>Cambridge</street>
<country>MA</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address>
</author>
<date month="September" year="1998" />
<area>General</area>
<keyword>Internet Engineering Task Force</keyword>
<abstract>
<t> The Internet Engineering Task Force (IETF) has responsibility for developing
and reviewing specifications intended as Internet Standards. IETF activities
are organized into working groups (WGs). This document describes the guidelines
and procedures for formation and operation of IETF working groups. It also
describes the formal relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF participants,
including WG Chairs, WG participants, and IETF Area Directors. </t>
</abstract>
</front>
<seriesInfo name="BCP" value="25" />
<seriesInfo name="RFC" value="2418" />
<format octets="62857" target="http://www.rfc-editor.org/rfc/rfc2418.txt" type="TXT" />
<format octets="77010" target="http://xml.resource.org/public/rfc/html/rfc2418.html"
type="HTML" />
<format octets="62422" target="http://xml.resource.org/public/rfc/xml/rfc2418.xml"
type="XML" />
</reference>
<reference anchor="Tao">
<front>
<title>The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force </title>
<author fullname="P. Hoffman" initials="P." role="editor" surname="Hoffman">
<organization />
</author>
<date year="2012" />
</front>
<seriesInfo name="IETF" value="http://www.ietf.org/tao.html" />
</reference>
<reference anchor="RFC6702">
<front>
<title>Promoting Compliance with Intellectual Property Rights (IPR) Disclosure
Rules</title>
<author fullname="T. Polk" initials="T." surname="Polk">
<organization />
</author>
<author fullname="P. Saint-Andre" initials="P." surname="Saint-Andre">
<organization />
</author>
<date month="August" year="2012" />
<abstract>
<t>The disclosure process for intellectual property rights (IPR) in documents
produced within the IETF stream is essential to the accurate development of
community consensus. However, this process is not always followed by IETF
participants. Regardless of the cause or motivation, noncompliance with IPR
disclosure rules can delay or even derail completion of IETF specifications.
This document describes some strategies for promoting compliance with the IPR
disclosure rules. These strategies are primarily intended for use by area
directors, working group chairs, and working group secretaries. This document
is not an Internet Standards Track specification; it is published for
informational purposes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6702" />
<format octets="35052" target="http://www.rfc-editor.org/rfc/rfc6702.txt" type="TXT" />
</reference>
<reference anchor="ID-Info">
<front>
<title>Checklist for Internet-Drafts (IDs) submitted for RFC publication</title>
<author fullname="B. Wijnen" initials="B." role="editor" surname="Wijnen" />
<date day="12" month="May" year="2009" />
</front>
<seriesInfo name="IETF" value="https://www.ietf.org/id-info/checklist.html" />
</reference>
<reference anchor="IDNITS">
<front>
<title>IDNITS Tool</title>
<author>
<organization>IETF</organization>
</author>
<date year="2013" />
</front>
<seriesInfo name="IETF" value="https://www.ietf.org/tools/idnits/" />
</reference>
<reference anchor="ID-Guidelines">
<front>
<title>Guidelines to Authors of Internet-Drafts</title>
<author fullname="R. Housley" initials="R." role="editor" surname="Housley">
<organization>Vigil Security</organization>
</author>
<date day="7" month="December" year="2010" />
</front>
<seriesInfo name="IETF" value="http://www.ietf.org/ietf-ftp/1id-guidelines.txt" />
</reference>
<reference anchor="Approval">
<front>
<title>IETF Internet-Draft Initial Version Approval Tracker</title>
<author>
<organization>IETF</organization>
</author>
<date />
</front>
<seriesInfo name="IETF"
value="https://datatracker.ietf.org/cgi-bin/wg/wg_init_rev_approval.cgi" />
</reference>
<reference anchor="Heli-Sub">
<front>
<title>On Helicopters and Submarines</title>
<author fullname="M. Rose" initials="M." surname="Rose">
<organization>Invisible Worlds</organization>
</author>
<date />
</front>
<seriesInfo name="ACM Queue - Instant Messaging" value="Vol 1, Issue 8, Page 10" />
<seriesInfo name="ACM" value="http://dl.acm.org/ft_gateway.cfm?id=966726" />
</reference>
<reference anchor="Consensus">
<front>
<title>On Consensus and Humming in the IETF</title>
<author fullname="P. Resnick" initials="P." surname="Resnick" />
<date month="November" year="2013" />
</front>
<seriesInfo name="I-D" value="draft-resnick-on-consensus-06" />
<format target="https://datatracker.ietf.org/doc/draft-resnick-on-consensus/" type="Web"
/>
</reference>
<reference anchor="Individual">
<front>
<title>Guidance on Area Director Sponsoring of Documents</title>
<author fullname="IESG" surname="IESG" />
<date month="March" year="2007" />
</front>
<seriesInfo name="IETF"
value="http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html" />
</reference>
</references>
<section title="IANA Considerations">
<t> There are no requests for IANA.</t>
<t>The RFC Editor should remove this section.</t>
</section>
<section title="Acknowledgements">
<t>This document was based on a presentation made at an IETF Working Group Chairs lunch.
<xref target="Farrel-Chairs" />)</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:57 |