Creating an IETF Working Group Draft
draft-crocker-id-adoption-04

Network Working Group                                          A. Farrel
Internet-Draft                                          Juniper Networks
Intended status: Informational                           D. Crocker, Ed.
Expires: April 10, 2014                      Brandenburg InternetWorking
                                                        October 07, 2013

                  Creating an IETF Working Group Draft
                      draft-crocker-id-adoption-04

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 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 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 April 10, 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
   (http://trustee.ietf.org/license-info) in effect on the date of

Farrel & Crocker         Expires April 10, 2014                 [Page 1]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   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 . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Document History and Stability  . . . . . . . . . . . . . . .   7
   5.  Some Issues for Consideration . . . . . . . . . . . . . . . .   9
     5.1.  Individual I-Ds Under WG Care . . . . . . . . . . . . . .   9
     5.2.  Competing Drafts  . . . . . . . . . . . . . . . . . . . .  10
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   8.  Informative References  . . . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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.

Farrel & Crocker         Expires April 10, 2014                 [Page 2]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   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.  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) [ID-Info].  Working groups use this mechanism
   for producing their official output, per Section 7.2 of [RFC2418] and
   Section 8.3 of [RFC4677].  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 editors and authors.  See Section 3 for discussion about their
   selection and role.

1.2.  Working Group Authority and Consensus

   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.  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 5.2 of [RFC4677].

Farrel & Crocker         Expires April 10, 2014                 [Page 3]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   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/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 to provide their reasons, not merely their preferences.
   In effect, this treats the matter of consensus as an on-going
   discussion.  Ideally one 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
   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?

Farrel & Crocker         Expires April 10, 2014                 [Page 4]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

      *  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.  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.  Pre-approve the document as an Internet Draft, using
          [Approval].

      6.  Tell the editors to submit the -00 version of the document.

      7.  Request Secretariat to ensure that the Datatracker records
          that the old internet-draft has been replaced by the new
          working group draft.

      8.  Enjoy 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?

Farrel & Crocker         Expires April 10, 2014                 [Page 5]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

      *  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 adoption of 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?

   There are, however, some criteria that do not need to be met:

      Rough consensus:    Working group agreement to adopt is not
            required to be unanimous.

      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.

      Group not chairs:   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
      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

Farrel & Crocker         Expires April 10, 2014                 [Page 6]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   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?  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 often specify an initial set of existing
   documents to use.  Working group charters sometimes specify an
   initial set of existing documents to use as a basis of the working
   group's work.  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 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

Farrel & Crocker         Expires April 10, 2014                 [Page 7]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   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:

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

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

Farrel & Crocker         Expires April 10, 2014                 [Page 8]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

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

   , 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 does
   not have agreement about the text in the document.

Farrel & Crocker         Expires April 10, 2014                 [Page 9]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   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

   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, as discussed in xref target="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.

   QUESTION:  Isn't there an RFC somewhere about coin-tossing to resolve
      "draws"? (ed.)

   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.

Farrel & Crocker         Expires April 10, 2014                [Page 10]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

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

Farrel & Crocker         Expires April 10, 2014                [Page 11]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   This draft was developed from an IETF tutorial given by A. Farrel.
   L. Anderson contributed useful comments.

8.  Informative References

   [Approval]
              IESG, "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-02, March 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", IESG https://www.ietf.org/
              id-info/checklist.html, May 2009.

   [IDNITS]   IETF, "IDNITS Tool", IETF https://www.ietf.org/tools/
              idnits/, .

   [Individual]
              IESG, ., "Guidance on Area Director Sponsoring of
              Documents", Web http://www.ietf.org/iesg/statement/ad-
              sponsoring-docs.html, March 2007.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, September 1998.

Farrel & Crocker         Expires April 10, 2014                [Page 12]
Internet-Draft    Creating an IETF Working Group Draft      October 2013

   [RFC4677]  Hoffman, P. and S. Harris, "The Tao of IETF - A Novice's
              Guide to the Internet Engineering Task Force", RFC 4677,
              September 2006.

   [RFC6702]  Polk, T. and P. Saint-Andre, "Promoting Compliance with
              Intellectual Property Rights (IPR) Disclosure Rules", RFC
              6702, August 2012.

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 April 10, 2014                [Page 13]