Movatterモバイル変換

Internet Engineering Task Force (IETF)                         A. FarrelRequest for Comments: 7221                              Juniper NetworksCategory: Informational                                  D. Crocker, Ed.ISSN: 2070-1721                              Brandenburg InternetWorking                                                              April 2014Handling of Internet-Drafts by IETF Working GroupsAbstract   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 document is not an Internet Standards Track specification; it is   published for informational purposes.   This document is a product of the Internet Engineering Task Force   (IETF).  It represents the consensus of the IETF community.  It has   received public review and has been approved for publication by the   Internet Engineering Steering Group (IESG).  Not all documents   approved by the IESG are a candidate for any level of Internet   Standard; seeSection 2 of RFC 5741.   Information about the current status of this document, any errata,   and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc7221.Farrel & Crocker              Informational                     [Page 1]

RFC 7221                 Handling of I-Ds by WGs              April 2014   Copyright Notice   Copyright (c) 2014 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 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 Contents1. Introduction ....................................................21.1. What Is a WG Draft? ........................................31.2. Working Group Authority and Consensus ......................41.3. Questions Considered in This Document ......................52. Adoption Sequence ...............................................62.1. Common Steps ...............................................62.2. Criteria for Adoption ......................................63. Authors/Editors .................................................84. Document History and Stability ..................................85. Some Issues for Consideration ..................................105.1. Individual I-Ds under WG Care .............................105.2. WG Drafts Can Become Individual Drafts ....................115.3. Competing Drafts ..........................................116. Security Considerations ........................................137. Acknowledgements ...............................................138. Informative References .........................................131.  Introduction   The productive output of an IETF working group (WG) is documents, as   mandated by the working group's charter.  Working groups develop   these documents 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.  The discussion applies   only to the IETF and does not cover IRTF groups, where practices vary   widely.Farrel & Crocker              Informational                     [Page 2]

RFC 7221                 Handling of I-Ds by WGs              April 2014   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 document 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 WG 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-Ds) [RFC2026] [ID-Info].  Working groups use this   mechanism for producing their official output, perSection 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 seeSection 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.  SeeSection 3 for discussion about their   selection and role.Farrel & Crocker              Informational                     [Page 3]

RFC 7221                 Handling of I-Ds by WGs              April 20141.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   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 inSection 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 inSection 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.Farrel & Crocker              Informational                     [Page 4]

RFC 7221                 Handling of I-Ds by WGs              April 2014   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 ongoing 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:   *  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?Farrel & Crocker              Informational                     [Page 5]

RFC 7221                 Handling of I-Ds by WGs              April 20142.  Adoption Sequence2.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, because it typically entails a negotiation between the       current owners and the IETF, including a formal agreement.)   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.  Instruct authors to post the WG I-D.   6.  Approve posting [Approval].   7.  Ensure that the non-working group version of the draft is marked       as being replaced by this working group version.   8.  Encourage everyone to 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?   *  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?Farrel & Crocker              Informational                     [Page 6]

RFC 7221                 Handling of I-Ds by WGs              April 2014   *  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?   *  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.Farrel & Crocker              Informational                     [Page 7]

RFC 7221                 Handling of I-Ds by WGs              April 20143.  Authors/Editors   Document authors/editors are chosen by the Working Group Chairs.   Document editors are described inSection 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      '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/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.   Because the document has already had editors, the question "Are the   same people appropriate for continuing the task?" is asked.   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 reclassifying the   previous team as coauthors).   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.Farrel & Crocker              Informational                     [Page 8]

RFC 7221                 Handling of I-Ds by WGs              April 2014   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 inSection 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;   *  a basic design, with all of the actual details still fluid;   *  a rough draft, subject to extensive revision;   *  a solid specification that merely needs review, refinement, and      maybe enhancement;   *  a deployed technology that is best served by trying to protect its      installed base, but with some tolerance for changes that affect      interoperability;   *  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 life cycle, 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, any changes that are incompatible   are likely to be problematic for that market and can hinder adoption   of the changes overall.  For example, immediately after the   development investment is made -- and especially when there has been   considerable initial deployment but there is 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.Farrel & Crocker              Informational                     [Page 9]

RFC 7221                 Handling of I-Ds by WGs              April 2014   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.   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 life cycle, 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 Consideration5.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 inSection 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.Farrel & Crocker              Informational                    [Page 10]

RFC 7221                 Handling of I-Ds by WGs              April 2014   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 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 trade-offs, 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."Farrel & Crocker              Informational                    [Page 11]

RFC 7221                 Handling of I-Ds by WGs              April 2014   Various management efforts can facilitate the handling of competing   proposals.  Some examples include:   *  Developing a requirements document that is independent of specific      proposals; this can highlight features that are deemed essential      and distinguish them from features that are of secondary      importance, and can facilitate a discussion about features without      reference to specific proposals.   *  Developing a comparison table of the proposals; this can aid      understanding of their differences.   *  Discussing 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?Farrel & Crocker              Informational                    [Page 12]

RFC 7221                 Handling of I-Ds by WGs              April 20146.  Security Considerations   Beyond the credibility of the IETF, this document raises no security   concerns.7.  Acknowledgements   This document was developed from an IETF tutorial given by A. Farrel   at an IETF Working Group Chairs lunch [Farrel-Chairs].  L. Anderson   contributed useful comments.8.  Informative References   [Approval] IETF, "IETF Internet-Draft Initial Version Approval              Tracker", (IETF Datatracker),              <https://datatracker.ietf.org/cgi-bin/wg/wg_init_rev_approval.cgi>.   [Consensus]              Resnick, P.,"On Consensus and Humming in the IETF", Work              in Progress, April 2014.   [Farrel-Chairs]              Farrel, A., "What is a Working Group ID (and when to adopt              one)", (IETF 78 WG chairs lunch Material), July 2010,              <http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>.   [Heli-Sub]              Rose, M., "On Helicopters and Submarines", ACM Queue -              Instant Messaging, Vol. 1, Issue 8, Page 10,              <http://dl.acm.org/ft_gateway.cfm?id=966726>.   [ID-Guidelines]              Housley, R., Ed., "Guidelines to Authors of Internet-              Drafts", December 2010,              <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.   [ID-Info]  Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs)              submitted for RFC publication", May 2009,              <https://www.ietf.org/id-info/checklist.html>.   [IDNITS]   IETF, "IDNITS Tool", 2013,              <https://tools.ietf.org/tools/idnits/>.   [Individual]              IESG, "Guidance on Area Director Sponsoring of Documents",              March 2007, <http://www.ietf.org/iesg/statement/ad-sponsoring-docs.html>.Farrel & Crocker              Informational                    [Page 13]

RFC 7221                 Handling of I-Ds by WGs              April 2014   [RFC-Auth-Ed]              RFC Editor, "RFC Editorial Guidelines and Procedures --              Author Overload", 2014,              <http://www.rfc-editor.org/policy.html#policy.authlist>.   [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", 2012,              <http://www.ietf.org/tao.html>.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.netFarrel & Crocker              Informational                    [Page 14]