[要約] RFC 8720は、IANAレジストリの運用原則に関するものであり、インターネット割り当て番号機関（IANA）のレジストリの運用に関するガイドラインを提供しています。このRFCの目的は、IANAレジストリの一貫性と信頼性を確保し、インターネットの運用における番号の割り当てと管理を効果的に行うことです。
Internet Architecture Board (IAB) R. Housley, Ed.
Request for Comments: 8720 O. Kolkman, Ed.
Obsoletes: 7500 February 2020
Category: Informational
ISSN: 2070-1721
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 candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8720.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8720で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Principles for the Operation of IANA Registries
3. Discussion
3.1. Ensuring Uniqueness, Stability, and Predictability
3.2. Public
3.3. Open and Transparent
3.4. Accountable
4. Security Considerations
5. Changes since RFC 7500
6. Informative References
IAB Members at the Time of Approval
Acknowledgements
Authors' Addresses
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, 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 [RFC8126], 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.
指定された専門家[RFC8126]を含む割り当てなど、一部の割り当てには判断が含まれることを認識して、予測可能なプロセスは、所定の日数で完了する必要はありません。むしろ、それは割り当てを行う過程で予期しないステップが導入されないことを意味します。
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 must 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 [RFC8126], the recommendations by designated experts must be visible to the public to the maximum extent possible and subject to challenge or appeal.
指定された専門家[RFC8126]を含むものなど、一部の割り当てには判断が含まれることを認識し、指定された専門家による推奨は可能な限り一般に公開され、異議申し立てまたは控訴の対象となる必要があります。
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 a 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 Administration Limited Liability Company (IETF LLC), as part of the IETF Administrative Support Activity (IASA), is responsible for IETF administrative and financial matters [RFC8711]. In that role, the IETF LLC 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 Board of the IETF LLC are accountable to the larger Internet community and are being held accountable through the IETF NomCom process [RFC8713].
プロトコルパラメータ[RFC6220]の場合、IANA機能の一般的な監視は、[RFC2850]からのチャーターされた責任としてIABによって実行されます。さらに、IETF管理サポート活動（IASA）の一部として、IETF管理有限責任会社（IETF LLC）がIETFの管理および財務問題[RFC8711]に責任を負います。その役割において、IETF LLCは、現在のレジストリオペレーターであるInternet Corporation for Assigned Names and Numbers（ICANN）とのSLAを維持し、それにより、プロトコルパラメーターレジストリの調整、維持、公開に関する運用要件を指定します。 IABとIETF LLCの理事会の両方が、より大きなインターネットコミュニティに対して責任を負い、IETF NomComプロセス[RFC8713]を通じて責任を問われます。
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レジストリを信頼するために必要です。
Section 3.4 has been updated to align with the restructuring of the IETF Administrative Support Activity (IASA). Under the new structure, the IETF LLC maintains an SLA with the protocol parameter registry operator. Under the old structure, the SLA was maintained by the IETF Administrative Oversight Committee (IAOC).
セクション3.4は、IETF管理サポート活動（IASA）の再編に合わせて更新されました。新しい構造の下で、IETF LLCはプロトコルパラメータレジストリオペレータを使用してSLAを維持します。古い構造では、SLAはIETF管理監視委員会（IAOC）によって維持されていました。
[ASOMOU] ICANN, "Address Supporting Organization (ASO) MoU", October 2004, <https://archive.icann.org/en/aso/aso-mou-29oct04.htm>.
[ASOMOU] ICANN、「Address Supporting Organization（ASO）MoU」、2004年10月、<https://archive.icann.org/en/aso/aso-mou-29oct04.htm>。
[RFC2850] Internet Architecture Board and B. Carpenter, Ed., "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, <https://www.rfc-editor.org/info/rfc2850>.
[RFC2850]インターネットアーキテクチャボードおよびB.カーペンター編、「インターネットアーキテクチャボード（IAB）のチャーター」、BCP 39、RFC 2850、DOI 10.17487 / RFC2850、2000年5月、<https：//www.rfc-editor .org / info / rfc2850>。
[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, DOI 10.17487/RFC6220, April 2011, <https://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、DOI 10.17487 / RFC6220、2011年4月、<https://www.rfc-editor.org/info/rfc6220>。
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <https://www.rfc-editor.org/info/rfc7020>.
[RFC7020] Housley、R.、Curran、J.、Huston、G。、およびD. Conrad、「The Internet Numbers Registry System」、RFC 7020、DOI 10.17487 / RFC7020、2013年8月、<https：//www.rfc -editor.org/info/rfc7020>。
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, DOI 10.17487/RFC7249, May 2014, <https://www.rfc-editor.org/info/rfc7249>.
[RFC7249] Housley、R。、「インターネット番号レジストリ」、RFC 7249、DOI 10.17487 / RFC7249、2014年5月、<https://www.rfc-editor.org/info/rfc7249>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of the IETF Administrative Support Activity, Version 2.0", BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, <https://www.rfc-editor.org/info/rfc8711>.
[RFC8711]ハーバーマン、B。、ホール、J。、およびJ.リビングウッド、「IETF管理サポート活動の構造、バージョン2.0」、BCP 101、RFC 8711、DOI 10.17487 / RFC8711、2020年2月、<https：// www.rfc-editor.org/info/rfc8711>。
[RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, February 2020, <https://www.rfc-editor.org/info/rfc8713>.
[RFC8713] Kucherawy、M.、Ed。、Hinden、R.、Ed。、and J. Livingood、Ed。、 "IAB、IESG、and IETF LLC Selection、Confirmation、and Recall Process：Operation of the IETF Nomination and Recall委員会」、BCP 10、RFC 8713、DOI 10.17487 / RFC8713、2020年2月、<https://www.rfc-editor.org/info/rfc8713>。
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko Alissa Cooper Stephen Farrell Wes Hardaker Ted Hardie Christian Huitema Zhenbin Li Erik Nordmark Mark Nottingham Melinda Shore Jeff Tantsura Martin Thomson Brian Trammell
ジャリアルコアリッサクーパースティーブンファレルウェスハーダーカーテッドハーディークリスチャンウイテマジェンビンリーエリックノードマークマークノッティンガムメリンダショアジェフタンツラマーティントムソンブライアントラメル
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 by comments from: Bernard Aboba, Jaap Akkerhuis, Jari Arkko, Marcelo Bagnulo, Mark Blanchet, Brian Carpenter, David Conrad, Alissa Cooper, Steve Crocker, John Curran, 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 the leadership of the Internet community, i.e., from the RIRs, ISOC, W3C, IETF, and IAB.
このテキストは、IAB IANA進化プログラム内で作成されました。アイデアと多くのテキストの断片と修正は、バーナードアボバ、ジャープアッカーフイス、ジャリアルコ、マルセロバニュロ、マークブランシェ、ブライアンカーペンター、デビッドコンラッド、アリッサクーパー、スティーブクロッカー、ジョンカラン、レスリーダイグル、エリーゼゲリッチ、ジョンクレンシン、ベルトランデラシャペル、エリオットリア、ダニーマクファーソン、ジョージマイケルソン、トーマスナーテン、アンドレイロバチェフスキー、アンドリューサリバン、デイブターラー、ブライアントラメル、グレッグウッド。インターネットコミュニティのリーダーとのさまざまな会議、つまり、RIR、ISOC、W3C、IETF、およびIABからのさらなるインスピレーションとインプットが引き出されました。
Please do not assume those acknowledged endorse the resulting text.
認められている人が結果のテキストを支持していると想定しないでください。
Authors' Addresses
著者のアドレス
Russ Housley (editor) Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 United States of America
Russ Housley（編集者）Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ合衆国
Email: housley@vigilsec.com
Olaf Kolkman (editor) Internet Society Science Park 400 1098 XH Amsterdam Netherlands
Olaf Kolkman（編集者）Internet Society Science Park 400 1098 XHアムステルダムオランダ
Email: kolkman@isoc.org