Creating an IETF Working Group Draft
draft-crocker-id-adoption-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7221.
|
|
|---|---|---|---|
| Authors | Adrian Farrel , Dave Crocker | ||
| Last updated | 2013-09-19 | ||
| RFC stream | (None) | ||
| Formats | |||
| Reviews | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Became RFC 7221 (Informational) | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-crocker-id-adoption-03
Network Working Group A. Farrel
Internet-Draft Juniper Networks
Intended status: Informational D. Crocker, Ed.
Expires: March 24, 2014 Brandenburg InternetWorking
September 20, 2013
Creating an IETF Working Group Draft
draft-crocker-id-adoption-03
Abstract
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 typicals aspects of a working
group's handling of its formal documents, which are targeted for
publication.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 24, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Farrel & Crocker Expires March 24, 2014 [Page 1]
Internet-Draft Creating an IETF Working Group Draft September 2013
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What is a Working Group Draft? . . . . . . . . . . . . . 3
1.2. Working Group Authority and Consensus . . . . . . . . . . 3
1.3. Questions Considered in This Document . . . . . . . . . . 4
2. Adoption Sequence . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Typical Steps . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Criteria for Adoption . . . . . . . . . . . . . . . . . . 5
3. Authors/Editors . . . . . . . . . . . . . . . . . . . . . . . 7
4. Document History and Stability . . . . . . . . . . . . . . . 7
5. Some Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Individual I-Ds Under WG Care . . . . . . . . . . . . . . 9
5.2. Competing Drafts . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. References - Informative . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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 sequence often applied when
adopting and developing formal IETF working group drafts, which are
targeted for publication. The discussion applies only to the IETF
and does not cover IRTF groups, where practices vary widely.
Farrel & Crocker Expires March 24, 2014 [Page 2]
Internet-Draft Creating an IETF Working Group Draft September 2013
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.
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.
1.1. What is a Working Group Draft?
Working Group drafts are documents that are subject to IETF Working
Group revision control. Adoption of the draft by the working group,
and substantive changes to the document, need to represent working
group rough consensus.
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 [RFC2418] and
Section 8.3 of [RFC4677] and [ID-Info]. 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
[ID-Guidelines]. That is:
draft-ietf-<wgname>-...
Responsibility for direct revision of a working group I-D is assigned
to its authors. See Section 3 for discussion about their selection
and role.
1.2. Working Group Authority and Consensus
Farrel & Crocker Expires March 24, 2014 [Page 3]
Internet-Draft Creating an IETF Working Group Draft September 2013
A core premise of IETF working groups is that the 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 task 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.
Other than for selection of document authors, as discussed in
Section 3, 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 [RFC2418] and
Section 5.2 of [RFC4677].
In formal terms, a working group raises and discusses each item of
document content. For difficult topics and/or difficult working
group dynamics, this is the required mode. It is laborious, but
diligent, and it validates progress at each step along the way.
At times a document author can appear to have considerable authority
over content, but this is (merely) for efficiency. That is, the
chairs can permit authors 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.
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 to provide their reasons, not merely their preferences.
In effect, this treats the matter of consensus as an on-going
discussion. Ideally, that can produce changes in the document or in
participant views, or both.
1.3. Questions Considered in This Document
The purpose of this document is to discuss the criteria and sequence
typically followed when adopting and developing a formal IETF working
Farrel & Crocker Expires March 24, 2014 [Page 4]
Internet-Draft Creating an IETF Working Group Draft September 2013
group document. Therefore, this document considers the following
questions that are particularly relevant to working group chairs who
are charged with running the process:
* How do working group chairs decide which drafts to adopt and
when?
* Is it necessary to poll the working group explicitly, and what
does a working group poll look like?
* How do working group chairs make the decision?
* What are the process steps the working group will choose to
use, for an I-D to become a WG I-D?
* Are there any special cases?
* Can a document be created as a WG I-D from scratch?
* How can competing drafts be handled?
* Can an Individual I-D be under the care of a WG?
2. Adoption Sequence
2.1. Typical Steps
To adopt a new working group document, the chairs often:
1. Inform the working group of the intent.
2. Obtain working group rough consensus.
3. Choose document editors.
4. Pre-approve the document as an Internet Draft, using
[Approval].
5. Tell the editors to submit the -00 version of the document.
6. Enjoy the ensuing working group discussion...
2.2. Criteria for Adoption
Farrel & Crocker Expires March 24, 2014 [Page 5]
Internet-Draft Creating an IETF Working Group Draft September 2013
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.
There are some basic considerations when deciding to adopt a draft:
* Is there a charter milestone that explicitly calls for such a
document?
* Is the topic of the I-D within scope for the working group?
* Is the purpose of the draft sufficiently clear?
* What are the process or technical objections to pursuing the
draft?
* If not already in scope, is a simple modification to the
charter feasible and warranted?
* Does the draft carry known intellectual property rights issues?
* Is there strong working group support for working on the draft?
Some specifically-inappropriate criteria include:
* Working group support is not required to be unanimous.
* 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
needs to at least pass [IDNITS].
* The document is not required to already contain a complete and/
or sufficient solution, although of course this can be helpful.
* The position of the working group chairs, concerning the draft,
has no special authority.
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
Farrel & Crocker Expires March 24, 2014 [Page 6]
Internet-Draft Creating an IETF Working Group Draft September 2013
dictate retaining 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.
3. Authors/Editors
Document authors/editors are chosen by the working group chairs.
Authors are described in Section 6.3 of [RFC2418].
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 who
demonstrate sustained misunderstanding of their authority are
subject to replacement...
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? Often 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).
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 quickly as possible.
4. Document History and Stability
Working group charters often specify an initial set of existing
documents to use. The basis of that use can vary widely. Documents
that are used as 'input' or as 'a basis' to the working group's
efforts. 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,
Farrel & Crocker Expires March 24, 2014 [Page 7]
Internet-Draft Creating an IETF Working Group Draft September 2013
concerning adoption of drafts and the constraints on changes made to
them.
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 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 [RFC2418].
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:
o It can treat it as no more than a set of ideas, to be used or
ignored;
o It can treat it as a basic design, with all of the actual details
still fluid;
o It can treat it as a rough draft, subject to extensive revision;
o It can treat it as a solid specification that merely needs review,
refinement and maybe enhancement;
o 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;
o It can treat it as a deployed technology for which protecting the
installed base is essential, including retention of core
interoperability.
These suggest a wide range of possible constraints on working group
effort.
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.
When technology is brand new, with at most some prototypes done as
proofs of concept, then significant changes to the spec won't
necessarily add much to the development and deployment costs. On the
Farrel & Crocker Expires March 24, 2014 [Page 8]
Internet-Draft Creating an IETF Working Group Draft September 2013
other extreme, a mature, deployed market can be almost cavalier about
the freedom of a working group charter, because its base of
experience is sufficient to hold sway over a working group that gets
silly: that is, the installed base is sufficiently well-established
and unified in what it will accept, so that it's leverage is clear.
However, 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
will not take kindly to disruptive standards work that undermines
their recent investment; worse, such work can seriously damage
further adoption.
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.
5. Some Issues
5.1. Individual I-Ds Under WG Care
Although rare, a working group sometimes 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:
draft-<lastname>-<wgname>...
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 might be the case that the working group
has consensus that the document will be published as an RFC, but not
have agreement about the text in the document.
Of course, the author and the working group might decide to change
the document's status, such as making it a formal working group
draft, or publish it along a different RFC stream or submission path.
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.
5.2. Competing Drafts
Farrel & Crocker Expires March 24, 2014 [Page 9]
Internet-Draft Creating an IETF Working Group Draft September 2013
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.
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. [Heli-Sub] 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 has ultimate authority to approve any
decisions, but it is not required that it be involved in all the
discussions.
Various management efforts can facilitate the handling of competing
proposals. Some examples include:
* 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.
* Develop a comparison table of the proposals; this can aid
understanding of their differences.
* 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.
The problem of competing drafts can be particularly painful when it
arises in either of two circumstances:
* 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
Farrel & Crocker Expires March 24, 2014 [Page 10]
Internet-Draft Creating an IETF Working Group Draft September 2013
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?
* 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. 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?
6. Security Considerations
Beyond the credibility of the IETF, this document raises no security
concerns.
7. Acknowledgements
This draft was developed from an IETF tutorial given by A. Farrel.
L. Anderson contributed useful comments.
8. References - Informative
[Approval]
IESG, "IETF Internet-Draft Initial Version Approval
Tracker", IETF https://datatracker.ietf.org/cgi-bin/wg/
wg_init_rev_approval.cgi, .
[Farrel-Chairs]
Farrel, A., "What is a Working Group ID (and when to adopt
one)", Web
http://wiki.tools.ietf.org/group/edu/wiki/IETF78#, July
2010.
Farrel & Crocker Expires March 24, 2014 [Page 11]
Internet-Draft Creating an IETF Working Group Draft September 2013
[Heli-Sub]
Rose, M., "On Helicopters and Submarines", ACM Queue -
Instant Messaging Vol 1, Issue 8, Page 10, ACM
http://dl.acm.org/ft_gateway.cfm?id=966726, .
[ID-Guidelines]
Housley, R., Ed., "Guidelines to Authors of Internet-
Drafts", IETF
http://www.ietf.org/ietf-ftp/1id-guidelines.txt, December
2010.
[ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs)
submitted for RFC publication", IESG https://www.ietf.org/
id-info/checklist.html, May 2009.
[IDNITS] IETF, "IDNITS Tool", IETF https://www.ietf.org/tools/
idnits/, .
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC4677] Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
Guide to the Internet Engineering Task Force", RFC 4677,
September 2006.
Appendix A. Acknowledgements
This document was based on a presentation made at an IETF Working
Group Chairs lunch. [Farrel-Chairs])
Authors' Addresses
Adrian Farrel
Juniper Networks
Email: adrian@olddog.co.uk
Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
Farrel & Crocker Expires March 24, 2014 [Page 12]