idnits 2.17.1 draft-carpenter-gendispatch-draft-adoption-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 31, 2020) is 1425 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBD' is mentioned on line 235, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Best Current Practice F. Gont 5 Expires: December 2, 2020 SI6 Networks 6 M. Richardson 7 Sandelman Software Works 8 May 31, 2020 10 Process for Working Group Adoption of Drafts 11 draft-carpenter-gendispatch-draft-adoption-00 13 Abstract 15 IETF working groups often formally adopt drafts. This document 16 specifies minimum requirements for this process, thereby extending 17 RFC 2418. It also describes how an adopted draft may be withdrawn 18 from the working group process. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 2, 2020. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Consequences of WG Adoption of an Internet-Draft . . . . . . 2 56 3. Rules for Adoption of an Internet-Draft . . . . . . . . . . . 3 57 4. Withdrawal of an Adopted Internet-Draft . . . . . . . . . . . 4 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 63 8.2. Informative References . . . . . . . . . . . . . . . . . 6 64 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 65 A.1. Draft-00 . . . . . . . . . . . . . . . . . . . . . . . . 6 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 According to [RFC2418], the Internet-Drafts (I-D) mechanism is a 71 "resource for posting and disseminating in-process copies of working 72 group documents." However, most I-Ds start as individual 73 contributions and only become working group documents by a WG 74 decision generally referred to as "adoption." As noted in [RFC7221], 75 this process was not previously documented as a formal step in the 76 IETF WG process. This has sometimes led to confusion about the 77 significance of such adoption and about how it fits into the IETF 78 standards process. The present document is intended to define a few 79 formal rules about adoption to reduce such confusion. 81 2. Consequences of WG Adoption of an Internet-Draft 83 After a draft has been formally adopted by a WG, its original authors 84 no longer have formal change control of the text. In addition to the 85 normal consequence of posting a draft, i.e., that it becomes an IETF 86 Contribution under [RFC5378], all future substantive changes to the 87 draft require WG consensus and are no longer at the authors' sole 88 discretion. 90 As a practical matter, the original authors usually continue to edit 91 the document and make routine editorial decisions, but substantive 92 changes must be referred to the WG and require WG rough consensus, 93 consistently with [RFC2418]. It is also possible that new authors or 94 editors will join the draft, or that previous authors may withdraw. 96 Adoption represents a commitment that the WG will spend time and 97 effort on the draft, but it does not guarantee that the draft will 98 reach WG consensus and be submitted to the IESG for publication as an 99 RFC. 101 3. Rules for Adoption of an Internet-Draft 103 A WG Adoption Call of an I-D is not a required step of the IETF 104 standards process. The WG chairs decide what documents belong in the 105 WG, and can create new documents by fiat. A simple situation would 106 be if a WG decides that an existing document should be split into two 107 pieces: There is no reason to adopt each piece, that is needless 108 bureaucracy. A WG that decides to create a design team to solve a 109 problem has implicitely agreed to adopt the result. To not adopt the 110 result is to say that the results of the WG mandated design team does 111 not deserve first class agenda time. Such a design team would have 112 been created, for instance, when a WG can not decide between two 113 competing individual drafts and decides to merge them. 115 It is legitimate for a draft to be submitted to the IESG as described 116 in [RFC2026] without a formal adoption by a WG. 118 If WG Chairs choose to consult the WG about adopting a document, this 119 is the recommended process. The WG Chairs should also consider the 120 additional guidelines in [RFC7221]. 122 o Any participant may request the adoption of a draft, after there 123 has been a period of technical discussion of the draft in the 124 relevant WG. 126 o WG Chairs have discretion about when to issue an WG call for 127 adoption, but they should do so regardless of their own opinions, 128 when the WG discussion shows that there is clear interest in the 129 draft in question. 131 o A WG Chair or WG Secretary must send a formal WG call for adoption 132 of a draft to the WG mailing list with at least two weeks time to 133 respond. 135 o This proposal should remind all participants, not just the 136 authors, of their obligation to disclose relevant intellectual 137 property rights (IPR) under [RFC8179]. 139 o Participants should consider the following aspects when responding 140 to the WG call for adoption: 142 * The draft must fit within the current WG charter, or would do 143 so with a simple modification to the charter. 145 * The purpose of the draft should be clear. 147 * The proposal should be useful. 149 * The quality of writing should be sufficient for document to 150 serve as the basis further work. 152 * There should be no strong technical objections. 154 * Any IPR disclosures should be acceptable. 156 * The work should not be in conflict with work elsewhere in the 157 IETF. 159 o An informal summary of these criteria is: Is this a problem the WG 160 wants to solve in a way approximately as described in the draft? 162 o After this period, a WG Chair must, in a timely fashion, consider 163 the comments and discussion in order to judge whether there is 164 rough consensus to adopt the draft, and whether there is enough 165 interest in the work that its completion is likely. 167 o If there is such consensus, this WG Chair will announce the result 168 and, if positive, will request the authors to post a new version 169 using an appropriate naming convention. 171 o This whole process is subject to the appeals process of [RFC2026]. 173 4. Withdrawal of an Adopted Internet-Draft 175 It sometimes happens that an adopted draft does not reach WG 176 consensus to be submitted to the IESG for publication as an RFC due 177 to lack of interest, lack of effort, or lack of consensus. In such a 178 case, it may be desirable for the WG to formally withdraw the WG 179 draft, such that it is explicitly removed from the WG's agenda and 180 returned to the authors' control. 182 The withdrawal of WG document should be the result of an explicit 183 decision by the relevant WG, and should follow the following 184 recommendations. 186 o Upon evidence that progress on a WG draft has been stalled for a 187 considerable period of time, a WG chair should evaluate the 188 reasons of the apparent lack of progress. Such reasons may may 189 include lack of interest, lack of effort, or lack of consensus. 191 o When progress on a document has been stalled for a considerable 192 period of time, a WG chair, in consultation with the WG draft 193 authors and editors, should attempt to resume progress by taking 194 appropriate actions that will normally depend on the nature of the 195 lack of progress. For example, a WG draft that has been stalled 196 due to apparent lack of interest may benefit from a call for a 197 number of volunters to produce detailed reviews of the WG draft. 198 Similarly, a WG draft that has been stalled due to lack of effort 199 by its authors/editors may benefit from the incorporation of new 200 WG draft editors or the replacement of some of the existing ones. 202 o If after succesive failed attempts to make progress on a WG draft 203 its completion remains unlikely, the WG Chairs may, at their own 204 discretion, conclude that it is time for the WG to consider the 205 formal withdrawal of the WG draft. 207 o In such case, a WG Chair or WG Secretary must send a formal WG 208 consensus call for withdrawal of the WG draft to the WG mailing 209 list with at least two weeks time to respond, explaining the 210 events that have triggered the aforementioned consensus call. 212 o After this period, a WG Chair must, in a timely fashion, consider 213 the comments and discussion in order to judge whether there is any 214 concrete evidence that completion of the work may now be feasible, 215 or whether completion of the work remains unlikely. 217 o If further progress on the document remains unlikely, the WG Chair 218 will announce the result of the consensus call and the formal 219 withdrawal of the WG document. This will result in the document 220 being removed from the WG's agenda and returned to the authors' 221 control. 223 o This whole process is subject to the appeals process of [RFC2026]. 225 5. IANA Considerations 227 This document makes no request of IANA. 229 6. Security Considerations 231 This document should not affect the security of the Internet. 233 7. Acknowledgements 235 Useful comments were received from [TBD] ... 237 8. References 239 8.1. Normative References 241 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 242 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 243 . 245 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 246 Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, 247 September 1998, . 249 [RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights 250 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 251 DOI 10.17487/RFC5378, November 2008, 252 . 254 [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property 255 Rights in IETF Technology", BCP 79, RFC 8179, 256 DOI 10.17487/RFC8179, May 2017, 257 . 259 8.2. Informative References 261 [RFC7221] Farrel, A. and D. Crocker, Ed., "Handling of Internet- 262 Drafts by IETF Working Groups", RFC 7221, 263 DOI 10.17487/RFC7221, April 2014, 264 . 266 Appendix A. Change Log 268 A.1. Draft-00 270 o Original version 272 Authors' Addresses 274 Brian E. Carpenter 275 The University of Auckland 276 School of Computer Science 277 PB 92019 278 Auckland 1142 279 New Zealand 281 Email: brian.e.carpenter@gmail.com 282 Fernando Gont 283 SI6 Networks 284 Evaristo Carriego 2644 285 Haedo, Provincia de Buenos Aires 1706 286 Argentina 288 Email: fgont@si6networks.com 289 URI: https://www.si6networks.com 291 Michael Richardson 292 Sandelman Software Works 294 Email: mcr+ietf@sandelman.ca 295 URI: https://www.sandelman.ca/mcr/