[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]



Network Working Group                                       B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Best Current Practice                           F. Gont
Expires: December 2, 2020                                   SI6 Networks
                                                           M. Richardson
                                                Sandelman Software Works
                                                            May 31, 2020


              Process for Working Group Adoption of Drafts
             draft-carpenter-gendispatch-draft-adoption-00

Abstract

   IETF working groups often formally adopt drafts.  This document
   specifies minimum requirements for this process, thereby extending
   RFC 2418.  It also describes how an adopted draft may be withdrawn
   from the working group process.

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 December 2, 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



Carpenter, et al.       Expires December 2, 2020                [Page 1]


Internet-Draft       Process for Adoption of Drafts             May 2020


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Consequences of WG Adoption of an Internet-Draft  . . . . . .   2
   3.  Rules for Adoption of an Internet-Draft . . . . . . . . . . .   3
   4.  Withdrawal of an Adopted Internet-Draft . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   6
     A.1.  Draft-00  . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   According to [RFC2418], the Internet-Drafts (I-D) mechanism is a
   "resource for posting and disseminating in-process copies of working
   group documents."  However, most I-Ds start as individual
   contributions and only become working group documents by a WG
   decision generally referred to as "adoption."  As noted in [RFC7221],
   this process was not previously documented as a formal step in the
   IETF WG process.  This has sometimes led to confusion about the
   significance of such adoption and about how it fits into the IETF
   standards process.  The present document is intended to define a few
   formal rules about adoption to reduce such confusion.

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





Carpenter, et al.       Expires December 2, 2020                [Page 2]


Internet-Draft       Process for Adoption of Drafts             May 2020


   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.

3.  Rules for Adoption of an Internet-Draft

   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.  A WG that decides to create a design team to solve a
   problem has implicitely agreed to adopt the result.  To not adopt the
   result is to say that the results of the WG mandated design team does
   not deserve first class agenda time.  Such a design team would have
   been created, for instance, when a WG can not decide between two
   competing individual drafts and decides to merge them.

   It is legitimate for a draft to be submitted to the IESG as described
   in [RFC2026] without a formal adoption by a WG.

   If WG Chairs choose to consult the WG about adopting a document, this
   is the recommended process.  The WG Chairs should also consider the
   additional guidelines in [RFC7221].

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

   o  WG Chairs have discretion about when to issue an WG 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.

   o  A WG Chair or WG Secretary must send a formal WG call for adoption
      of a draft to the WG mailing list with at least two weeks time to
      respond.

   o  This proposal should remind all participants, not just the
      authors, of their obligation to disclose relevant intellectual
      property rights (IPR) under [RFC8179].

   o  Participants should consider the following aspects when responding
      to the WG call for adoption:

      *  The draft must fit within the current WG charter, or would do
         so with a simple modification to the charter.



Carpenter, et al.       Expires December 2, 2020                [Page 3]


Internet-Draft       Process for Adoption of Drafts             May 2020


      *  The purpose of the draft should be clear.

      *  The proposal should be useful.

      *  The quality of writing should be sufficient for document to
         serve as the basis further work.

      *  There should be no strong technical objections.

      *  Any IPR disclosures should be acceptable.

      *  The work should not be in conflict with work elsewhere in the
         IETF.

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

   o  After this period, a WG Chair must, 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.

   o  If there is such consensus, this WG Chair will announce the result
      and, if positive, will request the authors to post a new version
      using an appropriate naming convention.

   o  This whole process is subject to the appeals process of [RFC2026].

4.  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 consensus.  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 and
   returned to the authors' control.

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

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

   o  When progress on a document has been stalled for a considerable
      period of time, a WG chair, in consultation with the WG draft



Carpenter, et al.       Expires December 2, 2020                [Page 4]


Internet-Draft       Process for Adoption of Drafts             May 2020


      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.

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

   o  In such case, a WG Chair or WG Secretary must 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.

   o  After this period, a WG Chair must, 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.

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

   o  This whole process is subject to the appeals process of [RFC2026].

5.  IANA Considerations

   This document makes no request of IANA.

6.  Security Considerations

   This document should not affect the security of the Internet.

7.  Acknowledgements

   Useful comments were received from [TBD] ...








Carpenter, et al.       Expires December 2, 2020                [Page 5]


Internet-Draft       Process for Adoption of Drafts             May 2020


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

   [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

   [RFC7221]  Farrel, A. and D. Crocker, Ed., "Handling of Internet-
              Drafts by IETF Working Groups", RFC 7221,
              DOI 10.17487/RFC7221, April 2014,
              <https://www.rfc-editor.org/info/rfc7221>.

Appendix A.  Change Log

A.1.  Draft-00

   o  Original version

Authors' Addresses

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

   Email: brian.e.carpenter@gmail.com






Carpenter, et al.       Expires December 2, 2020                [Page 6]


Internet-Draft       Process for Adoption of Drafts             May 2020


   Fernando Gont
   SI6 Networks
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   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/




































Carpenter, et al.       Expires December 2, 2020                [Page 7]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/