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.
命名権をプロトコルフィールド、すなわち、プロトコルフィールドを持つ商用ブランドの関連性：この文書では、標準化活動を支援するためのIETFのための新たな収益源を提案しています。このメモは、権利の譲渡のためのプロセスを説明し、プロセスに関連する問題のいくつかを探ります。一の以上のプロトコルフィールドの命名権を購入することを希望する個人や組織がこのプロセスに従うことが期待されています。
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の継続的な実行可能性に有利です。
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).
この提案は、特にスタジアムのために、スポーツ産業は命名権のエネルギッシュかつ成功した使用をした実現から生まれた、例えば、ロサンゼルスのステープルズセンター（バスケットボール）、サンディエゴのクアルコム・スタジアム（サッカー）、中ミニッツメイドパークヒューストン（野球）、およびアーロンの「ラッキードッグは、」get-ラップバック（カーレース）。
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プロトコル（第3節）におけるブランディングの概念の導入に続いてIETF（第2節）のための追加収入の必要性のためのケースを作ります。こうした収益の流れを実用的にするために必要ないくつかのルールや制約は（セクション4-14）探求されています。最後に、このメモは、このようなサービス（セクション15-17）をサポートするために、IANAとRFCエディタで必要な変更の初期評価で締めくくり。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
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を実行すると、安価ではありません。これは、IETFのために2008年予算[予算はこの予算で米国について2007年に米国の売上高の$ 3メートルをアップ$ 4.1 Mから$ 4.5Mのを、超えていたことフィラデルフィア、ペンシルバニア州、米国の第71回IETF会議で報告された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.
命名権をレンタルから追加US $ 1Mのを上げると大幅に予算のダイナミクスを変更することができます。おそらく、会議の手数料は、すべての参加者のために減少させることができるか、特別な補助金は貧しい学生、研究者、または求職者に提供することができます。増収の使用のための他のオプションは、第71回IETFでのケースだった、またはのためのバーを借りるとして週ではなく、単なる一日半のオタクの家族を養うのに十分な大きブレーククッキーサイジングすることができワーキンググループは、むしろ騒々しい地元の人々を我慢するよりも社会的な椅子。 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標準に準拠するために主張されている場合、完全なブランド名を使用しなければなりません。完全なブランド名を使用しない場合は、プロトコルの実装、および関連文書からの出力は、非準拠とみなされなければなりません。
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の名前は、完全なブランド名です。それは1が存在する完全なブランド名を使用しない限り、このように、プロトコルを参照するすべての外部で生成されたドキュメントは、不完全な考慮されなければなりません。 IETFは、非IETF文書に完全なブランド名の使用を強制するためにライセンシーにそれを残します。
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ワーキンググループ名、Tシャツ、およびホストプレゼンテーションを他のIETF活動のために有用であろうことに注意してください。）
Within the limits of taste, the branded protocol field may be used for any purpose.
味の限界内で、ブランドのプロトコルフィールドは、任意の目的のために使用することができます。
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エディタの考慮事項、およびツールの考慮事項のセクションを参照してください。
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.
最も効果的な名前は、スポンサーに望ましい特性を持つフィールドのセマンティクスをペアリングするものです。善と悪のペアリングの次の例では、適切なペアリングが魅力的にする方法を示しています。
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
BEEP：AAA BEEP SOAP：ダウニーSOAP PPP：フロマックス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
トーマス・ウルフソースアドレスフィールド
SIP: Seagrams Vodka SIP Event
SIP: Calvin Klein Event Package
IP: Viagra Total Length
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：米国郵便サービスの郵便コマンドのIPv6：ITU-TプロトコルフィールドIKE：RSAベンダーID
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].
（セクション16を参照）ASCIIのみのReal-RFCに印刷するためには、すべてのブランドは、ASCII形式を含める必要があります。 ASCII名は、RFC 2223 [RFC2233]の要求事項に従わなければなりません。ブランドは、必要に応じて非ASCII表現で使用するUTF-8バージョンを含むかもしれません。 RFC 3629 [RFC3629]を参照してください。
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に補償しなければなりません。
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プロトコルの適用は法的管轄区域に該当するように制御されていないので、特定の商標が登録されている場合があり、単にそれらの場所が含まれるように命名権を制限することは困難です。このメモに記載された方法は、ブランドのフィールドの使用上の地理的または地政学的な境界の使用が含まれていません。設計チームは、この問題を克服するための提案に取り組んでいます。設計チームが成功した場合は、同じ提案は、国際外交の多くの分野で応用を見つける必要があります。
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は、ブランドのプロトコル名の外部使用のための権利を販売することができます。
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）代表の購入を希望する当事者間の交渉によって設定されます。しかし、私たちは強く、複数の入札者[KOVENOCK]があり、最適な価格を見つけるための（もTullockオークションとして知られている）すべての有料オークションへの移行を示唆しています。また、オープン抗議のオークションは、[EKLOR]、おそらく秘密のリザーブ価格で、同時に、オープン参加で実施する味の見直しやブランドの割り当て（販売）を許可する、のBoFセッションを使用してIETFミーティングで開催することができます。様々なオークションスタイルの詳細については、[MILGROM]を参照してください。
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.
設計チームは、プロトコルフィールドに名前を付けるための権限のリースのデフォルトの期間について合意に来ることができませんでした。これは、最高の最高の成熟したインターネット企業が提供する製品の半減期を表すことになり、インターネットのスタートアップ（1年または2年）と長期の半減期を表すことになり長期の間で分割された（8〜10年） 。もう10年以上の用語のアイデアは、例えば、プロトコルが標準化トラック（すなわち、およそ無限）に進んだときに終了となるリースは、議論が、非常に少ない会社ではその長さのために任意の認識可能な形で生き残るために、一般的に破棄されましたインターネット空間での時間。最終的には、設計チームは、リース期間は、IETFおよび購買組織間の交渉の一部であるべきと結論付けました。
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（インターネットドラフトタグは短期リースのために利用可能な）プロトコルフィールドを特定のアプリケーションを実行します。プロトコルフィールドに名前を付ける権利は、以下のプロセスを使用して購入しています。その時、彼らは自分たちのブランドを特定し、外部の利用と所有権の長さのために彼らの提案を提示します。次のステップは、オークションやIABの交渉が続い味のレビューです。購入はIANAが彼らのプロトコルフィールド名マッピングデータベースを更新して終了します。
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]を使用して解決しなければなりません。プロトコルフィールドは、ドメイン名ではありませんが、彼らは問題の同じ種類を提示し、ブランドと我々はそれが既存のプロセスを活用することではなく、新しいものを発明する方が良いでしょうと感じています。
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の：ハーマン・メルヴィルジャンボグラムオプション
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-開発や-maintainedプロトコルのすべてのプロトコルフィールドを含むプロトコルフィールド・ツー・ブランド名データベース（「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フィールド）に関連する2つのブランド名のフィールドは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.
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日以内に終了するリースを探し、IABは、追加の用語にサインアップするleaseholderに近づくことができるように、そのようなリースのIETFに通知するために、データベースをスキャンしないものとします。リースの有効期限が切れたときIANAは、データベースからすべてのブランド名を削除するものとします。
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 Editorは、すべてのIETFのRFCのXMLバージョンを作成するものとします。 XMLは、元のRFCの完璧なコピーが、そのようなxml2rfc [XML2RFC]などのツールを使用して製造することができるようなものでなければなりません。 RFCのXMLバージョンは、フォームのXMLプロトコルフィールド要素を使用して、すべての個々のプロトコルフィールドを識別しなければなりません。
<pfield name="IPv4 Destination Address"/>
<pfield名= "IPv4宛先アドレス" />
(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 Editorは、その後、「Real_RFCxxxx.txt」の命名規則を使用してXMLファイルからのRFCのASCIIバージョンを作成しないものとします。翻訳時には、各プロトコルフィールドは、IANAのプロトコルフィールド・ツー・ブランド名データベースで検索されます。プロトコルフィールドに関連付けられたASCIIのブランド名がある場合は芸術を歪める名前の長さを変える場所の名前はASCIIアートに表示されていない限り、単語「」とブランド名は（フィールドのIETFの名前の前に付加されています）。例えば、プロトコルフィールドは、IANAデータベースに「宛先アドレス」とのブランド名である場合は、「ガーミンGPS」、「ガーミンGPSの宛先アドレスが」Real_RFCで使用される文字列です。そのような名前の長さを変更すると、このような目次でページ番号として文書の他の詳細を調整する必要があります。書式設定の一部を行うためのソフトウェアは少しトリッキーかもしれません。
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_RFCsの他の非規範的なバージョンを生成することができます。例えば、非規範的なポータブルドキュメントフォーマット（PDF）版は、ASCII Real_RFCバージョンに加えて、作成することができます。存在する場合、RFC Editorは、そのような代替のバージョンでは、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 Editorは、プロトコルフィールドライセンスの現在の状態を反映し、最新のReal_RFCsを作成するために、定期的にすべてのReal_RFCsを再構築しないものとします。
The RFC Editor SHALL provide a list of un-leased field names to the IANA for inclusion in the IETF Protocol Branding Catalog.
RFC Editorは、IETFプロトコルブランディングカタログに含めるためIANAに非リースフィールド名のリストを提供しなければなりません。
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_RFCs（又はReal_IDs）を生成するために使用されているときにIANAデータベースを参照するツールを更新するものとします。この提案の適用により、文書作成者は、文書が公表のために承認されたときにRFCエディタにxml2rfcツールの生のXML入力ファイルを送信する必要があります。
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悪ビットを」名前を付ける権利を購入することができます。
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プロトコルと関連する意味をブランディングの概念を導入しました。明らかに起動して、このような収入の流れを維持するために非自明なコストがあります。しかし、広告には、無料のテレビ放送や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.
ブランドのプロトコルが確立するにつれて、新しいプロトコルは、ブランディングに資する名で開発されます。実際には、ライセンシーは、確立された適切なフィールドを参照するだけで、新たなIETFの作業を開始することができます。だから、IETFへの経済的利益のほかに、このイニシアチブは、実際にIETFが作業をせずになることはありません、したがって、自立と自己永続確保に役立つことがあります。
[RFC2233] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC2233]ポステル、J.、およびJ.レイノルズ、RFC 2223、1997年10月 "RFC作者への指示"。
[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.＆デフリース、CG、UFAE 311.95とIAEワーキングペーパー、経済分析（UAB）と経済分析研究所の単位財団1995年「完全な情報を持つすべての-有料オークション」 （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.、 "オークションと入札：入門"、経済展望、アメリカ経済学会誌vol。 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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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/>。
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
アーロンフォークBBNテクノロジーズ10モールトンストリートケンブリッジMA、02138 USA
Phone: +1 617 873 2575 EMail: falk@bbn.com
電話：+1 617 873 2575 Eメール：falk@bbn.com
Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138 USA
スコット・ブラッドナーハーバード大学29オックスフォードセントケンブリッジMA、02138 USA
Phone: +1 617 495 3864 EMail: sob@harvard.edu
電話：+1 617 495 3864 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。