RFC 5241

Naming Rights in IETF Protocols 🦋

okay bestie, this is RFC 5241, and the vibes are immaculate 💅 It's Informational, so it just provides info for the Internet community and doesn't set any Internet standard. It was written by A. Falk of BBN and S. Bradner of Harvard University, and it's dated 1 April 2008 🙈 The title block doesn't list any RFCs it obsoletes or updates, and distribution is unlimited ✨

Status of This Memo ✨

ngl this section is just the legal-ish bit: the memo gives information to the Internet community, it does not specify an Internet standard of any kind, and it can be distributed without limit 🌸

Abstract 🎀

okay so the big idea is a brand new revenue source for the IETF to fund standardization work 💰 It's called protocol field naming rights, which basically means attaching commercial brands to protocol fields 😭 This memo lays out a process for handing out those rights and pokes at some of the issues that come with it. Anyone who wants to buy naming rights for one or more protocol fields is expected to follow that process 🫶

1. Introduction 💖

okay so normal engineering practice is naming the fields in network protocols, and the names are usually picked super carefully so they match what the field does. Like the IPv4 Destination Address field, which is literally just telling you what it is 🧚

Protocol designers get really, really attached to these fields. Some of the most intense IETF debates have been about tiny field details 😭 Honestly the IETF is lowkey lucky that dueling is outlawed in the countries where it meets 💀

But the money side is real. Funding Internet engineering and standardization may mean the IETF has to ask whether names on protocol fields could be an asset that gets responsibly monetized 🤑 Some protocol purists might be scandalized by this, but the authors think the situation is so urgent that the proposal is worth a look 🙈

This document describes a process and some issues with managing the sale of commercial branding rights (a.k.a. naming rights) for IETF protocol fields. The authors believe this modest proposal could be a revenue source that keeps supporting IETF standardization for years 🌈

The idea came from the sports world, which has gone all in on naming rights, especially for stadiums. Examples are 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 created a whole new online economy. Even after the burst bubble in early 2000, it's still growing like crazy and making new services 📈 Lots of old-economy companies would love to be linked with that world and would pay for the privilege. Internet protocols run around the world on tons of operating systems and devices, so being part of them is being part of the engine changing how commerce works 🚀 Plenty of protocol fields also show up in popular user apps, either as key parts of the GUI or in error and diagnostic messages. If the branded protocol field is required, the IETF could put client brands in front of the thousands of software developers building on these protocols and the hundreds of millions of users who use them 👑 And anyone who licenses and brands a protocol field can use it in their other marketing and truthfully claim that they are "in the network" ✨

The proposal includes creating a primary name value for each protocol field in the IANA registry, plus a process where any organization or individual can license the right to record a name of their choice in that field 🎀

The document makes the case for the IETF needing extra revenue (Section 2), then introduces the concept of branding in IETF protocols (Section 3). Several rules and constraints that make this revenue stream practical get explored next (Sections 4-14). Last, the memo gives an initial assessment of the changes the IANA and RFC Editor would need to support this 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]. 📖

2. Revenue Needs 💸

running the IETF is not cheap, bestie 😭 At the 71st IETF meeting in Philadelphia, PA, USA, it was reported that the 2008 budget [BUDGET] had passed US$4.5 M, up from $4.1 M in 2007. About US$3 M of that revenue comes straight from IETF activities, like meeting fees and sponsorships, and the rest comes from the Internet Society (ISOC). Over the last few years the IETF has had to keep raising meeting fees just to keep the budget balanced 🥲

Pulling in an extra US$1 M from renting naming rights could seriously change the budget dynamics 🤩 Maybe meeting fees could go down for everyone, or special subsidies could go to needy students, researchers, or job seekers 🎓 Other options: making the break cookies big enough to feed a family of geeks for a week instead of the mere day and a half they lasted at the 71st IETF 🍪, or renting out a bar for the working group chairs social so they don't have to deal with the rowdy locals 🍸. There are lots of other deserving ways the IETF could spend this money too 💜 Just know that any of these perks might have to wait a few years to pay off the startup costs mentioned below ⏳

3. How Are Branded Protocol Fields Used? 🦋

3.1. Within the IETF

okay so once a protocol field name is licensed from the IETF, all future IETF activities and documentation for products that claim to conform to IETF standards MUST use the complete branded name 📣 And if the complete branded name isn't used, the output from protocol implementations and their documentation MUST be considered non-conformant. No exceptions, periodt 💅

