draft-carpenter-gendispatch-rfc7221bis-01.txt

Network Working Group                                          A. Farrel
Internet-Draft                                          Juniper Networks
Obsoletes: 7221 (if approved)                                 D. Crocker
Intended status: Informational               Brandenburg InternetWorking
Expires: 2 May 2021                                       B.E. Carpenter
                                                       Univ. of Auckland
                                                                 F. Gont
                                                            SI6 Networks
                                                           M. Richardson
                                                Sandelman Software Works
                                                         29 October 2020


    Handling and Adoption of Internet-Drafts by IETF Working Groups
               draft-carpenter-gendispatch-rfc7221bis-01

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 https://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 2 May 2021.





Farrel, et al.             Expires 2 May 2021                   [Page 1]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


Copyright Notice

   Copyright (c) 2020 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 (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  What Is a WG Draft? . . . . . . . . . . . . . . . . . . .   3
     1.2.  Working Group Authority and Consensus . . . . . . . . . .   4
     1.3.  Questions Considered in This Document . . . . . . . . . .   5
   2.  Adoption Sequence . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  Consequences of WG Adoption of an Internet-Draft  . . . .   6
     2.2.  Relationship to Formal IETF Rules . . . . . . . . . . . .   6
     2.3.  Common Steps  . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Criteria for Adoption . . . . . . . . . . . . . . . . . .   8
   3.  Authors/Editors . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Document History and Stability  . . . . . . . . . . . . . . .  10
   5.  Some Issues for Consideration . . . . . . . . . . . . . . . .  11
     5.1.  Individual I-Ds under WG Care . . . . . . . . . . . . . .  11
     5.2.  Withdrawal of an Adopted Internet-Draft . . . . . . . . .  12
     5.3.  Competing Drafts  . . . . . . . . . . . . . . . . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

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



Farrel, et al.             Expires 2 May 2021                   [Page 2]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   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 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, 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-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 see Section 5.1 for an elaboration on this naming.)





Farrel, et al.             Expires 2 May 2021                   [Page 3]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   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, 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 in
   Section 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 in Section 3.3 of [RFC2418] and
   Section 4.2 of [Tao].  Discussion of the nature of rough consensus
   can be found in [RFC7282].

   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, et al.             Expires 2 May 2021                   [Page 4]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   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?

2.  Adoption Sequence











Farrel, et al.             Expires 2 May 2021                   [Page 5]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


2.1.  Consequences of WG Adoption of an Internet-Draft

   After a draft has been formally adopted by a WG, its original authors
   no longer have formal change control of the text.  In addition to the
   normal consequence of posting a draft, i.e., that it becomes an IETF
   Contribution under [RFC5378], all future substantive changes to the
   draft require WG consensus and are no longer at the authors' sole
   discretion.

   As a practical matter, the original authors usually continue to edit
   the document and make routine editorial decisions, but substantive
   changes must be referred to the WG and require WG rough consensus,
   consistently with [RFC2418].  It is also possible that new authors or
   editors will join the draft, or that previous authors may withdraw.

   Adoption represents a commitment that the WG will spend time and
   effort on the draft, but it does not guarantee that the draft will
   reach WG consensus and be submitted to the IESG for publication as an
   RFC.

2.2.  Relationship to Formal IETF Rules

   A WG Adoption Call of an I-D is not a required step of the IETF
   standards process.  The WG chairs decide what documents belong in the
   WG, and can create new documents by fiat.  A simple situation would
   be if a WG decides that an existing document should be split into two
   pieces: there is no reason to adopt each piece, that is needless
   bureaucracy.  Similarly, if there is WG consensus to merge two drafts
   into one, a complete adoption procedure may be pointless.  However, a
   WG that decides to create a design team to solve a problem has not
   agreed to adopt the result automatically.  The design team's output
   has the same status as any other draft, even if it has a high chance
   of being adopted.

   It is legitimate for a draft to be submitted to the IESG as described
   in [RFC2026] without a formal adoption by a WG.  Clearly this should
   only happen when the WG Chairs are already satisfied that there is
   strong consensus to do so.

