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