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

IETF协议中的命名权

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.

本文件提出了IETF支持标准化活动的新收入来源:协议字段命名权,即商业品牌与协议字段的关联。本备忘录描述了权利转让流程,并探讨了与该流程相关的一些问题。希望为一个或多个协议字段购买命名权的个人或组织应遵循此流程。

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.

正常的工程实践包括为网络协议中的字段指定名称。通常仔细选择这些名称以反映字段的功能,例如IPv4目标地址字段。

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.

随着协议设计人员投入到他们的工作中,许多人开始深入参与这些协议领域。IETF中一些最激烈的讨论是关于这些领域的细节。事实上,在IETF举行会议的国家,决斗是非法的,这有利于IETF的持续生存。

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.

但是,资助互联网工程和标准化过程的金融现实可能决定IETF必须考虑与这些协议字段相关联的名称是否代表能够负责货币化的资产。这个概念可能会冒犯一些协议纯粹主义者;然而,我们认为,由于局势的紧迫性,下面的建议值得考虑。

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.

本文档描述了与管理IETF协议字段的商业品牌权(或命名权)销售相关的流程和一些问题。作者认为,这一适度的建议可能成为未来几年支持IETF标准化活动的收入来源。

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

互联网催生了一种新的在线经济,即使在2000年初泡沫破裂之后,这种经济仍在产生惊人的增长和新的服务。很明显,许多旧经济公司会高度重视与新网络经济的关联,并愿意为这种特权付费。互联网协议在世界各地的无数操作系统和设备中使用。成为互联网协议的一部分,就是成为彻底改变商业运作方式的引擎的一部分。许多协议字段在流行的用户应用程序中显示为GUI的关键方面,或者显示在错误或诊断消息中。通过要求使用品牌协议领域,IETF能够将客户公司的品牌摆在使用这些协议进行构建的数千名软件开发人员以及从中受益的数亿用户面前。最后,那些对协议领域进行许可和品牌推广的人将能够在其他营销活动中使用该领域,并真实地宣称他们“在网络中”。

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.

该提案包括为IANA注册表中的每个协议字段创建一个主名称值,并建立一个流程,使组织或个人可以授权在该字段中记录自己选择的名称。

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

本文件说明了IETF需要额外收入(第2节),随后介绍了IETF协议中的品牌概念(第3节)。然后探讨了使这种收入流切实可行所需的若干规则和约束(第4-14节)。最后,本备忘录最后对IANA和RFC编辑器支持此类服务所需的变更进行了初步评估(第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].

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.

运行IETF并不便宜。在美国宾夕法尼亚州费城举行的第71届IETF会议上,据报道,IETF的2008年预算已超过450万美元,高于2007年的410万美元。本预算中约300万美元的收入直接来自IETF活动,包括会议费和赞助,其余收入来自互联网协会(ISOC)。在过去几年中,IETF不得不反复提高会议费用,以保持合理的预算平衡。

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.

当协议字段名称从IETF获得许可时,所有未来的IETF活动以及声称符合IETF标准的产品文档必须使用完整的品牌名称。如果未使用完整的品牌名称,则协议实施和相关文档的输出必须视为不一致。

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.

购买字段的官方IETF名称是完整的品牌名称。因此,所有引用协议的外部生成的文档必须被视为不完整的,除非其使用了完整的品牌名称。IETF让被许可方强制在非IETF文件中使用完整的品牌名称。

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

品牌名称和协议字段名称的组合必须避免被互联网社区的某些部分视为冒犯性的使用。应审查名称采购的品味。潜在购买者必须准备一份关于如何在广告或其他媒体中使用品牌协议名称的提案。(请注意,完善的品味审查流程可能对其他IETF活动有用,例如IETF工作组名称、T恤衫和主持人演示。)

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.

正如在出售或租赁冠名权的其他地区所发现的那样,商业现实和发展意味着一个品牌可能会突然失宠,甚至不再代表现有实体。此外,品牌是租赁的(即,在有限的时间内出售以供使用),并且当租赁到期时,特定字段的品牌可能会发生变化。因此,必须有一种机制在需要时改变品牌。有关更多信息,请参阅IANA注意事项、RFC编辑器注意事项和工具注意事项部分。

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:

协议名称出现在其他协议的字段中;因此,协议本身可能是品牌的候选方案:

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

蜂鸣声: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

SMTP:US邮政服务邮件命令IPv6:ITU-T协议字段IKE:RSA供应商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.

任何组织或个人都可以购买协议字段的品牌权。IETF不承诺确保采购组织有权使用其选择使用的名称。所有采购组织必须赔偿IETF,使其免受对采购组织使用该名称的权限的任何质疑。

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.

由于IETF协议的应用未受到与法律管辖区相对应的控制,因此很难将命名权限制为仅包括可能注册特定商标的地方。本备忘录中描述的过程不包括在使用品牌油田时使用地理或地缘政治边界。设计团队正在制定一项解决此问题的方案。如果设计团队获得成功,同样的建议应该在国际外交的许多领域得到应用。

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.

IETF应保留允许在IETF协议中使用品牌协议名称的唯一权利。如果协议是在IETF过程中开发的,并且协议字段尚未由使用相同过程的其他人标记,则IETF可以出售品牌协议名称的外部使用权。

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.

