Naming Rights in IETF Protocols
RFC 5241

Document Type RFC - Informational (April 2008; No errata)
Last updated 2013-03-02
Stream ISE
Formats plain text pdf html bibtex
Stream ISE state (None)
Consensus Boilerplate Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 5241 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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",
Show full document text