One document matched: draft-crocker-id-adoption-01.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-01"
ipr="trust200902">
<front>
<title>Creating an IETF Working Group Draft</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
month="December"
year="2012"></date>
<area>General</area>
<workgroup></workgroup>
<keyword>IETF process working group draft adoption creation</keyword>
<abstract>
<t>The productive output of IETF working groups is documents, as
mandated by the working group's charter. When a working group is
ready to develop a particular document it usually "adopts" it as a
working group draft. 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 the process of creating formal
working group drafts that are targeted for publication. </t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>The productive output of IETF working groups 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 the criteria and process for
adopting and developing formal working group drafts that are
targeted for publication. </t>
<t>Within the general constraints of formal IETF process and the
specific constraints of a working group's charter, there is
considerable freedom in the adoption and development of drafts. As
with most IETF processes, the ultimate arbiter of such choices is
working group agreement. As with most working group management, this
agreement might be explicit or implicit, depending upon the process
efficiencies that are deemed appropriate.</t>
<t>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. <list>
<t>[[editor's note: Working Group Guidelines and Procedures is a
BCP. The current document /could/ serve to amend that
document; or it could be left as merely non-normative
commentary. /d ]]</t>
</list></t>
<section
title="What is a Working Group Draft?">
<t>Documents under development in the IETF community are distributed
as Internet Drafts (I-D). Working groups use this mechanism for
producing their official output, per Section 7.2 of <xref
target="RFC2418"></xref> and Section 8.3 of <xref
target="RFC4677"></xref> and <xref
target="ID-Info"></xref>. The 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"></xref>. That is: <figure>
<artwork>
<![CDATA[draft-ietf-<wgname>-...]]></artwork>
</figure></t>
<t>Responsibility for direct revision of a working group I-D is
assigned to its authors, often called editors, as described in
Section 6.3 of <xref
target="RFC2418"></xref>. <list
style="hanging">
<t
hangText="NOTE: ">The distinction between an 'author' and
an 'editor' is, at best, subjective. Whatever the label, in
all cases, formal authority for content in a working group
draft remains with the entire working group. Choices are
ultimately controlled by the usual working group rough
consensus process. At times a document author can appear to
have considerable authority over content, but this is
(merely) for efficiency.</t>
</list></t>
</section>
<section
title="Questions Considered in This Document">
<t>The purpose of this document is to discuss the criteria and
processes for adopting a document into a working group as a
formal 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, 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 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 should competing drafts be handled?</t>
<t>Can an Individual I-D be under the care of a WG?</t>
</list></t>
</list>
</t>
</section>
</section>
<section
title="Adoption Process">
<section
title="Criteria for Adoption">
<t>Working group charters often specify documents that are used as
'input' or as 'a basis' to the working group's efforts, with the
milestones typically detailing an exact set of documents to be
produced. In some cases, a charter essentially declares an
existing document to be the formal start of a working group
document. The details can vary quite a bit over the life of a
working group, concerning adoption of drafts. 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 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>What are the process or technical objections to
pursuing the draft?</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 the
draft?</t>
<t>What is the position of the working group chairs,
concerning the draft?<list>
<t>[[editor note: I am not sure this is relevant.
Indeed is might be specifically not relevant.
/a]]</t>
</list></t>
</list></t>
</list></t>
<t>Some specifically-inappropriate criteria should be noted:<list>
<t><list
style="symbols">
<t>Working group support is not required to be
unanimous.</t>
<t>The writing quality is not required to be
ready-for-publication, although writing quality can
be a problem and does need explicit attention;
certainly a new working group draft should at least
pass <xref
target="IDNITS"></xref>.</t>
<t>The document is not required to already contain a
complete and/or sufficient solution, although of
course this can be helpful.</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. It is
a responsibility of the working group chairs to ensure that
document authors make modifications in accord with working
group rough consensus.</t>
</list></t>
<section
title="Going Straight to WG I-D">
<t>Absent charter restrictions, a working group is free to create
new documents. It is not required that all drafts start
outside the working group. Of course, the criteria for brand
new documents needs 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"></xref>.</t>
</section>
</section>
<section
title="Polling the Working Group">
<t>Other than for selection of document authors, 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"></xref> and Section 5.2 of <xref
target="RFC4677"></xref>.</t>
<t>Thus, when it is not completely obvious what the opinion of the
working group is, working group chairs should 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 to provide their reasons,
not merely their preferences. In effect, this treats the
consensus process as an on-going discussion. Ideally, that can
produce changes in the document or in participant views, or
both.</t>
</section>
<section
title="Chosing Editors">
<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 should continue the task? Often the
answer is yes, but it should not be 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 will continue, the chairs need 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 needs to be discussed, including its
reasons; this should be done as quickly as possible.</t>
</section>
<section
title="Formal Steps">
<t>To adopt a new working group document, the chairs need to: <list>
<t><list
style="numbers">
<t>Inform the working group of the intent.</t>
<t>Obtain working group rough consensus.</t>
<t>Choose document editors.</t>
<t>Pre-approve the document as an Internet Draft, using <xref
target="Approval"></xref>.</t>
<t>Tell the editors to submit the -00 version of the
document.</t>
<t>Enjoy the ensuing working group discussion...</t>
</list></t>
</list></t>
</section>
</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. On the other hand, some differences
cannot be resolved and attempting a merge can produce a weaker
result. <xref
target="Heli-Sub"></xref> Some would argue that this is the more
common outcome. At the least, detailed discussions to merge are
better held in private than amidst the dynamics of an open working
group mailing list. The working group must approve any decisions,
but it is not required that it be present for all discussions.</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="numbers">
<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 should not be disregarded. 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 may help to ask
the working group for their opinion: should the working
group adopt one document as a starting point and fold in
the ideas from the second under the control of
consensus, or should 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 and
into the public domain for consideration and discussion.
The working group chairs will want to encourage the
working group to consider the new proposal. Should it be
adopted and entirely replace the current working group
draft? Should the new ideas be incorporated into the
work of the working group through the normal editorial
process? Should the working group adopt a second
competing solution? Or should the new draft be rejected
and not adopted by the working group?</t>
</list></t>
</list></t>
</section>
<section
title="Individual I-Ds Under WG Care">
<t><list>
<t>[[Editor's note: I can't find an explicit description of
Individual vs. Working group draft. Some pages/docs imply the
distinction, but not define it. /d]]</t>
</list></t>
<t>Sometimes, a working group facilitates a draft, but does not own it.
These are "individual" drafts, with a common filename convention of
the working group name following the personal name: <figure>
<artwork><![CDATA[draft-<lastname>-<wgname>...]]></artwork>
</figure></t>
<t>Typically such documents are subject to normal working group
process. However ownership stays with the original author and the
document is not formally working group output. In these situations,
when publication is requested, it may be the case that the working
group has consensus that the document should be published as an RFC,
but not have agreement about the text in the document.</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="Security Considerations">
<t>Beyond the credibility of the IETF, this document raises no security
concerns.</t>
</section>
</middle>
<back>
<references
title="References - Informative">
<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"></date>
</front>
<seriesInfo
name="Web"
value="http://wiki.tools.ietf.org/group/edu/wiki/IETF78#"></seriesInfo>
</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"></date>
<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>
<seriesInfo
name="RFC"
value="2418"></seriesInfo>
<format
octets="62857"
target="http://www.rfc-editor.org/rfc/rfc2418.txt"
type="TXT"></format>
<format
octets="77010"
target="http://xml.resource.org/public/rfc/html/rfc2418.html"
type="HTML"></format>
<format
octets="62422"
target="http://xml.resource.org/public/rfc/xml/rfc2418.xml"
type="XML"></format>
</reference>
<reference
anchor="RFC4677">
<front>
<title>The Tao of IETF - A Novice's Guide to the Internet
Engineering Task Force</title>
<author
fullname="P. Hoffman"
initials="P."
surname="Hoffman">
<organization></organization>
</author>
<author
fullname="S. Harris"
initials="S."
surname="Harris">
<organization></organization>
</author>
<date
month="September"
year="2006"></date>
<abstract>
<t>This document describes the inner workings of IETF meetings
and Working Groups, discusses organizations related to the
IETF, and introduces the standards process. It is not a
formal IETF process document but instead an informational
overview. This memo provides information for the Internet
community.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4677"></seriesInfo>
<format
octets="127383"
target="http://www.rfc-editor.org/rfc/rfc4677.txt"
type="TXT"></format>
</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"></author>
<date
day="12"
month="May"
year="2009"></date>
</front>
<seriesInfo
name="IESG"
value="https://www.ietf.org/id-info/checklist.html"></seriesInfo>
</reference>
<reference
anchor="IDNITS">
<front>
<title>IDNITS Tool</title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
<seriesInfo
name="IETF"
value="https://www.ietf.org/tools/idnits/"></seriesInfo>
</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"></date>
</front>
<seriesInfo
name="IETF"
value="http://www.ietf.org/ietf-ftp/1id-guidelines.txt"></seriesInfo>
</reference>
<reference
anchor="Approval">
<front>
<title>IETF Internet-Draft Initial Version Approval
Tracker</title>
<author>
<organization>IESG</organization>
</author>
<date></date>
</front>
<seriesInfo
name="IETF"
value="https://datatracker.ietf.org/cgi-bin/wg/wg_init_rev_approval.cgi"></seriesInfo>
</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></date>
</front>
<seriesInfo
name="ACM Queue - Instant Messaging"
value="Vol 1, Issue 8, Page 10"></seriesInfo>
<seriesInfo
name="ACM"
value="http://dl.acm.org/ft_gateway.cfm?id=966726"></seriesInfo>
</reference>
</references>
<section
title="Acknowledgements">
<t>This document was based on a presentation made at an IETF Working
Group Chairs lunch. <xref
target="Farrel-Chairs"></xref>)</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:26:57 |