Network Working Group A. Farrel
Internet-Draft Juniper Networks
Intended status: Informational D. Crocker, Ed.
Expires: August 07, 2014 Brandenburg InternetWorking
February 03, 2014

Handling of Internet Drafts by IETF Working Group
draft-crocker-id-adoption-06

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 07, 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 (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

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 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. 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.

draft-ietf-<wgname>-...

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-<lastname>-... 

Individual submissions are drafts being created and pursued outside of a working group, although a working group might choose to adopt the draft later, as discussed below. Anyone is free to create an individual submission at any time. Such documents are typically distinguished through the use of the author's last name, in the style of:

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 a working group has final authority over the content of its documents, within the constraints of the working group charter. No individual has special authority for the content. The chairs assign document authors/editors and can formulate design teams, but the content of working group documents is always, ultimately, subject to working group approval. Approval is described in terms of the IETF's "rough consensus" construct, which is the prime example of the IETF's preference for pragmatics over niceties. Unanimous agreement is always desirable, but more approximate (rough) agreement will suffice, as long as it is clear and strong. Further discussion of the nature of rough consensus can be found in [Consensus].

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 process rules. Useful descriptions of this process for a working group are in Section 3.3 of [RFC2418] and Section 4.2 of [Tao].

In terms of the IETF's formal rough consensus processes, the working group raises and discusses an item of document content and then determines its rough consensus. For difficult topics and/or difficult working group dynamics, this laborious process really is essential, because its diligence validates progress at each step along the way. However working groups often handle simpler matters more simply, such as having a Chair assert the likely agreement and merely call for objections. Ultimately, the mode of working group decision making is determined by the comfort of the working group with the way the decisions are being made.

At times, a document author/editor can appear to have considerable authority over content, but this is (merely) for efficiency. That is, the chairs can permit authors and editors to proceed with an implied (default) working group agreement, as long as the working group is comfortable with that mode. Of course the benefit in the mode is efficiency, but its risk is failure to retain or verify actual consensus among the working group participants. When a working group is operating in the mode of active, direct author content development, an easy validation method is simply to have chairs query the working group when a new document version appears, asking for comments and concerns.

In general when it is not completely obvious what the opinion of the working group is, working group chairs can poll the working group to find out. As with any other consensus question, the form in which it is asked can make a difference. In particular, a general 'yes/no' question often is not as helpful as asking supporters and detractors of a draft -- or of the decision under consideration -- to provide their reasons, not merely their preferences. In effect, this treats the matter of consensus as an on-going discussion. Ideally the discussion can produce changes in the document or in participant views, or both.

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:

2. Adoption Sequence

2.1. Typical Steps

When there is an existing document and the chairs want to propose adopting it as a new working group document, the chairs often:

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:

Adoption has some basic pragmatics:

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].

NOTE:
The distinction between an 'author' and an 'editor' is, at best, subjective. A simplistic rule of thumb is that editors tend to do the mechanics of incorporating working group detail, whereas authors tend to create the detail, subject to working group approval. That is, one role is more active with the content and the other is more passive. It is a responsibility of the working group chairs to ensure that document authors make modifications in accord with working group rough consensus. Authors serve at the pleasure of the working group chairs, and are subject to replacement for a variety of reasons.

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.

Absent charter restrictions, a working group is free to create new documents. It is not required that all drafts start as the effort of an individual. Of course the criteria for brand new documents are likely to be the same as for those imported into the working group with the additional and obvious requirement that the working group chairs will need to appoint authors/editors before any work can progress. Note that from time to time a working group will form a design team to produce the first version of a working group draft. Design teams are discussed in Section 6.5 of [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:

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 specification will not necessarily add much to the development and deployment costs. However when the technology is part of a mature, well-deployed market, incompatible changes are likely to be problematic for that market, which can hinder adoption of the changes.

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.

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 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].

draft-ietf-<wgname>-...

draft-<lastname>-<wgname>...

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:

Such documents can be handled according to normal, internal working group process management. However matters of ownership, working group final approval, and the like are all subject to negotiation amongst the document authors, working group and area directors.

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. 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 an individual wishes to pursue the document outside of the working group, the document can be released to them.

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, as discussed in [Heli-Sub].

Various management efforts can facilitate the handling of competing proposals. Some examples include:

The problem of competing drafts can be particularly painful when it arises in either of two circumstances:

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. Informative References

[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.
[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.
[Tao] Hoffman, P., "The Tao of IETF - A Novice's Guide to the Internet Engineering Task Force ", IETF http://www.ietf.org/tao.html, 2012.
[RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules", RFC 6702, August 2012.
[ID-Info] Wijnen, B., "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.
[ID-Guidelines] Housley, R., "Guidelines to Authors of Internet-Drafts", IETF http://www.ietf.org/ietf-ftp/1id-guidelines.txt, December 2010.
[Approval] IETF, "IETF Internet-Draft Initial Version Approval Tracker", IETF https://datatracker.ietf.org/cgi-bin/wg/wg_init_rev_approval.cgi, .
[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, .
[Consensus] Resnick, P., "On Consensus and Humming in the IETF", I-D draft-resnick-on-consensus-06, November 2013.
[Individual] IESG, , "Guidance on Area Director Sponsoring of Documents", IETF http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html, March 2007.

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