NEWTRK J. Rosenberg Internet-Draft Cisco Systems Expires: April 18, 2005 A. Mankin October 18, 2004 What's In a Name: RFC draft-rosenberg-mankin-newtrk-rfc-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Currently, the Request for Comments (RFC) moniker applies to all documents that are published by the RFC editor. This includes documents produced by IETF processes, such as IAB documents or working group standards, on an equal footing with individual contributions to the RFC editor. As a result, the term RFC does not mean that a document has been produced by the IETF (though some non-IETF RFCs strongly resemble IETF RFCs). This is at odds with the understanding of the commons, which has come to view RFCs as the output document series of the IETF. This document discusses the Rosenberg & Mankin Expires April 18, 2005 [Page 1] Internet-Draft Defining RFC October 2004 importance of aligning fact with this common understanding, and proposes that the name RFC be associated only with IETF documents. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Importance of Naming - Brand . . . . . . . . . . . . . . . . . 5 3. RFC as a Brand . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Should the IETF Care about Brand? . . . . . . . . . . . . . . 7 4.1 Decrease in Provider Demand for RFCs . . . . . . . . . . . 7 4.2 Decrease in Vendor Implementation of RFCs . . . . . . . . 7 4.3 Increase in Negative Perception of the IETF . . . . . . . 8 5. Why is this a problem now? . . . . . . . . . . . . . . . . . . 9 6. Defining RFC . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Rosenberg & Mankin Expires April 18, 2005 [Page 2] Internet-Draft Defining RFC October 2004 1. Introduction The Request For Comments (RFC) series of documents began over thirty years ago with the publication of RFC 1 in 1969 at UCLA by Steve Crocker. At the time, the Internet did not exist in its current form. ARPANET was still under design, and the contract to build the first Interface Message Processor (IMP) had just been awarded to Bolt Baranek and Newman (BBN) [4]. In the thirty five years since, a great deal has changed in the technology and process that make up the Internet. Much of it is documented in the long series of RFC documents, which at this time number 3932 with the publication of RFC 3932 in October 2004 [5]. The term RFC originally meant as the name implied - a request for comments on a technical paper. According to the RFC editor web site, an RFC series is a set of technical and organizational notes about the Internet (originally the ARPANET), beginning in 1969. However, many (but not all) of the documents published in the RFC series are outputs of the IETF standards process [3]. Some are direct outputs from the Internet Architecture Board (IAB). Some (the vast majority) are developed by IETF working groups and passed through IESG, according to the RFC 2026 process. A small number become IETF standards through individual sponsorship in the same process. But, some continue to be technical documents produced outside of the IETF process, and sent directly to the RFC editor for publication. And recently, a new category of document has become more common: documents which began in IETF working groups, which look very much like IETF standards work, but which are turned down from the IETF. The archival records of this unfinished work or work which does not gain consensus, becomes part of the RFC series as well. In the past, all documents to be published as RFCs were reviewed by the IESG whether or not they were products of the IETF. Now, however, the IESG will only verify that the documents are not a standards end-run, and if not, simply publish a statement on the document that the publication has included no IETF review [5]. Indeed, a surprising number of documents have been published as RFCs outside of the IETF standards process. The precise number is unknown, since one cannot tell from examination of the document whether or not it was produced through that process. During the 2003/2004 period, the IESG considered 44 documents whose publication was requested directly from the RFC editor. Of these, the IESG recommended that 5 not be published. However, these recommendations for "do-not-publish" are just recommendations. Ultimately, the RFC editor has the right to independently assess whether to publish these documents. In one instance, the RFC editor elected to publish the document after some modifications, despite the IESG recommendations Rosenberg & Mankin Expires April 18, 2005 [Page 3] Internet-Draft Defining RFC October 2004 otherwise. This document [2] is now in the RFC editor queue. As a result of this, when a non-standards track document bears the label "RFC", it is not possible to draw formal conclusions about that document, beyond that it was published by the RFC editor. An example can make this very clear. The Reliable Multicast Transport (RMT) working group has published all of their documents initially as Experimental RFCs, but with full working group, IETF and IESG review. Their recent "standard" on a needed piece of multicast congestion control is RFC 3738 [8]. A recent document on multicast and differentiated service was submitted directly to the RFC Editor and published as an Informational RFC, RFC 3754 [9]. This document did not undergo a consensus process or community review. RMT states in their text that they will evaluate RFC 3738 for standards track. RFC 3754 states that it is not the product of a working group. As a result, we have two documents, one of which is experimental, one of which is informational, both of which solve the same problem. One was the product of the IETF, and the other was not. There is no way to determine this by looking at the documents. Both documents are RFCs, loud and clear. This document discusses this issue, and in particular introduces the notion of RFC as a "brand". It argues that this brand is a key asset to the Internet community, and that it is essential that a clear and unambiguous definition be given to the term RFC. It proposes that this definition be tied to the key value propositions of the IETF - technical quality and open standards. Rosenberg & Mankin Expires April 18, 2005 [Page 4] Internet-Draft Defining RFC October 2004 2. Importance of Naming - Brand It is of no suprise to IETF participants that the name given to something is one of its most important attributes. In both the real world and in computer science, a name is a reference. Its a way to take something small and compact, and use it to help locate something else. The name "sneaker" refers to a class of clothing worn on peoples feet. The name "Allison Mankin" refers to a specific person. The name "RFC 3261" refers to a specific document. However, in the real world, a name also invokes emotion and meaning in the mind of the person that sees the name. This meaning is built up from the experiences that person has gathered over time about the thing represented by the name. These experiences cause people to make judgements when the name is invoked, and those judgements impact behavior. This simple fact is why corporations spend billions of dollars each year to run ads and why the trademark system exists. It takes a long time to establish a positive and consistent meaning around a name. When this final does happen, it results in the creation of a brand. Brands are not limited to retailers of consumer goods, they exist everywhere. Looking close to home, the IEEE 802 series of specifications represents a brand. A large set of people in the engineering community know that a specification starting with 802 refers to ethernet, WiFi, and related technologies. The success of these technologies has resulted in a positive association of the name "802". People think of concepts such as "successful", "widely used" and "important" when they see this name. Perhaps most importantly, when a new 802 specification comes out, people associate these same feelings with it, even though they would not have read or seen the new spec. The brand carries value. It is because people associate value with a brand, even before understanding or even seeing, hearing or touching new things associated with the brand, that brings incredible value to a successful brand. Companies will fight long and hard to protect that brand. Protection includes preventing others from using the brand, and making sure that people continue to have a positive feeling when the brand is invoked. Rosenberg & Mankin Expires April 18, 2005 [Page 5] Internet-Draft Defining RFC October 2004 3. RFC as a Brand The success of the Internet and of the specifications produced by the IETF has also created a brand - "RFC". The RFC series are the visible output of the IETF, and the place in which the core Internet technologies - IP, TCP, email, web, and routing, to name a few - are documented. As a result, whether it was intended or not, the name "RFC" has become associated with "Internet Standards". One way to quickly get the sense of this is to google for "RFC" and check what the top sites say an RFC is. The following sites on the first page of the google search results which provide a definition of RFC have this to say: www.rfc-editor.org: "The Requests for Comments (RFC) document series is a set of technical and organizational notes about the Internet (originally the ARPANET), beginning in 1969.". www.rfc.net: "An RFC is a document describing the standards that make the Internet work." www.cse.ohio-state.edu/cs/Services/rfc/ " The Internet Request For Comments (or RFC) documents are the written definitions of the protocols and policies of the Internet." www.rfc-ignorant.org: "...the RFCs, the building block "rules" of the net." The consistent statement, outside of the rfc-editor site itself, is that an RFC is the documentation series of the standards that make the Internet work. As a result, when a new document bears the moniker RFC, it says something positive about the document to people, even if they never read the document or even retrieve it. Rosenberg & Mankin Expires April 18, 2005 [Page 6] Internet-Draft Defining RFC October 2004 4. Should the IETF Care about Brand? The natural question to ask next is whether the IETF, and more broadly, the Internet community, should care that the term RFC has become a brand, and has come to mean "Internet Standard". The easiest way to explore this question is to examine the implications of this brand being eliminated. What would happen if, tomorrow, we could change people's perceptions? What if people thought an RFC was just a document, no different than the output of an academic conference, some of which were produced by IETF, and some of which represented an Internet standard? That is, let us assume that IETF is still producing quality specifications, but people no longer associated an RFC in any strong way with the IETF. The implications are hard to predict, of course, in no small part because much else would need to be broken for this fact to be true. However, a few points can be made. 4.1 Decrease in Provider Demand for RFCs When service providers look to build out a network, they often create a Request for Product (RFP) that asks vendors whether or not they can provide an enumerated set of capabilities. It is not uncommon practice for providers to ask for all RFCs in a particular area, without even having reviewed the content of the RFC in any great detail to see if it solves real needs. That doesn't mean that vendors go off and implement these specifications, or that provides run and deploy them. However, it creates the seed for a converation between vendors and providers, as the technology is discussed and evaluated to assess whether or not it solves problems. In other words, the mere fact that a technology is an RFC gives it special consideration by service providers. Service providers don't usually ask for technologies described in proceedings of academic conferences or journals; they ask for documents produced by standards bodies, and RFCs are included. If RFCs lost their brand, service providers would not ask for them in advance of detailed examination, and their consideration would, in fact, be equal to any other series of documents not produced by a standards organization - virtually nil. The bar would be raised much higher for such a document to be considered, and as such, more good work would go unnoticed, reducing overall demand for IETF specifications. 4.2 Decrease in Vendor Implementation of RFCs A natural consequence of the previous result is that vendors will implement fewer IETF technologies, since they are ultimately driven Rosenberg & Mankin Expires April 18, 2005 [Page 7] Internet-Draft Defining RFC October 2004 by provider demand. 4.3 Increase in Negative Perception of the IETF If the RFC brand is no longer limited to Internet standards, but rather, refers to almost any document produced about Internet technologies, there will undoubtedly be good documents and bad documents. Unfortunately, the name alone is insufficient to differentiate documents that belong to IETF, versus ones that do not. One would hope that everyone who reads or uses an RFC would cleanly delineate in their minds and in their communications, RFCs that were products of IETF and those which were not. However, human nature is not that way. The nature of brand is that perception and value are tied to the brand itself, even without understanding anything about the specific products that make up the brand. Thus, if RFC's were no longer viewed in a positive light, even if this decline were do entirely to non-IETF documents, the perception would be that IETF documents have also declined in quality. Worse yet, once a brand loses its positive perception by the community, it is almost impossible to recover. Negative perception of the IETF has direct implications on IETF attendance, finances, and the well-being of the organization overall. Clearly, this argument is predicated on the fact that non-IETF RFCs would be of lower quality than IETF produced RFCs. There are many poor documents produced by IETF, and high quality ones produced outside of the IETF process. Thus, the disassociation of RFC with IETF does not, in and of itself imply a loss of quality. However, it does imply that the quality of those documents resides outside of IETF process and control. The purpose of this argument is to pose a thought experiment - what would happen *if* this were to occur - in order to demonstrate the importance of maintaining RFC as a brand. Rosenberg & Mankin Expires April 18, 2005 [Page 8] Internet-Draft Defining RFC October 2004 5. Why is this a problem now? The disconnect between the perception of an RFC and its actual meaning is not new. This fact has existed for as long as the industry perceived RFCs to just be the product of the IETF standards process - perhaps the last 5-10 years. Clearly, during this period, none of the aforementioned problems have occurred. Thus, is there a real problem here? This is an important question to address. The simplest answer is that the disconnect leads to the possibility of the aforementioned problems, not their certainty by any stretch of the imagination. As such, just because we have not yet seen an incident that has tainted the RFC brand, doesn't mean we won't in the future. It's like wearing a seatbelt. If you don't, it doesn't mean you'll get into in accident. However, wearing one protects you in case you do. That said, the problem has become more pressing with the publication of RFC 3932. With this change, IESG and IETF review no longer take place for documents sent directly to the RFC editor, beyond a determination of whether the specification is an end run around standards. Previously, nearly 10% of the documents sent to RFC editor for publication using this route were blocked by IESG and IETF concerns in 2003 and 2004. Now, these documents will proceed towards publication, subject to the standards and policies of the RFC editor. Extending the analogy in the previous paragraph, we are now driving the car much faster, and that means you really want to think about that seatbelt. Furthermore, the IETF and the Internet continues to mature. In particular, it is now entering an era of increased government attention. In an environment where the output of the IETF has the interest and scrutiny of governments across the world, the consequences of this problem become more dire. Finally, although there haven't been any sizeable problems as a result of this issue, there have been problems. One in particular is the existence of both the Media Gateway Control Protocol (MGCP) [6] and the Gateway Control Protocol version 1.0 (MEGACO) [7] as RFCs. The former was an industry specification that was published as an RFC, and the latter is the output of an IETF working group meant to standardize a solution for the problem at hand. MGCP is arguably more widely used and deployed than MEGACO. However, vendors have complained about needing to implement both (both are requested by service providers). Rosenberg & Mankin Expires April 18, 2005 [Page 9] Internet-Draft Defining RFC October 2004 6. Defining RFC The what-if scenarios in the previous section make it clear that it is important to the Internet community to protect the value of RFC as a brand. However, there is currently a disconnect in the perception about what an RFC is ("an Internet Standard") and what it actually is ("a series of documents on Internet technologies"). One of the most important ways a brand is maintained is through "authenticity" - make sure that perception matches reality. As a result, it is important that whatever the brand the community wishes RFC to have, should match with what an RFC is. It is our proposition that the value of an RFC to the industry is tied to its perception as an "Internet standard", and that the name RFC should only be granted to documents which match that criteria. To be more specific, we would propose that there are two characteristics of the IETF process that make it unique and impart value: Openness: The IETF process is open. Anyone can participate, and small companies can have an influence over large ones when their technology has merit. Technical Quality: Technical quality of the documents is of great concern to IETF. The IETF performs a review for technical quality, and the IETF is striving to improve its ability to review documents as it scales up [1]. The IETF standards process, described in Section 6.1 of RFC 2026 [3] defines the process for approval of documents. This process provides the openness and technical review that are the key qualities of an Internet standard. Although this process is described as applicable to documents on the standards track (proposed standard, draft standard and standard), it is currently used for nearly all documents produced by the IETF. Rosenberg & Mankin Expires April 18, 2005 [Page 10] Internet-Draft Defining RFC October 2004 7. Recommendation Our proposal is that the term "RFC" only be given to documents which are produced as part of the process described in Section 6.1 of RFC 2026. This includes working group documents and documents developed outside of a working group. It includes experimental and informational documents, in addition to standards track. All of these documents are still published through the Internet standards process, providing review, comment, an open process and a structure for appeals. Documents published by the RFC editor, but did not go through this process, should be given a different title and be part of a different document series. These documents are still important and still deserve publication. However, the name they are given should be different. Rosenberg & Mankin Expires April 18, 2005 [Page 11] Internet-Draft Defining RFC October 2004 8. Security Considerations One of the benefits of the technical review that IETF provides is the emphasis on security. If documents produced outside of the IETF, and published as RFCs, do not have adequate security review, and those documents see implementation, it could reduce the overall security of the Internet. Rosenberg & Mankin Expires April 18, 2005 [Page 12] Internet-Draft Defining RFC October 2004 9. Acknowledgements The authors would like to thank Eric Rescorla for his comments. 10 Informative References [1] Partain, D., "An Experiment in Early Cross-Area Review for the IETF", draft-ietf-icar-experiment-early-review-00 (work in progress), July 2004. [2] Allan, D., "Guidelines for MPLS Load Balancing", draft-allan-mpls-loadbal-05 (work in progress), October 2003. [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [4] Braden, R., Reynolds, J., Crocker, S., Cerf, V., Feinler, J. and C. Anderson, "30 Years of RFCs", RFC 2555, April 1999. [5] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [6] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999. [7] Groves, C., Pantaleo, M., Anderson, T. and T. Taylor, "Gateway Control Protocol Version 1", RFC 3525, June 2003. [8] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004. [9] Bless, R. and K. Wehrle, "IP Multicast in Differentiated Services (DS) Networks", RFC 3754, April 2004. Authors' Addresses Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@dynamicsoft.com URI: http://www.jdrosen.net Rosenberg & Mankin Expires April 18, 2005 [Page 13] Internet-Draft Defining RFC October 2004 Allison Mankin EMail: mankin@psg.com Rosenberg & Mankin Expires April 18, 2005 [Page 14] Internet-Draft Defining RFC October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg & Mankin Expires April 18, 2005 [Page 15]