2.3.  Common Steps

   Any participant may request the adoption of a draft, after there has
   been a period of technical discussion of the draft in the relevant
   WG.







Farrel, et al.             Expires 2 May 2021                   [Page 6]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   WG Chairs have discretion about when to issue a call for adoption,
   but they should do so regardless of their own opinions, when the WG
   discussion shows that there is clear interest in the draft in
   question.

   When there is interest in adopting a document as a new working group
   document, the Chairs (or a WG Secretary, if there is one) typically:

   1.  Remind current draft authors 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 under [RFC8179],
       using some technique like those described in [RFC6702].  This
       might be combined with the following action.

   3.  Obtain working group rough consensus.  Typically the Chairs or WG
       Secretary will send a call for adoption of a draft to the WG
       mailing list with at least two weeks time to respond.

       *  After this period, a WG Chair should, in a timely fashion,
          consider the comments and discussion in order to judge whether
          there is rough consensus to adopt the draft, and whether there
          is enough interest in the work that its completion is likely.
          The result should be announced to the WG.

   4.  Choose document editors.  As noted above, these might or might
       not be the existing authors.

   5.  Request authors to post the WG I-D according to the naming
       convention described above.

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










Farrel, et al.             Expires 2 May 2021                   [Page 7]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


2.4.  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.
   Participants responding to a WG call for adoption should consider
   these points.

   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?

   *  If not already in scope, is a simple modification to the charter
      feasible and warranted?

   *  Is the purpose of the draft sufficiently clear?

   *  Is the proposal useful?

   *  Does the document provide an acceptable platform for continued
      effort by the working group?  In particular, is the quality of
      writing sufficient to serve as the basis further work?

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

   *  Does the draft carry known intellectual property rights issues?
      If so, are the IPR disclosures acceptable?

   *  Is the work in conflict with work elsewhere in the IETF?

   *  Is there strong working group support for working on the draft?

   An informal summary of these questions is: Is this a problem the WG
   wants to solve in a way approximately as described in the draft?

   Adoption has some basic pragmatics:

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



Farrel, et al.             Expires 2 May 2021                   [Page 8]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   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.

3.  Authors/Editors

   Document authors/editors are chosen by the Working Group Chairs.
   Document editors are described in Section 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.




Farrel, et al.             Expires 2 May 2021                   [Page 9]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   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.

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

   *  a basic design, with all of the actual details still fluid;

   *  a rough draft, subject to extensive revision;



Farrel, et al.             Expires 2 May 2021                  [Page 10]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


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

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




Farrel, et al.             Expires 2 May 2021                  [Page 11]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


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

   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.

   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.  Withdrawal of an Adopted Internet-Draft

   It sometimes happens that an adopted draft does not reach WG
   consensus to be submitted to the IESG for publication as an RFC due
   to lack of interest, lack of effort, or lack of agreement.  In such a
   case, it may be desirable for the WG to formally withdraw the WG
   draft, such that it is explicitly removed from the WG's agenda.  If a
   working group drops a draft, then anyone (most likely the original
   authors) can pursue it as an Individual or Independent Submission,
   subject to the document's existing copyright constraints.

   The withdrawal of a WG document should be the result of an explicit
   decision by the relevant WG, and the Chairs should consider the
   following recommendations.

   *  Upon evidence that progress on a WG draft has been stalled for a
      considerable period of time, a WG chair should evaluate the
      reasons of the apparent lack of progress.  Such reasons may may
      include lack of interest, lack of effort, or lack of consensus.