随着时间的推移,可能会使用协议字段命名权的多种定价策略。定价的主要目标是使IETF获得最大可能的收入。最初,价格将由希望购买命名权的一方与互联网拍卖委员会(IAB)代表协商确定。但是,我们强烈建议迁移到全付费拍卖(也称为Tullock拍卖),以便在有多个投标人[KOVENOCK]时找到最佳价格。或者,公开喊价拍卖[EKLOR],可能有秘密底价,可以在IETF会议上使用BoF会议进行,允许在开放参与的情况下同时进行口味审查和品牌分配(销售)。有关各种拍卖风格的信息,请参见[MILGROM]。

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

设计团队无法就命名协议字段的权限租约的默认条款达成共识。它分为两个期限,一个是最能代表互联网初创企业的半衰期(1年或2年),另一个是最能代表成熟互联网公司提供的产品的半衰期(8至10年)。例如,条款期限超过10年的想法,即当协议在标准轨道上发展时(即,大致无限期),租赁将终止,但通常被放弃,因为很少有公司以任何可识别的形式生存下来

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.

互联网空间中的时间长度。最后,设计团队得出结论,租赁期限应该是IETF和采购组织之间谈判的一部分。

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.

协议字段的命名权是通过以下过程购买的:被许可人完成一个应用程序,在该应用程序中,他们确定了他们希望使用的协议字段以及该字段出现的特定RFC(Internet草稿标签可用于短期租赁)。当时,他们确定了自己的品牌,并提出了外部使用和所有权期限的建议。下一步是品味评估,然后是拍卖或IAB谈判。购买结束时,IANA将更新其协议字段名称映射数据库。

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.

此过程中产生的所有争议必须使用ICANN统一域名争议解决政策[UDRP]解决。虽然协议字段不是域名,但对它们进行品牌化会带来相同类型的问题,我们认为最好利用现有流程,而不是发明新流程。

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.

采纳本提案后,IANA应建立一个协议字段到品牌名称数据库(“IETF协议品牌目录”),其中包括IETF开发或维护的协议中的所有协议字段。该数据库可以从现有的协议注册数据库[PROTREG]引导,但该列表必须扩充,以包括所有IETF协议中的所有字段,甚至包括没有进行IANA分配的字段。

The two brand name fields associated with each protocol field (the ASCII field and the optional UTF-8 field) are initialized as NULL.

与每个协议字段关联的两个品牌名称字段(ASCII字段和可选UTF-8字段)初始化为空。

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.

每当IETF租赁协议字段时,IANA应将品牌名称输入与协议字段相关的品牌命名字段,并将租赁终止日期设置为适当的值。

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.

此外,IANA应定期扫描数据库,以查找在未来30天内终止的租赁,并将任何此类租赁通知IETF,以便IAB可以与租赁人联系,以签署额外期限。租赁期满后,IANA应从其数据库中删除任何品牌名称。

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

(对所有现有RFC执行此操作可能需要一些工作。)

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.

Real_RFC应用于IETF和其他地方的所有正常用途,原始版本保留为存档参考。

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.

RFC编辑器应定期重建所有Real_RFC,以创建反映协议现场许可证当前状态的最新Real_RFC。

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

RFC编辑器应向IANA提供一份未租用字段名称列表,以纳入IETF协议品牌目录。

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.

采纳本提案后,官方xml2rfc工具的维护者应更新该工具,以支持协议字段元素,并在用于生成Real_RFC(或Real_ID)时查阅IANA数据库。在采纳本提案后,当批准发布文档时,文档作者需要将xml2rfc工具的原始XML输入文件传输给RFC编辑器。

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

IETF不承诺确保采购组织有权使用其选择使用的名称,这一事实可能导致损害。例如,Microsoft竞争对手可以购买将IPv4标头安全标志[RFC3514]命名为“Microsoft邪恶位”的权利。

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.

上述讨论介绍了品牌化IETF协议的概念及其相关含义。显然,启动和维持这样一个收入流需要付出不菲的成本。然而,广告在支持免费广播电视和谷歌等有价值的社区服务方面有着悠久而杰出的历史。

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.

随着品牌协议的建立,新协议将以有利于品牌化的名称开发。事实上,被许可方可以发起新的IETF工作,只是为了看到一个合适的领域建立起来。因此,除了IETF的经济效益外,这一举措实际上可能有助于确保IETF永远不会停止工作,从而实现自我维持和自我永存。

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, <http://iaoc.ietf.org/documents/2008_Budget_Final.pdf>.

[预算]IETF 2008年预算<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.

[EKLOR]EKLOR,M和A.Launander,“秘密底价公开喊价拍卖:瑞典房客公寓行政拍卖的实证应用”,《计量经济学杂志》,第114卷,第2期,2003年6月,第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.

[MILGROM]MILGROM,P.,“拍卖和投标:入门”,经济展望杂志,美国经济协会,第3卷(3),第3-22页,1989年夏季。

[PROTREG] IANA Protocol Registries, <http://www.iana.org/protocols/>.

[PROTREG]IANA协议注册中心<http://www.iana.org/protocols/>.

[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", <http://www.icann.org/udrp/udrp.htm>.

[UDRP]ICANN,“统一域名争议解决政策”<http://www.icann.org/udrp/udrp.htm>.

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

[XML2RFC]“一个方便的小工具”<http://xml.resource.org/>.

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
   EMail: falk@bbn.com
        
   Phone: +1 617 873 2575
   EMail: falk@bbn.com
        

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

斯科特·布拉德纳哈佛大学美国马萨诸塞州牛津圣剑桥29号,邮编02138

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

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2008).

版权所有(C)IETF信托基金(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中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

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.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

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 http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为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.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.