idnits 2.17.1
draft-flanagan-fiftyyears-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (25 March 2019) is 1859 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC 4845' is mentioned on line 609, but not defined
== Missing Reference: 'RFC 5743' is mentioned on line 611, but not defined
== Missing Reference: 'RFC 4846' is mentioned on line 613, but not defined
== Unused Reference: 'RFC2555' is defined on line 1029, but no explicit
reference was found in the text
== Unused Reference: 'RFC5540' is defined on line 1051, but no explicit
reference was found in the text
-- Obsolete informational reference (is this intentional?): RFC 3
(Obsoleted by RFC 10)
-- Obsolete informational reference (is this intentional?): RFC 433
(Obsoleted by RFC 503)
-- Obsolete informational reference (is this intentional?): RFC 1083
(Obsoleted by RFC 1100)
-- Obsolete informational reference (is this intentional?): RFC 1150
(Obsoleted by RFC 6360)
-- Obsolete informational reference (is this intentional?): RFC 4844
(Obsoleted by RFC 8729)
-- Obsolete informational reference (is this intentional?): RFC 6635
(Obsoleted by RFC 8728)
Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group H. Flanagan, Ed.
3 Internet-Draft RFC Editor
4 Updates2555, 5540 (if approved) 25 March 2019
5 Intended status: Informational
6 Expires: 26 September 2019
8 Fifty Years of RFCs
9 draft-flanagan-fiftyyears-02
11 Abstract
13 This RFC marks the fiftieth anniversary for the RFC Series. It
14 includes both retrospective material from individuals involved at key
15 inflection points, as well as a review of the current state of
16 affairs. It concludes with thoughts on possibilities for the next
17 fifty years for the Series. This document updates and brings current
18 the history started in RFCs 2555 and 5540.
20 Status of This Memo
22 This Internet-Draft is submitted in full conformance with the
23 provisions of BCP 78 and BCP 79.
25 Internet-Drafts are working documents of the Internet Engineering
26 Task Force (IETF). Note that other groups may also distribute
27 working documents as Internet-Drafts. The list of current Internet-
28 Drafts is at https://datatracker.ietf.org/drafts/current/.
30 Internet-Drafts are draft documents valid for a maximum of six months
31 and may be updated, replaced, or obsoleted by other documents at any
32 time. It is inappropriate to use Internet-Drafts as reference
33 material or to cite them other than as "work in progress."
35 This Internet-Draft will expire on 26 September 2019.
37 Copyright Notice
39 Copyright (c) 2019 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents (https://trustee.ietf.org/
44 license-info) in effect on the date of publication of this document.
45 Please review these documents carefully, as they describe your rights
46 and restrictions with respect to this document. Code Components
47 extracted from this document must include Simplified BSD License text
48 as described in Section 4.e of the Trust Legal Provisions and are
49 provided without warranty as described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
54 2. Key Moments in RFC History . . . . . . . . . . . . . . . . . 4
55 3. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . 5
56 3.1. The Origins of RFCs - by Stephen D. Crocker . . . . . 5
57 3.2. The RFC Management and Editing Team - Vint Cerf . . . . 10
58 3.3. Formalizing the RFC Editor Model - Leslie Daigle
59 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
60 3.4. The Continuation, or Creation, of a Stream - Nevil
61 Brownlee . . . . . . . . . . . . . . . . . . . . . . . 13
62 3.5. A View from Inside the RFC Editor - Sandy Ginoza
63 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
64 4. The Next Fifty Years of RFCs . . . . . . . . . . . . . . . . 19
65 4.1. Preservation . . . . . . . . . . . . . . . . . . . . . 19
66 4.2. Evolution of the RFC Format . . . . . . . . . . . . . . 20
67 4.3. Stream Structure . . . . . . . . . . . . . . . . . . . 20
68 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21
69 6. Informative References . . . . . . . . . . . . . . . . . . . 21
70 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24
71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
73 1. Introduction
75 The RFC Series began in April 1969 with the publication of "Host
76 Software" by Steve Crocker. The early RFCs were extremely informal
77 and included poems, satires, and April 1 jokes, to name a few. Since
78 then, over 8000 RFCs have been published, ranging across best
79 practice information, experimental protocols, informational material,
80 and, of course, standards. Material is accepted for publication
81 through the IETF, the IAB, the IRTF, and the Independent Submissions
82 stream, each with clear processes on how drafts are submitted and
83 potentially approved for publication as an RFC. Ultimately, the goal
84 of the RFC Series is to provide a canonical source for the material
85 published by the RFC Editor, and to support the preservation of that
86 material in perpetuity.
88 Since the very first RFC was published fifty years ago, the focus of
89 the Series has evolved to be a stable record of what has been
90 published and to provide a source for the dissemination to the world
91 of the ideas contained in the RFCs. In particular, when Internet
92 Drafts first started being produced [need a date check], RFCs became
93 a much more formal body of material requiring serious curation, from
94 the editing process through to the curation and archiving of the
95 documents. Today, there is still a tension between having that
96 stable, archival record, versus making the latest ideas available as
97 soon as possible; evolution will continue, in no small part driven by
98 that tension.
100 Change does come to the Series, albeit slowly. First, we saw the
101 distribution method change from postal mail to FTP and email. From
102 there, we saw increased guidance for authors on how to write an RFC.
103 The editorial staff went from one person, Jon Postel, to a team of
104 five to seven. The actual editing and publishing work split from the
105 service for registration of protocol codepoints. The whole RFC
106 Editor structure was reviewed and refined [RFC6635]. And, in the
107 last few years, we have started the process to change the format of
108 the RFC documents themselves.
110 This is evolution, and the Series will continue to adapt in order to
111 meet the needs and expectations of the community of authors,
112 operators, historians, and users of the RFC Series. These changes
113 will be always be balanced against the core mission of the Series: to
114 maintain a strong, stable, archival record of technical
115 specifications, protocols, and other information relevant to the
116 Arpanet and Internet networking communities.
118 There is more to the history of the RFC Series than can be covered in
119 this document. Readers interested in earlier perspectives may find
120 the following RFCs of particular interest that focus on the enormous
121 contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and
122 first RFC Editor:
124 [RFC2441]"Working with Jon, Tribute delivered at UCLA"
126 [RFC2555]"30 Years of RFCs"
128 [RFC5540]"40 Years of RFCs"
130 In this document, several individuals who have been a part of shaping
131 the Series offer their observations of key moments in the series.
132 Steve Crocker, author of RFC 1, offers his thoughts on how and why
133 the Series began. Leslie Daigle, a major influence in the
134 development of the RFC Editor model, offers her thoughts on the
135 change of the RFC Editor to a stronger, contracted function. Nevil
136 Brownlee, Independent Submissions Editor from 2010 through February
137 2018, shares his view on the clarification of the IS and its
138 transition from Bob Braden. As the current RFC Series Editor, I will
139 put my thoughts in on the most recent changes in formalizing the
140 digital preservation of the Series, the process to modernize the
141 format while respecting the need for stability, and my thoughts on
142 the next fifty years of RFCs.
144 This document brings up to date the historical records started in
145 RFCs 2555 and 5540.
147 2. Key Moments in RFC History
149 +----------------+-----------+---------------------------------+
150 | Marker | Date | Event |
151 +================+===========+=================================+
152 | [RFC0001] | 1969 | First RFC published |
153 +----------------+-----------+---------------------------------+
154 | [RFC0114] | 1971 | First distribution of RFCs over |
155 | | | the network |
156 +----------------+-----------+---------------------------------+
157 | [RFC0433] | December | First mention of the Czar of |
158 | | 1972 | Socket Numbers and the proposal |
159 | | | for a formal registry |
160 +----------------+-----------+---------------------------------+
161 | [RFC0690] | June 1975 | Relationship starts between ISI |
162 | | | and the RFC Editor, judging by |
163 | | | Jon Postel's affiliation change |
164 +----------------+-----------+---------------------------------+
165 | [RFC0748] | March | First April 1st RFC |
166 | | 1977 | |
167 +----------------+-----------+---------------------------------+
168 | [RFC1083] | December | Three stage standards process |
169 | | 1988 | defined |
170 +----------------+-----------+---------------------------------+
171 | [RFC1150] | March | FYI sub-series started |
172 | | 1990 | |
173 +----------------+-----------+---------------------------------+
174 | [RFC1311] | March | STD sub-series started |
175 | | 1992 | |
176 +----------------+-----------+---------------------------------+
177 | [RFC1818] | August | BCP sub-series started |
178 | | 1995 | |
179 +----------------+-----------+---------------------------------+
180 | [RFC-ONLINE] | (approx) | RFC Online Project |
181 | | 1998-2010 | |
182 +----------------+-----------+---------------------------------+
183 | [IAB-19880712] | July 1988 | IAB approves the creation of an |
184 | | | Internet Draft series |
185 +----------------+-----------+---------------------------------+
186 | [RFC2441] | 15 | Jon Postel's death |
187 | | October | |
188 | | 1998 | |
189 +----------------+-----------+---------------------------------+
190 | [ISI-to-AMS] | October | Transition starts from ISI to |
191 | | 2009 | Association Management |
192 | | | Solutions (AMS) |
193 +----------------+-----------+---------------------------------+
194 | [RFC4844] | July 2007 | RFC Stream structure |
195 +----------------+-----------+---------------------------------+
196 | [RFC6360] | August | FYI sub-series ended |
197 | | 2011 | |
198 +----------------+-----------+---------------------------------+
199 | [RFC6410] | October | Two stage standards process |
200 | | 2011 | formalized |
201 +----------------+-----------+---------------------------------+
202 | [RFC6949] | May 2013 | RFC Format change project |
203 | | | started |
204 +----------------+-----------+---------------------------------+
205 | [RFC8153] | April | RFCs no longer printed to paper |
206 | | 2017 | upon publication |
207 +----------------+-----------+---------------------------------+
209 Table 1
211 3. Perspectives
213 3.1. The Origins of RFCs - by Stephen D. Crocker
215 [This is a revision of material included in [RFC1000] August 1987,
216 more than thirty years ago.]
218 The Internet community now includes millions of nodes and billions of
219 users. It owes its beginning to the Arpanet, which was once but a
220 gleam in the eyes of Bob Taylor, Larry Roberts, and J. C. R.
221 Licklider of ARPA. While much of the development proceeded according
222 to plan, the initial design of the protocols and the creation of the
223 RFCs was largely accidental.
225 The procurement of the ARPANET was initiated in the summer of 1968
226 --remember Vietnam, flower children, etc.? There had been prior
227 experiments at various ARPA sites to link together computer systems,
228 but this was the first version to explore packet-switching as a core
229 part of the communication strategy. ("ARPA" didn't become "DARPA"
230 until 1972. It briefly changed back to ARPA in 1993 and then back
231 again to DARPA.) The government's Request for Quotations (RFQ)
232 called for four packet-switching devices, called Interface Message
233 Processors ("IMPs"), to be delivered to four sites in the western
234 part of the United States: University of California, Los Angeles
235 (UCLA); SRI International in Menlo Park, CA; University of
236 California, Santa Barbara; the University of Utah in Salt Lake City.
237 These sites, respectively, were running a Scientific Data Systems
238 (SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10. These
239 machines not only had different operating systems, but even details
240 like character sets and byte sizes varied, and other sites would have
241 further variations.
243 The focus was on the basic movement of data. The precise use of the
244 ARPANET was not spelled out in advance, thus requiring the research
245 community to take some initiative. To stimulate this process, a
246 meeting was called in August 1968 with representatives from the
247 selected sites, chaired by Elmer Shapiro from SRI. Based on
248 Shapiro's notes from that meeting, the attendees were Dave Hopper and
249 Jeff Rulifson from SRI, Glen Culler and Gordon Buck from Santa
250 Barbara, R. Stephenson, C. Stephen Carr and W. Boam from Utah,
251 Vint Cerf and me from UCLA, and a few others from potential future
252 sites.
254 That first meeting was seminal. We had lots of questions. How IMPs
255 and "hosts" (I think that was the first time I was exposed to that
256 term) would be connected? What hosts would say to each other? What
257 applications would be supported? The only concrete answers were
258 remote login as a replacement for dial-up, telephone based
259 interactive terminal access, and file transfer, but we knew the
260 vision had to be larger. We found ourselves imagining all kinds of
261 possibilities -- interactive graphics, cooperating processes,
262 automatic data base query, electronic mail -- but no one knew where
263 to begin. We weren't sure whether there was really room to think
264 hard about these problems; surely someone senior and in charge,
265 likely from the East, would be along by and by to bring the word.
266 But we did come to one conclusion: we ought to meet again. Over the
267 next several months, we met at each of our sites, thereby setting the
268 precedent for regular face to face meetings. We also instantly felt
269 the irony. This new network was supposed to make it possible to work
270 together at a distance, and the first thing we did was schedule a
271 significant amount of travel.
273 Over the next several months, a small, fairly consistent set of
274 graduate students and staff members from the first four sites met.
275 We used the term Network Working Group (NWG) to designate ourselves.
276 This was the same term Elmer Shapiro had used when he convened our
277 first meeting, although it had been used until that point to refer to
278 the principal investigators and ARPA personnel -- senior people who
279 had been planning the network. Our group was junior and disjoint
280 from the prior group, except, of course, that each of us worked for
281 one of the principal investigators.
283 The first few meetings were quite tenuous, primarily because we
284 weren't sure how narrow or expansive our goals should be. We had no
285 official charter or leadership, and it remained unclear, at least to
286 me, whether someone or some group would show up with the official
287 authority and responsibility to take over the problems we were
288 dealing with. Without clear definition of what the host-IMP
289 interface would look like, or even a precise definition of what
290 functions the IMP would provide, we focused on broader ideas. We
291 envisioned the possibility of application specific protocols, with
292 code downloaded to user sites, and we took a crack at designing a
293 language to support this. The first version was known as DEL, for
294 "Decode-Encode Language" and a later version was called NIL, for
295 "Network Interchange Language."
297 In late 1968 Bolt Beranek and Newman (BBN) in Cambridge, MA won the
298 contract for the IMPs and began work in January 1969. A few of us
299 flew to Boston in the middle of February to meet the BBN crew. The
300 BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein,
301 Ben Barker, Will Crowther, Bernie Cosell and Dave Walden. They were
302 organized, professional and focused. Their first concern was how to
303 meet their contract schedule of delivering the first IMP to UCLA at
304 the beginning of September and how to get bits to flow quickly and
305 reliably. The details of the host-IMP interface were not yet firm;
306 the specification came a few months later as BBN Report 1822. In
307 particular, BBN didn't take over our protocol design process, nor did
308 any other source of authority appear. Thus, we doggedly continued
309 debating and designing the protocols.
311 A month later our small NWG met in Utah. As the meeting came toward
312 an end, it became clear to us that we should start writing down our
313 discussions. We had accumulated a few notes on the design of DEL and
314 other matters, and we decided to put them together in a set of notes.
315 We assigned writing chores to each of us, and I took on the
316 additional task of organizing the notes. I suppose I was the first
317 RFC Editor, though I never use that term because we never reviewed or
318 changed the content of any of the RFCs. Each of the RFCs were
319 numbered in sequence. The only rule I imposed was the note had to be
320 complete before I assigned a number because I wanted to minimize the
321 number of holes in the sequence.
323 I tried a couple of times to write a note on how the notes would be
324 organized, but I found myself full of trepidation. Would these notes
325 look as if we were asserting authority we didn't have? Would we
326 unintentionally offend whomever the official protocol designers were?
327 Finally, unable to sleep, I wrote the a few humble words. The basic
328 ground rules were that anyone could say anything and that nothing was
329 official. And to emphasize the point, I used Bill Duvall's
330 suggestion and labeled the notes "Request for Comments." I never
331 dreamed these notes would eventually be distributed through the very
332 medium we were discussing in these notes. Talk about Sorcerer's
333 Apprentice!
334 After BBN distributed the specification for the hardware and software
335 interface to the IMPs to the initial ARPANET sites, our attention
336 shifted to low-level matters. The ambitious ideas for automatic
337 downloading of code evaporated. It would be several years before
338 ideas like mobile code, remote procedure calls, ActiveX, JAVA and
339 RESTful interfaces appeared.
341 Over the spring and summer of that year we grappled with the detailed
342 problems of protocol design. Although we had a vision of the vast
343 potential for intercomputer communication, designing usable protocols
344 was another matter. We knew a custom hardware interface and a custom
345 software addition in the operating system was going to be required
346 for anything we designed, and we anticipated these would pose some
347 difficulty at each of the sites. We looked for existing abstractions
348 to use. It would have been convenient if we could have made the
349 network simply look like regular device, e.g. a tape drive, but we
350 knew that wouldn't do. The essence of this network was peer-to-peer
351 cooperation among the machines and the processes running inside them,
352 not a central machine controlling dependent devices. We settled on a
353 virtual bit stream layer as the basic building block for the
354 protocols, but even back then we knew that some applications like
355 voice might need to avoid that layer of software. (Why a virtual bit
356 stream instead of a virtual byte stream? Because each computer had
357 its own notion of how many bits were in a byte. Eight-bit bytes
358 didn't become standard until a few years later.)
360 Over the next two years, we developed, exchanged, and implemented
361 ideas. I took a leave from UCLA in June 1971 to spend time working
362 at ARPA. Jon Postel took over the care and feeding of the RFCs,
363 evolving the process and adding collaborators over the next twenty-
364 seven years.
366 The rapid growth of the network and the working group also led to a
367 large pile of RFCs. When the 100th RFC was in sight, Peggy Karp at
368 MITRE took on the task of indexing them. That seemed like a large
369 task then, and we could have hardly anticipated seeing more than a
370 1000 RFCs several years later, and the evolution toward Internet
371 Drafts yet later.
373 When we first started working on the protocols, the network did not
374 exist. Except for our occasional face-to-face meetings, RFCs were
375 our only means of communication. In [RFC0003], I set the bar as low
376 as possible:
378 The content of a NWG note may be any thought, suggestion, etc.
379 related to the HOST software or other aspect of the network.
380 Notes are encouraged to be timely rather than polished.
381 Philosophical positions without examples or other specifics,
382 specific suggestions or implementation techniques without
383 introductory or background explication, and explicit questions
384 without any attempted answers are all acceptable. The minimum
385 length for a NWG note is one sentence.
387 These standards (or lack of them) are stated explicitly for two
388 reasons. First, there is a tendency to view a written statement
389 as ipso facto authoritative, and we hope to promote the exchange
390 and discussion of considerably less than authoritative ideas.
391 Second, there is a natural hesitancy to publish something
392 unpolished, and we hope to ease this inhibition.
394 Making the RFCs informal was not only a way of encouraging
395 participation; it was also important in making the communication
396 effective. One of the early participants said he was having trouble
397 writing and sending an RFC because his institution wanted to subject
398 them to publication review. These are not "publications," I
399 declared, and the problem went away. Another small detail, handled
400 instinctively and without debate, was the distribution model. Each
401 institution was required to send a copy directly to each of the other
402 handful of participating institutions. Each institution handled
403 internal copies and distribution itself. Submission to a central
404 point for redistribution was not required, so as to minimize delays.
405 SRI's Network Information Center, however, did maintain a central
406 repository of everything and provided an invaluable record.
408 We didn't intentionally set out to challenge the existing standards
409 organizations, but our natural mode of operation yielded some
410 striking results. The RFCs are open in two important respects:
411 anyone can write one for free and anyone get them for free. At the
412 time, virtually everyone in the ARPANET community was sponsored by
413 the government, so there was little competition and no need to use
414 documents as a way of raising money. Of course, as soon as we had
415 email working on the ARPANET, we distributed RFCs electronically.
416 When the ARPANET became just a portion of the Internet, this
417 distribution process became worldwide. The effect of this openness
418 is often overlooked. Students and young professionals all over the
419 world have been able to download the RFCs, learn about the many
420 pieces of technology, and then build the most amazing software. And
421 they still are. [They are also a fantastic resource for historians.]
423 Where will it end? The Arpanet begat the Internet and the underlying
424 technology transitioned from the original host-host protocol to TCP/
425 IP, but the superstructure of protocol layers, community driven
426 protocol design, and the RFCs continued. Through the many changes in
427 physical layer technology - analog copper circuits, digital circuits,
428 fiber and wireless -- resulting in speed increases from thousands to
429 billions of bits per second and a similar increase from thousands to
430 billions of users, this superstructure, including the RFCs has
431 continued to serve the community. All of the computers have changed,
432 as have all of the transmission lines. But the RFCs march on. Maybe
433 I'll write a few words for RFC 10,000.
435 Quite obviously the circumstances have changed. Email and other
436 media are most often used for the immediate exchange of inchoate
437 thoughts. Internet Drafts are the means for exchanging substantial,
438 albeit sometimes speculative content. And RFCs are reserved for
439 fully polished, reviewed, edited and approved specifications.
440 Comments to RFCs are not requested, although usage-related
441 discussions and other commentary on mailing lists often takes place
442 nonetheless. Rather than bemoan the change, I take it as a
443 remarkable example of adaptation. RFCs continue to serve the
444 protocol development community. Indeed, they are the bedrock of a
445 very vibrant and productive process that has fueled and guided the
446 Internet revolution.
448 3.2. The RFC Management and Editing Team - Vint Cerf
450 As Steve Crocker mentions in Section 3.1, Jon Postel assumed the role
451 of RFC manager in 1971 when Steve left UCLA for ARPA. Jon took on
452 this role in addition to his subsequent "numbers Czar"
453 responsibilities. Initially, his focus was largely on assigning RFC
454 numbers to aspiring writers but with time, and as the standardization
455 of the ARPANET and Internet protocols continued apace, he began to
456 serve in an editorial capacity. Moreover, as an accomplished
457 software engineer, he had opinions about technical content in
458 addition to writing style and did not hesitate to exercise editorial
459 discretion as would-be published authors presented their offerings
460 for his scrutiny. As the load increased, he recruited additional
461 "volunteer" talent, most notably Joyce K. Reynolds, a fellow
462 researcher at USC/ISI. Over the ensuing years, he also drafted
463 Robert (Bob) Braden into the team and when Jon unexpectedly passed
464 away in October 1998 (see [RFC2468]), Joyce and Bob undertook to
465 carry on with the RFC work in his stead, adding Sandy Ginoza to the
466 team. During the period when Jon and Joyce worked closely together,
467 Joyce would challenge me to tell which edits had been made by Jon and
468 which by her. I found this impossible, so aligned were they in their
469 editorial sensibilities. Sadly, three of these tireless Internauts
470 have passed on and we have only the product of their joint work and
471 Sandy Ginoza's and others' corporate memory by which to recall
472 history.
474 3.3. Formalizing the RFC Editor Model - Leslie Daigle
476 I was the chair of the Internet Architecture Board, the board
477 responsible for the general oversight of the RFC Series, at a
478 particular inflection point in the evolution of all Internet
479 technology institutions. To understand what we did, and why we had
480 to, let me first paint a broader picture of the arc of these
481 institutions.
483 Like many others who were in decision-making roles in the mid -00's,
484 I wasn't present when the Internet was born. The lore passed down to
485 me was that, out of the group of talented researchers that developed
486 the core specifications and established the direction of the
487 Internet, different individuals stepped up to take on roles necessary
488 to keep the process of specification development organized and open.
489 As the work of specification expanded, those individuals were
490 generally supported by organizations that carried on in the same
491 spirit. This was mostly Jon Postel, managing the allocation and
492 assignment of names and numbers, as well as working as the editor of
493 RFCs, but there were also individuals and institutions supporting the
494 IETF's Secretariat function. By the late 20th century, even this
495 model was wearing thin - the support functions were growing, and
496 organizations didn't have the ability to donate even more resources
497 to run them. In some cases (IANA) there was significant industry and
498 international dependence on the function and its neutrality.
500 The IETF, too, had grown in size, stature, and commercial reliance.
501 This system of institutional pieces "flying in formation" was not
502 providing the kind of contractual regularity or integrated
503 development that the IETF needed. People who hadn't been there as
504 the institutions developed, including IETF decision-makers, didn't
505 innately understand why things "had to be the way they were", and
506 were frustrated when trying to get individual systems updated for new
507 requirements, and better integrated across the spectrum of
508 activities.
510 Internet engineering had expanded beyond the point of being
511 supportable by a loosely-coupled set of organizations of people who
512 had been there since the beginning and knew each other well. New
513 forms of governance and were needed, as well as rationalized funding
514 The IANA function was absorbed into a purpose-built international
515 not-for-profit organization. The IETF stepped up to manage its own
516 organizational destiny, creating the IETF Administrative Support
517 Activity (IASA), and the Secretariat became one of its contracted
518 functions.
520 This left the RFC Editor function as an Internet Society-supported,
521 independent effort.
523 That independent nature was necessary for the historic role of the
524 RFC Series in considering all technical contributions. But, at that
525 inflection point in the Series' history, it needed a new governance
526 and funding model, just as the other Internet technical specification
527 supporting organizations had. Also, the IETF leadership had some
528 concerns it felt needed to addressed in its own technical publication
529 stream. While the RFC Series had been established before there was
530 an IETF, and had historically continued to have documents in it that
531 didn't originate from the IETF, the IETF was its largest and most
532 organized contributor. There was no particular organization of
533 independent contributors. Equally, the funding for the RFC Editor
534 was at that point coming from the Internet Society in the guise of
535 "support for the IETF". For people who hadn't been involved with the
536 institution from the outset, it was pretty easy to perceive the RFC
537 Series uniquely as the IETF's publication series. So, the challenge
538 was to identify and address the IETF's issues, along with governance
539 and funding, without sacrificing the fundamental nature of the RFC
540 Series as a broader-than-IETF publication series.
542 To give a sense of the kinds of tensions that were prevalent, let me
543 share that the one phrase that sticks in my mind from those
544 discussions is: "push to publish". There were those in IETF
545 leadership who felt that it would significantly reduce costs and
546 improve timeliness if an RFC could be published by, literally,
547 pushing a button on a web interface the moment it was approved by the
548 IESG. It would also, they argued, remove the specification issues
549 being introduced by copy-editors that were hired as occasional
550 workers to help with improving publication rates, but who weren't
551 necessarily up to speed on terms of art in technical specifications.
552 (There were some pretty egregious examples of copyeditors introducing
553 changes that significantly changed the technical meaning of the text
554 that I forbear from citing here; let's just say it wasn't strictly a
555 problem of Internet engineers getting uptight about their cheese
556 being moved). While "push to publish" would have addressed those
557 issues, it would not have addressed the loss of clarity from the many
558 significant text improvements copy editors successfully introduced,
559 or the fact that not all RFCs are approved by the IESG.
561 Institutionally, it was clear that the target was to have the RFC
562 Editor function governance within the reach of the Internet technical
563 community (as opposed to any particular private organization),
564 without tying it specifically to the IETF. That was reasonably
565 achievable by ensuring that the resultant pieces were established
566 under the oversight of the IAB (which is, itself, independent of the
567 IETF, even as it is supported by the IASA organization).
569 The IETF worked on a document outlining functional requirements for
570 its technical specification publication. This could have been useful
571 for establishing its own series, but it also was helpful in
572 establishing awareness of the challenges in document publishing (it
573 always looks easy when you haven't thought about it), and also to lay
574 the ground work for dialogue with the RFC Editor. The requirements
575 document was published as [RFC4714], as an Informational RFC that
576 stands today to provide guidance in the editing processes surrounding
577 IETF publications.
579 There was still, however, a certain lack of clarity about
580 responsibilities for making decisions and changes in the RFC Series
581 itself. To that end, I and the IAB worked with the various involved
582 parties to produce [RFC4744]. That document captured the RFC Series
583 mission (for a purpose greater than IETF technical specification
584 publication), as well as the roles and responsibilities of the
585 parties involved. The RFC Editor has responsibility for ensuring the
586 implementation of the mission. The IAB continues to have oversight
587 responsibilities, including policy oversight, which it could act on
588 by changing the person (organization) in the role of RFC Editor. At
589 the same time, operational oversight was migrated to the IASA support
590 function of the IETF (and IAB).
592 The discussions, and the resulting publication of RFC 4744, allowed
593 greater visibility into and commitment to the RFC Series, as a
594 general Internet publication. It also meant that subsequent
595 adjustments could be made, as requirements evolved - the responsible
596 parties are clearly identified.
598 3.4. The Continuation, or Creation, of a Stream - Nevil Brownlee
600 Starting in 2006 with [RFC4714], the IAB began working towards a new
601 structure for publishing RFCs; in 2009 that emerged as the 'RFC
602 Editor (Version 1)' [RFC5629]. In this model the RFC Series Editor
603 (RSE) oversees RFC publishing and development, and four separate
604 'Streams' produce the documents to be published. The IETF Stream
605 produces standards-related material, all of its output has full IETF
606 consensus. The way each new Stream operates is specified in a
607 separate RFC, i.e.,
609 [RFC 4845] IAB: Architecture Reports and Procedures material
611 [RFC 5743] IRTF: Internet Research material
613 [RFC 4846] Independent: Other material
615 Before 2009 the RFC Editor could accept 'Independent' submissions
616 from individuals, and - if he judged they were significant - publish
617 them as RFCs; the Independent Stream was set up to continue that
618 function. From February 2010 through February 2018 I was the
619 Independent Stream Editor (ISE) - I began by reading [RFC4846], then
620 went on to develop the Independent Stream (IS).
622 First I spent several days at the RFC Production Centre at ISI in
623 Marina Del Ray with the RFC Editor (Bob Braden) and Sandy Ginoza and
624 Alice Hagens, so as to learn how RFCs were actually edited and
625 published. All RFCs reach the Production Centre as Internet Drafts;
626 they are copy-edited, until the edited version can be approved by
627 their authors (AUTH48). At any stage authors can check their draft's
628 status in the RFC Editor Database.
630 For the Independent Submissions, Bob kept a journal (a simple ASCII
631 file) of his interactions with authors for every draft, indexed by
632 the draft name. Bob also entered the Independent drafts into the RFC
633 Editor database, so that authors could track their draft's status.
634 After my few days with his team at ISI, he handed me that journal
635 (covering about 30 drafts) over to me and said "now it's over to
636 you!"
638 I began by following in Bob's footsteps, maintaining a journal and
639 tracking each draft's status in the RFC Editor database. My first
640 consideration was that every serious Internet draft submitted needs
641 several careful reviews. If the ISE knows suitable reviewers, he can
642 simply ask them. Otherwise, if the draft relates to an IETF or IRTF
643 Working Group, he can ask ask Working Group chairs or Area Directors
644 to suggest reviewers. As well, the ISE has an Independent
645 Submissions Editorial Board (Ed Board) that he can ask for reviewers.
646 My experience with reviewers was that most of those I approached were
647 happy to help.
649 Most drafts were straightforward, but there were some that needed
650 extra attention. Often a draft requests IANA code points, and for
651 that IANA were always quick to offer help and support. Code points
652 in some IANA Registries require Expert Review - sometimes the
653 interactions with Expert reviewers took quite a long time! Again,
654 sometimes a draft seemed to fit better in the IETF Stream; for these
655 I would suggest that the draft authors try to find an Area Director
656 to sponsor their work as in Individual submission to the IETF Stream.
658 After my first few years as ISE, the IETF Tools Team developed the
659 Data Tracker so that it could keep show draft status, and perform all
660 the 'housekeeping' tasks for all of the streams. At that stage I
661 switched to use the Data Tracker rather than the RFC Editor database.
663 Once a draft has been reviewed, and the authors have revised it in
664 dialogue with their reviewers, the ISE must submit that draft to the
665 IESG for their "Conflict Review" [RFC5742]. Overall, each IS draft
666 benefited from discussions (which were usually simple) with my Ed
667 Board and the IESG. A (very) few drafts were somewhat controversial
668 - for those I was able to work with the IESG to negotiate a suitable
669 'IESG Statement' and/or an 'ISE Statement' to make it clearer why the
670 ISE published the draft.
672 One rather special part of the Independent Stream is the April First
673 drafts. These are humorous RFCs that are never formally posted as
674 drafts and which have no formal review process. The authors must
675 send them directly to the ISE or the RFC Editor. Only a few of them
676 can be published each year; they are reviewed by the ISE and the RSE;
677 Bob Braden's criteria for April First drafts were:
679 They must relate to the Internet (like all drafts)
681 Their readers should reach the end of page two before realising
682 this is an April First RFC
684 They must actually be funny!
686 April First RFCs have a large following, feedback (on the rfc-
687 interest list) on 1 April each year has been enthusiastic and quick!
689 I published 159 Independent Stream RFCs during my eight years as ISE.
690 Over those eight years I worked with, and often met with at IETF
691 meetings, most of their authors. For me that was a very rewarding
692 experience, so I thank all those contributors. Also, I've worked
693 with most of the IESG members during those eight years, that also
694 gave me a lot of helpful interaction. Last, I've always enjoyed
695 working with the RFC Editor, and all the staff of the RFC Production
696 Centre. The IETF (as a whole) is very fortunate to have such an
697 effective team of talented Professional Staff.
699 3.5. A View from Inside the RFC Editor - Sandy Ginoza
701 When I joined ISI, shortly after Jon Postel passed away, the RFC
702 Editor as we know it today (as defined in RFC 5620, and as obsoleted
703 by RFCs 6548 and 6635) did not exist. The RFC Editor functioned as
704 one unit; there was no RSE, Production Center, Publisher, or
705 Independent Submissions Editor. All of these roles were performed by
706 the RFC Editor, which was comprised of four individuals: Bob Braden,
707 Joyce Reynolds, a part-time student programmer, and me.
709 Bob provided high-level guidance and reviewed Independent
710 Submissions. While Bob was a researcher in "Div 7" (Networking) at
711 ISI, ostensibly, the percentage of time he had for the RFC Editor was
712 10%, but he invested much more time to keep the series running. He
713 pitched in where he could, especially when processing times were
714 getting longer; at one point, he even NROFFed a couple of RFCs-to-be.
716 Joyce was a full-time employee, but while continuing to ensure RFCs
717 were published and serve as a User Services Area Director and a
718 keynote speaker about the Internet, she was also temporarily on loan
719 to IANA for 50% of her time while IANA was getting established after
720 separating from ISI. The student programmer performed programming
721 tasks as requested and was, at the time, responsible for parsing
722 MIBs. I was a full-time staffer and had to quickly learn the ropes
723 so RFCs would continue to be published.
725 My primary tasks were to manage the publication queue, format and
726 prepare documents for Joyce's review, carry out AUTH48 once Joyce
727 completed her review, and publish, index, and archive the RFCs (both
728 soft and hard copies).
730 The workload increased significantly over the next few years. As the
731 workload increased, the RFC Editor reacted and slowly grew their
732 staff over time. To understand the team growth, let's first take a
733 look at the publication rates throughout history. The table below
734 shows average annual publication rates during 5-year periods.
736 +-------------+-------------------+
737 | Years | Avg Pubs per Year |
738 +=============+===================+
739 | 1969 - 1972 | 80 |
740 +-------------+-------------------+
741 | 1973 - 1977 | 55 |
742 +-------------+-------------------+
743 | 1978 - 1982 | 20 |
744 +-------------+-------------------+
745 | 1983 - 1987 | 39 |
746 +-------------+-------------------+
747 | 1988 - 1992 | 69 |
748 +-------------+-------------------+
749 | 1993 - 1997 | 171 |
750 +-------------+-------------------+
751 | 1998 - 2002 | 237 |
752 +-------------+-------------------+
753 | 2003 - 2007 | 325 |
754 +-------------+-------------------+
755 | 2008 - 2012 | 333 |
756 +-------------+-------------------+
757 | 2013 - 2017 | 295 |
758 +-------------+-------------------+
760 Table 2
762 There were significant jumps in the publication rates in the 90s and
763 onward, with the number of publications almost doubling between 1993
764 and 2007. The annual submission count surpassed the 300 mark for the
765 first time in 2004 and reached an all-time high of 385 in 2011. The
766 submission rate did not drop below 300 until 2016 (284).
768 As the submissions grew, the RFC Editor experienced growing pains.
769 Processing times began to increase as the existing staff was unable
770 to keep up with the expanding queue size. In an attempt to reduce
771 the training hump and to avoid permanently hiring staff in case the
772 submission burst was a fluke, ISI brought on temporary copy editors -
773 this way, the staff could easily be resized as needed. However, as
774 Leslie noted, this didn't work very well. The effects of the
775 experiment would be lasting, as this led to a form of the process we
776 have now, where the RFC Editor asks more questions during AUTH/AUTH48
777 and technical changes require approval from the relevant Area
778 Directors. These changes added to the workload and extended
779 publication times; many often now jokingly refer to AUTH48 as the
780 authors' "48 days", "48 weeks", etc.
782 Because the workload continued to increase (in more ways than just
783 document submissions; tool testing, editorial process changes, and
784 more) and the lessons learned with temporary copy editors, our team
785 grew more permanently. While we had other editors in between, two
786 additions are of particular interest, as they experienced much of the
787 RFC Editor's growing pains, helped work us out of a backlogged state,
788 shaped the RFC Editor function, and are still with the team today:
789 Alice Russo joined the team in 2005 and Megan Ferguson joined us in
790 2007.
792 With the understanding that the record breaking number of submissions
793 was not an anomaly, we made significant upgrades to the
794 infrastructure of the RFC Editor function to facilitate document
795 tracking and reporting. For example, the illustrious "black binder"
796 - an actual 3-ring binder used to track number assignment, a manually
797 edited HTML file for the queue page, and a Rube-Goldberg set of text
798 files and scripts that created queue statistics, all were eventually
799 replaced; an errata system was proposed and implemented; and XML
800 became a newly accepted source file.
802 In 2009, RFC 5620 was published, introducing the initial version of
803 the RFC Editor model we have now. While it was published in 2009, it
804 did not go into effect until 2010, when the RFC Editor project as I
805 knew it was disbanded and divvied up into four pieces: RFC Series
806 Editor (RSE), Independent Submissions Editor (ISE), RFC Production
807 Center (RPC), and Publisher. In addition, the RFC Series Advisory
808 Group (RSAG) was created to "provide expert, informed guidance
809 (chiefly, to the RSE) in matters affecting the RFC Series operation
810 and development."
811 In 2010, the RPC and Publisher contracts were awarded to Association
812 Management Systems (AMS); we started with three existing team members
813 (Alice Russo, Megan Ferguson, and me) and we were pleased to be
814 joined by Lynne Bartholomew, a new colleague to anchor us in the AMS
815 office, and later Rebecca VanRheenen shortly thereafter.
817 I was wary of this model and was especially worried about the hole
818 Bob Braden's departure would create. Luckily for us, Bob Braden
819 provided wise counsel and insight during the transition (and beyond).
820 He gave the staff transitioning to AMS particularly helpful parting
821 words - "keep the RFCs coming" - and that is what we did.
823 AMS embraced the RFC Series and helped us quickly get set up on new
824 servers. The RFC Production Center and Publisher were now part of
825 the AMS family and it was all hands on deck to make sure the
826 transition went smoothly to minimize the impact on document
827 processing.
829 Our focus during transition was to 1) keep the trains running; that
830 is, we wanted to get ourselves up and running with minimal down time
831 and 2) work with the Transitional RSE, the Independent Submissions
832 Editor (Nevil Brownlee), RSAG, and the IAD to better understand and
833 implement the newly defined RFC Editor model.
835 Though some portions of the transition were challenging and lasted
836 longer than expected, the Acting RSE officially handed the reigns
837 over to the RSE (Heather Flanagan) in 2012. She had to jump in,
838 learn the RFC Editor and IETF culture, and work through a backlog of
839 issues that had been left unattended.
841 Two of the backlogged issues were so old, they were ones someone
842 asked me about at my first IETF: when is the RFC Editor going to
843 allow UTF-8 in RFCs and when will the RFC Editor adopt a more modern
844 publication format.
846 At that time, while we understood the desire to move toward UTF-8 and
847 to have more modern outputs, we also routinely received emails from
848 individuals requesting that we send them plain-text files (instead of
849 pointing them to the website) because their Internet access was
850 limited. We also regularly received complaints from rfc-editor.org
851 users whenever something on the site didn't work correctly with their
852 older browsers. In short, we could not advance without leaving a
853 large number of users behind.
855 However, we now find ourselves on the precipice of change. 2019
856 promises to be a BIG year for the RFC Series, as we expect to
857 transition from publishing plaintext, ASCII-only files to publishing
858 multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both
859 UTF-8 and SVG art.
861 Interestingly enough, I find that the RFC Editor has been in an
862 almost constant state of change since I joined the team, even though
863 the goal of the RFC Editor remains the same: to produce archival
864 quality RFCs in a timely manner that are easily accessible for future
865 generations.
867 4. The Next Fifty Years of RFCs
869 As Steve Crocker mentioned, the Series began with a goal of
870 communication over formality, openness over structure. As the
871 Internet has grown and become a pervasive, global construct, we still
872 aim for openness and communication, but recognize that for protocols
873 and other information to support interoperability, there must be
874 points of stability to build from. Small-time app developers to
875 multi-billion dollar companies are on the same footing. And anyone
876 can look back at a point in time and understand what was done, and
877 why.
879 While the informality has given way to increased structure, the
880 openness and solid foundation that the Series provides must continue.
881 With that in mind, what is next for the next fifty years of RFCs?
883 4.1. Preservation
885 The RFC Editor exists to edit, publish, and maintain an archive of
886 documents published in the RFC Series. A proper digital archive,
887 however, is more than just saving RFCs to disk and making sure the
888 disks are backed up; the field of digital preservation has grown and
889 transformed into an industry in and of itself. "Digital Preservation
890 Considerations for the RFC Series" [RFC8153] reviews what a digital
891 archive means today and describes ways to support the archive into
892 the future, and recommends ways for the RFC Editor to take advantage
893 of those organizations that specialize in this field.
895 The future of digital preservation as far as the RFC Series is
896 concerned will mean both finding new partners that can absorb and
897 archive RFCs into a public, maintained digital archive, and reviewing
898 the RFC format to ensure that the published documents are archivable
899 according to whatever the industry best practice is over time.
901 4.2. Evolution of the RFC Format
903 RFCs have been digital documents since very early in the days of the
904 Series. While not always published in US-ASCII, that format has been
905 the canonical format for decades. The fact that this format has
906 lasted through so much evolution and change is remarkable.
908 Unfortunately, the old US-ASCII format does not extend enough to meet
909 the expectations and requirements of users today. The entire field
910 of online document presentation, consumption, and preservation, has
911 in some cases only been invented years after the first RFC was
912 published. While it can and has) been argued that those newer fields
913 and their tools have not had a chance to stand the test of time, the
914 RFC Series Editor, in consultation with the community, started a
915 concerted effort in 2012 to bring the RFC Series into alignment with
916 a new array of possibilities for preservation and display started.
918 Information about the current RFC format project, the reasoning and
919 requirements for the changes underway today, can be found in
920 [RFC7990]. With the advent of these changes, the door has been
921 opened to consider further changes in the future as the
922 specifications for archiving digital material evolves, and as the
923 expectation of web development advances.
925 4.3. Stream Structure
927 In the eyes of many [this content may be updated based on
928 conversations with third-party marketing research groups],
929 particularly within the IETF, the RFC Series is synonymous with the
930 IETF. While the Series itself predates the IETF by eighteen years,
931 over time the IETF has become the source of the majority of documents
932 submitted for publication to the RFC Editor. The policies developed
933 for IETF stream drafts tend to apply across all four document
934 streams, and publication-related tools tend to focus on the IETF as
935 the primary audience for their use. It is difficult for people to
936 see how, or even why, there is a distinction between the Series and
937 the IETF.
939 We are in the midst of that question now more than ever. What is the
940 future of the Series? If people cannot tell where the IETF ends and
941 the Series starts, should we consider this an artificial distinction
942 and declare them to be the same entity?
944 Ultimately, this will be something the community decides, and
945 conversations are underway to consider the ramifications of possible
946 changes.
948 5. Conclusion
950 As the Internet evolves, expectations and possibilities evolve, too.
951 Over the next fifty years, the Series will continue demonstrate a
952 balance between the need to stay true to the original mission of
953 publication and preservation, while also staying relevant to the
954 needs of the authors and consumers of RFCs. The tension in balancing
955 those needs rests on the RFC Editor and the community to resolve. We
956 will not run short of challenges.
958 6.
959 Informative References
961 [IAB-19880712]
962 IAB, ""IAB Minutes 1988-07-12"", July 1988,
963 .
966 [ISI-to-AMS]
967 The IETF Administrative Support Activity, "RFC Production
968 Center Agreement between Association Management Solutions,
969 LLC, and the Internet Society", October 2009,
970 .
973 [RFC-ONLINE]
974 RFC Editor, "History of RFC Online Project", March 2019,
975 .
977 [RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001,
978 April 1969, .
980 [RFC0003] Crocker, S.D., "Documentation conventions", RFC 3,
981 DOI 10.17487/RFC0003, April 1969,
982 .
984 [RFC0114] Bhushan, A.K., "File Transfer Protocol", RFC 114,
985 DOI 10.17487/RFC0114, April 1971,
986 .
988 [RFC0433] Postel, J., "Socket number list", RFC 433,
989 DOI 10.17487/RFC0433, December 1972,
990 .
992 [RFC0690] Postel, J., "Comments on the proposed Host/IMP Protocol
993 changes", RFC 690, DOI 10.17487/RFC0690, June 1975,
994 .
996 [RFC0748] Crispin, M.R., "Telnet randomly-lose option", RFC 748,
997 DOI 10.17487/RFC0748, April 1978,
998 .
1000 [RFC1000] Reynolds, J.K. and J. Postel, "Request For Comments
1001 reference guide", RFC 1000, DOI 10.17487/RFC1000, August
1002 1987, .
1004 [RFC1083] Defense Advanced Research Projects Agency and Internet
1005 Activities Board, "IAB official protocol standards",
1006 RFC 1083, DOI 10.17487/RFC1083, December 1988,
1007 .
1009 [RFC1150] Malkin, G.S. and J.K. Reynolds, "FYI on FYI: Introduction
1010 to the FYI Notes", RFC 1150, DOI 10.17487/RFC1150, March
1011 1990, .
1013 [RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311,
1014 DOI 10.17487/RFC1311, March 1992,
1015 .
1017 [RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current
1018 Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995,
1019 .
1021 [RFC2441] Cohen, D., "Working with Jon, Tribute delivered at UCLA,
1022 October 30, 1998", RFC 2441, DOI 10.17487/RFC2441,
1023 November 1998, .
1025 [RFC2468] Cerf, V., "I REMEMBER IANA", RFC 2468,
1026 DOI 10.17487/RFC2468, October 1998,
1027 .
1029 [RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555,
1030 DOI 10.17487/RFC2555, April 1999,
1031 .
1033 [RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical
1034 Publication Service", RFC 4714, DOI 10.17487/RFC4714,
1035 October 2006, .
1037 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over
1038 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,
1039 DOI 10.17487/RFC4744, December 2006,
1040 .
1042 [RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC
1043 Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844,
1044 July 2007, .
1046 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent
1047 Submissions to the RFC Editor", RFC 4846,
1048 DOI 10.17487/RFC4846, July 2007,
1049 .
1051 [RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540,
1052 DOI 10.17487/RFC5540, April 2009,
1053 .
1055 [RFC5629] Rosenberg, J., "A Framework for Application Interaction in
1056 the Session Initiation Protocol (SIP)", RFC 5629,
1057 DOI 10.17487/RFC5629, October 2009,
1058 .
1060 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for
1061 Handling of Independent and IRTF Stream Submissions",
1062 BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009,
1063 .
1065 [RFC6360] Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360,
1066 DOI 10.17487/RFC6360, August 2011,
1067 .
1069 [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the
1070 Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
1071 DOI 10.17487/RFC6410, October 2011,
1072 .
1074 [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor
1075 Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June
1076 2012, .
1078 [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
1079 Requirements and Future Development", RFC 6949,
1080 DOI 10.17487/RFC6949, May 2013,
1081 .
1083 [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990,
1084 DOI 10.17487/RFC7990, December 2016,
1085 .
1087 [RFC8153] Flanagan, H., "Digital Preservation Considerations for the
1088 RFC Series", RFC 8153, DOI 10.17487/RFC8153, April 2017,
1089 .
1091 Appendix A. Contributors
1093 With many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil
1094 Brownlee, and Sandy Ginoza for their perspectives on the Series, and
1095 their ongoing support.
1097 Author's Address
1099 Heather Flanagan (editor)
1100 RFC Editor
1102 Email: rse@rfc-editor.org
1103 URI: https://orcid.org/0000-0002-2647-2220