[要約] RFC 7500は、IANAレジストリの運用原則に関するものであり、インターネット割り当て番号機関（IANA）のレジストリの運用に関するガイドラインを提供しています。このRFCの目的は、IANAレジストリの一貫性と信頼性を確保し、インターネットの運用における番号の割り当てと管理を効果的に行うことです。
Internet Architecture Board (IAB) R. Housley, Ed.
Request for Comments: 7500 Vigil Security
Category: Informational O. Kolkman, Ed.
ISSN: 2070-1721 Internet Society
April 2015
Principles for Operation of Internet Assigned Numbers Authority (IANA) Registries
Internet Assigned Numbers Authority（IANA）レジストリの運用に関する原則
Abstract
概要
This document provides principles for the operation of Internet Assigned Numbers Authority (IANA) registries.
このドキュメントは、Internet Assigned Numbers Authority（IANA）レジストリの操作の原則を提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7500.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7500で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Principles for the Operation of IANA Registries .................3
3. Discussion ......................................................4
3.1. Ensuring Uniqueness, Stability, and Predictability .........4
3.2. Public .....................................................4
3.3. Open and Transparent .......................................4
3.4. Accountable ................................................5
4. Security Considerations .........................................5
5. Informative References ..........................................6
IAB Members at the Time of Approval ................................7
Contributors and Acknowledgements ..................................7
Authors' Addresses .................................................7
The Internet Engineering Task Force (IETF) and its predecessors have traditionally separated the publication of protocol specifications in immutable Request for Comments (RFCs) and the registries containing protocol parameters. Traditionally, the registries are maintained by a set of functions known collectively as the Internet Assigned Numbers Authority (IANA). Dating back to the earliest days of the Internet, specification publication and the registry operations were tightly coupled: Jon Postel of the Information Sciences Institute (ISI) of the University of Southern California (USC) was responsible for both RFC publication and IANA registry operation. This tight coupling had advantages, but it was never a requirement. Indeed, today the RFC Editor and IANA registry operation are provided by different entities.
インターネット技術標準化委員会（IETF）とその前身は、プロトコル仕様の公開を、不変のRequest for Comments（RFC）とプロトコルパラメータを含むレジストリで伝統的に分離してきました。従来、レジストリは、Internet Assigned Numbers Authority（IANA）と総称される一連の機能によって管理されていました。インターネットの初期にさかのぼり、仕様の公開とレジストリの操作は密接に結びついていました。南カリフォルニア大学（USC）の情報科学研究所（ISI）のジョンポステルは、RFCの公開とIANAのレジストリ操作の両方を担当しました。この密結合には利点がありましたが、それが要件であるということは決してありませんでした。実際、今日、RFCエディタとIANAレジストリ操作は異なるエンティティによって提供されています。
Internet registries are critical to the operation of the Internet, because they provide a definitive record of the value and meaning of identifiers that protocols use when communicating with each other. Almost every Internet protocol makes use of registries in some form. At the time of writing, the IANA maintains more than two thousand protocol parameter registries.
インターネットレジストリは、プロトコルが相互に通信するときに使用する識別子の値と意味の明確な記録を提供するため、インターネットの運用に不可欠です。ほとんどすべてのインターネットプロトコルは、なんらかの形でレジストリを使用します。執筆時点では、IANAは2,000を超えるプロトコルパラメータレジストリを保持しています。
Internet registries hold protocol identifiers consisting of constants and other well-known values used by Internet protocols. These values can be numbers, strings, addresses, and so on. They are uniquely assigned for one particular purpose or use. Identifiers can be maintained in a central list (such as a list of cryptographic algorithms) or they can be hierarchically allocated and assigned by separate entities at different points in the hierarchy (such as IP addresses and domain names). To maximize trust and usefulness of the IANA registries, the principles in this document should be taken into consideration for centralized registries as well as hierarchically delegated registries. In hierarchically delegated registries, entries nearest to top level have broad scope, but lower-level entries have narrow scope. The Internet Architecture Board (IAB) will encourage support for these principles in all delegations of Internet identifiers.
インターネットレジストリは、定数と、インターネットプロトコルで使用されるその他の既知の値で構成されるプロトコル識別子を保持します。これらの値は、数値、文字列、アドレスなどにすることができます。それらは、1つの特定の目的または使用に対して一意に割り当てられます。識別子は中央のリスト（暗号化アルゴリズムのリストなど）で維持することも、階層的に割り当てて、階層内のさまざまなポイント（IPアドレスやドメイン名など）の別のエンティティーに割り当てることもできます。 IANAレジストリの信頼性と有用性を最大化するには、集中型レジストリと階層的に委任されたレジストリについて、このドキュメントの原則を考慮する必要があります。階層的に委任されたレジストリでは、最上位に最も近いエントリのスコープは広くなりますが、下位のエントリのスコープは狭くなります。インターネットアーキテクチャボード（IAB）は、インターネット識別子のすべての委任におけるこれらの原則のサポートを促進します。
The registry system is built on trust and mutual cooperation. The use of the registries is voluntary and is not enforced by mandates or certification policies. While the use of registries is voluntary, it is noted that the success of the Internet creates enormous pressure to use Internet protocols and the identifier registries associated with them.
レジストリシステムは、信頼と相互協力に基づいて構築されています。レジストリの使用は任意であり、義務または認証ポリシーによって強制されません。レジストリの使用は自発的ですが、インターネットの成功は、インターネットプロトコルとそれらに関連付けられた識別子レジストリを使用するという大きなプレッシャーを生み出していることに注意してください。
This document provides principles for the operation of IANA registries, ensuring that protocol identifiers have consistent meanings and interpretations across all implementations and deployments, and thus providing the necessary trust in the IANA registries.
このドキュメントは、IANAレジストリの操作の原則を提供し、プロトコル識別子がすべての実装と展開にわたって一貫した意味と解釈を持つようにし、IANAレジストリに必要な信頼を提供します。
The following key principles underscore the successful functioning of the IANA registries, and they provide a foundation for trust in those registries:
次の主要な原則は、IANAレジストリの正常な機能を強調しており、それらのレジストリに対する信頼の基盤を提供します。
Ensure Uniqueness: The same protocol identifier must not be used for more than one purpose.
一意性の確保：同じプロトコル識別子を複数の目的で使用しないでください。
Stable: Protocol identifier assignment must be lasting.
安定：プロトコル識別子の割り当ては永続的である必要があります。
Predictable: The process for making assignments must not include unexpected steps.
予測可能：割り当てを行うプロセスには、予期しないステップが含まれていてはなりません。
Public: The protocol identifiers must be made available in well-known locations in a manner that makes them freely available to everyone.
公開：プロトコル識別子は、誰でも自由に利用できるように、既知の場所で利用できるようにする必要があります。
Open: The process that sets the policy for protocol identifier assignment and registration must be open to all interested parties.
オープン：プロトコル識別子の割り当てと登録のポリシーを設定するプロセスは、すべての関係者にオープンでなければなりません。
Transparent: The protocol registries and their associated policies should be developed in a transparent manner.
透明性：プロトコルレジストリとそれに関連するポリシーは、透明性のある方法で開発する必要があります。
Accountable: Registry policy development and registry operations need to be accountable to the affected community.
説明責任：レジストリポリシーの開発とレジストリ操作は、影響を受けるコミュニティに対して説明責任を負う必要があります。
The principles discussed in Section 2 provide trust and confidence in the IANA registries. This section expands on these principles.
セクション2で説明する原則は、IANAレジストリへの信頼と信頼を提供します。このセクションでは、これらの原則について詳しく説明します。
Protocol identifier assignment and registration must be unique, stable, and predictable. Developers, vendors, customers, and users depend on the registries for unique protocol identifiers that are assigned in a stable and predictable manner.
プロトコル識別子の割り当てと登録は、一意で、安定していて、予測可能でなければなりません。開発者、ベンダー、顧客、およびユーザーは、安定した予測可能な方法で割り当てられる一意のプロトコル識別子をレジストリに依存しています。
A protocol identifier may only be reassigned for a different purpose after due consideration of the impact of such a reassignment, and if possible, with the consent of the original assignee.
プロトコル識別子は、そのような再割り当ての影響を十分に検討した後、可能であれば元の譲受人の同意を得て、別の目的でのみ再割り当てできます。
Recognizing that some assignments involve judgment, such as those involving a designated expert [RFC5226], a predictable process does not require completion in a predetermined number of days. Rather, it means that no unexpected steps are introduced in the process of making an assignment.
指定された専門家[RFC5226]を含む割り当てなど、一部の割り当てには判断が含まれることを認識して、予測可能なプロセスは、所定の日数で完了する必要はありません。むしろ、それは割り当てを行う過程で予期しないステップが導入されないことを意味します。
Once assigned, the protocol identifiers must be made available in a manner that makes them freely available to everyone without restrictions. The use of a consistent publication location builds confidence in the registry. This does not mean that the publication location can never change, but it does mean that it must change infrequently and only after adequate prior notice.
割り当てられたプロトコル識別子は、制限なしに誰でも自由に利用できるようにする必要があります。一貫した発行場所を使用することで、レジストリの信頼が高まります。これは、発行場所が変更されないことを意味するのではなく、適切な事前通知の後にのみ、頻繁に変更しなければならないことを意味します。
The process that sets the policy for protocol identifier assignment and registration must be open to all interested parties and operate in a transparent manner.
プロトコル識別子の割り当てと登録のポリシーを設定するプロセスは、すべての関係者に公開され、透過的な方法で動作する必要があります。
When a registry is established, a policy is set for the addition of new entries and the updating of existing entries. While making additions and modifications, the registry operator may expose instances where policies lack clarity. When this occurs, the registry operator should provide helpful feedback to allow those policies to be improved. In addition, the registry operator not being involved in establishing registry policy avoids the risks associated with (perceptions of) favoritism and unfairness.
レジストリが確立されると、新しいエントリの追加と既存のエントリの更新に関するポリシーが設定されます。追加や変更を行っている間に、レジストリオペレータはポリシーが明確でないインスタンスを公開する場合があります。これが発生した場合、レジストリオペレーターは、それらのポリシーを改善できるように役立つフィードバックを提供する必要があります。さらに、レジストリオペレーターがレジストリポリシーの確立に関与していないことで、好意と不公平に関連するリスク（認識）が回避されます。
Recognizing that some assignments involve judgment, such as those involving a designated expert [RFC5226], the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal.
指定された専門家[RFC5226]を含むものなど、一部の割り当てには判断が含まれることを認識して、指定された専門家による推奨は可能な限り一般に公開され、異議申し立てまたは控訴の対象となる必要があります。
The process that sets the policy for IANA registries and the operation of the registries must be accountable to the parties that rely on the protocol identifiers. Oversight is needed to ensure these are properly serving the affected community.
IANAレジストリのポリシーとレジストリの操作を設定するプロセスは、プロトコル識別子に依存する関係者に責任があります。これらが影響を受けるコミュニティに適切にサービスを提供していることを確認するには、監視が必要です。
In practice, accountability mechanisms for the registry operator may be defined by contract, memoranda of understanding, or service level agreements (SLAs). An oversight body uses these mechanisms to ensure that the registry operator is meeting the needs of the affected community. The oversight body is held accountable to the affected community by vastly different mechanisms, for instance recall and appeal processes.
実際には、レジストリオペレーターのアカウンタビリティメカニズムは、契約、了解覚書、またはサービスレベル契約（SLA）によって定義されます。監視機関は、これらのメカニズムを使用して、レジストリオペレーターが影響を受けるコミュニティのニーズを満たしていることを確認します。監督機関は、たとえばリコールやアピールのプロセスなど、非常に異なるメカニズムによって影響を受けるコミュニティに対して責任を負います。
For protocol parameters [RFC6220], the general oversight of the IANA function is performed by the IAB as a chartered responsibility from [RFC2850]. In addition, the IETF Administrative Oversight Committee (IAOC), a body responsible for IETF administrative and financial matters [BCP101], maintains an SLA with the current registry operator, the Internet Corporation for Assigned names and Numbers (ICANN), thereby specifying the operational requirements with respect to the coordination, maintenance, and publication of the protocol parameter registries. Both the IAB and the IAOC are accountable to the larger Internet community and are being held accountable through the IETF Nomcom process [BCP10].
プロトコルパラメータ[RFC6220]の場合、IANA機能の一般的な監視は、[RFC2850]からのチャーターされた責任としてIABによって実行されます。さらに、IETFの管理上および財務上の問題[BCP101]に責任を負う機関であるIETF管理監視委員会（IAOC）は、現在のレジストリオペレーターであるInternet Corporation for Assigned Names and Numbers（ICANN）とのSLAを維持し、それによって運用プロトコルパラメータレジストリの調整、保守、公開に関する要件。 IABとIAOCの両方は、より大きなインターネットコミュニティに対して説明責任を負い、IETF Nomcomプロセス[BCP10]を通じて説明責任を負っています。
For the Internet Number Registries [RFC7249], oversight is performed by the Regional Internet Registries (RIRs) as described RFC 7020 [RFC7020]. The RIRs are member-based organizations, and they are accountable to the affected community by elected governance boards. Furthermore, per agreement between the RIRs and ICANN, the policy development for the global IANA number registries is coordinated by a community-elected number council and subject to process review before ratification by the ICANN Board of Trustees [ASOMOU].
インターネット番号レジストリ[RFC7249]の場合、RFC 7020 [RFC7020]で説明されているように、地域インターネットレジストリ（RIR）によって監視が行われます。 RIRはメンバーベースの組織であり、選出されたガバナンス委員会によって影響を受けるコミュニティに対して説明責任を負います。さらに、RIRとICANNの間の合意に従って、グローバルIANA番号レジストリのポリシー開発は、コミュニティによって選出された番号評議会によって調整され、ICANN理事会[ASOMOU]による承認前のプロセスレビューの対象となります。
Internet Registries are critical to elements of Internet security. The principles described in this document are necessary for the Internet community to place trust in the IANA registries.
インターネットレジストリは、インターネットセキュリティの要素にとって重要です。このドキュメントで説明する原則は、インターネットコミュニティがIANAレジストリを信頼するために必要です。
[ASOMOU] ICANN, "ICANN Address Supporting Organization (ASO) MoU", October 2004, <http://archive.icann.org/en/aso/aso-mou-29oct04.htm>.
[ASOMOU] ICANN、「ICANNアドレスサポート組織（ASO）MoU」、2004年10月、<http://archive.icann.org/en/aso/aso-mou-29oct04.htm>。
[BCP10] Kucherawy, M., Ed., "IAB, IESG, and IAOC Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 7437, January 2015, <http://www.rfc-editor.org/info/bcp10>.
[BCP10] Kucherawy、M。、編、「IAB、IESG、およびIAOCの選択、確認、およびリコールプロセス：指名委員会およびリコール委員会の運営」、BCP 10、RFC 7437、2015年1月、<http：// www .rfc-editor.org / info / bcp10>。
[BCP101] Austein, R., Ed., and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005.
[BCP101] Austein、R.、Ed。およびB. Wijnen、Ed。、「Structure of the IETF Administrative Support Activity（IASA）」、BCP 101、RFC 4071、2005年4月。
Carpenter, B., Ed., and L. Lynch, Ed., "BCP 101 Update for IPR Trust", BCP 101, RFC 4371, January 2006.
Carpenter、B。、編、およびL. Lynch、編、「BCP 101 Update for IPR Trust」、BCP 101、RFC 4371、2006年1月。
<http://www.rfc-editor.org/info/bcp101>
[RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000, <http://www.rfc-editor.org/info/rfc2850>.
[RFC2850]インターネットアーキテクチャボードおよびB.カーペンター編、「インターネットアーキテクチャボード（IAB）のチャーター」、BCP 39、RFC 2850、2000年5月、<http://www.rfc-editor.org/info/ rfc2850>。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.
[RFC2860] Carpenter、B.、Baker、F。、およびM. Roberts、「Internet Assigned Numbers Authorityの技術的作業に関する覚書」、RFC 2860、2000年6月、<http：//www.rfc-editor .org / info / rfc2860>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC6220] McPherson, D., Ed., Kolkman, O., Ed., Klensin, J., Ed., Huston, G., Ed., and Internet Architecture Board, "Defining the Role and Function of IETF Protocol Parameter Registry Operators", RFC 6220, April 2011, <http://www.rfc-editor.org/info/rfc6220>.
[RFC6220] McPherson、D.、Ed。、Kolkman、O.、Ed。、Klensin、J.、Ed。、Huston、G.、Ed。、and Internet Architecture Board、 "Defining the Role and Function of IETF Protocol Parameterレジストリオペレーター」、RFC 6220、2011年4月、<http://www.rfc-editor.org/info/rfc6220>。
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, August 2013, <http://www.rfc-editor.org/info/rfc7020>.
[RFC7020] Housley、R.、Curran、J.、Huston、G。、およびD. Conrad、「The Internet Numbers Registry System」、RFC 7020、2013年8月、<http://www.rfc-editor.org/ info / rfc7020>。
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, May 2014, <http://www.rfc-editor.org/info/rfc7249>.
[RFC7249] Housley、R。、「インターネット番号レジストリ」、RFC 7249、2014年5月、<http://www.rfc-editor.org/info/rfc7249>。
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko (IETF Chair) Mary Barnes Marc Blanchet Joel Halpern Ted Hardie Joe Hildebrand Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Brian Trammell
Jari Arkko（IETF議長）メアリーバーンズマークブランシェジョエルハルパーンテッドハーディジョーヒルデブランドラスヒュースリーエリオットリアシンリーエリックノードマークアンドリューサリバンデイブターラーブライアントランメル
Contributors and Acknowledgements
寄稿者と謝辞
This text has been developed within the IAB IANA Evolution Program. The ideas and many text fragments, and corrections came from or were inspired on comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Steve Crocker, John Curran, Alissa Cooper, Leslie Daigle, Elise Gerich, John Klensin, Bertrand de La Chapelle, Eliot Lear, Danny McPherson, George Michaelson, Thomas Narten, Andrei Robachevsky, Andrew Sullivan, Dave Thaler, Brian Trammell, and Greg Wood. Further inspiration and input was drawn from various meetings with IETF and other Internet community (RIRs, ISOC, W3C, IETF, and IAB) leadership.
このテキストは、IAB IANA進化プログラム内で作成されました。アイデアと多くのテキストの断片、および訂正は、バーナードアボバ、ジャープアッカーフイス、ジャリアルコ、マルセロバニュロ、マークブランシェ、ブライアンカーペンター、デビッドコンラッド、スティーブクロッカー、ジョンカラン、アリッサクーパー、レスリーダイグル、エリーゼゲリッチ、ジョンクレンシン、ベルトランデラシャペル、エリオットリア、ダニーマクファーソン、ジョージマイケルソン、トーマスナーテン、アンドレイロバチェフスキー、アンドリューサリバン、デイブターラー、ブライアントラメル、グレッグウッド。 IETFおよび他のインターネットコミュニティ（RIR、ISOC、W3C、IETF、およびIAB）のリーダーシップとのさまざまな会議から、さらにインスピレーションと情報が得られました。
Please do not assume those acknowledged endorse the resulting text.
認められている人が結果のテキストを支持していると想定しないでください。
Authors' Addresses
著者のアドレス
Russ Housley 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com
Russ Housley 918 Spring Knoll Drive Herndon、VA 20170 USA Eメール：housley@vigilsec.com
Olaf Kolkman Science Park 400 Amsterdam 1098 XH The Netherlands EMail: kolkman@isoc.org
オラフコルクマンサイエンスパーク400アムステルダム1098 XHオランダEメール：kolkman@isoc.org