3.2. Externally

the official IETF name for a purchased field is the complete branded name 🎀 So any 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 up to the licensee to enforce the use of complete branded names in non-IETF documents 🫶

4. Names Must Be in Good Taste 🌸

the combination of brand names and protocol field names has to avoid anything some part of the Internet community might find offensive 🙈 Name purchases shall be reviewed for taste. Prospective purchasers have to prepare a proposal for how the branded protocol name will be used in advertising or other media. (Side note: a well-developed taste-review process might also be useful for other IETF stuff, like working group names, T-shirts, and host presentations 👕)

As long as it's within the limits of taste, the branded protocol field may be used for any purpose 💖

5. When Names Change 🔄

as other areas that sell or lease naming rights have found, commercial realities can change fast. A brand name can suddenly fall out of favor or even stop referring to an existing entity 😬 Also, branding is leased (sold for use over a limited time), so the branding on a particular field may change when the lease is up 📅 That means there must be a mechanism to change branding when needed. Check the IANA Considerations, RFC Editor Considerations, and Tools Considerations sections for more info 🧚

6. Example Names ✨

the most effective names pair the meaning of a field with something a sponsor wants. The examples below show good and bad pairings, so you can see how a well-matched pairing can be super 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

Protocol names show up inside the fields of other protocols, so the protocols themselves could be candidates for branding too 🌈

BEEP: AAA BEEP
SOAP: Downey SOAP
PPP: FloMax PPP

Branding doesn't have to be limited to company names or other trademarked terms either 🦋 For example, a publisher could decide to honor one of their authors:

The Thomas Wolfe Source Address Field

6.2. In Bad Taste 🙈

these are the ones that are NOT it, bestie. Don't be these 💀

SIP: Seagrams Vodka SIP Event
SIP: Calvin Klein Event Package
IP: Viagra Total Length

6.3. Confusing Names 😵‍💫

Places where the brand could get in the way of understanding the protocol are prohibited 🚫

SMTP: US Postal Service Mail command
IPv6: ITU-T Protocol field
IKE: RSA Vendor ID

6.4. Valid Names 📝

so, 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 won't make sure the purchasing organization actually has the right to use the name they picked. All purchasing organizations MUST indemnify the IETF against any challenges to their authority to use the name 🛡️

8. Scope of Naming Applicability 🌍

because IETF protocols aren't controlled in a way that matches legal jurisdictions, it's hard to limit naming rights to just the places where a particular trademark can be registered 🗺️ The process in this memo doesn't use geographic or geopolitical boundaries on branded fields. The design team is working on a proposal to fix this issue. If the design team succeeds, 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, but only if the protocols were developed within the IETF process and the protocol field hasn't already been branded by someone else using the same process 🫶

10. Pricing 💸

Okay so there are going to be multiple pricing strategies for naming rights to protocol fields over time, bestie 💅. The main goal of pricing is to get the greatest possible revenue for the IETF 🤑. At first, prices get set by negotiation between whoever wants to buy the naming right and the Internet Auction Board (IAB) representative 🤝. BUT we strongly suggest migrating to an all pay auction (also known as a Tullock auction) to find the optimal price when there are multiple bidders [KOVENOCK] 🔥. Another option is open-outcry auctions [EKLOR], perhaps with a secret reserve price, held at IETF meetings during a BoF session 🎀. That way, taste review and brand assignment (sale) can happen at the same time, with open participation ✨. See [MILGROM] for info on the different auction styles 📚.

11. Time of Ownership ⏳

The design team literally could not agree on a default lease term 😭. Half of them wanted a term that matches the half-life of an Internet startup (1 or 2 years), and the other half wanted one that matches the half-life of a product from a mature Internet company (8 to 10 years) 🍓. Terms longer than 10 years, like leases that would end when a protocol advanced on the standards track (basically forever), came up but got mostly tossed 🗑️, because so few companies in Internet land survive in any recognizable form that long 💀. In the end, the design team decided the lease term should be part of the negotiation between the IETF and the purchasing organization 🫶.

12. How Are Naming Rights Purchased? 🛍️

