[要約] RFC 5241は、IETFプロトコルにおける命名権に関するガイドラインを提供しています。その目的は、プロトコルの命名に関する一貫性と明確さを確保し、ユーザーの混乱を最小限に抑えることです。
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つ以上のプロトコルフィールドの命名権を購入したい個人または組織は、このプロセスに従うことが期待されています。
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).
この提案は、スポーツ業界が特にスタジアム、例えばロサンゼルスのステープルズセンター（バスケットボール）、サンディエゴ（サッカー）のクアルコムスタジアム、ミニッツメイドパークのミニッツメイドパークのために、命名権をエネルギッシュかつ成功させたという認識から生じました。ヒューストン（野球）、およびアーロンの「ラッキードッグ」ゲットアラップバック（カーレース）。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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を実行することは安価ではありません。米国ペンシルベニア州フィラデルフィアで開催された第71回IETF会議で、IETFの2008年の予算[予算]が2007年の4.1百万ドルから4.5百万米ドルを超えたことが報告されました。会議費用やスポンサーシップを含む活動、および残りはインターネット社会（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米ドルを調達すると、予算のダイナミクスが大幅に変化する可能性があります。おそらく、すべての参加者の会議料金を削減するか、貧しい学生、研究者、または求職者に特別な補助金を提供できる可能性があります。収益の増加を使用する他のオプションは、第71 IETFの場合のように、1日半ではなく、1週間にわたってオタクの家族を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標準に準拠すると主張する製品のドキュメントは、完全なブランド名を使用する必要があります。プロトコルの実装からの出力と関連するドキュメントは、完全なブランド名が使用されていない場合は、不適合と見なされる必要があります。
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は、ライセンシーに任せて、非ITETFドキュメントで完全なブランド名の使用を実施します。
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
ビープ音：AAAビープ石鹸：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:
ブランド化が会社名またはその他の商標条件に限定される必要はありません。たとえば、出版社は著者の1人を称えることを決定できます。
The Thomas Wolfe Source Address Field
トーマス・ウルフのソースアドレスフィールド
SIP: Seagrams Vodka SIP Event SIP: Calvin Klein Event Package IP: Viagra Total Length
SIP：Seagrams Vodka sipイベントSIP：Calvin KleinイベントパッケージIP：バイアグラ全体の長さ
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].
ASCII-ONLY REAL-RFC（セクション16で説明）に印刷するには、すべてのブランドに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]。あるいは、おそらく秘密の予備価格で、Open-Outcryオークション[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年）が提供する製品の半減期を最もよく表す用語との間に分割されました。。たとえば、標準のトラックでプロトコルが進んだときに終了するリース（つまり、ほぼ無限）が議論されましたが、一般的に廃棄されたのは、その長さの認識可能な形式で生存する企業はほとんどないため、一般的に破棄されました。インターネットスペースでの時間。最終的に、設計チームは、リース期間は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が開発または維持したプロトコルのすべてのプロトコルフィールドを含むプロトコルフィールドからブランドへの名前データベース（「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日以内に終了するリースを探し、IETFにそのようなリースを通知して、IABがリースホルダーにアプローチして追加の用語にサインアップできるようにします。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エディターはすべてのIETF RFCのXMLバージョンを作成するものとします。XMLは、XML2RFC [XML2RFC]などのツールを使用して、元のRFCの完全なコピーを生成できるようにする必要があります。RFCSのXMLバージョンは、フォームのXMLプロトコルフィールド要素を使用して、すべての個々のプロトコルフィールドを識別する必要があります。
<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 RFCSが完了すると、RFCエディターは、「REAL_RFCXXXX.TXT」の命名規則を使用して、XMLファイルからRFCのASCIIバージョンを作成します。翻訳中、各プロトコルフィールドはIANAプロトコルフィールドからブランド名データベースで調べられます。プロトコルフィールドに関連付けられたASCIIブランド名がある場合、「The」とブランド名はフィールドのIETF名に加えられます（名前がASCIIアートに表示されない限り、名前の長さを変更するとアートがアートを歪めます。）。たとえば、プロトコルフィールドが「宛先アドレス」であり、IANAデータベースのブランド名が「Garmin GPS」の場合、文字列「Garmin 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を生成する場合があります。たとえば、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_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エディターは、IETFプロトコルブランディングカタログに含めるために、IANAに非リースフィールド名のリストを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データベースを参照するためのツールを更新するものとします。この提案が採用されると、文書の著者は、ドキュメントが公開された場合にXML2RFCツールのRAW XML入力ファイルをRFCエディターに送信する必要があります。
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]「The Microsoft Evil Bit」という名前を付ける権利を購入できます。
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] Postel、J。およびJ. Reynolds、「RFC著者への指示」、RFC 2223、1997年10月。
[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、「秘密の予備価格を備えたオープンアウトクリオークション：スウェーデンのテナントオーナーのアパートのエグゼクティブオークションへの経験的アプリケーション」、Journal of Econometrics、Volume 114、Issue 2、2003年6月243-ページ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、Unitat de fonaments de l'Analisi Economica（UAB）およびInstitut D'Analisi Economica（CSIC）、改訂。
[MILGROM] Milgrom, P., "Auctions and Bidding: A Primer", Journal of Economic Perspectives, American Economic Association, vol. 3(3), pages 3-22, Summer 1989.
[ミルグロム]ミルグロム、P。、「オークションと入札：プライマー」、Journal of Economic Perspectives、American Economic Association、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] 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/>。
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.
クレイグ・ミロ・ロジャースは、この提案につながるアイデアのクレジットを受け取ります。アリソン・マンキンは、命名権に関連する問題のいくつかの初期の議論に貢献しました。また、オークションの種類に関するアドバイスをしてくれたDavid Parkesに感謝します。
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
Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138 USA
スコットブラッドナーハーバード大学29オックスフォードセントケンブリッジMA、02138 USA
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（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に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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への情報をお問い合わせください。