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]