Naming Rights in IETF Protocols
RFC - Informational
(April 2008; No errata)
No shepherd assigned
RFC 5241 (Informational)
||Send notices to
Network Working Group A. Falk
Request for Comments: 5241 BBN
Category: Informational S. Bradner
1 April 2008
Naming Rights in IETF Protocols
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
This document proposes a new revenue source for the IETF to support
standardization activities: protocol field naming rights, i.e., the
association of commercial brands with protocol fields. This memo
describes a process for assignment of rights and explores some of the
issues associated with the process. Individuals or organizations
that wish to purchase naming rights for one or more protocol fields
are expected to follow this process.
Normal engineering practice involves assigning names to fields in
network protocols. These names are generally carefully chosen to
reflect the function of the field, for example, the IPv4 Destination
As protocol designers engage in their work, many become intensely
involved with these protocol fields. Some of the most intense
discussions within the IETF have been over details about such fields.
In fact, it is an advantage to the continued viability of the IETF
that dueling is outlawed in the countries in which it meets.
But the financial realities of funding the Internet engineering and
standardization processes may dictate that the IETF must consider
whether names associated with such protocol fields represent an asset
capable of responsible monetization. This notion may be offensive to
some protocol purists; however, we believe the exigencies of the
situation make the proposal below worthy of consideration.
Falk & Bradner Informational [Page 1]
RFC 5241 Naming Rights 1 April 2008
This document describes a process and some issues associated with
managing the sale of commercial branding rights (or naming rights)
for IETF protocol fields. The authors believe that this modest
proposal may serve as a source of revenue capable of supporting IETF
standardization activities for years to come.
This proposal arose from the realization that the sports industry has
made energetic and successful use of naming rights, for stadiums in
particular, e.g., the Staples Center in Los Angeles (basketball),
Qualcomm Stadium in San Diego (football), Minute Maid Park in Houston
(baseball), and the Aaron's "Lucky Dog" get-a-lap-back (car racing).
The Internet has enabled a new online economy that, even in the wake
of the burst bubble in early 2000, is generating astounding growth
and new services. It is clear that many old-economy companies would
place high value on being associated with the new online economy and
would be willing to pay for the privilege. Internet protocols are
used around the world in myriad operating systems and devices. To be
part of the Internet protocols is to be part of the engine that is
revolutionizing how commerce is done. Many protocol fields are
displayed in popular user applications either as key aspects of the
GUI or in error or diagnostic messages. By requiring the use of the
branded protocol field, the IETF is in a position to put client
company brands in front of not only the thousands of software
developers who build with these protocols but also the hundreds of
millions of users who benefit from them. Finally, those who license
and brand a protocol field will be able to use that field in their
other marketing and claim, truthfully, that they are "in the
This proposal includes creating a primary name value for each
protocol field in the IANA registry and setting up a process whereby
an organization or an individual can license the right to record a
name of their choice in that field.
This document makes the case for the need for additional revenue for
the IETF (Section 2), followed by an introduction of the concept of
branding in IETF protocols (Section 3). Several rules and
constraints necessary to make such a revenue stream practical are
then explored (Sections 4-14). Finally, this memo concludes with an
initial assessment of the changes required by the IANA and RFC Editor
to support such a service (Sections 15-17).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Falk & Bradner Informational [Page 2]
Show full document text