Network Working Group                                            A. Falk
Request for Comments: 5241                                           BBN
Category: Informational                                       S. Bradner
                                                      Harvard University
                                                            1 April 2008
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.




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
1. 介绍

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.


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


2. Revenue Needs
2. 收入需求

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.

从冠名权租金中再筹集100万美元可能会显著改变预算动态。也许所有与会者的会议费用都可以降低,或者可以向有需要的学生、研究人员或求职者提供特别补贴。使用增加的收入的其他选择可能是将break Cookie的大小定得足够一个极客家庭吃一周,而不是像第71届IETF那样只吃一天半,或者租一个酒吧给社会工作组主席,而不必忍受当地人的吵闹。IETF还可以采用许多其他同样值得采用的方式来使用该提案产生的资源。应注意的是,任何此类福利可能不得不推迟几年,以支付下文所述的启动成本。

3. How Are Branded Protocol Fields Used?
3. 如何使用品牌协议字段?
3.1. Within the IETF
3.1. 在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
3.2. 外部

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.


4. Names Must Be in Good Taste
4. 名字一定很有品味

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
5. 当名字改变时

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
6. 示例名称

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
6.1. 可接受的口味
      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
      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 appear within the fields of other protocols; therefore, the protocols themselves may be candidates for branding:



蜂鸣声:AAA蜂鸣声肥皂:唐尼肥皂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

Thomas Wolfe源地址字段

6.2. In Bad Taste
6.2. 低级趣味

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

SIP:Seagrams伏特加SIP事件SIP:Calvin Klein事件包IP:Viagra总长度

6.3. Confusing Names
6.3. 混淆的名字

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
6.4. 有效名称

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

为了以ASCII格式打印,所有品牌必须包含ASCII格式。ASCII名称必须符合RFC 2223[RFC2233]中的要求。该品牌可选择包括UTF-8版本,用于非ASCII表示。参见RFC 3629[RFC3629]。

7. Who Can Buy Naming Rights?
7. 谁可以购买命名权?

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.


8. Scope of Naming Applicability
8. 命名适用范围

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?
9. 谁可以出售命名权?

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
10. 定价

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
11. 所有权时间

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


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?
12. 如何购买命名权?

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
13. 争端解决

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
14. 未来扩张

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

IPv6:Herman Melville巨型程序选项

15. IANA Considerations
15. IANA考虑

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.


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
16. RFC编辑器注意事项

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:

本提案通过后,RFC编辑应创建所有IETF RFC的XML版本。XML必须能够使用xml2rfc[xml2rfc]等工具生成原始RFC的完美副本。RFC的XML版本必须使用表单的XML协议字段元素标识所有单独的协议字段:

     <pfield name="IPv4 Destination Address"/>
     <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.

XML RFC完成后,RFC编辑器应使用“Real_rfcxxx.txt”命名约定从XML文件创建一个ASCII版本的RFC。在翻译过程中,每个协议字段都会在IANA协议字段中查找到品牌名称数据库。如果存在与协议字段相关联的ASCII品牌名称,则在该字段的IETF名称前加上单词“the”和品牌名称(除非名称出现在ASCII art中,更改名称长度会扭曲art)。例如,如果协议字段为“目的地地址”,IANA数据库中的品牌名称为“Garmin GPS”,则实际RFC中将使用字符串“Garmin GPS目的地地址”。更改此类名称的长度可能需要调整文件的其他细节,如目录中的页码。执行某些格式化的软件可能有点棘手。

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.

RFC编辑器可以选择生成Real_RFC的其他非规范版本。例如,除了ASCII Real_RFC版本外,还可以创建非标准的可移植文档格式(PDF)版本。RFC编辑器可在此类备用版本中使用UTF-8品牌(如有)。

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.


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
17. 工具生成器注意事项

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
18. 安全考虑

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
19. 结论

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.


20. References
20. 工具书类
20.1. Normative References
20.1. 规范性引用文件

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

[RFC2233]Postel,J.和J.Reynolds,“RFC作者须知”,RFC 2223,1997年10月。

20.2. Informative References
20.2. 资料性引用

[BUDGET] IETF 2008 budget, <>.

[预算]IETF 2008年预算<>.

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

[KOVENOCK]KOVENOCK,D.和de Vries,C.G.,1995年。“完全信息的全薪拍卖”,UFAE和IAE工作文件311.95,经济分析基金会(UAB)和经济分析研究所(CSIC),修订版。

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

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,1997年3月。

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

[RFC3514]Bellovin,S.,“IPv4头中的安全标志”,RFC 3514,2003年4月1日。

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

[RFC3629]Yergeau,F.,“UTF-8,ISO 10646的转换格式”,STD 63,RFC 3629,2003年11月。

[UDRP] ICANN, "Uniform Domain-Name Dispute-Resolution Policy", <>.


[XML2RFC] "A handy little tool", <>.


21. Acknowledgments
21. 致谢

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.

克雷格·米洛·罗杰斯(Craig Milo Rogers)因提出这一建议而获得赞誉。Allison Mankin对一些与命名权相关的问题的早期讨论做出了贡献。同时,感谢David Parkes对拍卖类型的建议。

Editors' Addresses


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

Aaron Falk BBN Technologies美国马萨诸塞州剑桥莫尔顿街10号,邮编:02138

   Phone: +1 617 873 2575
   Phone: +1 617 873 2575

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


   Phone: +1 617 495 3864
   Phone: +1 617 495 3864

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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。



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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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


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