Network Working Group A. Falk
Request for Comments: 5241 BBN
Category: Informational S. Bradner
Harvard University
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.
Abstract
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.
1. Introduction
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
Address field.
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
network".
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]
RFC 5241 Naming Rights 1 April 2008
2. Revenue Needs
Running the IETF is not inexpensive. It was reported at the 71st
IETF meeting in Philadelphia, PA, USA that the 2008 budget [BUDGET]
for the IETF had surpassed US$4.5 M, up from $4.1 M in 2007. About
US$3 M of revenue in this budget flows directly from IETF activities,
including meeting fees and sponsorships, and the remainder flows from
the Internet Society (ISOC). Over the last few years the IETF has
had to raise meeting fees repeatedly in order to keep this budget
balance reasonable.
Raising an additional US$1 M from the rental of naming rights could
significantly change the budget dynamics. Perhaps meeting fees could
be reduced for all attendees or special subsidies could be provided
to needy students, researchers, or job seekers. Other options for
the use of the increased revenue could be sizing the break cookies
large enough to feed a family of geeks for a week rather than the
mere day and a half as was the case at the 71st IETF, or renting out
a bar for the working group chairs social rather than having to put
up with the rowdy locals. There are many other equally deserving
ways that the IETF could spend the resources generated by this
proposal. It should be noted that any such benefits may have to be
delayed for a few years to pay for the startup costs noted below.
3. How Are Branded Protocol Fields Used?
3.1. Within the IETF
When a protocol field name is licensed from the IETF, all future IETF
activities, and documentation for products claiming to conform to
IETF standards, MUST use the complete branded name. The output from
protocol implementations, and associated documentation, MUST be
considered non-conformant if the complete branded name is not used.
3.2. Externally
The official IETF name for a purchased field is the complete branded
name. Thus, all externally generated documentation that references
the protocol must be considered incomplete unless it used the
complete branded name where one exists. The IETF leaves it to the
licensee to enforce the use of complete branded names in non-IETF
documents.
Falk & Bradner Informational [Page 3]
RFC 5241 Naming Rights 1 April 2008
4. Names Must Be in Good Taste
The combination of brand names and protocol field names must avoid
uses that may be considered offensive by some part of the Internet
community. Name purchases shall be reviewed for taste. Prospective
purchasers must prepare a proposal for how the branded protocol name
will be used in advertising or other media. (Note that a well-
developed taste-review process may prove useful for other IETF
activities, for example, IETF working group names, T-shirts, and host
presentations.)
Within the limits of taste, the branded protocol field may be used
for any purpose.
5. When Names Change
As has been discovered in other areas where naming rights are sold or
leased, commercial realities and developments mean that a brand name
can suddenly go out of favor or even cease to denote an existing
entity. In addition, branding is leased (i.e., sold to be used over
a limited time) and the branding for a particular field may change
when the lease is up. Thus, there must be a mechanism to change
branding when needed. See the IANA Considerations, RFC Editor
Considerations, and Tools Considerations sections for more
information.
6. Example Names
The most effective names are those that pair the semantics of a field
with a characteristic desirable to a sponsor. The following examples
of good and bad pairings illustrate how an appropriate pairing can be
appealing.
6.1. Acceptable Taste-Wise
IP: Garmin GPS Destination Address
IP: White & Day Mortuary Time-to-live
TCP: Princess Cruise Lines Port Number
ARP: Springfield Preschool Timeout
BGP: Sharpie Marker field
TFRC: Traveler's Insurance Loss Period
SCTP: Hershey's Chunk {type|flags|length}
SMTP: eHarmony HELO
Falk & Bradner Informational [Page 4]
RFC 5241 Naming Rights 1 April 2008
Protocol names appear within the fields of other protocols;
therefore, the protocols themselves may be candidates for branding:
BEEP: AAA BEEP
SOAP: Downey SOAP
PPP: FloMax PPP
There is no requirement for branding to be limited to company names
or other trademarked terms. For example, a publisher could decide to
honor one of their authors:
The Thomas Wolfe Source Address Field
6.2. In Bad Taste
SIP: Seagrams Vodka SIP Event
SIP: Calvin Klein Event Package
IP: Viagra Total Length
6.3. Confusing Names
Places where the brand could interfere with the understanding of the
protocol are prohibited:
SMTP: US Postal Service Mail command
IPv6: ITU-T Protocol field
IKE: RSA Vendor ID
6.4. Valid Names
In order to be printed in the ASCII-only Real-RFC (described in
Section 16) all brands must include an ASCII form. The ASCII name
MUST conform to the requirements in RFC 2223 [RFC2233]. The brand
MAY optionally include a UTF-8 version for use in non-ASCII
representations. See RFC 3629 [RFC3629].
7. Who Can Buy Naming Rights?
Any organization or individual can purchase the right to brand a
protocol field. The IETF will not undertake to ensure that the
purchasing organization has the right to use the name they choose to
use. All purchasing organizations MUST indemnify the IETF against
any challenges to the authority of the purchasing organization to use
the name.
Falk & Bradner Informational [Page 5]
RFC 5241 Naming Rights 1 April 2008
8. Scope of Naming Applicability
Because the application of IETF protocols is not controlled in a way
that corresponds to legal jurisdictions, it is difficult to restrict
naming rights to include just those places where a particular
trademark may be registered. The process described in this memo does
not include the use of geographic or geopolitical boundaries on the
use of branded fields. The design team is working on a proposal to
overcome this issue. If the design team is successful, the same
proposal should find application in a number of areas of
international diplomacy.
9. Who Can Sell Naming Rights?
The IETF SHALL retain the sole right to permit branded protocol names
to be used within IETF protocols. The IETF MAY sell rights for
external use of branded protocol names if the protocols have been
developed within the IETF process and if the protocol field has not
already been branded by someone else using the same process.
10. Pricing
Multiple pricing strategies for the naming rights to protocol fields
will likely be used over time. The primary objective of pricing is
to enable the greatest possible revenue for the IETF. Initially,
prices will be set by negotiation between the party wishing to
purchase the naming right and the Internet Auction Board (IAB)
representative. However, we strongly suggest migrating to an all pay
auction (also known as a Tullock auction) for finding the optimal
price when there are multiple bidders [KOVENOCK]. Alternatively,
open-outcry auctions [EKLOR], perhaps with a secret reserve price,
could be held at IETF meetings using a BoF session, permitting taste
review and brand assignment (sale) to be conducted concurrently and
with open participation. See [MILGROM] for information on various
auction styles.
11. Time of Ownership
The design team could not come to consensus on a default term of a
lease of the authority to name a protocol field. It was split
between a term that would best represent the half-life of an Internet
startup (1 or 2 years) and a term that would best represent the
half-life of a product offered by a mature Internet company (8 to 10
years). The idea of terms any longer than 10 years, for example,
leases that would terminate when a protocol advanced on the standards
track (i.e., roughly infinite), was discussed but generally discarded
because so few companies survive in any recognizable form for that
Falk & Bradner Informational [Page 6]
RFC 5241 Naming Rights 1 April 2008
length of time in the Internet space. In the end, the design team
concluded that the lease term should be part of the negotiation
between the IETF and the purchasing organization.
12. How Are Naming Rights Purchased?
The right to name a protocol field is purchased using the following
process: licensees complete an application where they identify the
protocol field they wish to use and the particular RFC in which it
appears (Internet-Draft tags are available for short term lease). At
that time, they identify their brand and present their proposal for
external use and length of ownership. The next step is a taste
review followed by an auction or IAB negotiation. The purchase
concludes with the IANA updating their protocol field name mapping
database.
13. Dispute Resolutions
All disputes arising from this process MUST be resolved using the
ICANN Uniform Domain-Name Dispute-Resolution Policy [UDRP]. While
the protocol fields are not domain names, branding them presents the
same types of issues and we feel that it's better to make use of an
existing process rather than to invent a new one.
14. Future Expansions
If this proposal proves successful, it can be easily expanded to
include other protocol features such as options and parameters. For
example:
IPv6: The Herman Melville Jumbogram option
15. IANA Considerations
Upon the adoption of this proposal the IANA SHALL set up a protocol
field-to-brand-name database (the "IETF Protocol Branding Catalog")
that includes all protocol fields in IETF-developed or -maintained
protocols. This database can be bootstrapped from the existing
protocol registries database [PROTREG], but this list will have to be
augmented to include all fields in all IETF protocols, even the ones
in which no IANA assignments are made.
The two brand name fields associated with each protocol field (the
ASCII field and the optional UTF-8 field) are initialized as NULL.
Falk & Bradner Informational [Page 7]
RFC 5241 Naming Rights 1 April 2008
Whenever the IETF leases a protocol field, the IANA SHALL enter the
brand name(s) into the brand-named fields associated with the
protocol field and SHALL set the lease termination date to the proper
value.
In addition, the IANA SHALL regularly scan the database to look for
leases terminating within the next 30 days and inform the IETF of any
such leases so that the IAB can approach the leaseholder to sign up
for an additional term. The IANA SHALL remove any brand names from
their database when the lease expires.
16. RFC Editor Considerations
Upon the adoption of this proposal the RFC Editor SHALL create XML
versions of all IETF RFCs. The XML must be such that a perfect copy
of the original RFC can be produced using a tool such as xml2rfc
[XML2RFC]. The XML versions of RFCs must identify all individual
protocol fields using an XML protocol field element of the form:
.
[EKLOR] Eklor, M and A. Launander, "Open outcry auctions with
secret reserve prices: an empirical application to
executive auctions of tenant owner's apartments in
Sweden", Journal of Econometrics, Volume 114, Issue 2,
June 2003, pages 243-260.
[KOVENOCK] Kovenock, D. & de Vries, C.G., 1995. "The All-Pay Auction
with Complete Information", UFAE and IAE Working Papers
311.95, Unitat de Fonaments de l'Analisi Economica (UAB)
and Institut d'Analisi Economica (CSIC), revised.
[MILGROM] Milgrom, P., "Auctions and Bidding: A Primer", Journal of
Economic Perspectives, American Economic Association, vol.
3(3), pages 3-22, Summer 1989.
[PROTREG] IANA Protocol Registries,
.
[XML2RFC] "A handy little tool",
RFC, FYI, BCP