-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathrfc-eval.latest
2800 lines (1892 loc) · 111 KB
/
rfc-eval.latest
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
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group C. Huitema
Internet-Draft Private Octopus Inc.
Intended status: Informational October 25, 2020
Expires: April 28, 2021
Evaluation of a Sample of RFC Produced in 2018
draft-huitema-rfc-eval-project-07
Abstract
This document presents the author's effort to understand the delays
involved in publishing an idea in the IETF or through the Independent
Stream, from the first individual draft to the publication of the
RFC. We analyze a set of randomly chosen RFC approved in 2018,
looking for history and delays. We also use two randomly chosen sets
of RFC published in 2008 and 1998 for comparing delays seen in 2018
to those observed 10 or 20 years ago. The average RFC in the 2018
sample was produced in 3 years and 4 months, of which 2 years and 10
months were spent in the Working Group, 3 to 4 months for IETF
consensus and IESG review, and 3 to 4 months in RFC production. The
main variation in RFC production delays comes from the AUTH-48 phase.
We also measure the number of citations of the chosen RFC using
Semantic Scholar, and compare citation counts with what we know about
deployment. We show that citation counts indicate academic interest,
but correlate only loosely with deployment or usage of the
specifications. Counting web references could complement that.
The RFCs selected for this survey were chosen at random and represent
a small sample of all RFCs produced, and only approximately 10% of
the RFCs produced in each of 1998, 2008, and 2018. It is possible
that different samples would produce different results. Furthermore,
the conclusions drawn from the observations made in this document
represent the author's opinions and do not have consensus of the
IETF.
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/.
Huitema Expires April 28, 2021 [Page 1]
Internet-Draft RFC-Eval-2018 October 2020
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 April 28, 2021.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Defining the Important Milestones . . . . . . . . . . . . 5
2.2. Selecting a Random Sample of RFCs . . . . . . . . . . . . 6
3. Analysis of 20 Selected RFCs . . . . . . . . . . . . . . . . 6
3.1. 8411 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. 8456 . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. 8446 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. 8355 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5. 8441 . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6. 8324 . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.7. 8377 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.8. 8498 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.9. 8479 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.10. 8453 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.11. 8429 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.12. 8312 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.13. 8492 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.14. 8378 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.15. 8361 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.16. 8472 . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.17. 8471 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.18. 8466 . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.19. 8362 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Huitema Expires April 28, 2021 [Page 2]
Internet-Draft RFC-Eval-2018 October 2020
3.20. 8468 . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Analysis of Process and Delays . . . . . . . . . . . . . . . 19
4.1. First Draft to RFC Delays . . . . . . . . . . . . . . . . 20
4.2. Working Group Processing Time . . . . . . . . . . . . . . 25
4.3. Preparation and Publication Delays . . . . . . . . . . . 28
4.4. Copy Editing . . . . . . . . . . . . . . . . . . . . . . 31
4.5. Independent Stream . . . . . . . . . . . . . . . . . . . 34
5. Citation Counts . . . . . . . . . . . . . . . . . . . . . . . 34
5.1. Citation Numbers . . . . . . . . . . . . . . . . . . . . 35
5.2. Comparison to 1998 and 2008 . . . . . . . . . . . . . . . 37
5.3. Citations Versus Deployments . . . . . . . . . . . . . . 40
5.4. Citations Versus Web References . . . . . . . . . . . . . 42
6. Observations and Next Steps . . . . . . . . . . . . . . . . . 44
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
10. Informative References . . . . . . . . . . . . . . . . . . . 46
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction
As stated on the organization's web site, "The IETF is a large open
international community of network designers, operators, vendors, and
researchers concerned with the evolution of the Internet architecture
and the smooth operation of the Internet." The specifications
produced by the IETF are published in the RFC series, along with
independent submissions, research papers and IAB documents. In this
memo, the author attempts to understand the delays involved in
publishing an idea in the IETF or through the Independent Stream,
from the first individual draft to the publication of the RFC. This
is an individual effort, and the author's conclusions presented here
are personal. There was no attempt to seek IETF consensus.
The IETF keeps records of documents and process actions in the IETF
datatracker [TRKR]. The IETF datatracker provides information about
RFCs and drafts, from which we can infer statistics about the
production system. We can measure how long it takes to drive a
proposition from initial draft to final publication, and how these
delays can be split between Working Group discussions, IETF reviews,
IESG assessment, RFC Editor delays and final reviews by the authors -
or, for Independent Stream RFCs, draft production, reviews by the
Independent Stream Editor, conflict reviews, RFC Editor delays and
final reviews. Tracker data is available for all RFCs, not just IETF
stream RFCs.
Just measuring production delays may be misleading. If the IETF or
the editors of the other series simply rubber-stamped draft proposals
and published them, the delays would be short but the quality and
Huitema Expires April 28, 2021 [Page 3]
Internet-Draft RFC-Eval-2018 October 2020
impact might suffer. We hope that most of the RFC that are published
are useful, but we need a way to measure that usefulness. We try to
do that by measuring the number of references of the published RFCs
in Semantic Scholar [SSCH], and also by asking the authors of each
RFC in the sample whether the protocols and technologies defined in
the RFCs were implemented and used on the Internet. The citations
measured by the Semantic Scholar include citations in other RFCs and
in Internet drafts. We also measure the number of references on the
web, which provides some results but would be hard to automate.
In order to limit the resource required for this study, we selected
at random 20 RFCs published in 2018, as explained in Section 2.2.
The statistical sampling picked both IETF stream and Independent
Stream documents. For comparison purposes, we also selected at
random 20 RFC published in 1998 and 20 published in 2008. Limiting
the sample to 20 out of 209 RFCs published in 2018 allows for in
depth analysis of each RFC, but readers should be reminded that the
this is a small sample. The sample is too small to apply general
statistical techniques and quantify specific ratios, and discussions
of correlation techniques would be inappropriate. Instead, the
purpose is to identify trends, spot issues and document future work.
The information gathered for every RFC in the sample is presented in
Section 3. In Section 4 we analyze the production process and the
sources of delays, comparing the 2018 sample to the selected samples
for 1998 and 2018. In Section 5.1 we present citation counts for the
RFCs in the samples, and analyze whether citation counts could be
used to evaluate the quality of RFCs.
The measurement of delays could be automated by processing dates and
events recorded in the datatracker. The measurement of published
RFCs could be complemented by statistics on abandoned drafts, which
would measure the efficiency of the IETF triaging process. More
instrumentation would help understanding how large delays happen
during Working Group processes. These potential next steps are
developed in Section 6.
2. Methodology
The study reported here started with a simple idea: take a sample of
RFCs, and perform an in-depth analysis of the path from the first
presentation of the idea to its publication, while also trying to
access the success of the resulting specification. This requires
defining the key milestones that we want to track, and drawing a
random sample using an unbiased process.
Huitema Expires April 28, 2021 [Page 4]
Internet-Draft RFC-Eval-2018 October 2020
2.1. Defining the Important Milestones
The IETF datatracker records a list of events for each document
processed by IETF Working Groups. This has a high granularity, and
also a high variability. Most documents start life as an individual
draft, are adopted by a Working Group, undergo a Working Group last
call, are submitted to the IESG, undergo an IETF last call and an
IESG review, get eventually approved by the IESG, and are processed
for publication by the RFC Editor, but there are exceptions. Some
documents are first submitted to one Working Group and then moved to
another. Some documents are published through the Independent
Stream, and are submitted to the Independent Stream Editor instead of
the IESG.
In order to simplify tabulation, we break the delay from between the
submission of the first draft and the publication of the RFC in three
big components:
o The Working Group processing time, from the first draft to the
start of the IETF last call;
o The IETF processing time, which lasts from the beginning of the
IETF last call to the approval by the IESG, including the reviews
by various directorates;
o The RFC production, from approval by the IESG to publication,
including the AUTH-48 reviews.
For submissions to the Independent Stream, we don't have a Working
Group. We consider instead the progression of the individual draft
until the adoption by the ISE as the equivalent of the "Working
Group" period, and the delay from adoption by the ISE until
submission to the RFC Editor as the equivalent of the IETF delay.
We measure the staring point of the process using the date of
submission of the first draft listed on that RFC page in the IETF
datatracker. In most case, this first draft is an individual draft
that then resubmitted as a Working Group draft, or maybe resubmitted
with a new name as the draft was searching for a home in an IETF
Working Group, or before deciding for submission on the Independent
Stream.
The IETF datatracker entries for RFCs and drafts do not list Working
Group events like Working Group Last Call. The only intermediate
event that we list between the first draft and the submission to the
IESG is the Working Group Adoption. For that, we use the date of
submission of the version 00 of the draft eventually published as
Huitema Expires April 28, 2021 [Page 5]
Internet-Draft RFC-Eval-2018 October 2020
RFC. We use the same definition for drafts submitted to the
Independent Stream.
2.2. Selecting a Random Sample of RFCs
Basic production mechanisms could be evaluated by processing data
from the IETF datatracker, but subjective data requires manual
assessment of results, which can be time consuming. Since our
resources are limited, we will only perform this analysis for a small
sample of RFCs, selected at random from the list of RFCs approved in
2018. Specifically, we will pick 20 RFC numbers at random between:
o RFC 8307, published in January 2018, and
o RFC 8511, published December 2018.
The list of 20 selected RFCs is: RFC 8411, RFC 8456, RFC 8446, RFC
8355, RFC 8441, RFC 8324, RFC 8377, RFC 8498, RFC 8479, RFC 8453, RFC
8429, RFC 8312, RFC 8492 , RFC 8378, RFC 8361, RFC 8472, RFC 8471,
RFC 8466, RFC 8362, and RFC 8468.
When evaluating delays and impact, we will compare the year 2018 to
2008 and 1998, 10 and 20 years ago. To drive this comparison, we
pick 20 RFCs at random among those published in 2008, and another 20
among those published in 1998.
The list of the 20 randomly selected RFCs from 2008 is: RFC 5227, RFC
5174, RFC 5172, RFC 5354, RFC 5195, RFC 5236, RFC 5348, RFC 5281, RFC
5186, RFC 5326, RFC 5277, RFC 5373, RFC 5404, RFC 5329, RFC 5283, RFC
5358, RFC 5142, RFC 5271, RFC 5349, and RFC 5301.
The list of the 20 randomly selected RFCs from 2008 is: RFC 2431, RFC
2381, RFC 2387, RFC 2348, RFC 2391, RFC 2267, RFC 2312, RFC 2448, RFC
2374, RFC 2398, RFC 2283, RFC 2382, RFC 2289, RFC 2282, RFC 2404, RFC
2449, RFC 2317, RFC 2394, RFC 2297, and RFC 2323.
3. Analysis of 20 Selected RFCs
We review each of the RFCs listed in Section 2.2 for the year 2018,
trying both to answer the known questions and to gather insight for
further analyzes. In many cases, the analysis of the data is
complemented by direct feedback from the RFC authors.
3.1. 8411
IANA Registration for the Cryptographic Algorithm Object Identifier
Range [RFC8411]:
Huitema Expires April 28, 2021 [Page 6]
Internet-Draft RFC-Eval-2018 October 2020
Informational, 5 pages
4 drafts (personal), first 2017-05-08.
Last call announced 2017-10-09
IESG evaluation starts 2017-12-28
Approved 2018-02-26, draft 03
AUTH-48 2018-04-20
AUTH-48 complete 2018-07-17
Published 2018-08-06
IANA action: create table
This RFC was published from the individual draft, which was not
resubmitted as a Working Group draft.
The draft underwent minor copy edit before publication.
Some but not all of the long delay in AUTH-48 is due to clustering
with [RFC8410]. MISSREF was cleared on 2018-05-09 and the document
re-entered AUTH-48 at once. AUTH-48 lasted over two months after
that.
The time after AUTH-48 and before publication (3 weeks) partly
overlaps with travel for IETF-102 and is partly due to coordinating
the cluster.
3.2. 8456
Benchmarking Methodology for Software-Defined Networking (SDN)
Controller Performance [RFC8456]:
Informational, 64 pages
2 personal drafts, 9 WG drafts, first 2015-03-23
WG adoption on 2015-10-18
Last call announced 2018-01-19
IESG evaluation starts 2018-02-27
IESG approved 2018-05-25
AUTH-48 2018-08-31
AUTH-48 complete 2018-10-16
Published 2018-10-30
The draft underwent very extensive copy editing, covering use of
articles, turn of phrases, choice of vocabulary. The changes are
enough to cause pagination differences. The "diff" tool marks pretty
much every page as changed. Some diagrams see change in protocol
elements like message names.
According to the author, the experience of producing this draft
mirrors a typical one in the Benchmarking Methodologies Working Group
(BMWG). There were multiple authors in multiple time zones, which
Huitema Expires April 28, 2021 [Page 7]
Internet-Draft RFC-Eval-2018 October 2020
slowed down the AUTH-48 process somewhat, although the AUTH-48 delay
of 46 days is only a bit longer than the average draft.
The RFC was part of cluster with [RFC8455].
BMWG publishes informational RFCs centered around benchmarking, and
the methodologies in RFC 8456 have been implemented in benchmarking
products.
3.3. 8446
The Transport Layer Security (TLS) Protocol Version 1.3 [RFC8446], as
the title indicates, defines the new version of the TLS protocol.
From the IETF datatracker, we extract the following:
Proposed standard
160 pages
29 WG drafts first 2014-04-17.
Last call announced 2018-02-15
IESG evaluation starts 2018-03-02
Approved 2018-03-21, draft 28
AUTH-48 2018-06-14
AUTH-48 complete 2018-08-10
Published 2018-08-10
This draft started as a WG effort.
The RFC was a major effort in the IETF. Working Group members
developed and tested several implementations. Researchers analyzed
the specifications and performed formal verifications. Deployment
tests outlined issues that caused extra work when the specification
was almost ready. These complexity largely explains the time spent
in the Working Group.
Comparing the final draft to the published version, we find
relatively light copy editing. It includes explaining acronyms on
first use, clarifying some definitions standardizing punctiation and
capitalization, and spelling out some numbers in text. This
generally fall in the category of "style", although some of the
clarifications go into message definitions. However, that simple
analysis does not explain why the AUTH-48 phase took almost two
months.
This document's AUTH-48 process was part of the "Github experiment",
which tried to use github pull requests to track the AUTH-48 changes
and review comments. The RPC staff had to learn using Github for
that process, and this required more work than the usual RFC. Author
and AD thoroughly reviewed each proposed edit, accepting some and
Huitema Expires April 28, 2021 [Page 8]
Internet-Draft RFC-Eval-2018 October 2020
rejecting some. The concern there was that any change in a complex
specification might affect a protocol that was extensively reviewed
in the Working Group, but of course these reviews added time to the
AUTH-48 delays.
There are 21 implementations listed in the Wiki of the TLS 1.3
project [TLS13IMP]. It has been deployed on major browsers, and is
already used in a large fraction of TLS connections.
3.4. 8355
Resiliency Use Cases in Source Packet Routing in Networking (SPRING)
Networks [RFC8355] is an informational RFC. It originated from a use
case informational draft that was mostly used for the BOF creating
the WG, and then to drive initial work/evolutions from the WG.
Informational, 13 pages.
2 personal drafts (personal), first 2014-01-31. 13 WG drafts.
WG adoption on 2014-05-13
Last call announced 2017-04-20
IESG evaluation starts 2017-05-04, draft 09
Approved 2017-12-19, draft 12
AUTH-48 2018-03-12
AUTH-48 complete 2018-03-27
Published 2018-03-28
Minor set of copy edits, mostly for style.
No implementation of the RFC itself, but the technology behind it
such as Segment Routing (architecture RFC 8402, TI-LFA draft-ietf-
rtgwg-segment-routing-ti-lfa) is widely implemented and deployment is
ongoing.
According to participants in the discussion, the process of adoption
of the source packet routing standards was very contentious. The
establishment of consensus at both the Working Group level and the
IETF level was difficult and time consuming.
3.5. 8441
Bootstrapping WebSockets with HTTP/2 [RFC8441]
Huitema Expires April 28, 2021 [Page 9]
Internet-Draft RFC-Eval-2018 October 2020
Proposed standard, 8 pages. Updates RFC 6455.
3 personal drafts (personal), first 2017-10-15. 8 WG drafts.
WG adoption on 2017-12-19
Last call announced 2018-05-07, draft 05
IESG evaluation starts 2018-05-29, draft 06
Approved 2018-06-07, draft 07
AUTH-48 2018-08-13
AUTH-48 complete 2018-09-15
Published 2018-09-21
IANA Action: table entries
This RFC defines the support of WebSockets in HTTP/2, which is
different from the mechanism defined for HTTP/1.1 in [RFC6455]. The
process was relatively straightforward, involving the usual type of
discussions, some on details and some on important points.
Comparing final draft and published RFC shows a minor set of copy
edit, mostly for style. However, the author recalls a painful
process. The RFC includes many charts and graphs that were very
difficult to format correctly in the author's production process that
involve conversions from markdown to XML, and then from XML to text.
The author had to get substantial help from the RFC editor.
There are several implementations, including Firefox and Chrome,
making RFC 8441 a very successful specification.
3.6. 8324
DNS Privacy, Authorization, Special Uses, Encoding, Characters,
Matching, and Root Structure: Time for Another Look? [RFC8324].
This is an opinion piece on DNS development, published on the
Independent Stream.
Informational, 29 pages. Independent Stream.
5 personal drafts (personal), first 2017-06-02.
ISE review started 2017-07-10, draft 03
IETF conflict review and IESG review started 2017-10-29
Approved 2017-12-18, draft 04
AUTH-48 2018-01-29, draft 05
AUTH-48 complete 2018-02-26
Published 2018-02-27
This RFC took only 9 months from first draft to publication, which is
the shortest in the 2018 sample set. In part, this is because the
text was privately circulated and reviewed by ISE designated experts
before the first draft was published. The nature of the document is
another reason for the short delay. It is an opinion piece, and does
Huitema Expires April 28, 2021 [Page 10]
Internet-Draft RFC-Eval-2018 October 2020
not require the same type of consensus building and reviews than a
protocol specification.
Comparing the final draft and the published version shows only minor
copy edit, mostly for style. According to the author, because this
is because he knows how to write in RFC Style with the result that
his documents often need a minimum of editing. He also makes sure
that the document on which the Production Center starts working
already has changes discussed and approved during Last Call and IESG
review incorporated rather than expecting the Production Center to
operate off of notes about changed to be made.
3.7. 8377
Transparent Interconnection of Lots of Links (TRILL): Multi-Topology
[RFC8377]
Proposed standard, 20 pages. Updates RFC 6325, 7177.
3 personal drafts (personal), first 2013-09-03. 7 WG drafts.
WG adoption on 2015-09-01
Last call announced 2018-02-19, draft 05
IESG evaluation starts 2018-03-02, draft 06
Approved 2018-03-12, draft 05
AUTH-48 2018-04-20, draft 06
AUTH-48 complete 2018-07-31
Published 2018-07-31
IANA Table, table entries
Minor set of copy edits, mostly for style, also clarity.
3.8. 8498
A P-Served-User Header Field Parameter for an Originating Call
Diversion (CDIV) Session Case in the Session Initiation Protocol
(SIP) [RFC8498].
Informational, 15 pages.
5 personal drafts (personal), first 2016-03-21. 9 WG drafts.
WG adoption on 2017-05-15
Last call announced 2018-10-12, draft 05
IESG evaluation starts 2018-11-28, draft 07
Approved 2018-12-10, draft 08
AUTH-48 2019-01-28
AUTH-48 complete 2019-02-13
Published 2019-02-15
IANA Action, table rows added.
Copy edit for style, but also clarification of ambiguous sentences.
Huitema Expires April 28, 2021 [Page 11]
Internet-Draft RFC-Eval-2018 October 2020
3.9. 8479
Storing Validation Parameters in PKCS#8 [RFC8479]
Informational, 8 pages. Independent Stream.
5 personal drafts (personal), first 2017-08-08.
ISE review started 2018-12-10, draft 00
IETF conflict review and IESG review started 2018-03-29
Approved 2018-08-20, draft 03
AUTH-48 2018-09-20, draft 04
AUTH-48 complete 2018-09-25
Published 2018-09-26
The goal of the draft was to document what the gnutls implementation
was using for storing provably generated RSA keys. This is a short
RFC that was published relatively quickly, although discussion
between the author, the Independent Series Editor and the IESG lasted
several months. In the initial conflict review, The IESG asked the
ISE to not publish this document before IETF Working Groups had an
opportunity to pick up the work. The author met that requirement by
a presentation to the SECDISPATCH WG in IETF 102. Since no WG was
interested in pickup the work, the document progressed on the
Independent Stream.
Very minor set of copy edit, moving some references from normative to
informative.
The author is not aware of other implementations than gnutls relying
on this RFC.
3.10. 8453
Framework for Abstraction and Control of TE Networks (ACTN) [RFC8453]
Informational, 42 pages.
3 personal drafts, first 2015-06-15. 16 WG drafts.
WG adoption on 2016-07-15
Out of WG 2018-01-26, draft 11
Expert review requested, 2018-02-13
Last call announced 2018-04-16, draft 13
IESG evaluation starts 2018-05-16, draft 14
Approved 2018-06-01, draft 15
AUTH-48 2018-08-13
AUTH-48 complete 2018-08-20
Published 2018-08-20
IANA Action, table rows added.
Minor copy editing.
Huitema Expires April 28, 2021 [Page 12]
Internet-Draft RFC-Eval-2018 October 2020
3.11. 8429
Deprecate Triple-DES (3DES) and RC4 in Kerberos [RFC8429]
BCP, 10 pages.
6 WG drafts, first 2017-05-01.
Last call announced 2017-07-16, draft 03
IESG evaluation starts 2017-08-18, draft 04
Approved 2018-05-25, draft 05
AUTH-48 2018-07-24
AUTH-48 complete 2018-10-31
Published 2018-10-31
IANA Action, table rows added.
This draft started as a Working Group effort.
This RFC recommends to deprecate two encryption algorithms that are
now considered obsolete and possibly broken. The document was sent
back to the WG after the first last call, edited, and then there was
a second last call. The delay from first draft to Working Group last
call was relatively short, but the number may be misleading. The
initial draft was a replacement of a similar draft in the KITTEN
Working Group, which stagnated for some time before the CURDLE
Working Group took up the work. The deprecation of RC4 was somewhat
contentious, but the WG had already debated this prior to the
production of this draft, and the draft was not delayed by this
debate.
Most of the 280 days between IETF LC and IESG approval was because
the IESG had to talk about whether this document should obsolete or
move to historic RFC 4757, and no one was really actively pushing
that discussion for a while.
The 99 days in AUTH-48 are mostly because one of the authors was a
sitting AD, and those duties ended up taking precedence over
reviewing this document.
Minor copy editing, for style.
The implementation of the draft would be the actual removal of
support for 3DES and RC4 in major implementations. This is
happening, but very slowly.
3.12. 8312
CUBIC for Fast Long-Distance Networks [RFC8312]
Huitema Expires April 28, 2021 [Page 13]
Internet-Draft RFC-Eval-2018 October 2020
Informational, 18 pages.
2 personal drafts, first 2014-09-01. 8 WG drafts
WG adoption on 2015-06-08
Last call announced 2017-09-18, draft 06
IESG evaluation starts 2017-11-14
Approved 2017-10-04, draft 07
AUTH-48 2018-01-08
AUTH-48 complete 2018-02-07
Published 2018-02-07
IANA Action, table rows added.
Minor copy editing, for style.
The TCP congestion control algorithm Cubic was defined first in 2005,
was implemented in Linux soon after, and was implemented in major
OSes after that. After some debates from 2015 to 2015, the TCPM
Working Group adopted the draft, with a goal of documenting Cubic in
the RFc series. According to the authors, this was not a high
priority effort, as Cubic was already implemented in multiple OSes
and documented in research papers. At some point, only one of the
authors was actively working on the draft. Ths may explain why
another two years was spent progressing the draft after adoption by
the WG.
The RFC publication may or may not have triggered further
implementations. On the other hand, several OSes picked up bug fixes
from the draft and the RFC.
3.13. 8492
Secure Password Ciphersuites for Transport Layer Security (TLS)
[RFC8492]
Informational, 40 pages. (Independent Stream)
10 personal drafts, first 2012-09-07. 8 WG drafts
Targeted to ISE stream 2016-08-05
ISE review started 2017-05-10, draft 01
IETF conflict review and IESG review started 2017-09-04
Approved 2017-10-29, draft 04
AUTH-48 2018-10-19, draft 05
AUTH-48 complete 2019-02-19
Published 2019-02-21
IANA Action, table rows added.
This RFC has a complex history. The first individual draft was
submitted to the TLS Working Group on September 7, 2012. It
progressed there, and was adopted by the WG after 3 revisions. There
were then 8 revisions in the TLS WG, until the WG decided to not
Huitema Expires April 28, 2021 [Page 14]
Internet-Draft RFC-Eval-2018 October 2020
progress it. The draft was parked in 2013 by the WG chairs after
failing to get consensus in WG last call. The AD finally pulled the
plug in 2016, and the draft was then resubmitted to the ISE.
At that point, the author was busy and was treating this RFC with a
low priority because, in his words, it would not be a "real RFC".
There were problems with the draft that only came up late. In
particular, it had to wait for a change in registry policy that only
came about with the publication of TLS 1.3, which caused the draft to
only be published after RFC 8446, and also required adding references
to TLS 1.3. The author also got a very late comment while in AUTH-48
that caused some rewrite. Finally, there was some IANA issue with
the extension registry where a similar extension was added by someone
else. The draft was changed to just use it.
Changes in AUTH-48 include added reference to TLS 1.3, copy-editing
for style, some added requirements, added paragraphs, and changes in
algorithms specification.
3.14. 8378
Signal-Free Locator/ID Separation Protocol (LISP) Multicast [RFC8378]
is an experimental RFC, defining how to implement Multicast in the
LISP architecture.
Experimental, 21 pages.
5 personal drafts, first 2014-02-28. 10 WG drafts
WG adoption on 2015-12-21
Last call announced 2018-02-13, draft 07
IESG evaluation starts 2018-02-28, draft 08
Approved 2018-03-12, draft 09
AUTH-48 2018-04-23
AUTH-48 complete 2018-05-02
Published 2018-05-02
Preparing the RFC took more than 4 years. According to the authors,
they were not aggressive pushing it and just let the Working Group
process decide to pace it. They also did implementations during that
time.
Minor copy editing, for style.
The RFC was implemented by lispers.net and cisco, and was used in
doing IPv6 multicast over IPv4 unicast/multicast at the Olympics in
PyeungChang. The plan is to work on a proposedstandard once the
experiment concludes.
Huitema Expires April 28, 2021 [Page 15]
Internet-Draft RFC-Eval-2018 October 2020
3.15. 8361
Transparent Interconnection of Lots of Links (TRILL): Centralized
Replication for Active-Active Broadcast, Unknown Unicast, and
Multicast (BUM) Traffic [RFC8361]
Proposed Standard, 17 pages.
3 personal drafts, first 2013-11-12. 14 WG drafts
WG adoption on 2014-12-16
Last call announced 2017-11-28, draft 10
IESG evaluation starts 2017-12-18, draft 11
Approved 2018-01-29, draft 13
AUTH-48 2018-03-09
AUTH-48 complete 2018-04-09
Published 2018-04-12
According to the authors, the long delays in producing this RFC was
due to a slow uptake of the technology in the industry.
Minor copy editing, for style.
There was at least 1 partial implementation.
3.16. 8472
Transport Layer Security (TLS) Extension for Token Binding Protocol
Negotiation [RFC8472]
Proposed Standard, 8 pages.
1 personal drafts, 2015-05-29. 15 WG drafts
WG adoption on 2015-09-11
Last call announced 2017-11-13, draft 10
IESG evaluation starts 2018-03-19
Approved 2018-07-20, draft 14
AUTH-48 2018-09-17
AUTH-48 complete 2018-09-25
Published 2018-10-08
This is a pretty simple document, but it took over 3 years from
individual draft to RFC. According to the authors,the biggest
setbacks occurred at the start: it took a while to find a home for
this draft. It was presented in the TLS WG (because it's a TLS
extension) and UTA WG (because it has to do with applications using
TLS). Then the ADs determined that a new WG was needed, so the
authors had to work through the WG creation process, including
running a BOF.
Huitema Expires April 28, 2021 [Page 16]
Internet-Draft RFC-Eval-2018 October 2020
Minor copy editing, for style, with the addition of a reference to
TLS 1.3.
Perhaps partially due to the delays, some of the implementers lost
interest in supporting this RFC.
3.17. 8471
The Token Binding Protocol Version 1.0 [RFC8471]
Proposed Standard, 18 pages.
1 personal drafts, 2014-10-13. 19 WG drafts
WG adoption on 2015-03-15
Last call announced 2017-11-13, draft 16
IESG evaluation starts 2018-03-19
Approved 2018-07-20, draft 19
AUTH-48 2018-09-17
AUTH-48 complete 2018-09-25
Published 2018-10-08
Presentation of a Token Binding Protocol for TLS. We can notice a
delay of 5 months before adoption of the draft by the WG. That
explains in part the overall delay of almost 4 years from first draft
to publication.
Minor copy editing, for style.
The web references indicates adoption in multiple development
projects.
3.18. 8466
A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service
Delivery [RFC8466]
Proposed Standard, 158 pages.
5 personal drafts, first 2016-09-01. 11 WG drafts
WG adoption on 2017-02-26
Last call announced 2018-02-21, draft 07
IESG evaluation starts 2018-03-14, draft 08
Approved 2018-06-25, draft 10
AUTH-48 2018-09-17
AUTH-48 complete 2018-10-09
Published 2018-10-12
Copy editing for style and clarity, with also corrections to the yang
model.
Huitema Expires April 28, 2021 [Page 17]
Internet-Draft RFC-Eval-2018 October 2020
3.19. 8362
OSPFv3 Link State Advertisement (LSA) Extensibility [RFC8362] is a
major extension to the OSPF protocol. It makes OSPFv3 fully
extensible.
Proposed Standard, 33 pages.
4 personal drafts, first 2013-02-17. 24 WG drafts
WG adoption on 2013-10-15
Last call announced 2017-12-19, draft 19
IESG evaluation starts 2018-01-18, draft 20
Approved 2018-01-29, draft 23
AUTH-48 2018-03-19
AUTH-48 complete 2018-03-30
Published 2018-04-03
The specification was first submitted as a personal draft in the IPv6
WG, then moved to the OSPF WG. The long delay of producing this RFC
is due to the complexity of the problem, and the need to wait for
implementations. It is a very important change to OSPF that makes
OSPFv3 fully extensible. Since it was a non-backward compatible
change, the developers started out with some very complex migration
scenarios but ended up with either legacy or extended OSPFv3 LSAs
within an OSPFv3 routing domain. The initial attempts to have a
hybrid mode of operation with both legacy and extended LSAs also
delayed implementation due to the complexity.
Copy editing for style and clarity.
This specification either was or will be implemented by all the
router vendors.
3.20. 8468
IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance
Metrics (IPPM) Framework [RFC8468].
Informational, 15 pages.
3 personal drafts, first 2015-08-06. 7 WG drafts
WG adoption on 2016-07-04
Last call announced 2018-04-11, draft 04
IESG evaluation starts 2018-05-24, draft 05
Approved 2018-07-10, draft 06
AUTH-48 2018-09-13