    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:

         <pfield name="IPv4 Destination Address"/>

       (Doing this for all existing RFCs may involve some work.)

       As the XML RFCs are completed, the RFC Editor SHALL then create an
       ASCII version of the RFC from the XML file using the naming
       convention of "Real_RFCxxxx.txt".  During the translation, each
       protocol field is looked up in the IANA protocol field-to-brand name
       database.  If there is an ASCII brand name associated with the
       protocol field, the word "the" and the brand name are prepended to
       the IETF name for the field (unless the name appears in ASCII art
       where changing the length of the name would distort the art).  For
       example, if the protocol field is "Destination Address" and the brand
       name in the IANA database is "Garmin GPS", the string "the Garmin GPS
       Destination Address" would be used in the Real_RFC.  Changing the
       lengths of such names may require adjusting the other details of the
       document such as page numbering in the Table of Contents.  The
       software to do some of the formatting might be a bit tricky.

       The RFC Editor may optionally produce other non-normative versions of
       Real_RFCs.  For example, a non-normative Portable Document Format
       (PDF) version may be created in addition to the ASCII Real_RFC
       version.  The RFC Editor may use the UTF-8 brand, if present, in such
       alternate versions.

       The Real_RFC SHALL be used for all normal purposes within the IETF
       and elsewhere with the original version being reserved as an archival
       reference.

    Falk & Bradner               Informational                      [Page 8]

    RFC 5241                     Naming Rights                  1 April 2008

       The RFC Editor SHALL rebuild all the Real_RFCs on a regular basis to
       create up-to-date Real_RFCs that reflect the current status of the
       protocol field licenses.

       The RFC Editor SHALL provide a list of un-leased field names to the
       IANA for inclusion in the IETF Protocol Branding Catalog.

    17.  Tool Builder Considerations

       Upon the adoption of this proposal, the maintainer of the official
       xml2rfc tool SHALL update the tool to support the protocol field
       element and to consult the IANA database when being used to produce
       Real_RFCs (or Real_IDs).  Upon the adoption of this proposal,
       document authors will be required to transmit the raw XML input file
       for the xml2rfc tool to the RFC Editor when the document is approved
       for publication.

    18.  Security Considerations

       The fact that the IETF will not undertake to ensure that the
       purchasing organization has the right to use the name they choose to
       use can lead to mischief.  For example, a Microsoft competitor could
       purchase the right to name the IPv4 Header Security Flag [RFC3514]
       "the Microsoft Evil bit".

    19.  Conclusion

       The discussion above has introduced the concept of branding IETF
       protocols and the associated implications.  Clearly there are non-
       trivial costs to starting up and maintaining such a revenue stream.
       However, advertising has a long and distinguished history of
       supporting valuable community services such as free broadcast
       television and Google.

       As branded protocols become established, new protocols will be
       developed with names conducive to branding.  In fact, licensees may
       initiate new IETF work just to see an appropriate field established.
       So, besides the economic benefits to the IETF, this initiative may in
       fact help ensure the IETF is never without work and, thus, self-
       sustaining and self-perpetuating.

    Falk & Bradner               Informational                      [Page 9]

    RFC 5241                     Naming Rights                  1 April 2008

    20.  References

    20.1.  Normative References

       [RFC2233]  Postel, J. and J. Reynolds, "Instructions to RFC Authors",
                  RFC 2223, October 1997.

    20.2.  Informative References

       [BUDGET]   IETF 2008 budget,
                  <http://iaoc.ietf.org/documents/2008_Budget_Final.pdf>.

       [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,
                  <http://www.iana.org/protocols/>.

       [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

       [RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header," RFC
                  3514, 1 April 2003.

       [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
                  10646", STD 63, RFC 3629, November 2003.

       [UDRP]     ICANN, "Uniform Domain-Name Dispute-Resolution Policy",
                  <http://www.icann.org/udrp/udrp.htm>.

       [XML2RFC]  "A handy little tool", <http://xml.resource.org/>.

    Falk & Bradner               Informational                     [Page 10]

    RFC 5241                     Naming Rights                  1 April 2008

    21.  Acknowledgments

       Craig Milo Rogers receives credit for the idea which lead to this
       proposal.  Allison Mankin contributed to some early discussions of
       the issues associated with naming rights.  Also, thanks to David
       Parkes for his advice on types of auctions.

    Editors' Addresses

       Aaron Falk
       BBN Technologies
       10 Moulton Street
       Cambridge MA, 02138 USA

       Phone: +1 617 873 2575
       EMail: falk@bbn.com

       Scott Bradner
       Harvard University
       29 Oxford St.
       Cambridge MA, 02138 USA

       Phone: +1 617 495 3864
       EMail: sob@harvard.edu

    Falk & Bradner               Informational                     [Page 11]

    RFC 5241                     Naming Rights                  1 April 2008

    Full Copyright Statement

       Copyright (C) The IETF Trust (2008).

       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.

       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, THE IETF TRUST 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.

    Intellectual Property

       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.

    Falk & Bradner               Informational                     [Page 12]