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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
|
<pre>Network Working Group L. Daigle, Ed.
Request for Comments: 4844
Category: Informational Internet Architecture Board
(IAB)
July 2007
<span class="h1">The RFC Series and RFC Editor</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document describes the framework for an RFC Series and an RFC
Editor function that incorporate the principles of organized
community involvement and accountability that has become necessary as
the Internet technical community has grown, thereby enabling the RFC
Series to continue to fulfill its mandate.
<span class="grey">Daigle & IAB Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. RFC Series Mission . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Roles and Responsibilities . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. RFC Editor . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. IAB . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.3">3.3</a>. Operational Oversight . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.4">3.4</a>. Policy Oversight . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4">4</a>. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Document Approval . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1.1">4.1.1</a>. Definition . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1.2">4.1.2</a>. Operational Implementation . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1.3">4.1.3</a>. Process Change . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.1.4">4.1.4</a>. Existing Approval Process Documents . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. Editing, Processing, and Publication of Documents . . . . <a href="#page-8">8</a>
<a href="#section-4.2.1">4.2.1</a>. Definition . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2.2">4.2.2</a>. Operational Implementation . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2.3">4.2.3</a>. Process Change . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.2.4">4.2.4</a>. Existing Process Documents . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.3">4.3</a>. Archiving, Indexing, and Accessibility . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.3.1">4.3.1</a>. Definition . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.3.2">4.3.2</a>. Operational Implementation . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.3.3">4.3.3</a>. Process Change . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.3.4">4.3.4</a>. Existing Process Documents . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Series-Wide Guidelines and Rules . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4.1">4.4.1</a>. Definition . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4.2">4.4.2</a>. Operational Implementation . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4.3">4.4.3</a>. Process Change . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4.4">4.4.4</a>. Existing Process Documents . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5">5</a>. RFC Streams . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.1">5.1</a>. RFC Approval Processes . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.1.1">5.1.1</a>. IETF Document Stream . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.1.2">5.1.2</a>. IAB Document Stream . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.1.3">5.1.3</a>. IRTF Document Stream . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.1.4">5.1.4</a>. Independent Submission Stream . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. RFC Technical Publication Requirements . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2.1">5.2.1</a>. IETF Documents . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2.2">5.2.2</a>. IAB Documents . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2.3">5.2.3</a>. IRTF Documents . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2.4">5.2.4</a>. Independent Submissions . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. IAB Members at the Time of Approval . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. Informative References . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. A Retrospective of IAB Charters and RFC Editor . . . <a href="#page-17">17</a>
<a href="#appendix-A.1">A.1</a>. 1992 . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-A.2">A.2</a>. 1994 . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#appendix-A.3">A.3</a>. 2000 . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="grey">Daigle & IAB Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The first Request for Comments (RFC) document was published in April
of 1969 as part of the effort to design and build what we now know of
as the Internet. Since then, the RFC Series has been the archival
series dedicated to documenting Internet technical specifications,
including both general contributions from the Internet research and
engineering community as well as standards documents.
As described in the history of the first 30 years of RFCs
([<a href="./rfc2555" title=""30 Years of RFCs"">RFC2555</a>]), the RFC Series was created for the purpose of capturing
the research and engineering thought that underlie the design of
(what we now know of as) the Internet. As the Internet Engineering
Task Force (IETF) was formalized to carry out the discussion and
documentation of Internet standards, IETF documents have become a
large part (but not the entirety) of the RFC Series.
As the IETF has grown up and celebrated its own 20 years of history,
its requirements for archival publication of its output have changed
and become more rigorous. Perhaps most significantly, the IETF must
be able to define (based on its own open consensus discussion
processes and leadership directions) and implement adjustments to its
publication processes.
At the same time, the Internet engineering and research community as
a whole has grown and come to require more openness and
accountability in all organizations supporting it. More than ever,
this community needs an RFC Series that is supported (operationally
and in terms of its principles) such that there is a balance of:
o expert implementation;
o clear management and direction -- for operations and evolution
across the whole RFC Series (whether originating in the IETF or
not); and
o appropriate community input into and review of activities.
Today, there is confusion and therefore sometimes tension over where
and how to address RFC issues that are particular to contributing
groups (e.g., the IETF, the Internet Architecture Board (IAB), or
independent individuals). It isn't clear where there should be
community involvement versus RFC Editor control; depending on the
issue, there might be more or less involvement from the IAB, the
Internet Engineering Steering Group (IESG), or the community at
large. There are similar issues with handling RFC Series-wide issues
-- where to discuss and resolve them in a way that is balanced across
the whole series.
<span class="grey">Daigle & IAB Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
For example, there are current discussions about Intellectual
Property Rights (IPR) for IETF-generated documents, but it's not
clear when or how to abstract the portions of those discussions that
are relevant to the rest of the RFC Series. Discussions of labeling
(of RFCs in general, IETF documents in particular, or some
combination thereof) generally must be applied on an RFC Series-wide
basis or not at all. Without an agreed-on framework for managing the
RFC Series, it is difficult to have those discussions in a non-
polarized fashion -- either the IETF dictating the reality of the
rest of the RFC Series, or the RFC Series imposing undue restrictions
on the IETF document series.
As part of its charter (see <a href="#appendix-A">Appendix A</a>), the IAB has a responsibility
for the RFC Editor. Acknowledging the IETF's and the general
Internet engineering and research community's evolving needs, the IAB
would like to see a future for the RFC Series that continues to meet
its original mandate of providing the archival series for the
technical research and engineering documentation that describes the
Internet.
With this document, the IAB provides the framework for the RFC Series
and an RFC Editor function with the specific purpose of ensuring that
the RFC Series is maintained and supported in ways that are
consistent with the stated purpose of the RFC Series and the
realities of today's Internet research and engineering community.
The framework describes the existing "streams" of RFCs, draws a
roadmap of existing process documents already defining the
implementation, and provides clear direction of how to evolve this
framework and its supporting pieces through discussion and future
document revision.
Specifically, this document provides a brief charter for the RFC
Series, describes the role of the RFC Editor, the IAB, and the IETF
Administrative Support Activity (IASA) in a framework for managing
the RFC Series, and discusses the streams of input to the RFC Series
from the various constituencies it serves.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. RFC Series Mission</span>
The RFC Series is the archival series dedicated to documenting
Internet technical specifications, including general contributions
from the Internet research and engineering community as well as
standards documents.
RFCs are available free of charge to anyone via the Internet.
<span class="grey">Daigle & IAB Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Roles and Responsibilities</span>
As this document sets out a revised framework for supporting the RFC
Series mission, this section reviews the updated roles and
responsibilities of the entities that have had, and will have,
involvement in continued support of the mission.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. RFC Editor</span>
Originally, there was a single person acting as editor of the RFC
Series (the RFC Editor). The task has grown, and the work now
requires the organized activity of several experts, so there are RFC
Editors, or an RFC Editor organization. In time, there may be
multiple organizations working together to undertake the work
required by the RFC Series. For simplicity's sake, and without
attempting to predict how the role might be subdivided among them,
this document refers to this collection of experts and organizations
as the "RFC Editor".
The RFC Editor is an expert technical editor and series editor,
acting to support the mission of the RFC Series. As such, the RFC
Editor is the implementer handling the editorial management of the
RFC Series, in accordance with the defined processes. In addition,
the RFC Editor is expected to be the expert and prime mover in
discussions about policies for editing, publishing, and archiving
RFCs.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. IAB</span>
In this model, the role of the IAB is to ensure that the RFC Series
mission is being appropriately fulfilled for the whole community for
which it was created. The IAB does not, organizationally, have
comprehensive publishing or editorial expertise. Therefore, the role
of the IAB as put forward in this document is focused on ensuring
that principles are met, the appropriate bodies and communities are
duly informed and consulted, and the RFC Editor has what it needs in
order to execute on the material that is in their mandate.
It is the responsibility of the IAB to approve the appointment of the
RFC Editor and to approve the general policy followed by the RFC
Editor.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Operational Oversight</span>
The IETF Administrative Support Activity (<a href="https://www.rfc-editor.org/bcp/bcp101">BCP 101</a>, [<a href="#ref-BCP101" title=""Structure of the IETF Administrative Support Activity (IASA)"">BCP101</a>]) was
created to provide administrative support for the IETF, the IAB, and
the Internet Research Task Force (IRTF). In its role of supporting
<span class="grey">Daigle & IAB Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
the IAB, the IASA is tasked with providing the funding for and
operational oversight of the RFC Editor.
The IAOC (IETF Administrative Oversight Committee) is the oversight
board of the IASA, and the IAD (IETF Administrative Director) is the
chief actor for the IASA.
The IAOC works with the IAB to identify suitable persons or entities
to fulfill the mandate of the RFC Editor.
The IAOC establishes appropriate contractual agreements with the
selected persons or entities to carry out the work that will satisfy
the technical publication requirements defined for the various RFC
input streams (see <a href="#section-5.2">Section 5.2</a>). The IAOC may define additional
operational requirements and policies for management purposes to meet
the requirements defined by the various communities.
In accordance with <a href="https://www.rfc-editor.org/bcp/bcp101">BCP 101</a>, the IAOC provides oversight of the
operation of the RFC Editor activity based on the established
agreements.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Policy Oversight</span>
The IAB monitors the effectiveness of the policies in force and their
implementation to ensure that the RFC Editor activity meets the
editorial management and document publication needs as referenced in
this document. In the event of serious non-conformance, the IAB,
either on its own initiative or at the request of the IAOC, may
require the IAOC to vary or terminate and renegotiate the
arrangements for the RFC Editor activity.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Framework</span>
With the RFC Series mission outlined above, this document describes a
framework for supporting
o the operational implementation of the RFC Series,
based on
o public process and definition documents,
for which there are
o clear responsibilities and mechanisms for update and change.
<span class="grey">Daigle & IAB Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
Generally speaking, the RFC Editor is responsible for the operational
implementation of the RFC Series. As outlined in <a href="#section-3.3">Section 3.3</a>, the
IAD provides the oversight of this operational role.
The process and definition documents are detailed below, including
responsibility for the individual process documents (maintenance and
update). The RFC Editor works with the appropriate community to
ensure that the process documents reflect current requirements. The
IAB is charged with the role of verifying that appropriate community
input has been sought and that any changes appropriately account for
community requirements.
There are 3 categories of activity, and a 4th category of series-wide
rules and guidelines, described for implementing the RFC Series to
support its mission:
o Approval of documents.
o Editing, processing, and publication of documents.
o Archiving and indexing the documents and making them accessible.
o Series rules and guidelines.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Document Approval</span>
The RFC Series mission implicitly requires that documents be reviewed
and approved for acceptance into the series.
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Definition</span>
<a href="#section-5.1">Section 5.1</a> describes the different streams of documents that are put
to the RFC Editor for publication as RFCs today. While there may be
general policies for approval of documents as RFCs (to ensure the
coherence of the RFC Series), there are also policies defined for the
approval of documents in each stream. Generally speaking, there is a
different approving body for each stream. The current definitions
are catalogued in <a href="#section-5.1">Section 5.1</a>.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Operational Implementation</span>
Each stream has its own documented approval process. The RFC Editor
is responsible for the approval of documents in one of the streams
(Independent Submission stream, see <a href="#section-5.1.4">Section 5.1.4</a>) and works with the
other approving bodies to ensure smooth passage of approved documents
into the next phases, ultimately to publication and archiving as an
RFC.
<span class="grey">Daigle & IAB Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Process Change</span>
From time to time, it may be necessary to change the approval
processes for any given stream, or even add or remove streams. This
may occur when the RFC Editor, the IAB, the body responsible for a
given stream of documents, or the community determines that there are
issues to be resolved in general for RFC approval or for per-stream
approval processes.
In this framework, the general approach is that the IAB will work
with the RFC Editor and other parties to get community input and it
will verify that any changes appropriately account for community
requirements.
<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>. Existing Approval Process Documents</span>
The existing documents describing the approval processes for each
stream are detailed in <a href="#section-5.1">Section 5.1</a>.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Editing, Processing, and Publication of Documents</span>
Producing and maintaining a coherent, well-edited document series
requires specialized skills and subject matter expertise. This is
the domain of the RFC Editor. Nevertheless, the community served by
the RFC Series and the communities served by the individual streams
of RFCs have requirements that help define the nature of the series.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Definition</span>
General and stream-specific requirements for the RFC Series are
documented in community-approved documents (catalogued in <a href="#section-5.2">Section 5.2</a>
below).
Any specific interfaces, numbers, or concrete values required to make
the requirements operational are the subject of agreements between
the IASA and the RFC Editor (e.g., contracts, statements of work,
service level agreements, etc).
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Operational Implementation</span>
The RFC Editor is responsible for ensuring that editing, processing,
and publication of RFCs are carried out in a way that is consistent
with the requirements laid out in the appropriate documents. The RFC
Editor works with the IASA to provide regular reporting and feedback
on these operations.
<span class="grey">Daigle & IAB Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. Process Change</span>
From time to time, it may be necessary to change the requirements for
any given stream, or the RFC Series in general. This may occur when
the RFC Editor, the IAB, the approval body for a given stream of
documents, or the community determines that there are issues to be
resolved in general for RFCs or for per-stream requirements.
In this model, the general approach is that the IAB will work with
the RFC Editor to get community input and it will approve changes by
validating appropriate consideration of community requirements.
<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>. Existing Process Documents</span>
Documents describing existing requirements for the streams are
detailed in <a href="#section-5.2">Section 5.2</a>.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Archiving, Indexing, and Accessibility</span>
The activities of archiving, indexing, and making accessible the RFC
Series can be informed by specific subject matter expertise in
general document series editing. It is also important that they are
informed by requirements from the whole community. As long as the
RFC Series is to remain coherent, there should be uniform archiving
and indexing of RFCs across all streams and a common method of
accessing the resulting documents.
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Definition</span>
In principle, there should be a community consensus document
describing the archiving, indexing, and accessibility requirements
for the RFC Series. In practice, we continue with the archive as
built by the capable RFC Editors since the series' inception.
Any specific concrete requirements for the archive, index, and
accessibility operations are the subject of agreements between the
IASA and the RFC Editor (e.g., contracts, statements of work, service
level agreements, etc).
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Operational Implementation</span>
The RFC Editor is responsible for ensuring that the RFC archive and
index are maintained appropriately and that the resulting documents
are made available to anybody wishing to access them via the
Internet. The RFC Editor works with the IASA for regular reporting
and feedback.
<span class="grey">Daigle & IAB Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. Process Change</span>
Should there be a community move to propose changes to the
requirements for the RFC archive and index or accessibility, the IAB
will work with the RFC Editor to get community input and it will
approve changes by validating appropriate consideration of community
requirements.
<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>. Existing Process Documents</span>
There are no applicable process documents.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Series-Wide Guidelines and Rules</span>
The RFC Series style and content can be shaped by subject matter
expertise in document series editing. They are also informed by
requirements by the using community. As long as the RFC Series is to
remain coherent, there should be uniform style and content for RFCs
across all streams. This includes, but is not limited to, acceptable
language, use of references, and copyright rules.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. Definition</span>
In principle, there should be a community consensus document (or set
of documents) describing the content requirements for the RFC Series.
In practice, some do exist, though some need reviewing and more may
be needed over time.
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Operational Implementation</span>
The RFC Editor is responsible for ensuring that the RFC Series
guidelines are upheld within the RFC Series.
<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>. Process Change</span>
When additions or changes are needed to series-wide definitions, the
IAB will work with the RFC Editor and stream stakeholders to get
community input and review. The IAB will approve changes by
validating appropriate consideration of community requirements.
<span class="h4"><a class="selflink" id="section-4.4.4" href="#section-4.4.4">4.4.4</a>. Existing Process Documents</span>
Existing series-wide rules and guidelines documents include:
o Instructions to RFC Authors (<a href="./rfc2223">RFC 2223</a> [<a href="./rfc2223" title=""Instructions to RFC Authors"">RFC2223</a>], [<a href="#ref-RFC2223BIS" title=""Instructions to Request for Comments (RFC) Authors"">RFC2223BIS</a>])
o Copyright and intellectual property rules (<a href="./rfc3978">RFC 3978</a> [<a href="./rfc3978" title=""IETF Rights in Contributions"">RFC3978</a>] and
<a href="./rfc4748">RFC 4748</a> [<a href="./rfc4748" title=""RFC 3978 Update to Recognize the IETF Trust"">RFC4748</a>])
<span class="grey">Daigle & IAB Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
o Normative references (<a href="./rfc3967">RFC 3967</a> [<a href="./rfc3967" title=""Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level"">RFC3967</a>] and <a href="./rfc4897">RFC 4897</a> [<a href="./rfc4897" title=""Handling Normative References to Standards Track Documents"">RFC4897</a>])
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. RFC Streams</span>
Various contributors provide input to the RFC Series. These
contributors come from several different communities, each with its
own defined process for approving documents that will be published by
the RFC Editor. This is nothing new; however, over time the various
communities and document requirements have grown and separated. In
order to promote harmony in discussing the collective set of
requirements, it is useful to recognize each in their own space --
and they are referred to here as "streams".
Note that by identifying separate streams, there is no intention of
dividing them or undermining their management as one series. Rather,
the opposite is true -- by clarifying the constituent parts, it is
easier to make them work together without the friction that sometimes
arises when discussing various requirements.
The subsections below identify the streams that exist today. There
is no immediate expectation of new streams being created and it is
preferable that new streams NOT be created. Creation of streams and
all policies surrounding general changes to the RFC Series are
discussed above in <a href="#section-4">Section 4</a>.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. RFC Approval Processes</span>
Processes for approval of documents (or requirements) for each stream
are defined by the community that defines the stream. The IAB is
charged with the role of verifying that appropriate community input
has been sought and that the changes are consistent with the RFC
Series mission and this overall framework.
The RFC Editor is expected to publish all documents passed to it
after appropriate review and approval in one of the identified
streams.
<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>. IETF Document Stream</span>
The IETF document stream includes IETF WG documents as well as
"individual submissions" sponsored by an IESG area director. Any
document being published as part of the IETF standards process must
follow this stream -- no other stream can approve Standards-Track or
Best Current Practice (BCP) RFCs.
<span class="grey">Daigle & IAB Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
Approval of documents in the IETF stream is defined by
o the IETF standards process (<a href="./rfc2026">RFC 2026</a> [<a href="./rfc2026" title=""The Internet Standards Process -- Revision 3"">RFC2026</a>] and its
successors).
o the IESG process for sponsoring individual submissions [<a href="#ref-SPONSOR" title=""Guidance on Area Director Sponsoring of Documents"">SPONSOR</a>]).
Changes to the approval process for this stream are made by updating
the IETF standards process documents.
<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>. IAB Document Stream</span>
The IAB defines the processes by which it approves documents in its
stream. Consistent with the above, any documents that the IAB wishes
to publish as part of the IETF Standards Track (Standards or BCPs)
are subject to the approval processes referred to in <a href="#section-5.1.1">Section 5.1.1</a>.
The review and approval process for documents in the IAB stream is
described in
o the IAB process for review and approval of its documents (<a href="./rfc4845">RFC 4845</a>
[<a href="./rfc4845" title=""Process for Publication of IAB RFCs"">RFC4845</a>]).
<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>. IRTF Document Stream</span>
The IRTF is chartered as an activity of the IAB. With the approval
of the IAB, the IRTF may publish and update a process for publication
of its own, non-IETF Standards-Track, documents.
The review and approval process for documents in the IRTF stream is
described in
o IRTF Research Group RFCs [<a href="#ref-IRTF-DOCS" title=""IRTF Research Group RFCs"">IRTF-DOCS</a>].
<span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>. Independent Submission Stream</span>
The RFC Series has always served a broader Internet technical
community than the IETF. The "Independent Submission" stream is
defined to provide review and (possible) approval of documents that
are outside the scope of the streams identified above.
Generally speaking, approval of documents in this stream falls under
the purview of the RFC Editor, and the RFC Editor seeks input to its
review from the IESG.
<span class="grey">Daigle & IAB Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
The process for reviewing and approving documents in the Independent
Submission stream is defined by
o Independent Submissions to the RFC Editor (<a href="./rfc4846">RFC 4846</a> [<a href="./rfc4846" title=""Independent Submissions to the RFC Editor"">RFC4846</a>]).
o The IESG and RFC Editor Documents: Procedures (<a href="./rfc3932">RFC 3932</a>
[<a href="./rfc3932" title=""The IESG and RFC Editor Documents: Procedures"">RFC3932</a>]).
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. RFC Technical Publication Requirements</span>
The Internet engineering and research community has not only grown,
it has become more diverse, and sometimes more demanding. The IETF,
as a standards-developing organization, has publication requirements
that extend beyond those of an academic journal. The IAB does not
have the same interdependence with IANA assignments as the IETF
stream does. Therefore, there is the need to both codify the
publishing requirements of each stream, and endeavor to harmonize
them to the extent that is reasonable.
Therefore, it is expected that the community of effort behind each
document stream will outline their technical publication
requirements.
As part of the RFC Editor oversight, the IAB must agree that the
requirements are consistent with and implementable as part of the RFC
Editor activity.
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. IETF Documents</span>
The requirements for this stream are defined in <a href="./rfc4714">RFC 4714</a> [<a href="./rfc4714" title=""Requirements for IETF Technical Publication Service"">RFC4714</a>].
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. IAB Documents</span>
Although they were developed for the IETF standards process, the IAB
will identify the applicable requirements in <a href="./rfc4714">RFC 4714</a> for its stream.
If the IAB elects to define other requirements, they should deviate
minimally from those (in an effort to keep the collective technical
publication requirements reasonably managed by one technical
publisher).
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. IRTF Documents</span>
Although they were developed for the IETF standards process, the IRTF
will identify the applicable requirements in <a href="./rfc4714">RFC 4714</a> for its stream.
If the IRTF elects to define other requirements, they should deviate
minimally from those (in an effort to keep the collective technical
<span class="grey">Daigle & IAB Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
publication requirements reasonably managed by one technical
publisher).
<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>. Independent Submissions</span>
Although they were developed for the IETF standards process, the RFC
Editor will identify the applicable requirements in <a href="./rfc4714">RFC 4714</a> for its
stream.
If the RFC Editor elects to define other requirements, they should
deviate minimally from those (in an effort to keep the collective
technical publication requirements reasonably managed by one
technical publisher).
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
The processes for the publication of documents must prevent the
introduction of unapproved changes. Since the RFC Editor maintains
the index of publications, sufficient security must be in place to
prevent these published documents from being changed by external
parties. The archive of RFC documents, any source documents needed
to recreate the RFC documents, and any associated original documents
(such as lists of errata, tools, and, for some early items, non-
machine readable originals) need to be secured against failure of the
storage medium and other similar disasters.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IAB Members at the Time of Approval</span>
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Elwyn Davies
Kevin Fall
Olaf Kolkman
Kurtis Lindqvist
David Meyer
David Oran
Eric Rescorla
Dave Thaler
Lixia Zhang
<span class="grey">Daigle & IAB Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Informative References</span>
[<a id="ref-BCP101">BCP101</a>] Austein, R. and B. Wijnen, "Structure of the IETF
Administrative Support Activity (IASA)", <a href="./rfc4071">RFC 4071</a>,
<a href="https://www.rfc-editor.org/bcp/bcp101">BCP 101</a>, April 2005.
[<a id="ref-IABCHARTER">IABCHARTER</a>] Carpenter, B., "Charter of the Internet Architecture
Board (IAB)", <a href="./rfc2850">RFC 2850</a>, May 2000.
[<a id="ref-IRTF-DOCS">IRTF-DOCS</a>] Falk, A., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22IRTF+Research+Group+RFCs%22'>"IRTF Research Group RFCs"</a>, Work in Progress,
February 2006.
[<a id="ref-RFC1358">RFC1358</a>] Chapin, L., "Charter of the Internet Architecture Board
(IAB)", <a href="./rfc1358">RFC 1358</a>, August 1992.
[<a id="ref-RFC1601">RFC1601</a>] Huitema, C., "Charter of the Internet Architecture
Board (IAB)", <a href="./rfc1601">RFC 1601</a>, March 1994.
[<a id="ref-RFC2026">RFC2026</a>] Bradner, S., Ed., "The Internet Standards Process --
Revision 3", <a href="./rfc2026">RFC 2026</a>, October 1996.
[<a id="ref-RFC2223">RFC2223</a>] Postel, J. and J. Reynolds, "Instructions to RFC
Authors", <a href="./rfc2223">RFC 2223</a>, October 1997.
[<a id="ref-RFC2223BIS">RFC2223BIS</a>] Reynolds, J., Ed. and R. Braden, Ed., "Instructions to
Request for Comments (RFC) Authors", Work in Progress,
August 2004.
[<a id="ref-RFC2555">RFC2555</a>] Editor, RFC., "30 Years of RFCs", <a href="./rfc2555">RFC 2555</a>, April 1999.
[<a id="ref-RFC3932">RFC3932</a>] Alvestrand, H., "The IESG and RFC Editor Documents:
Procedures", <a href="./rfc3932">RFC 3932</a>, October 2004.
[<a id="ref-RFC3967">RFC3967</a>] Bush, R. and T. Narten, "Clarifying when Standards
Track Documents may Refer Normatively to Documents at a
Lower Level", <a href="./rfc3967">RFC 3967</a>, December 2004.
[<a id="ref-RFC3978">RFC3978</a>] Bradner, S., Ed., "IETF Rights in Contributions",
<a href="./rfc3978">RFC 3978</a>, March 2005.
[<a id="ref-RFC4693">RFC4693</a>] Alvestrand, H., "IETF Operational Notes", <a href="./rfc4693">RFC 4693</a>,
October 2006.
<span class="grey">Daigle & IAB Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
[<a id="ref-RFC4714">RFC4714</a>] Mankin, A. and S. Hayes, "Requirements for IETF
Technical Publication Service", <a href="./rfc4714">RFC 4714</a>, October 2006.
[<a id="ref-RFC4748">RFC4748</a>] Bradner, S., Ed., "<a href="./rfc3978">RFC 3978</a> Update to Recognize the
IETF Trust", <a href="./rfc4748">RFC 4748</a>, October 2006.
[<a id="ref-RFC4845">RFC4845</a>] Daigle, L., "Process for Publication of IAB RFCs",
<a href="./rfc4845">RFC 4845</a>, July 2007.
[<a id="ref-RFC4846">RFC4846</a>] Klensin, J. and D. Thaler, "Independent Submissions to
the RFC Editor", <a href="./rfc4846">RFC 4846</a>, July 2007.
[<a id="ref-RFC4897">RFC4897</a>] Klensin, J., "Handling Normative References to
Standards Track Documents", <a href="https://www.rfc-editor.org/bcp/bcp97">BCP 97</a>, <a href="./rfc4897">RFC 4897</a>,
June 2007.
[<a id="ref-SPONSOR">SPONSOR</a>] Arkko, J., "Guidance on Area Director Sponsoring of
Documents", ION, October 2006.
<span class="grey">Daigle & IAB Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. A Retrospective of IAB Charters and RFC Editor</span>
With this document, the IAB's role with respect to the RFC Series and
the RFC Editor is being adjusted to work more directly with the RFC
Editor and provide oversight to ensure the RFC Series mission
principles and communities' input are addressed appropriately.
This section provides an overview of the role of the IAB with respect
to the RFC Editor as it has been presented in IAB Charter RFCs dating
back to 1992. The point of this section is that the IAB's role has
historically been substantive -- whether it is supposed to be
directly responsible for the RFC Series' editorial management (circa
1992, <a href="#appendix-A.1">Appendix A.1</a>), or appointment of the RFC Editor organization
and approval of general policy (circa 2000, <a href="#appendix-A.3">Appendix A.3</a>).
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. 1992</span>
[<a id="ref-RFC1358">RFC1358</a>] says:
[The IAB's] responsibilities shall include:
[...]
(2) The editorial management and publication of the Request for
Comments (RFC) document series, which constitutes the
archival publication series for Internet Standards and
related contributions by the Internet research and
engineering community.
<span class="grey">Daigle & IAB Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. 1994</span>
[<a id="ref-RFC1601">RFC1601</a>] says:
[The IAB's] responsibilities under this charter include:
(d) RFC Series and IANA
The IAB is responsible for editorial management and publication of
the Request for Comments (RFC) document series, and for
administration of the various Internet assigned numbers.
which it elaborates as
2.4 RFC Series and Assigned Numbers
The RFC Series constitutes the archival publication channel for
Internet Standards and for other contributions by the Internet
research and engineering community. The IAB shall select an RFC
Editor, who shall be responsible for the editorial management and
publication of the RFC Series.
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. 2000</span>
[<a href="#ref-IABCHARTER" title=""Charter of the Internet Architecture Board (IAB)"">IABCHARTER</a>], which is the most recent IAB Charter document, says:
(d) RFC Series and IANA
The RFC Editor executes editorial management and publication of the
IETF "Request for Comment" (RFC) document series, which is the
permanent document repository of the IETF. The RFC Series
constitutes the archival publication channel for Internet Standards
and for other contributions by the Internet research and engineering
community. RFCs are available free of charge to anyone via the
Internet. The IAB must approve the appointment of an organization to
act as RFC Editor and the general policy followed by the RFC Editor.
<span class="grey">Daigle & IAB Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
Authors' Addresses
Leslie L. Daigle (editor)
EMail: ledaigle@cisco.com, leslie@thinkingcat.com
IAB
EMail: iab@iab.org
URI: <a href="http://www.iab.org/">http://www.iab.org/</a>
<span class="grey">Daigle & IAB Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4844">RFC 4844</a> The RFC Series and RFC Editor July 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Daigle & IAB Informational [Page 20]
</pre>
|
