In April 2009, the RFC Editor published RFC 5540: 40 Years of RFCs, which summarized the RFC Series’ publication history. The series has been the technical publication series for Internet technology since long before there was an Internet Engineering Task Force. While the RFC Series is the publication vehicle for the IETF, it has been, and remains, scoped more broadly than that. This is captured in RFC 4844: 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 series’ history, the RFC Editor work has been carried out at the University of Southern California Information Sciences Institute (USC/ISI). At the time of this writing, as 2009 draws to a close, the RFC Editor role is facing 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: RFC Editor Model (Version 1).
At the IETF 76 plenary, 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 sit down and 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 it in 1969 as an activity to keep track of RFC Series documents. Bob Braden, who was then part of the ARPANET research programme, 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 UCLA, and 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 the University of California, Los Angeles, and Bob worked with him as a colleague. It was before Jon got his Ph.D. and moved to SRI in 1973-74. 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. 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 on board 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 centred 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 while 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 was resolved with RFC 4846, 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 issue 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 was 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 impacts 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 Wednesday night 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 IAB [Internet Architecture Board], 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 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 role’s origins, Bob Braden pointed out that “originally, Jon was prince of his kingdom. As RFC Editor, he was honourary 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. 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 are often focused on getting the technical ideas right, but nobody has sat down and read the text from beginning to end. In addition, there are many in the community who are not native English speakers. It all comes back to the consistency and professionalism of the output of the series.
RFC Editing Process
Reorganizing the RFC Editor
The RFC production centre and RFC publisher have been selected after an IAOC-led procurement process. AMS takes over the responsibility for these functions as of January 1, 2010. The two other functions that the RFC Editor model (RFC 5620) defines are the RFC Series Editor and the Independent Submissions Editor.
The priority of the IAB is to appoint an RFC Series Editor. After a first acquisition round, it was decided that during the first couple of months, the focus would be on managing the transition from Bob Braden’s team at ISI to the multiple roles as defined by the RFC Editor model. As such, the responsibilities and profile of the person performing that transition are likely to differ from the responsibilities and profile of the person performing the role after the transition.
At the time of this writing, the advisory committee that assists the IAB is working on a recommendation to the IAB for the RSE function. After that job is finished, the committee will continue by working on a recommendation for the ISE position.
In the meantime, Bob has been found willing and able to provide background and assistance for the transitional RSE and to keep the wheels in motion while that RSE has not yet started.
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 Web site 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 key. Sandy said she was surprised by how “simple grammatical changes can have a serious technical impact; 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 (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 and the 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. The status of those structural changes (and their implementation) is noted in the sidebar (see sidebar, below), provided by IAB chair Olaf Kolkman. In October 2009, AMS was awarded two-year contracts to manage the RFC Production Centre and the RFC Publisher.
Sandy will be joining Association Management Solutions (AMS) as RFC Production Centre 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 issues. 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 RSAG [RFC Series Advisory Group], 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 [Independent Submissions Editor] and RSE [RFC Series Editor] be respected individuals who are granted some of the independence the RFC Editor had at ISI.”
Alice added that the biggest shift will be the institutional memory of Bob Braden, but, as she explained, “there were 10 years of overlap, so it’s not going into a black hole. And much of it 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 function are clearly continuing what has been a long process of constant evolution and change. This is just a new chapter in the series’ history.
* This article is composed of interviews conducted by Leslie Daigle and Lucy Lynch, and notes compiled by Mat Ford.
This article was posted on 20 January 2010 .