Internet DRAFT - draft-crocker-id-adoption
draft-crocker-id-adoption
Network Working Group A. Farrel
Internet-Draft Juniper Networks
Intended status: Informational D. Crocker, Ed.
Expires: August 11, 2014 Brandenburg InternetWorking
February 7, 2014
Handling of Internet Drafts by IETF Working Groups
draft-crocker-id-adoption-09
Abstract
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.
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 August 11, 2014.
Copyright Notice
Copyright (c) 2014 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 August 11, 2014 [Page 1]
Internet-Draft Handling of I-Ds by WGs February 2014
(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 . . . . . . . . . . 5
2. Adoption Sequence . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Common Steps . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Criteria for Adoption . . . . . . . . . . . . . . . . . . 6
3. Authors/Editors . . . . . . . . . . . . . . . . . . . . . . . 7
4. Document History and Stability . . . . . . . . . . . . . . . 8
5. Some Issues for Consideration . . . . . . . . . . . . . . . . 10
5.1. Individual I-Ds Under WG Care . . . . . . . . . . . . . . 10
5.2. WG Drafts Can become Individual Drafts . . . . . . . . . 11
5.3. Competing Drafts . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. Informative References . . . . . . . . . . . . . . . . . . . 13
Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 14
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
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.
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
Farrel & Crocker Expires August 11, 2014 [Page 2]
Internet-Draft Handling of I-Ds by WGs February 2014
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, with advancement for publication as an RFC
requiring rough consensus in the working group and then in the
broader IETF. 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.
Documents under development in the IETF community are distributed as
Internet Drafts (I-D) [RFC2026], [ID-Info]. Working groups use this
mechanism for producing their official output, per Section 7.2 of
[RFC2418] and Section 6.3 of [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
[ID-Guidelines]. That is:
draft-ietf-<wgname>-...
In contrast, 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/editor's last
name, in the style of:
draft-<lastname>-...
(Also see Section 5.1 for an elaboration on this naming.)
Responsibility for direct revision of a working group I-D is assigned
to its editors and authors. See Section 3 for discussion about their
selection and role.
1.2. Working Group Authority and Consensus
A premise of the IETF is that, within a working group, it is the
working group itself that has final authority over the content of its
documents, within the constraints of the working group's charter. No
Farrel & Crocker Expires August 11, 2014 [Page 3]
Internet-Draft Handling of I-Ds by WGs February 2014
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.
Other than for selection of document authors/editors, as discussed in
Section 3, working group decision-making about document management is
subject to normal IETF rough consensus rules. Useful descriptions of
this process for a working group are in Section 3.3 of [RFC2418] and
Section 4.2 of [Tao]. Discussion of the nature of rough consensus
can be found in [Consensus].
In terms of the IETF's formal rough consensus processes, the working
group explicitly develops, modifies, reviews, and approves document
content, according to overt rough consensus. For difficult topics
and/or difficult working group dynamics, this laborious process
really is essential. Its diligence validates progress at each step
along the way. However working groups often handle simpler matters
more simply, such as allowing a Chair to assert the likely agreement
and then merely call for objections. Ultimately, the mode of working
group decision making is determined by the comfort and engagement of
the working group with the way the decisions are being made.
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/
editor 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 -- 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
Farrel & Crocker Expires August 11, 2014 [Page 4]
Internet-Draft Handling of I-Ds by WGs February 2014
discussion 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
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?
* Can a WG I-D become an Individual I-D?
2. Adoption Sequence
2.1. Common Steps
When there is interest in adopting a document as a new working group
document, the chairs often:
1. Remind current draft owners that they are transferring change
control for the document to the IETF. (This is a particularly
significant point for a document covered by proprietary
interests, which typically entails a negotiation between the
current owners and the IETF, including a formal agreement.)
Farrel & Crocker Expires August 11, 2014 [Page 5]
Internet-Draft Handling of I-Ds by WGs February 2014
2. Check for known IPR that needs to be disclosed, using some
technique like those described in [RFC6702]
3. Obtain working group rough consensus.
4. Choose document editors.
5. Chairs instruct authors to post WG I-D.
6. Chairs approve posting.[Approval]
7. Chairs ensure that the non-working group version of the draft
is marked as being replaced by this working group version.
8. Everyone enjoys the ensuing working group discussion...
2.2. Criteria for Adoption
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?
* Does the document provide an acceptable platform for continued
effort by the working group?
* What are the process or technical objections to adoption of the
draft?
* Is the draft likely to be completed in a timely manner?
* Does the intended status of the document seem reasonable to the
working group?
* If not already in scope, is a simple modification to the
charter feasible and warranted?
* Does the draft carry known intellectual property rights issues?
Farrel & Crocker Expires August 11, 2014 [Page 6]
Internet-Draft Handling of I-Ds by WGs February 2014
* Is there strong working group support for working on the draft?
Adoption has some basic pragmatics:
Rough consensus: Working group agreement to adopt is not
required to be unanimous. [RFC2418]
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 [IDNITS].
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.
Group, not chairs: Concerning the draft, the position of the
working group chairs has no special authority, except to assess
working group consensus.
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.
3. Authors/Editors
Document authors/editors are chosen by the working group chairs.
Authors are described in Section 6.3 of [RFC2418]. Authors and
editors are described in [RFC-Auth-Ed].
NOTE: In this document, the terms 'author' and 'editor' are meant
interchangeably. Within the IETF the distinction between an
'editor' 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
Farrel & Crocker Expires August 11, 2014 [Page 7]
Internet-Draft Handling of I-Ds by WGs February 2014
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/editors are solely chosen by the chairs
-- although the views of the working group should be considered --
and are subject to replacement for a variety of reasons, as the
chairs see fit.
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).
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.
4. Document History and Stability
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.
Within the scope of its charter, 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 [RFC2418].
Work that is brought to the IETF has different levels of completeness
and maturity, and different timings for having achieved those levels.
Farrel & Crocker Expires August 11, 2014 [Page 8]
Internet-Draft Handling of I-Ds by WGs February 2014
When the IETF charters a group and includes existing material, the
charter can cast the role of that material in very different ways:
* It can treat it as no more than a set of ideas, to be used or
ignored;
* It can treat it as a basic design, with all of the actual
details still fluid;
* It can treat it as a rough draft, subject to extensive
revision;
* It can treat it as a solid specification that merely needs
review, refinement and maybe enhancement;
* 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;
* 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. Technology is brought to the IETF at different points of
maturity along its lifecycle and the nature of the technology can
have widely varying utility in developing an Internet standard.
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 already part of a mature and extensive
operational deployment, incompatible changes are likely to be
problematic for that market, which can hinder adoption of the
changes. 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.
Conversely, even a deployed technology with a solid base might be
inappropriate to deploy at Internet scale, and while a document
specifying such a technology might serve as a good starting point on
which to base a new specification, undermining of the deployed base
might be completely appropriate.
Farrel & Crocker Expires August 11, 2014 [Page 9]
Internet-Draft Handling of I-Ds by WGs February 2014
In reflecting upon the basis for adopting an existing draft and the
way it will be used by the working group, it is important to consider
the document's place in its lifecycle, the needs of any installed
base, and the applicability of the draft's technology, when deciding
on the constraints to impose on document development. It will all
depend on the constraints of the charter and the analysis of the
working group.
5. Some Issues for Consideration
5.1. Individual I-Ds Under WG Care
Sometimes, a working group facilitates a draft, but does not own it
or formally adopt it. These are "individual" drafts [Individual].
As noted in Section 1.1 and reinforced in [ID-Guidelines], the
convention for identifying an I-D formally under the ownership of a
working group is by following the naming convention:
draft-ietf-<wgname>-...
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.
draft-<lastname>-<wgname>...
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.
The working group can choose to apply any of its normal, internal
working group process management mechanisms to an Individual I-D.
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.
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.
Farrel & Crocker Expires August 11, 2014 [Page 10]
Internet-Draft Handling of I-Ds by WGs February 2014
5.2. WG Drafts Can become Individual Drafts
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 a working group drops a
draft then anyone is permitted to pursue it as an Individual or
Independent Submission, subject to the document's existing copyright
constraints.
5.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. 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.
On the other hand, some differences cannot be resolved and attempting
a merge can produce a weaker result. An example of this problem of
conflicting design goals is discussed in [Heli-Sub], noting:
"Helicopters are great, and so are submarines. The problem is
that if you try to build one vehicle to perform two fundamentally
different jobs, you're going to get a vehicle that does neither
job well."
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.
Farrel & Crocker Expires August 11, 2014 [Page 11]
Internet-Draft Handling of I-Ds by WGs February 2014
* 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
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, 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?
6. Security Considerations
Beyond the credibility of the IETF, this document raises no security
concerns.
Farrel & Crocker Expires August 11, 2014 [Page 12]
Internet-Draft Handling of I-Ds by WGs February 2014
7. Acknowledgements
This draft was developed from an IETF tutorial given by A. Farrel.
L. Anderson contributed useful comments.
8. Informative References
[Approval]
IETF, "IETF Internet-Draft Initial Version Approval
Tracker", IETF https://datatracker.ietf.org/cgi-bin/wg/
wg_init_rev_approval.cgi, .
[Consensus]
Resnick, P., "On Consensus and Humming in the IETF", I-D
draft-resnick-on-consensus-06, November 2013.
[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.
[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", IETF https://www.ietf.org/
id-info/checklist.html, May 2009.
[IDNITS] IETF, "IDNITS Tool", IETF https://www.ietf.org/tools/
idnits/, 2013.
[Individual]
IESG, , "Guidance on Area Director Sponsoring of
Documents", IETF http://www.ietf.org/iesg/statement/
ad-sponsoring-docs.html, March 2007.
Farrel & Crocker Expires August 11, 2014 [Page 13]
Internet-Draft Handling of I-Ds by WGs February 2014
[RFC-Auth-Ed]
"RFC Editorial Guidelines and Procedures -- Author
Overload", WEB
http://www.rfc-editor.org/policy.html#policy.authlist,
2014.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, September 1998.
[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with
Intellectual Property Rights (IPR) Disclosure Rules", RFC
6702, August 2012.
[Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to
the Internet Engineering Task Force", IETF
http://www.ietf.org/tao.html, 2012.
Appendix A. IANA Considerations
There are no requests for IANA.
The RFC Editor should remove this section.
Appendix B. 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 August 11, 2014 [Page 14]
