-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-carpenter-draft-adoption-00.txt
392 lines (235 loc) · 13.6 KB
/
draft-carpenter-draft-adoption-00.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
Network Working Group B.E. Carpenter
Internet-Draft Univ. of Auckland
Intended status: Best Current Practice F. Gont
Expires: 2 December 2020 SI6 Networks
M. Richardson
Sandelman Software Works
31 May 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 2 December 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Carpenter, et al. Expires 2 December 2020 [Page 1]
Internet-Draft Process for Adoption of Drafts May 2020
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
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 . . . . . . . . . . . . . . . . . . . . . . 6
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.
Carpenter, et al. Expires 2 December 2020 [Page 2]
Internet-Draft Process for Adoption of Drafts May 2020
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.
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].
* 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.
* 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.
* 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.
* This proposal should remind all participants, not just the
authors, of their obligation to disclose relevant intellectual
property rights (IPR) under [RFC8179].
Carpenter, et al. Expires 2 December 2020 [Page 3]
Internet-Draft Process for Adoption of Drafts May 2020
* 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.
- 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.
* 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?
* 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.
* 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.
* 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.
Carpenter, et al. Expires 2 December 2020 [Page 4]
Internet-Draft Process for Adoption of Drafts May 2020
* 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.
* 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 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.
* 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.
* 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.
* 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.
Carpenter, et al. Expires 2 December 2020 [Page 5]
Internet-Draft Process for Adoption of Drafts May 2020
7. Acknowledgements
Useful comments were received from [TBD] ...
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
* Original version
Authors' Addresses
Brian E. Carpenter
The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand
Carpenter, et al. Expires 2 December 2020 [Page 6]
Internet-Draft Process for Adoption of Drafts May 2020
Email: [email protected]
Fernando Gont
SI6 Networks
Evaristo Carriego 2644
1706 Haedo
Provincia de Buenos Aires
Argentina
Email: [email protected]
URI: https://www.si6networks.com
Michael Richardson
Sandelman Software Works
Email: [email protected]
URI: https://www.sandelman.ca/mcr/
Carpenter, et al. Expires 2 December 2020 [Page 7]