Creating an IETF Working Group Draft
draft-crocker-id-adoption-01
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 | 2012-12-02 | ||
| 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-01
Network Working Group A. Farrel
Internet-Draft Juniper Networks
Intended status: Informational D. Crocker, Ed.
Expires: June 5, 2013 Brandenburg InternetWorking
December 2, 2012
Creating an IETF Working Group Draft
draft-crocker-id-adoption-01
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 the process of creating formal
working group drafts that 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 June 5, 2013.
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
Farrel & Crocker Expires June 5, 2013 [Page 1]
Internet-Draft Creating an IETF Working Group Draft December 2012
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is a Working Group Draft? . . . . . . . . . . . . . . 3
1.2. Questions Considered in This Document . . . . . . . . . . 4
2. Adoption Process . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Criteria for Adoption . . . . . . . . . . . . . . . . . . 4
2.2. Polling the Working Group . . . . . . . . . . . . . . . . 6
2.3. Chosing Editors . . . . . . . . . . . . . . . . . . . . . 6
2.4. Formal Steps . . . . . . . . . . . . . . . . . . . . . . . 7
3. Competing Drafts . . . . . . . . . . . . . . . . . . . . . . . 7
4. Individual I-Ds Under WG Care . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References - Informative . . . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Farrel & Crocker Expires June 5, 2013 [Page 2]
Internet-Draft Creating an IETF Working Group Draft December 2012
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 process for adopting and
developing formal working group drafts that are targeted for
publication.
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.
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.
[[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 ]]
1.1. What is a Working Group Draft?
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, often called editors, as described in Section 6.3 of
[RFC2418].
Farrel & Crocker Expires June 5, 2013 [Page 3]
Internet-Draft Creating an IETF Working Group Draft December 2012
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.
1.2. Questions Considered in This Document
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:
* How do working group chairs decide which drafts to adopt and
when?
* Is it necessary to poll the working group, and what does a
working group poll look like?
* How do working group chairs make the decision?
* What are the process steps 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 should competing drafts be handled?
* Can an Individual I-D be under the care of a WG?
2. Adoption Process
2.1. Criteria for Adoption
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
Farrel & Crocker Expires June 5, 2013 [Page 4]
Internet-Draft Creating an IETF Working Group Draft December 2012
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 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 the draft?
* What is the position of the working group chairs, concerning
the draft?
+ [[editor note: I am not sure this is relevant. Indeed is
might be specifically not relevant. /a]]
Some specifically-inappropriate criteria should be noted:
* 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
should 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.
Farrel & Crocker Expires June 5, 2013 [Page 5]
Internet-Draft Creating an IETF Working Group Draft December 2012
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.
2.1.1. Going Straight to WG I-D
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 [RFC2418].
2.2. Polling the Working Group
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 [RFC2418] and Section 5.2 of [RFC4677].
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.
2.3. Chosing Editors
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).
Farrel & Crocker Expires June 5, 2013 [Page 6]
Internet-Draft Creating an IETF Working Group Draft December 2012
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.
2.4. Formal Steps
To adopt a new working group document, the chairs need to:
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...
3. Competing Drafts
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 must approve any decisions, but it is not
required that it be present for all discussions.
Farrel & Crocker Expires June 5, 2013 [Page 7]
Internet-Draft Creating an IETF Working Group Draft December 2012
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:
1. 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?
2. 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
Farrel & Crocker Expires June 5, 2013 [Page 8]
Internet-Draft Creating an IETF Working Group Draft December 2012
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?
4. Individual I-Ds Under WG Care
[[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]]
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:
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 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.
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. Security Considerations
Beyond the credibility of the IETF, this document raises no security
concerns.
6. 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 June 5, 2013 [Page 9]
Internet-Draft Creating an IETF Working Group Draft December 2012
[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
Farrel & Crocker Expires June 5, 2013 [Page 10]
Internet-Draft Creating an IETF Working Group Draft December 2012
Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
Farrel & Crocker Expires June 5, 2013 [Page 11]