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

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

Abstract

   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 workiing
   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
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect

Farrel & Crocker          Expires June 5, 2013                  [Page 1]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

   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 . . . . . . . . . . . . . . . . . . . . . . . . . 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  . . . . . . . . . . . . . . . . . . . . . . . 6
   3.  Competing Drafts  . . . . . . . . . . . . . . . . . . . . . . . 7
   4.  Individual I-Ds Under WG Care . . . . . . . . . . . . . . . . . 8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  References - Informative  . . . . . . . . . . . . . . . . . . . 8
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

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 utlimate 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 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 working group name in the third field of the I-D filename, 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].

   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

Farrel & Crocker          Expires June 5, 2013                  [Page 3]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

      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

   [[editor's note: These are from Stephen's presentation.  It's not
   clear how to incorporate these, or whether. /d ]]

         How do I decide?

         Polling the WG.

         Making the decision.

         What are the process steps to become a WG I-D?

         Special cases.

         Creating a document as a WG I-D.

         Competing drafts.

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

   The first concern when considering adoption of a draft, should be
   basic criteria for the decisions, such as:

Farrel & Crocker          Expires June 5, 2013                  [Page 4]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

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

   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 it is helpful for a new
         working group draft to already be able to pass [IDNITS].

      *  The document is not required to already contain a complete
         and/or sufficient solution, although of course this can be
         helpful.

   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.

Farrel & Crocker          Expires June 5, 2013                  [Page 5]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

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

   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.

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

Farrel & Crocker          Expires June 5, 2013                  [Page 6]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

      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.

   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.

Farrel & Crocker          Expires June 5, 2013                  [Page 7]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

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.

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.

   [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",

Farrel & Crocker          Expires June 5, 2013                  [Page 8]
Internet-Draft    Creating an IETF Working Group Draft     December 2012

              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

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