はじめに
- この文書は RFC5241 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
Naming Rights in IETF Protocols（IETF プロトコルの命名権）
- Network Working Group
- Request for Comments: 5241
- Category: Informational
- A. Falk
- BBN
- S. Bradner
- Harvard University
- 1 April 2008
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 つまたは複数のプロトコルフィールドの命名権を購入したい個人または組織は、このプロセスに従うことが期待されている。
1. Introduction（序論）
Normal engineering practice involves assigning names to fields in network protocols.
These names are generally carefully chosen to reflect the function of the field, for example, the IPv4 Destination Address field.
通常のエンジニアリングでは、ネットワークプロトコルのフィールドに名前を付ける。
これらの名前は、例えば IPv4 の Destination Address フィールドのように、フィールドの機能を反映するように慎重に選ばれるのが一般的である。
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].
本文書におけるキーワード「MUST」「MUST NOT」「REQUIRED」「SHALL」「SHALL NOT」「SHOULD」「SHOULD NOT」「RECOMMENDED」「MAY」「OPTIONAL」は [RFC2119] に記述されているように解釈されるものとする。
2. Revenue Needs（収益ニーズ）
Running the IETF is not inexpensive.
It was reported at the 71st IETF meeting in Philadelphia, PA, USA that the 2008 budget [BUDGET] for the IETF had surpassed US$4.5 M, up from $4.1 M in 2007.
About US$3 M of revenue in this budget flows directly from IETF activities, including meeting fees and sponsorships, and the remainder flows from the Internet Society (ISOC).
Over the last few years the IETF has had to raise meeting fees repeatedly in order to keep this budget balance reasonable.
IETF の運営費は決して安くはない。
米国ペンシルベニア州フィラデルフィアで開催された第 71 回 IETF 会議では、IETF の 2008 年度予算 [BUDGET] が、2007 年の 410 万ドルから 450 万ドルを突破したと報告された。
この予算のうち約 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 万米ドルを調達すれば、予算の動きが大きく変わるかもしれない。
たとえば、すべての参加者の会費を引き下げたり、貧しい学生や研究者、求職者に特別な補助金を支給したりすることも可能だろう。
増加した収入の使い道としては、休憩用のクッキーを第 71 回 IETF の時のように 1 日半ではなく、1 週間分のギークの家族を養えるほどの大きさにしたり、騒がしい地元の人たちに我慢するのではなく、ワーキンググループの議長がバーを貸し出して社交の場にしたりすることも考えられるだろう。
この提案によって得られたリソースを IETF が使うのに等しくふさわしい方法は、他にもたくさんあるはずである。
ただし、そのような利益は、以下に述べる立ち上げコストを支払うために、数年間遅らせなければならないかもしれないことに留意が必要である。
3. How Are Branded Protocol Fields Used?（ブランド化プロトコルフィールドはどのように使用されるか？）
3.1. Within the 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 標準に準拠すると主張する製品のドキュメントは、完全なブランド名を使用しなければならない (MUST)。
プロトコルの実装や関連文書の出力は、完全なブランド名が使用されていない場合、不適合と見なされなければならない (MUST)。
3.2. Externally（外部）
The official IETF name for a purchased field is the complete branded name.
Thus, all externally generated documentation that references the protocol must be considered incomplete unless it used the complete branded name where one exists.
The IETF leaves it to the licensee to enforce the use of complete branded names in non-IETF documents.
購入したフィールドの公式の IETF 名称は、完全なブランド名である。
したがって、プロトコルを参照するすべての外部生成文書は、完全なブランド名が存在する場合はそれを使用しない限り、不完全であるとみなさなければならない。
IETF は、IETF 以外の文書で完全なブランド名を使用することを強制することをライセンシーに委ねている。
4. Names Must Be in Good Taste（ネーミングはセンスが問われる）
The combination of brand names and protocol field names must avoid uses that may be considered offensive by some part of the Internet community.
Name purchases shall be reviewed for taste.
Prospective purchasers must prepare a proposal for how the branded protocol name will be used in advertising or other media.
(Note that a well-developed taste-review process may prove useful for other IETF activities, for example, IETF working group names, T-shirts, and host presentations.)
ブランド名とプロトコルフィールド名の組み合わせは、インターネットコミュニティの一部から不快に思われるような使用は避けなければならない。
名称の購入は、そのセンスについて審査されるものとする。
購入希望者は、ブランド化されたプロトコル名が広告や他のメディアでどのように使用されるかについての提案書を作成しなければならない。
(よく練られたセンス審査プロセスは、他の IETF 活動、たとえば IETF 作業部会名、Tシャツ、ホスト・プレゼンテーションなどにも有用であることが分かっていることに留意すること)。
Within the limits of taste, the branded protocol field may be used for any purpose.
好みの範囲で、ブランド化されたプロトコルのフィールドはどのような目的にも使用することができる。
5. When Names Change（名前が変わるとき）
As has been discovered in other areas where naming rights are sold or leased, commercial realities and developments mean that a brand name can suddenly go out of favor or even cease to denote an existing entity.
In addition, branding is leased (i.e., sold to be used over a limited time) and the branding for a particular field may change when the lease is up.
Thus, there must be a mechanism to change branding when needed.
See the IANA Considerations, RFC Editor Considerations, and Tools Considerations sections for more information.
命名権の販売やリースが行われている他の分野でも見られるように、商業的な現実や発展は、ブランド名が突然人気を失ったり、既存の事業体を表すものでなくなったりすることを意味する。
さらに、ブランドはリース (一定期間使用するために販売) されるため、リース期間が終了すると、特定の分野のブランドは変更される可能性がある。
したがって、必要なときにブランディングを変更するメカニズムが必要である。
詳細については、「IANA に関する考慮事項」、「RFC エディターに関する考慮事項」、「ツールに関する考慮事項」の各章を参照すること。
6. Example Names（名前の例）
The most effective names are those that pair the semantics of a field with a characteristic desirable to a sponsor.
The following examples of good and bad pairings illustrate how an appropriate pairing can be appealing.
最も効果的な名称は、その分野のセマンティクスとスポンサーにとって望ましい特性とを組み合わせたものである。
次の良い組み合わせと悪い組み合わせの例は、適切な組み合わせがいかに魅力的であるかを示している。
6.1. Acceptable Taste-Wise（良い組み合わせ）
- IP: Garmin GPS Destination Address
- IP: White & Day Mortuary Time-to-live
- TCP: Princess Cruise Lines Port Number
- ARP: Springfield Preschool Timeout
- BGP: Sharpie Marker field
- TFRC: Traveler's Insurance Loss Period
- SCTP: Hershey's Chunk {type|flags|length}
- SMTP: eHarmony HELO
- IP: Garmin GPSの宛先アドレス
- IP：White & Day Mortuaryの生存時間
- TCP：プリンセス・クルーズ・ラインのポート番号
- ARP スプリングフィールドプリスクールのタイムアウト
- BGP：シャープペンシルのマーカーフィールド
- TFRC：旅行者保険の損失期間
- SCTP: Hershey's Chunk の {タイプ|フラグ|長さ}
- SMTP: イーハーモニーの 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
- トーマス・ウルフのソースアドレスフィールド
6.2. In Bad Taste（悪い組み合わせ）
- SIP: Seagrams Vodka SIP Event
- SIP: Calvin Klein Event Package
- IP: Viagra Total Length
- SIP：シーグラム・ウォッカの SIP イベント
- SIP：カルバン・クラインのイベントパッケージ
- IP：バイアグラの全長
6.3. Confusing Names（紛らわしい名前）
Places where the brand could interfere with the understanding of the protocol are prohibited:
プロトコルの理解に支障をきたす恐れのある場所での使用は禁止されている。
- SMTP: US Postal Service Mail command
- IPv6: ITU-T Protocol field
- IKE: RSA Vendor ID
- SMTP：アメリカ合衆国郵便公社の Mail コマンド
- IPv6：ITU-T プロトコルフィールド
- IKE：RSA ベンダ ID
6.4. Valid Names（有効な名称）
In order to be printed in the ASCII-only Real-RFC (described in Section 16) all brands must include an ASCII form.
The ASCII name MUST conform to the requirements in RFC 2223 [RFC2233].
The brand MAY optionally include a UTF-8 version for use in non-ASCII representations.
See RFC 3629 [RFC3629].
ASCII のみの Real-RFC (16 章で説明) に印刷されるためには、すべての ブランドは ASCII の書式を含まなければならない。
ASCII 名は RFC 2223 [RFC2233] の要件に準拠しなければならない (MUST)。
ブランドは、ASCII 以外の表現で使用するために、オプションで UTF-8 バージョンを含んでもよい (MAY)。
RFC 3629 [RFC3629] を参照。
7. Who Can Buy Naming Rights?（命名権を購入できるのは誰か？）
Any organization or individual can purchase the right to brand a protocol field.
The IETF will not undertake to ensure that the purchasing organization has the right to use the name they choose to use.
All purchasing organizations MUST indemnify the IETF against any challenges to the authority of the purchasing organization to use the name.
どのような組織や個人でも、プロトコルのフィールドをブランド化する権利を購入することができる。
IETF は、購入組織が選択した名称を使用する権利を確実に持つことを約束しない。
すべての購入組織は、購入組織がその名称を使用する権限に対して異議を唱えた場合、IETF に補償しなければならない (MUST)。
8. Scope of Naming Applicability（命名の適用範囲）
Because the application of IETF protocols is not controlled in a way that corresponds to legal jurisdictions, it is difficult to restrict naming rights to include just those places where a particular trademark may be registered.
The process described in this memo does not include the use of geographic or geopolitical boundaries on the use of branded fields.
The design team is working on a proposal to overcome this issue.
If the design team is successful, the same proposal should find application in a number of areas of international diplomacy.
IETF プロトコルの適用は、法的管轄に対応する方法では管理されていないため、特定の商標が登録されている可能性のある場所のみを含むように命名権を制限することは困難である。
このメモで説明されているプロセスには、ブランド化されたフィールドの使用に関する地理的または地政学的な境界は含まれていない。
設計チームは、この問題を克服するための提案に取り組んでいる。
設計チームが成功した場合、同じ提案が国際外交の多くの分野で適用されるはずである。
9. Who Can Sell Naming Rights?（命名権を販売できるのは誰か？）
The IETF SHALL retain the sole right to permit branded protocol names to be used within IETF protocols.
The IETF MAY sell rights for external use of branded protocol names if the protocols have been developed within the IETF process and if the protocol field has not already been branded by someone else using the same process.
IETF は、ブランド化されたプロトコル名を IETF プロトコル内で使用することを許可する唯一の権利を保持しなければならない (SHALL)。
IETF は、プロトコルが IETF プロセス内で開発され、同じプロセスを使用する他の誰かによってプロトコルフィールドがまだブランド化されていない場合、ブランド化されたプロトコル名の外部使用の権利を販売してもよい (MAY)。
10. Pricing（価格）
Multiple pricing strategies for the naming rights to protocol fields will likely be used over time.
The primary objective of pricing is to enable the greatest possible revenue for the IETF.
Initially, prices will be set by negotiation between the party wishing to purchase the naming right and the Internet Auction Board (IAB) representative.
However, we strongly suggest migrating to an all pay auction (also known as a Tullock auction) for finding the optimal price when there are multiple bidders [KOVENOCK].
Alternatively, open-outcry auctions [EKLOR], perhaps with a secret reserve price, could be held at IETF meetings using a BoF session, permitting taste review and brand assignment (sale) to be conducted concurrently and with open participation.
See [MILGROM] for information on various auction styles.
プロトコルフィールドの命名権に対する複数の価格設定戦略が、時間の経過とともに使用されると考えられる。
価格設定の第一の目的は、IETF が可能な限り最大の収益を得られるようにすることである。
当初は、命名権購入希望者とインターネットオークション委員会 (IAB) 代表との間の交渉によって価格が設定される予定である。
しかし、複数の入札者がいる場合に最適な価格を見つけるために、オールペイオークション (タロックオークションとも呼ばれる) に移行することを強く推奨する [KOVENOCK]。
あるいは、オープンアウトクライオークション [EKLOR] を、おそらく秘密の予備価格を付けて、BoF セッションを使って IETF 会議で開催し、センスのレビューとブランドの割り当て (販売) を同時かつオープンな参加で実施することを可能にすることもできる。
様々なオークションスタイルに関する情報は、[MILGROM] を参照。
11. Time of Ownership（所有期間）
The design team could not come to consensus on a default term of a lease of the authority to name a protocol field.
It was split between a term that would best represent the half-life of an Internet startup (1 or 2 years) and a term that would best represent the half-life of a product offered by a mature Internet company (8 to 10 years).
The idea of terms any longer than 10 years, for example, leases that would terminate when a protocol advanced on the standards track (i.e., roughly infinite), was discussed but generally discarded because so few companies survive in any recognizable form for that 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 と購入組織との間の交渉で決めるべきだという結論に達した。
12. How Are Naming Rights Purchased?（命名権の購入方法は？）
The right to name a protocol field is purchased using the following process: licensees complete an application where they identify the protocol field they wish to use and the particular RFC in which it appears (Internet-Draft tags are available for short term lease).
At that time, they identify their brand and present their proposal for external use and length of ownership.
The next step is a taste review followed by an auction or IAB negotiation.
The purchase concludes with the IANA updating their protocol field name mapping database.
プロトコルフィールドの命名権は、以下のプロセスで購入される。ライセンシーは、使用を希望するプロトコルフィールドと、それが出現する特定の RFC (Internet-Draft タグは短期リース可能) を特定する申請書に記入する。
その際、ライセンシーはブランドを特定し、外部での使用と所有期間に関する提案を提示する。
次のステップはセンス審査で、その後にオークションまたは IAB の交渉が行われる。
購入は、IANA がプロトコルフィールド名マッピングデータベースを更新することで終了する。
13. Dispute Resolutions（紛争解決）
All disputes arising from this process MUST be resolved using the ICANN Uniform Domain-Name Dispute-Resolution Policy [UDRP].
While the protocol fields are not domain names, branding them presents the same types of issues and we feel that it's better to make use of an existing process rather than to invent a new one.
このプロセスから生じるすべての紛争は、ICANN Uniform Domain-Name Dispute-Resolution Policy [UDRP] を用いて解決されなければならない (MUST)。
プロトコルフィールドはドメイン名ではないが、ブランディングには同じ種類の問題があり、我々は新しいプロセスを発明するよりも既存のプロセスを利用する方が良いと考えている。
14. Future Expansions（今後の拡張性）
If this proposal proves successful, it can be easily expanded to include other protocol features such as options and parameters.
この提案が成功すれば、オプションやパラメータなど他のプロトコルの機能にも容易に拡張することができる。
For example:
- IPv6: The Herman Melville Jumbogram option
例えば：
- IPv6：Herman Melville のジャンボグラムオプション
15. IANA Considerations（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 Protocol Branding Catalog」)をセットアップしなければならない (SHALL)。
このデータベースは、既存のプロトコル登録データベース [PROTREG] から始めることはできるが、このリストは、IANA 割り当てが行われていないものであっても、すべての IETF プロトコルのすべてのフィールドを含むように補強されなければならないだろう。
The two brand name fields associated with each protocol field (the ASCII field and the optional UTF-8 field) are initialized as NULL.
各プロトコルフィールドに関連する 2 つのブランド名フィールド (ASCII フィールドとオプションの UTF-8 フィールド) は、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 はプロトコルフィールドに関連するブランド名フィールドにブランド名を入力し、リース終了日を適切な値に設定しなければならない (SHALL)。
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 がリース所有者に追加期間の契約を打診できるようにしなければならない (SHALL)。
IANA は、リースの期限が切れると、データベースからブランド名を削除するものとする。
16. RFC Editor Considerations（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 バージョンを作成しなければならない (SHALL)。
その XML は、xml2rfc [XML2RFC] などのツールを使って、オリジナルの RFC の完全なコピーを作成できるようなものでなければならない。
RFC の 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 RFC が完成すると、RFC エディターは「Real_RFCxxxx.txt」という命名規則に従って、XML ファイルから ASCII 版の RFC を作成しなければならない (SHALL)。
翻訳中、各プロトコルフィールドは、IANA プロトコルフィールド-ブランド名データベースで検索される。
プロトコルフィールドに関連する ASCII ブランド名がある場合、そのフィールドの IETF 名の前に「the」という単語とブランド名が追加される (名前の長さを変更するとアートが歪むような ASCII アートで名前が表示される場合は除く)。
例えば、プロトコルフィールドが「Destination Address」で、IANA データベースのブランド名が「Garmin GPS」の場合、Real_RFC では「the Garmin GPS Destination Address」という文字列が使用されるだろう。
このような名前の長さを変更すると、目次のページ番号など、文書の他の細部を調整する必要が生じる場合がある。
一部の書式設定変更を行うソフトウェアは、少し注意が必要だと思われる。
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 に加えて、非正規の Portable Document Format (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 およびその他の場所で通常の目的に使用され、オリジナル版はアーカイブ参照用として予約されなければならない (SHALL)。
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 を再構築しなければならない (SHALL)。
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 Protocol Branding Catalog に含めるために、IANA に未リースのフィールド名のリストを提供しなければならない (SHALL)。
17. Tool Builder Considerations（ツールに関する考慮事項）
Upon the adoption of this proposal, the maintainer of the official xml2rfc tool SHALL update the tool to support the protocol field element and to consult the IANA database when being used to produce Real_RFCs (or Real_IDs).
Upon the adoption of this proposal, document authors will be required to transmit the raw XML input file for the xml2rfc tool to the RFC Editor when the document is approved for publication.
この提案が採用されると、公式 xml2rfc ツールのメンテナは、Real_RFC (またはReal_ID) の生成に使用される場合、プロトコルフィールド要素をサポートし、 IANA データベースを参照するようツールをアップデートしなければならない (SHALL)。
この提案が採用されると、文書の作成者は、文書の公開が承認された時点で、xml2rfc ツール用の生の XML 入力ファイルを RFC エディターに送信することが要求される。
18. Security Considerations（セキュリティに関する考慮事項）
The fact that the IETF will not undertake to ensure that the purchasing organization has the right to use the name they choose to use can lead to mischief.
For example, a Microsoft competitor could purchase the right to name the IPv4 Header Security Flag [RFC3514] "the Microsoft Evil bit".
IETF が、購入組織が使用することを選択した名前を使用する権利を確実に持つことを約束しないという事実は、いたずらにつながる可能性がある。
たとえば、Microsoft の競合他社が、IPv4 ヘッダーセキュリティフラグ [RFC3514] に「Microsoft の Evil ビット」という名前を付ける権利を購入する可能性がある。
19. Conclusion（結論）
The discussion above has introduced the concept of branding IETF protocols and the associated implications.
Clearly there are non-trivial costs to starting up and maintaining such a revenue stream.
However, advertising has a long and distinguished history of supporting valuable community services such as free broadcast television and Google.
以上、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 が仕事なしになることはなく、その結果、自立的で永続的なものになる可能性がある。
20. References
20.1. Normative References
[RFC2233] Postel, J. and J. Reynolds, "Instructions to RFC Authors",
RFC 2223, October 1997.
20.2. Informative References
[BUDGET] IETF 2008 budget,
<http://iaoc.ietf.org/documents/2008_Budget_Final.pdf>.
[EKLOR] Eklor, M and A. Launander, "Open outcry auctions with
secret reserve prices: an empirical application to
executive auctions of tenant owner's apartments in
Sweden", Journal of Econometrics, Volume 114, Issue 2,
June 2003, pages 243-260.
[KOVENOCK] Kovenock, D. & de Vries, C.G., 1995. "The All-Pay Auction
with Complete Information", UFAE and IAE Working Papers
311.95, Unitat de Fonaments de l'Analisi Economica (UAB)
and Institut d'Analisi Economica (CSIC), revised.
[MILGROM] Milgrom, P., "Auctions and Bidding: A Primer", Journal of
Economic Perspectives, American Economic Association, vol.
3(3), pages 3-22, Summer 1989.
[PROTREG] IANA Protocol Registries,
<http://www.iana.org/protocols/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header," RFC
3514, 1 April 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UDRP] ICANN, "Uniform Domain-Name Dispute-Resolution Policy",
<http://www.icann.org/udrp/udrp.htm>.
[XML2RFC] "A handy little tool", <http://xml.resource.org/>.
21. Acknowledgments（謝辞）
Craig Milo Rogers receives credit for the idea which lead to this proposal.
Allison Mankin contributed to some early discussions of the issues associated with naming rights.
Also, thanks to David Parkes for his advice on types of auctions.
Craig Milo Rogers は、この提案のきっかけとなったアイデアに対して功績を認められています。
Allison Mankin は、命名権に関連する問題についての初期の議論に貢献しました。
また、オークションの種類についてのアドバイスをいただいた David Parkes に感謝します。
Editors' Addresses
Aaron Falk
BBN Technologies
10 Moulton Street
Cambridge MA, 02138 USA
Phone: +1 617 873 2575
EMail: falk@bbn.com
Scott Bradner
Harvard University
29 Oxford St.
Cambridge MA, 02138 USA
Phone: +1 617 495 3864
EMail: sob@harvard.edu
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.