Farrel, et al.             Expires 2 May 2021                  [Page 12]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   *  When progress on a document has been stalled for a considerable
      period of time, a WG chair, in consultation with the WG draft
      authors and editors, should attempt to resume progress by taking
      appropriate actions that will normally depend on the nature of the
      lack of progress.  For example, a WG draft that has been stalled
      due to apparent lack of interest may benefit from a call for a
      number of volunters to produce detailed reviews of the WG draft.
      Similarly, a WG draft that has been stalled due to lack of effort
      by its authors/editors may benefit from the incorporation of new
      WG draft editors or the replacement of some of the existing ones.

   *  If after succesive failed attempts to make progress on a WG draft
      its completion remains unlikely, the WG Chairs may, at their own
      discretion, conclude that it is time for the WG to consider the
      formal withdrawal of the WG draft.

   *  In such case, a WG Chair or WG Secretary would send a formal WG
      consensus call for withdrawal of the WG draft to the WG mailing
      list with at least two weeks time to respond, explaining the
      events that have triggered the aforementioned consensus call.

   *  After this period, a WG Chair should, in a timely fashion,
      consider the comments and discussion in order to judge whether
      there is any concrete evidence that completion of the work may now
      be feasible, or whether completion of the work remains unlikely.

   *  If further progress on the document remains unlikely, the WG Chair
      will announce the result of the consensus call and the formal
      withdrawal of the WG document.  This will result in the document
      being removed from the WG's agenda and returned to the authors'
      control.

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.









Farrel, et al.             Expires 2 May 2021                  [Page 13]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


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

   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



Farrel, et al.             Expires 2 May 2021                  [Page 14]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


      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?

6.  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.  It was updated in September 2020 to add
   more detail on the adoption process.

8.  References

8.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
              September 1998, <https://www.rfc-editor.org/info/rfc2418>.

   [RFC5378]  Bradner, S., Ed. and J. Contreras, Ed., "Rights
              Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
              DOI 10.17487/RFC5378, November 2008,
              <https://www.rfc-editor.org/info/rfc5378>.





Farrel, et al.             Expires 2 May 2021                  [Page 15]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   [RFC8179]  Bradner, S. and J. Contreras, "Intellectual Property
              Rights in IETF Technology", BCP 79, RFC 8179,
              DOI 10.17487/RFC8179, May 2017,
              <https://www.rfc-editor.org/info/rfc8179>.

8.2.  Informative References

   [Approval] IETF, "IETF Internet-Draft Initial Version Approval
              Tracker", n.d., <https://datatracker.ietf.org/cgi-bin/wg/
              wg_init_rev_approval.cgi>.

   [Farrel-Chairs]
              IETF, "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)", November
              2003, <http://dl.acm.org/ft_gateway.cfm?id=966726>.

   [ID-Guidelines]
              Housley(Ed.), R., "Guidelines to Authors of Internet-
              Drafts", December 2010,
              <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.

   [ID-Info]  Wijnen(Ed.), B., "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>.

   [RFC-Auth-Ed]
              RFC Editor, "RFC Editorial Guidelines and Procedures --
              Author Overload", 2014,
              <http://www.rfc-editor.org/policy.html#policy.authlist>.

   [RFC6702]  Polk, T. and P. Saint-Andre, "Promoting Compliance with
              Intellectual Property Rights (IPR) Disclosure Rules",
              RFC 6702, DOI 10.17487/RFC6702, August 2012,
              <https://www.rfc-editor.org/info/rfc6702>.





Farrel, et al.             Expires 2 May 2021                  [Page 16]

Internet-Draft    Handling and Adoption of I-Ds by WGs      October 2020


   [RFC7282]  Resnick, P., "On Consensus and Humming in the IETF",
              RFC 7282, DOI 10.17487/RFC7282, June 2014,
              <https://www.rfc-editor.org/info/rfc7282>.

   [Tao]      Hoffman(Ed.), P., "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
   Brandenburg InternetWorking

   Email: dcrocker@bbiw.net


   Brian E. Carpenter
   The University of Auckland
   School of Computer Science
   PB 92019
   Auckland 1142
   New Zealand

   Email: brian.e.carpenter@gmail.com


   Fernando Gont
   SI6 Networks
   Evaristo Carriego 2644
   1706 Haedo
   Provincia de Buenos Aires
   Argentina

   Email: fgont@si6networks.com
   URI:   https://www.si6networks.com


   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca
   URI:   https://www.sandelman.ca/mcr/



Farrel, et al.             Expires 2 May 2021                  [Page 17]