by Leslie Daigle, ISOC

In April 2009, the Request For Comments (RFC) Editor published RFC 5540 [1], "40 Years of RFCs," which summarized the publication history of the RFC Series. The series has been the technical publication series for Internet technology since long before there was an Internet Engineering Task Force (IETF). Although the RFC Series is the publication vehicle for the IETF, it has been, and remains, scoped more broadly than that (refer to RFC 4844 [2], "The RFC Series and RFC Editor").The RFC Series is the archival series dedicated to documenting Internet technical specifications, including general contributions from the Internet research and engineering community as well as standards documents.

For the past three of the four decades of the history of the series, the RFC Editor work has been carried out at the University of Southern California Information Sciences Institute (USC/ISI). The RFC Editor role now faces another evolutionary step: The work involved in managing the overall series is being split up to recognize the different components of the editing, production, and archiving activities and to lay the groundwork to ensure its continued success, as outlined in RFC 5620 [3], "RFC Editor Model (Version 1)."

At the IETF 76 plenary in Hiroshima, Japan, in November 2009, USC/ISI and the role it has played in supporting the RFC Editor over the past 30 years were given special recognition. Some members of the team will move from USC/ISI to the RFC Editor's new home, where they will continue their work. We took the opportunity to talk with current and future RFC Editor staff and advisory board members, including current RFC Editor staff members Bob Braden, Sandy Ginoza, and Alice Hagens, as well as Bob Hinden, who is a member of the RFC Editor advisory board.

The People Behind the RFC Editor

Jon Postel was the first RFC Editor, starting the position in 1969 as an activity to keep track of RFC Series documents. Bob Braden, who was then part of the Advanced Research Project Agency Network (ARPANET) research program, told how he got started with the RFC Series: "I wrote my first RFC in the early 1970s, when it was somewhere around RFC 100. I was at that point manager of programming for the Computing Center at the University of California, Los Angeles (UCLA), and Advanced Research Projects Agency (ARPA) wanted to connect it to ARPANET as a resource." This was all pre-TCP/IP, and Bob's staff had to implement file transfer and Telnet. At the same time, Jon was a graduate student at UCLA, and Bob worked with him as a colleague. It was before Jon got his Ph.D. and moved to SRI in 1973–1974. In 1980, Jon moved to USC/ISI, taking the RFC editorship with him. Joyce Reynolds went to work for Jon at USC/ISI. She did much of the actual editing and became an important part of making the RFC Editor activity viable.

Jon was responsible for quality control, running the operation, and generally being the series editor. When Jon died suddenly in 1998, Bob, who joined USC/ISI in 1986, and Joyce both felt a keen sense of loss. "Jon was a very remarkable guy in many ways," Bob said. "We knew how much the RFC Series meant to Jon, and we volunteered to carry it on."

Sandy Ginoza joined USC/ISI to work on the RFC Editor activity in 1999, just after Jon passed away. Alice Hagens came onboard in 2005, taking on more of the computer-oriented aspects of the work.

RFC Series

Although we tend to reference and read individual RFC documents, it is important to understand that there is significant value in the collection of published RFCs as a series. On the importance of the RFC Series, Bob Hinden said, "This community is IETF-focused, but to the larger world not centered around the IETF; it's really the RFCs that are how you build the Internet. One of the things that made the Internet possible was the RFC Series: that you could build things and deploy things without coming to IETF meetings was valuable." Bob went on to outline his own experiences, such as meeting engineers in Taipei, for whom it was the first time they had ever met anyone who had written an RFC. Even the notion of going to an IETF meeting was in another dimension. "The RFC Series is what enables people to build products, networks, and the Internet," he said.

And it is quite an active series. Currently, some 300 documents (10,000 pages) are published every year, and although it might be interesting to review the material to detect trends or arcs of work in the Internet technical community, that type of activity is beyond the current scope of the RFC Editor. Focusing on consistency of the series, Bob Braden wondered, "Will we eventually have good enough statistics from the errata system to gauge our error rate?"

The intent of the RFC Series is to serve the broader Internet community; it is not just for or by the IETF. Sandy's perspective on the value of the Independent Stream of RFCs is that "it offers an alternate view than what happens in the IETF and what working groups have decided to take on as part of their chartered activities. It's good to document that work was done, results were generated, lessons learned, etc. 'We tried it; don't do it this way.' We often get asked why it's called RFC when we're not really requesting comments anymore, but that is the genesis, and the Independent Stream keeps some of that alive."

Bob Braden offered his own perspective on the Independent Stream.

"Historically, the RFC Series is supposed to be larger than the IETF, and while Jon was alive, the editor did whatever he thought he ought to do; the community didn't question it much."

