summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5241.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5241.txt')
-rw-r--r--doc/rfc/rfc5241.txt675
1 files changed, 675 insertions, 0 deletions
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:
+
+ <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]
+