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