However, in the absence of Jon as an authority figure, the community began to ask questions and build its own set of beliefs, eventually coming to believe that RFCs were only for the IETF. That matter was resolved with RFC 4846 [4], which explained that there is a separate set of independent submissions that do not come through the IETF.

"It's not a big stream, not a lot of documents, but it is important philosophically," Bob added. "The Internet community is bigger than the IETF."

The RFC Series is, nevertheless, entwined with the IETF and its activities. For instance, the discussion of (IETF) Intellectual Property Rights (IPR) has led to an impasse in assigning boilerplate to RFCs that allow the continued publication of the Independent Stream documents. That subject is being worked on and resolved, but it offers an example of some of the complexities—and frustrations—that can arise as part of the RFC Editor process. "The current situation—that the independent submissions cannot be published because we don't know what the boilerplate is—is just terrible," said Bob Braden.

Bob Hinden, who has been tracking the IPR work from the IETF side, agreed and elaborated on some important lessons learned: "The IETF created a process in the IPR working group that focused on trying to provide a solution to what they perceived as a problem. But they lost sight of the complexity and cost of implementing that solution compared with the actual risk of something bad happening. We have learned a lot about doing this in the future. This isn't like a protocol spec where you fix a bug in the finite state machine. This has a real effect on people doing stuff. When you ask for legal opinions you get the answer about how to solve the problem, but that's not the end of the process. You need to balance the cost of solving the problem with the risk of what you're trying to avoid. Lawyers are supposed to give you the lowest-risk answer. You need to follow through with questions about likelihood and consequences. This is all great hindsight, and I hope we can apply it in the future." Hinden also said he believes the current impasse could have been avoided if the new procedure had specified that it go into effect when appropriate supporting conditions were met, instead of on a specific flag day, such as the date of publication of the RFC.

The effects of entwining the RFC Series and the IETF go both ways. For example, the RFC Series recognizes three levels of standards documents: Proposed, Draft, and Full. The expectation, documented in the IETF standards process, is that standards-track specifications should be published as Proposed and then advanced to Draft and Full as the specification gets tested commercially and acknowledged as appropriately mature to move to the next stage.

In reality, as observed at the IETF 76 plenary, many of the important specifications that form the basis of the operating Internet are still published only as Proposed Standard. Bob Braden explained the history of the standards-track RFC maturity system this way: "Labels were invented whole cloth by the original Internet Architecture Board (IAB), who were a bunch of academics. At that point the Internet had not been commercialized—there were no commercial pressures—so we imagined that it made sense to step through progressions in a theoretical world. In the real world, companies are putting out products. There is no financial incentive for people to spend time advancing documents. Plus, the IETF is so large and there are so many working groups that we try to dispatch them as fast as we can; there is no one around to advance a document." There have been, and will continue to be, proposals for moving important, current standards (such as the Border Gateway Protocol [BGP]) forward in maturity or for collapsing the maturity scale and labeling system.

On the fun side of the RFC Series, there remains a tradition of "April 1st" RFCs. "That people want to participate in that is cool," said Sandy. "And we get to see the runners-up and the really-not-so-good ideas!"

Alice agreed, adding that "there are high standards for straight-faced satire."

RFC Editor

Traditionally, the RFC Editor has not only populated the series with new (approved) documents but also kept all the threads together in the RFC Series. Describing the origins of the role, Bob Braden pointed out that "Originally, Jon was prince of his kingdom. As RFC Editor, he was an honorary member of the IAB informally called the Protocol Czar. He used the RFC Editor position to actively prevent bad ideas from getting pushed. Jon imposed a consistency of style on the document series. You pick up RFC 1001 and compare it with 2001, and they look very similar." Jon believed, and the RFC Editor continues to believe today, that consistency was a worthwhile attribute, promoting stability in the series.

Reflecting back, Bob Braden said, "In discussions over the last five years, people have expressed the view that we don't need an RFC Editor—just take an Internet Draft and publish it. That notion drives me crazy. The implication is that it doesn't matter whether it is good English, correctly referenced, consistent, etc. I can't stand that view." One of the arguments for such an approach to IETF document publishing is that editing can inadvertently alter, and thereby introduce errors to, text. But the RFC Editors understand that.

Alice said changes to text can be problematic, "partly because of the technical content and partly because it is a group process. It's agreed-upon text. The idea is how precious the text is and how a slight change can make a large difference."

Sandy agreed, adding that "for as many changes that get pushed back upon, there are many that make it through the process: for as many people as look at the document before it gets to us, there are things that escape them; there is often missing text, missing words." According to Alice, with working group documents, people often focus on getting the technical ideas right, but nobody has read the text from beginning to end. In addition, many in the community are not native English speakers. It all comes back to the consistency and professionalism of the output of the series.

