Network Working Group A. Farrel
Internet-Draft Juniper Networks
Intended status: Informational D. Crocker, Ed.
Expires: June 05, 2013 Brandenburg InternetWorking
December 02, 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 05, 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 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 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.

1.1. What is a Working Group Draft?

                     draft-ietf-<wgname>-...

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:

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

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:

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

Some specifically-inappropriate criteria should be noted:

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

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:

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.

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:

4. Individual I-Ds Under WG Care

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

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:

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

[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.
[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.
[ID-Info] Wijnen, B., "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/, .
[ID-Guidelines] Housley, R., "Guidelines to Authors of Internet-Drafts", IETF http://www.ietf.org/ietf-ftp/1id-guidelines.txt, December 2010.
[Approval] IESG, "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, .

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