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
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
|
<pre>Internet Engineering Task Force (IETF) Y. Sheffer
Request for Comments: 6982 Porticor
Category: Experimental A. Farrel
ISSN: 2070-1721 Juniper
July 2013
<span class="h1">Improving Awareness of Running Code: The Implementation Status Section</span>
Abstract
This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by
including an Implementation Status section. This will allow
reviewers and working groups to assign due consideration to documents
that have the benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the implemented
protocols more mature.
The process in this document is offered as an experiment. Authors of
Internet-Drafts are encouraged to consider using the process for
their documents, and working groups are invited to think about
applying the process to all of their protocol specifications. The
authors of this document intend to collate experiences with this
experiment and to report them to the community.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. 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; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc6982">http://www.rfc-editor.org/info/rfc6982</a>.
<span class="grey">Sheffer & Farrel Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. The "Implementation Status" Section . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Introductory Text . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3">3</a>. Alternative Formats . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Process Experiment . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.1">5.1</a>. Duration . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Summary Report . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-5.3">5.3</a>. Success Criteria . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-8">8</a>. Informative References . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="grey">Sheffer & Farrel Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Most IETF participants are familiar with the saying "rough consensus
and running code" [<a href="#ref-Tao" title=""The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force"">Tao</a>] and can identify with its pragmatic approach.
However, implementation is not a requirement for publication as an
RFC. There are many examples of Internet-Drafts containing protocol
specification that have gone through to publication as Proposed
Standard RFCs without implementation. Some of them may never get
implemented.
Over time, a variety of policies have been applied within the IETF to
consider running code. In the Routing Area, it used to be a
requirement that one or more implementations must exist before an
Internet-Draft could be published as a Proposed Standard RFC
[<a href="./rfc1264" title=""Internet Engineering Task Force Internet Routing Protocol Standardization Criteria"">RFC1264</a>]. That RFC was later obsoleted and the requirement for
implementation was lifted, but each working group was given the
authority to impose its own implementation requirements [<a href="./rfc4794" title=""RFC 1264 Is Obsolete"">RFC4794</a>] and
at least one working group, Inter-Domain Routing (IDR), continues to
require two independent implementations.
The hypothesis behind the current document is that there are benefits
to the IETF standardization process of producing implementations of
protocol specifications before publication as RFCs. These benefits,
which include determining that the specification is comprehensible
and that there is sufficient interest to implement, are further
discussed in <a href="#section-4">Section 4</a>.
This document describes a simple mechanism that allows authors of
Internet-Drafts to record and publicize the status of known
implementations by including an Implementation Status section. The
document defines (quite informally) the contents of this section to
ensure that the relevant information is included. This will allow
reviewers and working groups to assign due consideration to documents
that have the benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the implemented
protocols more mature.
It is up to the individual working groups to use this information as
they see fit, but one result might be the preferential treatment of
documents, resulting in them being processed more rapidly. We
recommend that the Implementation Status section should be removed
from Internet-Drafts before they are published as RFCs. As a result,
we do not envisage changes to this section after approval of the
document for publication, e.g., the RFC errata process does not
apply.
<span class="grey">Sheffer & Farrel Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
The process in this document is offered as an experiment (though not
as an [<a href="./rfc3933" title=""A Model for IETF Process Experiments"">RFC3933</a>] experiment; see <a href="#section-5">Section 5</a>). Authors of Internet-
Drafts are encouraged to consider using the process for their
documents, and working groups are invited to think about applying the
process to all of their protocol specifications.
The scope of the intended experiment is all Internet-Drafts (I-Ds)
that contain implementable specifications, whether produced within
IETF working groups or outside working groups but intended for IETF
consensus. I-Ds published on the Independent Stream are explicitly
out of scope. It is expected that the greatest benefit in the
experiment will be seen with Standards Track documents developed
within working groups.
The authors of this document intend to collate experiences with this
experiment and to report them to the community.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. The "Implementation Status" Section</span>
Each Internet-Draft may contain a section entitled "Implementation
Status". This section, if it appears, should be located just before
the "Security Considerations" section and contain, for each existing
implementation, some or all of the following:
o The organization responsible for the implementation, if any.
o The implementation's name and/or a link to a web page describing
the implementation.
o A brief general description.
o The implementation's level of maturity: research, prototype,
alpha, beta, production, widely used, etc.
o Coverage: which parts of the protocol specification are
implemented and which versions of the Internet-Draft were
implemented.
o Licensing: the terms under which the implementation can be used.
For example: proprietary, royalty licensing, freely distributable
with acknowledgement (BSD style), freely distributable with
requirement to redistribute source (General Public License (GPL)
style), and other (specify).
o Implementation experience: any useful information the implementers
want to share with the community.
<span class="grey">Sheffer & Farrel Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
o Contact information: ideally a person's name and email address,
but possibly just a URL or mailing list.
In addition, this section can contain information about the
interoperability of any or all of the implementations, including
references to test-case descriptions and interoperability reports,
when such exist.
Working group chairs and area directors (ADs) are requested to ensure
that this section is not used as a marketing venue for specific
implementations.
Since this information is necessarily time dependent, it is
inappropriate for inclusion in a published RFC. The authors should
include a note to the RFC Editor requesting that the section be
removed before publication.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Introductory Text</span>
The following boilerplate text is proposed to head the Implementation
Status section:
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in <a href="./rfc6982">RFC</a>
<a href="./rfc6982">6982</a>. The description of implementations in this section is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.
According to <a href="./rfc6982">RFC 6982</a>, "this will allow reviewers and working
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".
Authors are requested to add a note to the RFC Editor at the top of
this section, advising the Editor to remove the entire section before
publication, as well as the reference to <a href="./rfc6982">RFC 6982</a>.
<span class="grey">Sheffer & Farrel Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Alternative Formats</span>
Sometimes it can be advantageous to publish the implementation status
separately from the base Internet-Draft, e.g., on the IETF wiki:
o When the Implementation Status section becomes too large to be
conveniently managed within the document.
o When a working group decides to have implementors, rather than
authors, keep the status of their implementations current.
o When a working group already maintains an active wiki and prefers
to use it for this purpose.
o If the working group decides that the information is still
valuable (and needs to be kept current) after the I-D is published
as an RFC, and the Implementation Status section had been removed
from it.
It is highly desirable for all readers of the Internet-Draft to be
made aware of this information. Initially, this can be done by
replacing the Implementation Status section's contents with a URL
pointing to the wiki. Later, the IETF Tools may support this
functionality, e.g., by including such a link in the HTML file of the
document, similar to the IPR link.
If the implementation status is published separately from the I-D,
then this information needs to be openly available without requiring
authentication, registration, or access controls if it is to have any
useful effects.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Benefits</span>
Publishing the information about implementations provides the working
group with several benefits:
o Working group members, chairs, and ADs may use the information
provided to help prioritize the progress of I-Ds, e.g., when there
are several competing proposals to solve a particular problem.
o Similarly, the information is useful when deciding whether the
document should be progressed on a different track (individual
submission, Experimental, etc.).
o Making this information public and an explicit part of WG
deliberations will motivate participants to implement protocol
proposals, which in turn helps in discovering protocol flaws at an
early stage.
<span class="grey">Sheffer & Farrel Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
o Other participants can use the software to evaluate the usefulness
of protocol features, its correctness (to some degree), and other
properties, such as resilience and scalability.
o WG members may choose to perform interoperability testing with
known implementations, especially when they are publicly
available.
o In the case of open source, people may want to study the code to
better understand the protocol and its limitations, determine if
the implementation matches the protocol specification, and whether
the protocol specification has omissions or ambiguities.
o And lastly, some protocol features may be hard to understand, and
for such features, the mere assurance that they can be implemented
is beneficial. We note though that code should never be used in
lieu of a clear specification.
We do not specify here whether and to what degree working groups are
expected to prefer proposals that have "running code" associated with
them, over others that do not.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Process Experiment</span>
The current proposal is proposed as an experiment. The inclusion of
Implementation Status sections in Internet-Drafts is not mandatory,
but the authors of this document wish to encourage authors of other
Internet-Drafts to try out this simple mechanism to discover whether
it is useful. Working group chairs are invited to suggest this
mechanism to document editors in their working groups, and to draw
the attention of their working group participants to Implementation
Status sections where they exist.
Following a community discussion, it was concluded that [<a href="./rfc3933" title=""A Model for IETF Process Experiments"">RFC3933</a>] is
not an appropriate framework for this experiment, primarily because
no change is required to any existing process.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Duration</span>
Given the typical time to produce an RFC (see [<a href="#ref-Stats" title=""Distribution of Processing Times"">Stats</a>]), we propose a
duration of 18 months for the experiment. Thus, 18 months after the
date of publication of this document as an RFC, the authors will
report on the experiment as described in the next section.
I-D authors are obviously free to include Implementation Status
sections in their documents even after the experiment has concluded.
<span class="grey">Sheffer & Farrel Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Summary Report</span>
The authors will summarize the results of the experiment at the end
of the period assigned to the experiment (see <a href="#section-5.1">Section 5.1</a>). If
nothing happens (no I-Ds or only a handful include an Implementation
Status section), an email to the IETF list will be sufficient. This
would obviously constitute a failure to adopt the idea and the
authors will abandon the experiment.
If this idea is adopted by document authors, a summary I-D will be
written containing the statistics of such adoption, as well as
(necessarily subjective) reports by working group members, chairs,
and area directors who have used this mechanism.
The authors may then propose more wide-scale use of the process and
might suggest more formal adoption of the process by the IETF.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Success Criteria</span>
The goal of this experiment is to improve the quality of IETF
specifications. This is impossible to quantify, of course. We
suggest that generally positive answers to the following questions
would indicate that the experiment was successful:
o Did the working group make decisions that were more informed when
comparing multiple competing solutions for the same work item?
o Did authors significantly modify proposed protocols based on
implementation experience?
o Did disclosure of implementations encourage more interoperability
testing than previously?
o Did non-authors review documents based on interactions with
running code and/or inspection of the code itself?
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This is a process document; therefore, it does not have a direct
effect on the security of any particular IETF protocol. However,
better-reviewed protocols are likely to also be more secure.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
We would like to thank Stephen Farrell, who reawakened community
interest in this topic. Several reviewers provided important input,
including Loa Andersson, Dave Crocker, Ned Freed, Christer Holmberg,
Denis Ovsienko, and Curtis Villamizar.
<span class="grey">Sheffer & Farrel Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6982">RFC 6982</a> Running Code July 2013</span>
This document was originally prepared using the lyx2rfc tool, and we
would like to thank Nico Williams, its author.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Informative References</span>
[<a id="ref-RFC1264">RFC1264</a>] Hinden, R., "Internet Engineering Task Force Internet
Routing Protocol Standardization Criteria", <a href="./rfc1264">RFC 1264</a>,
October 1991.
[<a id="ref-RFC3933">RFC3933</a>] Klensin, J. and S. Dawkins, "A Model for IETF Process
Experiments", <a href="https://www.rfc-editor.org/bcp/bcp93">BCP 93</a>, <a href="./rfc3933">RFC 3933</a>, November 2004.
[<a id="ref-RFC4794">RFC4794</a>] Fenner, B., "<a href="./rfc1264">RFC 1264</a> Is Obsolete", <a href="./rfc4794">RFC 4794</a>, December
2006.
[<a id="ref-Stats">Stats</a>] Arkko, J., "Distribution of Processing Times", December
2012, <<a href="http://www.arkko.com/tools/lifecycle/wgdistr.html">http://www.arkko.com/tools/lifecycle/wgdistr.html</a>>.
[<a id="ref-Tao">Tao</a>] Hoffman, P., Ed., "The Tao of IETF: A Novice's Guide to
the Internet Engineering Task Force", November 2012,
<<a href="http://www.ietf.org/tao.html">http://www.ietf.org/tao.html</a>>.
Authors' Addresses
Yaron Sheffer
Porticor
EMail: yaronf.ietf@gmail.com
Adrian Farrel
Juniper Networks
EMail: adrian@olddog.co.uk
Sheffer & Farrel Experimental [Page 9]
</pre>
|