RFC Editing Process

As the RFC Series has grown, achieving consistency has required the creation and refining of processes. "When Joyce and I took over," said Bob Braden, "we built the website and regularized a lot of things, and the community began to ask, 'Why do you do it that way?'" In response, the editors started publicizing the Style Manuals they used. Joyce and Bob generated a lot of rules that have become institutionalized.

Of course, there is continuing evolution. Bob Braden noted that the addition of errata was his idea, although "it has turned out to be a much, much bigger deal than ever imagined, as is often the case," he said, laughing. Now we're talking about adding image files to solve the problem of incorporating graphics in an ASCII RFC. John Klensin and I generated a plausible solution for that, and we hope to get it installed soon."

It is important to note that there are some edits the RFC Editor will not make. According to Sandy, the RFC Editor tries to ensure consistency of terminology and to make recommendations that improve consistency within a document, both in a technical sense and within the series. "We don't change the active/passive voice," she said.

"We might suggest it, but we are concerned that it would affect the author's intent." Being conservative is critical. Sandy said she was surprised by how "simple grammatical changes can have a serious technical effect; placement of a comma can make a big difference in how people read the document and what they implement."

Working with authors is an important part of making the editing process successful. Innovations such as having the RFC Editor Help Desk at IETF meetings and making the AUTH48 [5] (final check of the RFC Editor's edits) more of an interactive dialogue have helped build community and create awareness of how to build a better document that conveys the meaning as intended. "It is extremely useful to get discussions started earlier, which lessens problems during AUTH48," said Alice. She added that it has also been useful to have face time with the developers of community-created tools, such as xml2rfc [6] and the Augmented Backus–Naur Form (ABNF) checker, which have been instrumental in improving RFC production. Office hours, building relationships, and face time "all help make it about working together," said Sandy.

Looking forward, Sandy said she would like to see the RFC editing process (and series) "grow and continue to be more consistent, with better community relations and more transparency so authors can look at our site and better understand the process, instead of thinking their document has gone into a black box."

On the Verge of Major Change

As this article is written, the RFC world is on the brink of major structural change. Following IAB-led community discussion, there is a new model for recognizing the components of activity that make up the RFC activities. ISI is handing off the RFC Editor activity, which will be taken up by separate organizations working together. In February 2010, the IAB appointed Nevil Brownlee as the Independent Submissions Editor (ISE) and Glenn Kowack as the Transitional RFC Series Editor (RSE). In October 2009, Association Management Solutions (AMS) was awarded 2-year contracts to manage the RFC Production Center and the RFC Publisher.

Sandy will be joining AMS as RFC Production Center director and Alice will be joining as senior editor and information technology development project manager. To the question of whether the current RFC advisory board will carry forward in the current format or will change, Bob Braden answered, "The current board serves two functions: It provides a supply of experienced people who review independent submissions, but it also gives the RFC Editor advice on policy matters. Some members of the advisory board are very strong members of the IETF in terms of policy advice. In forming the board, I tended to identify a subset of people within the IETF who have long IETF and publishing experience. In the new world there will be an RFC Series Advisory Group (RSAG), which will take over the policy discussions that are currently being conducted by the editorial board. In practice it will be the same people, at least for a while, but with separate duties. That separation is useful."

In considering the change of organizations, Sandy said the biggest thing in moving to AMS is that it is a more service-oriented environment. "In the new model," she said, "it is important that the ISE and RSE be respected individuals who are granted some of the independence the RFC Editor had at ISI."

Alice added that the institutional memory of the RFC Editor function will not be lost with the move to AMS. "Sandy has worked side by side with Bob Braden for 10 years, and much of the process is written down in the document series. I'm confident that the continuity of the series won't be lost by the move to AMS."

Bob Hinden offered another perspective. "I think one of the positive things that has come out of the new model that has gotten lost is this: A lot of people in the IETF didn't understand where the series had come from, or why the IETF chose to use it," he said.

"It is the formalization that there are different streams that have different rules. Before, this was confused with the IETF standards process. Going forward we'll have the opportunity to use the RFC Series for other relevant Internet publication streams that have not been part of IETF. Now we have a framework that would allow that."

Although it is on the verge of major changes, the RFC Series and RFC Editor functions are clearly continuing what has been a long process of constant evolution and change. This transition is just a new chapter in the history of the series.

[Ed.: This article is composed of interviews conducted by Leslie Daigle and Lucy Lynch, and notes compiled by Mat Ford. The original version was published in The IETF Journal, Volume 5, Issue 3, January 2010 and has been been updated for use in IPJ. The IETF Journal can be obtained from http://isoc.org/ietfjournal/]