From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5241.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc5241.txt (limited to 'doc/rfc/rfc5241.txt') diff --git a/doc/rfc/rfc5241.txt b/doc/rfc/rfc5241.txt new file mode 100644 index 0000000..79c1d34 --- /dev/null +++ b/doc/rfc/rfc5241.txt @@ -0,0 +1,675 @@ + + + + + + +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: + + + + (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, + . + + [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, + . + + [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", + . + + [XML2RFC] "A handy little tool", . + + + + + + + + +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] + -- cgit v1.2.3