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