Here's how you buy a naming right 👀. Licensees fill out an application where they name the protocol field they want and the particular RFC it appears in (Internet-Draft tags are available for short term lease) 📝. Then they state their brand and pitch their proposal for external use and how long they want to own it 🦋. Next up is a taste review, followed by either an auction or IAB negotiation 💖. The whole thing wraps up when the IANA updates 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]. Protocol fields aren't domain names, but branding them causes the same kinds of drama 🙄, and we feel it's better to use an existing process than to invent a brand new one 🧚.

14. Future Expansions 🌈

If this proposal is a hit, it can easily expand to cover other protocol features like options and parameters ✨. Like, imagine this:

      IPv6: The Herman Melville Jumbogram option

15. IANA Considerations 🏛️

Upon 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 that list has to be beefed up to include all fields in all IETF protocols, even the ones where no IANA assignments are made 📈.

The two brand name fields for each protocol field (the ASCII field and the optional UTF-8 field) start out as NULL 🫥.

Whenever the IETF leases a protocol field, the IANA SHALL enter the brand name(s) into the brand-named fields tied to that protocol field and SHALL set the lease termination date to the proper value 🗓️.

Also, the IANA SHALL regularly scan the database for leases ending within the next 30 days and tell the IETF about them, so the IAB can reach out to the leaseholder and sign them up for an additional term 🔔. When a lease expires, the IANA SHALL remove any brand names from the database 👋.

16. RFC Editor Considerations 📝

Upon adoption of this proposal, the RFC Editor SHALL create XML versions of all IETF RFCs. The XML has to be such that a perfect copy of the original RFC can be produced using a tool like xml2rfc [XML2RFC] 🪄. The XML versions of RFCs must identify all individual protocol fields using an XML protocol field element of this form:

     <pfield name="IPv4 Destination Address"/>

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

As the XML RFCs get completed, the RFC Editor SHALL then create an ASCII version of each RFC from the XML file, using the naming convention Real_RFCxxxx.txt 📄. During the translation, each protocol field gets looked up in the IANA protocol field-to-brand name database. If there's an ASCII brand name linked to the protocol field, the word "the" and the brand name get prepended to the IETF name for the field (unless the name appears in ASCII art, where changing its length 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 names like this may mean adjusting other details of the document, like 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 kept as an archival reference 📚.

The RFC Editor SHALL rebuild all the Real_RFCs on a regular basis, so they're up to date and 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 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 it's used to produce Real_RFCs (or Real_IDs) 🔧. Also, once this is adopted, document authors will be required to send the raw XML input file for the xml2rfc tool to the RFC Editor when the document is approved for publication 📬.

18. Security Considerations 🚨

Okay bestie, this one's serious 😭🚨 The fact that the IETF will not undertake to ensure that the purchasing organization has the right to use the name they choose 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". Iconic? Absolutely not. Dangerous? Yes 💀.

19. Conclusion 🎉

The discussion above has introduced the concept of branding IETF protocols and the implications that come with it ✨. Clearly, there are non-trivial costs to starting up and maintaining a revenue stream like this 💸. BUT advertising has a long and distinguished history of supporting valuable community services, like free broadcast television and Google 📺.

As branded protocols get established, new protocols will be developed with names that are conducive to branding 💅. In fact, licensees may start new IETF work just to see an appropriate field established 🤭. So, besides the economic benefits for the IETF, this initiative may actually help make sure the IETF is never without work, and therefore self-sustaining and self-perpetuating ♾️.

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/>.

21. Acknowledgments 🫶

Craig Milo Rogers gets credit for the idea that led to this proposal 💡. Allison Mankin contributed to some early discussions of the issues around naming rights 💬. And 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

Full Copyright Statement ©️

Legal stuff, but it's still important, so here it is in full ✨

   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 💅

okay so this part is all about the legal stuff 🫶 The IETF is basically saying it takes no position on whether any patents or other rights covering this tech are valid, how far they reach, or whether a license is even available 🙈 It also hasn't gone looking for those rights itself, so no promises there. ngl, very responsible of them.

If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 ✨

Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses that will be offered, plus the results of anyone trying to get a general license or permission for implementers or users to use proprietary rights. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🧚

And if you spot a copyright, patent, patent application, or other proprietary right that might cover tech you'd need to implement this standard, the IETF wants to hear about it! Send it to ietf-ipr@ietf.org 💌 bestie is literally asking you to speak up 📣