NEWTRK                                                      J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: April 18, 2005                                        A. Mankin
                                                        October 18, 2004

                         What's In a Name: RFC

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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 18, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.


   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

   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

   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: "The Requests for Comments (RFC) document series
      is a set of technical and organizational notes about the Internet
      (originally the ARPANET), beginning in 1969.". "An RFC is a document describing the standards that make
      the Internet work." " The Internet Request For
      Comments (or RFC) documents are the written definitions of the
      protocols and policies of the Internet." "...the RFCs, the building block "rules" of the

   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

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
   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

   Phone: +1 973 952-5000

Rosenberg & Mankin       Expires April 18, 2005                [Page 13]

Internet-Draft                Defining RFC                  October 2004

   Allison Mankin


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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

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.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Rosenberg & Mankin       Expires April 18, 2005                [Page 15]