[要約] RFC 7979は、IANAプロトコルパラメータレジストリに関するICGの提案要求に対する応答です。その目的は、IANAのパラメータレジストリの運営と管理に関する提案を提供することです。
Internet Engineering Task Force (IETF) E. Lear, Ed.
Request for Comments: 7979 R. Housley, Ed.
Category: Informational August 2016
ISSN: 2070-1721
Response to the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals on the IANA Protocol Parameters Registries
IANAプロトコルパラメータレジストリに関する提案のIANAスチュワードシップ移行調整グループ（ICG）要求への応答
Abstract
概要
The U.S. National Telecommunications and Information Administration (NTIA) solicited a request from the Internet Corporation for Assigned Names and Numbers (ICANN) to propose how the NTIA should end its oversight of the Internet Assigned Numbers Authority (IANA) functions. After broad consultations, ICANN in turn created the IANA Stewardship Transition Coordination Group. That group solicited proposals for the three major IANA functions: names, numbers, and protocol parameters. This document contains the IETF response to that solicitation for protocol parameters. It was included in an aggregate response to the NTIA alongside those for names and numbering resources that are being developed by their respective operational communities. A reference to that response may be found in the introduction, and additional correspondence is included in the Appendix.
米国電気通信情報局（NTIA）は、割り当てられた名前と番号（ICANN）に対するインターネット会社からの要求を求め、NTIAがインターネット割り当て番号機関（IANA）の機能の監視をどのように終了させるべきかを提案しました。幅広い協議の後、ICANNはIANAスチュワードシップ移行コーディネーショングループを設立しました。そのグループは、3つの主要なIANA機能（名前、番号、プロトコルパラメータ）の提案を求めました。このドキュメントには、プロトコルパラメータの要請に対するIETF応答が含まれています。それは、それぞれの運用コミュニティによって開発されている名前と番号付けリソースに関するものと並んで、NTIAへの総回答に含まれていました。その応答への参照は序文にあり、追加の対応は付録に含まれています。
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 Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション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/rfc7979.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7979で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. IETF Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. The Formal RFP Response . . . . . . . . . . . . . . . . . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
4. Security Considerations . . . . . . . . . . . . . . . . . . . 20
5. IAB Note . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 22
Appendix A. The Charter of the IANA Stewardship Coordination
Group (ICG) . . . . . . . . . . . . . . . . . . . . 25
Appendix B. IANA Stewardship Transition Coordination Group
Request for Proposals . . . . . . . . . . . . . . . 28
Appendix C. Correspondence of the IETF to the ICG . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
In March of 2014, the U.S. National Telecommunications and Information Administration (NTIA) announced its intent to transition oversight of Internet Assigned Numbers Authority (IANA) functions [NTIA-Announce]. In that announcement, NTIA asked the Internet Corporation for Assigned Names and Numbers (ICANN) to establish a process to deliver a proposal for transition. As part of that process, the IANA Stewardship Transition Coordination Group (ICG) was formed. The charter for the ICG can be found in Appendix A. The ICG in turn solicited proposals regarding post-transition arrangements from the names, numbers, and protocol parameters communities in order to put forth a proposal to the NTIA. The final request for proposal (RFP) can be found in Appendix B. The response from the ICG to the NTIA may be found at [ICG-Response].
2014年3月、米国電気通信情報局（NTIA）は、Internet Assigned Numbers Authority（IANA）機能の監視を移行する意図を発表しました[NTIA-Announce]。その発表の中で、NTIAはインターネット企業に割り当てられた名前と番号（ICANN）に移行の提案を提供するプロセスを確立するように求めました。そのプロセスの一環として、IANAスチュワードシップ移行調整グループ（ICG）が設立されました。 ICGの憲章は付録Aにあります。ICGは、NTIAに提案を出すために、名前、番号、プロトコルパラメータコミュニティから移行後の取り決めに関する提案を求めました。最終的な提案依頼書（RFP）は付録Bにあります。ICGからNTIAへの応答は、[ICG-Response]にあります。
While there are interactions between all of the IANA functions and IETF standards, this document specifically addresses the protocol parameters registries function. Section 1 (this section) contains an introduction that is sourced solely within the IETF. Section 2 contains the questionnaire that was written by the ICG and a formal response by the IETF. We have quoted questions from that questionnaire with ">>> ", and we have prefaced answers to questions being asked with "IETF Response:". Note that there are small changes to the questions asked in order to match the RFC format.
IANAのすべての機能とIETF標準の間には相互作用がありますが、このドキュメントでは、特にプロトコルパラメータのレジストリ機能について説明しています。セクション1（このセクション）には、IETF内でのみ提供される概要が含まれています。セクション2には、ICGによって作成されたアンケートとIETFによる正式な回答が含まれています。私たちはそのアンケートからの質問を ">>>"で引用し、「IETF応答：」で質問に対する回答に序文を付けました。 RFC形式と一致させるために尋ねられる質問に小さな変更があることに注意してください。
We note that the following text was stated as a footnote in the original RFP:
次のテキストは元のRFPの脚注として記載されていたことに注意します。
In this RFP, "IANA" refers to the functions currently specified in the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well as any other functions traditionally performed by the IANA functions operator. SAC-067 [https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides one description of the many different meanings of the term "IANA" and may be useful reading in addition to the documents constituting the agreement itself.
このRFPでは、「IANA」は、NTIAとICANNの間の契約で現在指定されている機能[http://www.ntia.doc.gov/page/iana-functions-purchase-order]と、伝統的に他のすべての機能を指しますIANA関数演算子によって実行されます。 SAC-067 [https://www.icann.org/en/system/files/files/sac-067-en.pdf]は、「IANA」という用語の多くの異なる意味の1つの説明を提供します。契約自体を構成する文書に加えて。
The entire Request for Proposals, including introduction, can be found in Appendix B.
概要を含む提案依頼書全体は、付録Bにあります。
>>>
>>> 0. Proposal Type
>>>
>>> Identify which category of the IANA functions this
>>> submission proposes to address:
>>>
IETF Response: Protocol Parameters
IETF応答：プロトコルパラメータ
This response states the existing practice of the IETF, and also represents the views of the Internet Architecture Board and the IETF.
この回答は、IETFの既存の慣行を述べており、インターネットアーキテクチャボードとIETFの見解も表しています。
>>>
>>> I. Description of Community's Use of IANA Functions
>>>
>>> This section should list the specific, distinct IANA services
>>> or activities your community relies on. For each IANA service
>>> or activity on which your community relies, please provide the
>>> following:
>>> A description of the service or activity.
>>>
IETF Response:
IETF応答：
Many IETF protocols make use of commonly defined protocol parameters. These parameters are used by implementers, who are the primary users of the IETF standards and other documents. To ensure consistent interpretation of these parameter values by independent implementations, and to promote universal interoperability, these IETF protocol specifications define and require globally available registries containing the parameter values and a pointer to any associated documentation. The IETF uses the IANA protocol parameters registries to store this information in a public location. The IETF community presently accesses the protocol parameter registries via references based on the iana.org domain name, and makes use of the term "IANA" in the protocol parameter registry processes [RFC5226].
多くのIETFプロトコルは、一般的に定義されているプロトコルパラメータを使用します。これらのパラメーターは、IETF標準およびその他のドキュメントの主要なユーザーである実装者によって使用されます。独立した実装によるこれらのパラメーター値の一貫した解釈を保証し、普遍的な相互運用性を促進するために、これらのIETFプロトコル仕様は、パラメーター値と関連するドキュメントへのポインターを含むグローバルに利用可能なレジストリを定義および要求します。 IETFは、IANAプロトコルパラメータレジストリを使用して、この情報を公共の場所に格納します。 IETFコミュニティは現在、iana.orgドメイン名に基づく参照を介してプロトコルパラメータレジストリにアクセスし、プロトコルパラメータレジストリプロセス[RFC5226]で「IANA」という用語を利用しています。
ICANN currently operates the .ARPA top level domain on behalf of the Internet Architecture Board (IAB). This zone is used for certain Internet infrastructure services that are delegated beneath it. The IETF considers .ARPA part of the protocol parameters registries for purposes of this response.
ICANNは現在、インターネットアーキテクチャボード（IAB）に代わって.ARPAトップレベルドメインを運用しています。このゾーンは、その下に委任された特定のインターネットインフラストラクチャサービスに使用されます。 IETFは、この応答の目的で、プロトコルパラメータレジストリの.ARPA部分を考慮します。
>>>
>>> A description of the customer(s) of the service or activity.
>>>
IETF Response:
IETF応答：
The IANA protocol parameters registries operator maintains the protocol parameters registries for the IETF in conformance with all relevant IETF policies, in accordance with the Memorandum of Understanding [RFC2860] and associated supplemental agreements that include service level agreements (SLAs) established between the IETF and ICANN [MOUSUP].
IANAプロトコルパラメータレジストリオペレータは、IETFとICANNの間に確立されたサービスレベル契約（SLA）を含む了解覚書[RFC2860]および関連する補足契約に従って、関連するすべてのIETFポリシーに準拠してIETFのプロトコルパラメータレジストリを維持します。 [MOUSUP]。
The IETF is a global organization that produces voluntary standards, whose mission is to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better [RFC3935]. IETF standards are published in the RFC series. The IETF is responsible for the key standards that are used on the Internet today, including IP, TCP, DNS, BGP, and HTTP, to name but a few.
IETFは、自主規格を作成するグローバル組織であり、その使命は、インターネットをより良く機能させるような方法で人々がインターネットを設計、使用、および管理する方法に影響を与える、高品質で関連する技術およびエンジニアリングドキュメントを作成することです[RFC3935 ]。 IETF標準はRFCシリーズで公開されています。 IETFは、ほんの一例を挙げれば、IP、TCP、DNS、BGP、HTTPなど、今日インターネットで使用されている主要な標準を担当しています。
The IETF operates in an open and transparent manner [RFC6852]. The processes that govern the IETF are also published in the RFC series. The Internet Standards Process is documented in [RFC2026]. That document explains not only how standards are developed, but also how disputes about decisions are resolved. RFC 2026 has been amended a number of times [BCP9info]. The standards process can be amended in the same manner that standards are approved. That is, someone proposes a change by submitting a temporary document known as an Internet-Draft, the community discusses it, and if rough consensus can be found the change is approved by the Internet Engineering Steering Group (IESG), who also have day-to-day responsibility for declaring IETF consensus on technical decisions, including those that affect the IANA protocol parameters registries. Anyone may propose a change during a Last Call, and anyone may participate in the community discussion.
IETFはオープンで透過的な方法で動作します[RFC6852]。 IETFを管理するプロセスは、RFCシリーズでも公開されています。インターネット標準プロセスは[RFC2026]に文書化されています。その文書は、標準がどのように開発されるかだけでなく、決定に関する紛争がどのように解決されるかも説明しています。 RFC 2026は何度も修正されています[BCP9info]。標準プロセスは、標準が承認されるのと同じ方法で修正できます。つまり、誰かがInternet-Draftと呼ばれる一時的なドキュメントを提出することで変更を提案し、コミュニティがそれについて議論し、大まかなコンセンサスが見つかれば、変更はインターネットエンジニアリングステアリンググループ（IESG）によって承認されます。 IANAプロトコルパラメータレジストリに影響するものを含め、技術的な決定に関するIETFの合意を宣言するための現在の責任。ラストコール中に誰でも変更を提案でき、誰でもコミュニティディスカッションに参加できます。
>>>
>>> What registries are involved in providing the service or
>>> activity.
>>>
IETF Response:
IETF応答：
The protocol parameters registries are the product of IETF work. These also include the top-level registry for the entire IP address space and some of its sub-registries, autonomous system number space, and a number of special use registries with regard to domain names. For more detail please refer to the documentation in the "overlaps or interdependencies" section.
プロトコルパラメータレジストリは、IETFの成果物です。これらには、IPアドレス空間全体のトップレベルレジストリとそのサブレジストリの一部、自律システム番号空間、およびドメイン名に関するいくつかの特殊用途レジストリも含まれます。詳細については、「重複または相互依存」セクションのドキュメントを参照してください。
Administration of the protocol parameters registries is the service that is provided to the IETF.
プロトコルパラメータレジストリの管理は、IETFに提供されるサービスです。
>>>
>>> A description of any overlaps or interdependencies between your
>>> IANA requirements and the functions required by other customer
>>> communities.
>>>
IETF Response:
IETF応答：
In this context, the IETF considers "overlap" to be where there is in some way shared responsibility for a single registry across multiple organizations. In this sense, there is no overlap between organizations because responsibility for each registry is carefully delineated. There are, however, points of interaction between other organizations, and a few cases where the IETF may further define the scope of a registry for technical purposes. This is the case with both names and numbers, as described in the paragraphs below. In all cases, the IETF coordinates with the appropriate organizations.
このコンテキストでは、IETFは、「オーバーラップ」が、複数の組織にまたがる単一のレジストリに対して何らかの形で責任が共有される場所であると見なします。この意味で、各レジストリの責任は慎重に定義されているため、組織間に重複はありません。ただし、他の組織間の相互作用のポイントがあり、IETFが技術的な目的でレジストリの範囲をさらに定義する場合があります。これは、以下の段落で説明するように、名前と番号の両方に当てはまります。すべての場合において、IETFは適切な組織と調整します。
It is important to note that the IETF does not have formal membership. The term "the IETF" includes anyone who wishes to participate in the IETF, and IETF participants may also be members of other communities. Staff and participants from ICANN and the Regional Internet Registries (RIRs) regularly participate in IETF activities.
IETFには正式なメンバーシップがないことに注意することが重要です。 「IETF」という用語には、IETFへの参加を希望するすべての人が含まれ、IETFの参加者は他のコミュニティのメンバーになることもできます。 ICANNおよび地域インターネットレジストリ（RIR）のスタッフと参加者は、IETFの活動に定期的に参加しています。
o The IETF has specified a number of special use registries with regard to domain names. These registries require coordination with ICANN as the policy authority for the DNS root, including community groups that are responsible for ICANN policy on domain names such as the Generic Names Supporting Organization (GNSO) and the Country Code Names Supporting Organization (ccNSO). There are already mechanisms in place to perform this coordination, and the capacity to modify those mechanisms to meet new conditions as they might arise. [RFC6761]
o IETFは、ドメイン名に関していくつかの特殊用途レジストリを指定しています。これらのレジストリでは、Generic Names Supporting Organization（GNSO）やCountry Code Names Supporting Organization（ccNSO）などのドメイン名に関するICANNポリシーを担当するコミュニティグループなど、DNSルートのポリシー機関としてICANNとの調整が必要です。この調整を実行するためのメカニズムがすでに用意されており、それらのメカニズムを変更して、新しい条件が発生する可能性がある場合に満たすことができます。 [RFC6761]
o The IETF specifies the DNS protocol. From time to time there have been and will be updates to that protocol. As we make changes we will broadly consult the operational community about the impact of those changes, as we have done in the past.
o IETFはDNSプロトコルを指定します。そのプロトコルは時々更新されます。変更を加える際は、これまでと同じように、変更の影響について運用コミュニティに幅広く相談します。
o The IETF specifies minimum requirements for root servers. [RFC2870] Those requirements are currently under review, in consultations with the root server community.
o IETFは、ルートサーバーの最小要件を指定します。 [RFC2870]これらの要件は、ルートサーバーコミュニティとの協議の中で、現在検討中です。
o The routing architecture has evolved over time, and is expected to continue to do so. Such evolution may have an impact on appropriate IP address allocation strategies. If and when that happens, the IETF will consult and coordinate with the RIR community, as we have done in the past.
o ルーティングアーキテクチャは時間の経過とともに進化しており、今後も進化すると予想されます。このような進化は、適切なIPアドレス割り当て戦略に影響を与える可能性があります。これが発生した場合、IETFは、これまでと同じように、RIRコミュニティと協議して調整します。
o The IETF is responsible for policy relating to the entire IP address space and AS number space. Through the IANA protocol parameters registries, the IETF delegates unicast IP address and AS number ranges to the RIRs [RFC7020],[RFC7249]. Special address allocation, such as multicast and anycast addresses, often require coordination. Another example of IP addresses that are not administered by the RIR system is Unique Local Addresses (ULAs) [RFC4193], where local networks employ a prefix that is not intended to be routed on the public Internet. New special address allocations are added, from time to time, related to the evolution of the standards. In all cases, these special assignments are listed in the IANA protocol paramters registries.
o IETFは、IPアドレス空間全体とAS番号空間に関するポリシーを担当します。 IANAプロトコルパラメータレジストリを通じて、IETFはユニキャストIPアドレスとAS番号の範囲をRIR [RFC7020]、[RFC7249]に委任します。マルチキャストアドレスやエニーキャストアドレスなどの特別なアドレス割り当てでは、多くの場合、調整が必要です。 RIRシステムによって管理されないIPアドレスのもう1つの例は、一意のローカルアドレス（ULA）[RFC4193]です。この場合、ローカルネットワークは、パブリックインターネット上でルーティングすることを意図していないプレフィックスを使用します。標準の進化に関連して、新しい特別なアドレス割り当てが随時追加されます。すべての場合において、これらの特別な割り当ては、IANAプロトコルパラメータレジストリにリストされています。
o The IETF maintains sub-registries for special IPv4 and IPv6 assignments. These are specified in [RFC3307], [RFC5771], and [RFC6890]. The IETF coordinates such assignments with the RIRs.
o IETFは、特別なIPv4およびIPv6割り当て用のサブレジストリを維持します。これらは、[RFC3307]、[RFC5771]、および[RFC6890]で指定されています。 IETFは、そのような割り当てをRIRと調整します。
o Changes to IETF standards may have impact on operations of RIRs and service providers. A recent example is the extensions to BGP to carry the Autonomous System numbers as four-octet entities [RFC6793]. It is important to note that this change occurred out of operational necessity, and it demonstrated strong alignment between the RIRs and the IETF.
o IETF標準への変更は、RIRおよびサービスプロバイダーの運用に影響を与える可能性があります。最近の例は、自律システム番号を4オクテットエンティティとして運ぶためのBGPの拡張です[RFC6793]。この変更は運用上の必要性から生じたものであり、RIRとIETFの間に強い整合性があることを示していることに注意することが重要です。
>>> II. Existing, Pre-Transition Arrangements
>>>
>>> This section should describe how existing IANA-related
>>> arrangements work, prior to the transition.
>>>
>>> A. Policy Sources
>>>
>>>
>>> This section should identify the specific source(s) of policy
>>> which must be followed by the IANA functions operator in its
>>> conduct of the services or activities described above. If there
>>> are distinct sources of policy or policy development for
>>> different IANA activities, then please describe these
>>> separately. For each source of policy or policy development,
>>> please provide the following:
>>>
>>> Which IANA service or activity (identified in Section I) is
>>> affected.
>>>
IETF Response:
IETF応答：
The protocol parameters registries.
プロトコルパラメータレジストリ。
>>>
>>> A description of how policy is developed and established and
>>> who is involved in policy development and establishment.
>>>
IETF Response:
IETF応答：
Policy for overall management of the protocol parameters registries is stated in [RFC6220] and [RFC5226]. The first of these documents explains the model for how the registries are to be operated, how policy is set, and how oversight takes place. RFC 5226 specifies the policies that specification writers may employ when they define new protocol registries in the "IANA Considerations" section of each specification. All policies at the IETF begin with a proposal in the form of an Internet-Draft. Anyone may submit such a proposal. If there is sufficient interest, a working group whose scope includes the proposed work may choose to adopt it, the IESG may choose to create a working group, or an Area Director may choose to sponsor the draft. In any case, anyone may comment on the proposal as it progresses. A proposal cannot be passed by the IESG unless it enjoys sufficient community support as to indicate rough consensus [RFC7282]. In each case, a "Last Call" is made so that there is notice of any proposed change to a policy or process. Anyone may comment during a Last Call. For example, this process is currently being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].
プロトコルパラメータレジストリの全体的な管理のポリシーは、[RFC6220]と[RFC5226]に記載されています。これらのドキュメントの最初の部分では、レジストリの操作方法、ポリシーの設定方法、監視の方法についてのモデルを説明しています。 RFC 5226は、仕様作成者が各仕様の「IANAに関する考慮事項」セクションで新しいプロトコルレジストリを定義するときに使用できるポリシーを規定しています。 IETFのすべてのポリシーは、インターネットドラフトの形式の提案から始まります。誰でもそのような提案を提出することができます。十分な関心がある場合は、提案された作業を範囲に含むワーキンググループがそれを採用することを選択し、IESGがワーキンググループを作成することを選択するか、またはエリアディレクターがドラフトのスポンサーを選択する場合があります。いずれにせよ、進行中の提案には誰でもコメントできます。大まかなコンセンサス[RFC7282]を示すために十分なコミュニティのサポートを享受しない限り、提案はIESGによって可決されません。いずれの場合も、ポリシーまたはプロセスに対する提案された変更の通知があるように、「最終呼び出し」が行われます。ラストコール中に誰でもコメントできます。たとえば、このプロセスは現在、RFC 5226 [I-D.leiba-cotton-iana-5226bis]の更新に使用されています。
>>>
>>> A description of how disputes about policy are resolved.
>>>
IETF Response:
IETF応答：
Most disputes are handled at the lowest level through the working group and rough consensus processes. Should anyone disagree with any action, Section 6.5 of [RFC2026] specifies a multi-level conflict resolution and appeals process that includes the responsible Area Director, the IESG, and the IAB. Should appeals be upheld, an appropriate remedy is applied. In the case where someone claims that the procedures themselves are insufficient or inadequate in some way to address a circumstance, one may appeal an IAB decision to the Internet Society Board of Trustees.
ほとんどの紛争は、ワーキンググループと大まかなコンセンサスプロセスを通じて最低レベルで処理されます。誰かが何らかの行動に同意しない場合、[RFC2026]のセクション6.5は、責任のあるエリアディレクター、IESG、およびIABを含む、マルチレベルの紛争解決および異議申し立てプロセスを指定します。上訴が支持された場合、適切な救済策が適用されます。誰かが、状況自体に対処するための手順自体が不十分または不十分であると主張する場合、IABの決定をインターネット管理委員会に上訴することができます。
>>>
>>> References to documentation of policy development and dispute
>>> resolution processes.
>>>
IETF Response:
IETF応答：
As mentioned above, [RFC2026] Section 6.5 specifies a conflict resolution and appeals process. [RFC2418] specifies working group procedures. Note that both of these documents have been amended in later RFCs as indicated in the [RFC-INDEX].
上記のように、[RFC2026]セクション6.5は紛争の解決と異議申し立てのプロセスを規定しています。 [RFC2418]は、ワーキンググループプロシージャを指定します。これらのドキュメントはどちらも、[RFC-INDEX]に示されているように、後のRFCで修正されていることに注意してください。
>>> >>> B. Oversight and Accountability >>> >>> This section should describe all the ways in which oversight is >>> conducted over IANA functions operator's provision of the >>> services and activities listed in Section I and all the ways in >>> which IANA functions operator is currently held accountable for >>> the provision of those services. For each oversight or >>> accountability mechanism, please provide as many of the >>> following as are applicable: >>> >>> Which IANA service or activity (identified in Section I) is >>> affected. >>> IETF Response:
>>> >>> B.監視とアカウンタビリティ>>> >>>このセクションでは、監視が>>>セクションIにリストされている>>>サービスとアクティビティのIANA機能オペレーターの提供を通じて行われるすべての方法を説明する必要があります。 >>>のすべての方法で、IANA機能のオペレーターが現在、これらのサービスの提供について責任を負っています。各監視または>>>アカウンタビリティメカニズムについて、該当する>>>次の項目をすべて提供してください。>>> >>>影響を受けるIANAサービスまたはアクティビティ（セクションIで特定）>>> >>> IETF応答：
The protocol parameters registries.
プロトコルパラメータレジストリ。
>>>
>>> If not all policy sources identified in Section II.A are
>>> affected, identify which ones are affected.
>>>
IETF Response:
IETF応答：
All policy sources relating to the protocol parameters registry are affected.
プロトコルパラメータレジストリに関連するすべてのポリシーソースが影響を受けます。
>>>
>>> A description of the entity or entities that provide oversight
>>> or perform accountability functions, including how individuals
>>> are selected or removed from participation in those entities.
>>>
IETF Response:
IETF応答：
The Internet Architecture Board (IAB) is an oversight body of the IETF whose responsibilities include, among other things, confirming appointment of IESG members, managing appeals as discussed above, management of certain domains, including .ARPA [RFC3172], and general architectural guidance to the broader community. The IAB must approve the appointment of an organization to act as IANA operator on behalf of the IETF. The IAB is also responsible for establishing liaison relationships with other organizations on behalf of the IETF. The IAB's charter is to be found in [RFC2850].
インターネットアーキテクチャボード（IAB）はIETFの監督機関であり、IESGメンバーの任命の確認、前述の異議申し立ての管理、.ARPA [RFC3172]を含む特定のドメインの管理、および一般的なアーキテクチャガイダンスなどの責任があります。より広いコミュニティに。 IABは、IETFに代わってIANAオペレーターとして活動する組織の指名を承認する必要があります。 IABは、IETFに代わって他の組織との連絡関係を確立する責任もあります。 IABの憲章は[RFC2850]にあります。
The IAB members are selected and may be recalled through a Nominating Committee (NOMCOM) process, which is described in [RFC3777] and its updates. This process provides for selection of active members of the community who themselves agree upon a slate of candidates. The active members are chosen randomly from volunteers with a history of participation in the IETF, with limits regarding having too many active members with the same affiliation. The selection of the active members is performed in a manner that makes it possible for anyone to verify that the correct procedure was followed. The slate of candidates selected by the active members are sent to the Internet Society Board of Trustees for confirmation. In general, members are appointed for terms of two years. The IAB selects its own chair.
IABメンバーが選ばれ、[RFC3777]とその更新で説明されている指名委員会（NOMCOM）プロセスを通じて呼び戻すことができます。このプロセスでは、候補者のリストに同意するコミュニティのアクティブなメンバーを選択できます。アクティブメンバーは、IETFへの参加の歴史を持つボランティアからランダムに選択されますが、同じ所属を持つアクティブメンバーが多すぎるという制限があります。アクティブメンバーの選択は、正しい手順が実行されたことを誰でも確認できるように実行されます。正会員によって選ばれた候補者のスレートは、確認のためにインターネット協会理事会に送られます。通常、会員は2年間の任期で任命されます。 IABは独自の椅子を選択します。
The IAB provides oversight of the protocol parameters registries of the IETF, and is responsible for selecting appropriate operator(s) and related per-registry arrangements. Especially when relationships among protocols call for it, registries are at times operated by, or in conjunction with, other bodies. Unless the IAB or IETF has concluded that special treatment is needed, the operator for registries is currently ICANN.
IABは、IETFのプロトコルパラメーターレジストリの監視を提供し、適切なオペレーターと関連するレジストリごとの配置を選択する責任があります。特に、プロトコル間の関係が要求する場合、レジストリは他の組織によって、または他の組織と連携して操作されることがあります。 IABまたはIETFが特別な扱いが必要であると結論付けていない限り、レジストリのオペレーターは現在ICANNです。
>>>
>>> A description of the mechanism (e.g., contract, reporting
>>> scheme, auditing scheme, etc.). This should include a
>>> description of the consequences of the IANA functions operator
>>> not meeting the standards established by the mechanism, the
>>> extent to which the output of the mechanism is transparent and
>>> the terms under which the mechanism may change.
>>>
IETF Response:
IETF応答：
A memorandum of understanding (MoU) between ICANN and the IETF community has been in place since 2000. It can be found in [RFC2860]. The MoU defines the work to be carried out by the IANA functions operator for the IETF and the Internet Research Task Force (IRTF), a peer organization to the IETF that focuses on research.[RFC2014] Each year a service level agreement is negotiated that supplements the MoU.
ICANNとIETFコミュニティの間の了解覚書（MoU）は2000年以来実施されています。それは[RFC2860]で見つけることができます。 MoUは、IETFおよび研究に重点を置くIETFのピア組織であるInternet Research Task Force（IRTF）のIANA機能オペレーターによって実行される作業を定義します。[RFC2014]毎年、サービスレベル契約が交渉されます。覚書を補足します。
Day-to-day administration and contract management is the responsibility of the IETF Administrative Director (IAD). The IETF Administrative Oversight Committee (IAOC) oversees the IAD. The members of the IAOC are also the trustees of the IETF Trust, whose main purpose is to hold certain intellectual property for the benefit of the IETF as a whole. IAOC members are appointed by the Internet Society Board of Trustees, the IAB, the IESG, and the NOMCOM [RFC4071]. The IAOC works with the IANA functions operator to establish annual IANA performance metrics [METRICS] and operational procedures, and the resulting document is adopted as an supplement to the MoU each year [MOUSUP]. Starting from 2014, in accordance with these supplements, an annual audit is performed to ensure that protocol parameter requests are being processed according to the established policies. The conclusions of this audit will be available for anyone in the world to review.
日常の管理と契約管理は、IETF管理ディレクター（IAD）の責任です。 IETF管理監督委員会（IAOC）はIADを監督します。 IAOCのメンバーは、IETFトラストの受託者でもあります。その主な目的は、IETF全体の利益のために特定の知的財産を保持することです。 IAOCのメンバーは、インターネット協会理事会、IAB、IESG、およびNOMCOM [RFC4071]によって任命されます。 IAOCはIANA機能オペレーターと協力して、年次IANAパフォーマンスメトリック[METRICS]と運用手順を確立し、結果のドキュメントは毎年MoU [MOUSUP]の補足として採用されます。 2014年から、これらの補足に従って、プロトコルパラメータ要求が確立されたポリシーに従って処理されていることを確認するために年次監査が実行されます。この監査の結論は、世界中の誰でもレビューできるようになります。
To date there have been no unresolvable disputes or issues between the IETF and the current IANA functions operator. [RFC2860] specifies that should a technical dispute arise, "the IANA shall seek and follow technical guidance exclusively from the IESG." In the unlikely event that a more difficult situation should arise, the IAOC and the IAB would engage ICANN management to address the matter. The MoU also provides an option for either party to terminate the arrangement with six months notice. Obviously such action would only be undertaken after serious consideration. In that case a new IANA functions operator would be selected, and a new agreement with that operator would be established.
これまでに、IETFと現在のIANA機能オペレーターの間で解決できない論争や問題はありませんでした。 [RFC2860]は、技術的な論争が発生した場合に、「IANAはIESGからのみ技術的なガイダンスを求め、それに従うものとする」と明記しています。万一、より困難な状況が発生する必要がある場合、IAOCとIABはICANNの管理者に問題の対処を依頼します。 MoUはまた、いずれかの当事者が6か月前に通知をもって契約を終了するオプションを提供します。明らかに、そのような行動は真剣な検討の後にのみ行われるでしょう。その場合、新しいIANA機能オペレーターが選択され、そのオペレーターとの新しい合意が確立されます。
>>>
>>> Jurisdiction(s) in which the mechanism applies and the legal
>>> basis on which the mechanism rests.
>>>
IETF Response
IETF応答
This mechanism is global in nature. The current agreement does not specify a jurisdiction.
このメカニズムは本質的にグローバルです。現在の合意では、管轄は規定されていません。
>>>III. Proposed Post-Transition Oversight and Accountability
>>>Arrangements
>>>
>>> This section should describe what changes your community is
>>> proposing to the arrangements listed in Section II.B in light of
>>> the transition. If your community is proposing to replace one or
>>> more existing arrangements with new arrangements, that
>>> replacement should be explained and all of the elements listed
>>> in Section II.B should be described for the new
>>> arrangements. Your community should provide its rationale and
>>> justification for the new arrangements.
>>>
>>> If your community's proposal carries any implications for
>>> existing policy arrangements described in Section II.A, those
>>> implications should be described here.
>>>
>>> If your community is not proposing changes to arrangements
>>> listed in Section II.B, the rationale and justification for that
>>> choice should be provided here.
>>>
IETF Response:
IETF応答：
No new organizations or structures are required. Over the years since the creation of ICANN, the IETF, ICANN, and IAB have together created a system of agreements, policies, and oversight mechanisms that already cover what is needed. This system has worked well without any operational involvement from the NTIA.
新しい組織や構造は必要ありません。 ICANNの設立以来、長年にわたって、IETF、ICANN、およびIABは、必要なものをすでにカバーする合意、ポリシー、および監視メカニズムのシステムを共同で作成してきました。このシステムは、NTIAの運用に関与することなくうまく機能しています。
IANA protocol parameters registry updates will continue to function day-to-day, as they have been doing for the last decade or more. The IETF community is very satisfied with the current arrangement with ICANN. RFC 2860 remains in force and has served the IETF community very well. RFC 6220 has laid out an appropriate service description and requirements.
IANAプロトコルパラメータのレジストリの更新は、過去10年間以上行われているように、日々機能し続けます。 IETFコミュニティは、ICANNとの現在の取り決めに非常に満足しています。 RFC 2860は引き続き有効であり、IETFコミュニティに非常によく貢献しています。 RFC 6220は、適切なサービスの説明と要件を示しています。
However in the absence of the NTIA contract a few new arrangements may be needed in order to ensure the IETF community's expectations are met. Those expectations are the following:
ただし、NTIA契約がない場合は、IETFコミュニティの期待に応えるために、いくつかの新しい取り決めが必要になる場合があります。これらの期待は次のとおりです。
o The protocol parameters registries are in the public domain. It is the preference of the IETF community that all relevant parties acknowledge that fact as part of the transition.
o プロトコルパラメータレジストリはパブリックドメインにあります。すべての関係者が移行の一部としてその事実を認めるのは、IETFコミュニティの好みです。
o It is possible in the future that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledge that it will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition to subsequent operator(s), should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use the protocol parameters registries or other resources currently located at iana.org.
o プロトコルパラメータレジストリの操作がICANNから後続のオペレータに移行される可能性があります。 NTIA移行の一環として、ICANNがICANNとNTIAの間の現在のIANA機能契約のC.7.3およびI.61に基づいて確立された義務を履行することを認めることは、IETFコミュニティーの好みです[NTIA-Contract ]必要に応じて、後続の演算子にスムーズに移行するため。さらに、移行が発生した場合、ICANN、IETF、および後続のオペレーターが協力して、現在iana.orgにあるプロトコルパラメーターレジストリまたはその他のリソースの使用の中断を最小限に抑えることがIETFコミュニティの期待です。
In developing our response we have been mindful of the following points that the IETF community has discussed over the last year [ProtoParamEvo14] that have led to the following guiding principles for IAB efforts that impact IANA protocol parameter registries. These principles must be taken together; their order is not significant.
私たちの対応を展開する際、私たちはIETFコミュニティが昨年[ProtoParamEvo14]で議論した次の点に注意して、IANAプロトコルパラメータレジストリに影響を与えるIABの取り組みに関する以下の指針を導きました。これらの原則は一緒に取られなければなりません。それらの順序は重要ではありません。
1. The IETF protocol parameters registries function has been and continues to be capably provided by the Internet technical community.
1. IETFプロトコルパラメータのレジストリ機能は、インターネット技術コミュニティから提供されてきました。
The strength and stability of the function and its foundation within the Internet technical community are both important given how critical protocol parameters are to the proper functioning of IETF protocols.
IETFプロトコルの適切な機能に対するプロトコルパラメータの重要性を考えると、機能の強さと安定性、およびインターネット技術コミュニティ内でのその基盤はどちらも重要です。
We think the structures that sustain the protocol parameters registries function need to be strong enough that they can be offered independently by the Internet technical community, without the need for backing from external parties. And we believe we largely are there already, although the system can be strengthened further, and continuous improvements are being made.
プロトコルパラメータのレジストリ機能を維持する構造は、外部の関係者からの支援がなくても、インターネット技術コミュニティが独自に提供できるほど強力である必要があると考えています。また、システムはさらに強化でき、継続的な改善が行われていますが、ほぼすでに存在していると考えています。
2. The protocol parameters registries function requires openness, transparency, and accountability.
2. プロトコルパラメータレジストリ機能には、開放性、透明性、および説明責任が必要です。
Existing documentation of how the function is administered and overseen is good [RFC2860], [RFC6220]. Further articulation and clarity may be beneficial. It is important that the whole Internet community can understand how the function works, and that the processes for registering parameters and holding those who oversee the protocol parameters function accountable for following those processes are understood by all interested parties. We are committed to making improvements here if necessary.
関数の管理方法と監視方法に関する既存のドキュメントは適切です[RFC2860]、[RFC6220]。さらに明瞭度と明快さは有益かもしれません。インターネットコミュニティ全体がその機能の仕組みを理解できること、およびパラメータを登録し、プロトコルパラメータを監視する人がそれらのプロセスに従う責任を負うためのプロセスが、すべての関係者に理解されていることが重要です。必要に応じて、ここで改善に取り組んでいます。
3. Any contemplated changes to the protocol parameters registries function should respect existing Internet community agreements.
3. プロトコルパラメータのレジストリ機能への変更は、既存のインターネットコミュニティの合意を尊重する必要があります。
The protocol parameters registries function is working well. The existing Memorandum of Understanding in RFC 2860 defines "the technical work to be carried out by the Internet Assigned Numbers Authority on behalf of the Internet Engineering Task Force and the Internet Research Task Force." Any modifications to the protocol parameters registries function should be made using the IETF process to update RFC 6220 and other relevant RFCs. Put quite simply: evolution, not revolution.
プロトコルパラメータのレジストリ機能は正常に動作しています。 RFC 2860の既存の了解覚書では、「インターネット技術特別調査委員会およびインターネット調査特別調査委員会に代わってインターネット割当番号局が実施する技術作業」を定義しています。プロトコルパラメータレジストリ機能の変更は、IETFプロセスを使用してRFC 6220およびその他の関連RFCを更新する必要があります。簡単に言えば、革命ではなく進化です。
4. The Internet architecture requires and receives capable service by Internet registries.
4. インターネットアーキテクチャは、インターネットレジストリによる有能なサービスを必要とし、受け取ります。
The stability of the Internet depends on capable provision of not just IETF protocol parameters, but IP numbers, domain names, and other registries. Furthermore, DNS and IPv4/IPv6 are IETF-defined protocols. Thus we expect the role of the IETF in standards development, architectural guidance, and allocation of certain name/ number parameters to continue. IP multicast addresses and special-use DNS names are two examples where close coordination is needed. The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries. We fully understand the need to work together.
インターネットの安定性は、IETFプロトコルパラメータだけでなく、IP番号、ドメイン名、およびその他のレジストリの機能の提供にも依存しています。さらに、DNSおよびIPv4 / IPv6はIETF定義のプロトコルです。したがって、標準の開発、アーキテクチャガイダンス、および特定の名前/番号パラメータの割り当てにおけるIETFの役割が続くことを期待しています。 IPマルチキャストアドレスと特殊用途DNS名は、緊密な調整が必要な2つの例です。 IETFは、引き続きICANN、RIR、およびインターネットレジストリの継続的な円滑な運用に相互に投資している他の関係者と調整します。私たちは協力する必要性を完全に理解しています。
5. The IETF will continue management of the protocol parameter registry function as an integral component of the IETF standards process and the use of resulting protocols.
5. IETFは、IETF標準プロセスの不可欠なコンポーネントとしてのプロトコルパラメータレジストリ機能の管理と、結果として得られるプロトコルの使用を継続します。
RFC 6220 specifies the role and function of the protocol parameters registry, which is critical to IETF standards processes and IETF protocols. The IAB, on behalf of the IETF, has the responsibility to define and manage the relationship with the protocol registry operator role. This responsibility includes the selection and management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation.
RFC 6220は、プロトコルパラメータレジストリの役割と機能を指定しています。これは、IETF標準プロセスとIETFプロトコルに不可欠です。 IABは、IETFに代わって、プロトコルレジストリオペレーターの役割との関係を定義および管理する責任があります。この責任には、プロトコルパラメーターレジストリオペレーターの選択と管理、およびパラメーター登録プロセスの管理とパラメーター割り当てのガイドラインが含まれます。
6. The protocol parameters registries are provided as a public service.
6. プロトコルパラメータレジストリは、パブリックサービスとして提供されます。
Directions for the creation of protocol parameters registries and the policies for subsequent additions and updates are specified in RFCs. The protocol parameters registries are available to everyone, and they are published in a form that allows their contents to be included in other works without further permission. These works include, but are not limited to, implementations of Internet protocols and their associated documentation.
プロトコルパラメータレジストリの作成方法、およびその後の追加と更新のポリシーは、RFCで指定されています。プロトコル・パラメーター・レジストリーは誰でも使用でき、それらのコンテンツをそれ以上の許可なしに他の作品に組み込むことができる形式で公開されます。これらの著作物には、インターネットプロトコルの実装とそれに関連するドキュメントが含まれますが、これらに限定されません。
These principles will guide the IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures.
これらの原則は、IAN、IAOC、およびその他のIETFコミュニティがICANNと協力して将来のIANAパフォーマンスメトリックおよび運用手順を確立する際の指針となります。
>>> IV Transition Implications
>>>
>>> This section should describe what your community views as the
>>> implications of the changes it proposed in Section III. These
>>> implications may include some or all of the following, or other
>>> implications specific to your community:
>>>
>>> o Description of operational requirements to achieve continuity
>>> of service and possible new service integration throughout
>>> the transition.
>>> o Risks to operational continuity
>>> o Description of any legal framework requirements in the
>>> absence of the NTIA contract
>>> o Description of how you have tested or evaluated the
>>> workability of any new technical or operational methods
>>> proposed in this document and how they compare to established
>>> arrangements.
>>>
IETF Response:
IETF応答：
No structural changes are required for the handling of protocol parameters. The principles listed above will guide IAB, IAOC, and the rest of the IETF community as they work with ICANN to establish future IANA performance metrics and operational procedures, as they have in the past.
プロトコルパラメータの処理に構造上の変更は必要ありません。上記の原則は、IAN、IAOC、およびその他のIETFコミュニティがICANNと協力して、過去と同様に将来のIANAパフォーマンスメトリックと運用手順を確立する際の指針となります。
As no services are expected to change, no continuity issues are anticipated, and there are no new technical or operational methods proposed by the IETF to test. The IETF leadership, ICANN, and the RIRs maintain an ongoing informal dialog to spot any unforeseen issues that might arise as a result of other changes.
サービスの変更は予期されていないため、継続性の問題は予期されておらず、テストするためにIETFによって提案された新しい技術的または運用的な方法はありません。 IETFのリーダーシップ、ICANN、およびRIRは、進行中の非公式な対話を維持して、他の変更の結果として発生する可能性のある予期しない問題を発見します。
What is necessary as part of transition is the completion of any supplemental agreement(s) necessary to achieve the requirements outlined in our response in Section III of this RFP.
移行の一部として必要なのは、このRFPのセクションIIIの対応で概説されている要件を達成するために必要な補足契約の完了です。
>>>
>>> V. NTIA Requirements
>>>
>>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements:
>>>
>>> "Support and enhance the multistakeholder model;"
>>>
IETF Response:
IETF応答：
Because the IETF is open to everyone, participation is open to all stakeholders. IETF processes outlined in Section I were used to develop this proposal. Those same processes have been and shall be used to amend governance of the protocol parameters function. As mentioned previously, anyone may propose amendments to those processes, and anyone may take part in the decision process.
IETFは誰でも参加できるため、すべての関係者が参加できます。セクションIで概説したIETFプロセスは、この提案を作成するために使用されました。これらと同じプロセスが、プロトコルパラメータ機能のガバナンスを修正するために使用されてきました。前述のように、誰もがそれらのプロセスの修正を提案でき、誰もが決定プロセスに参加できます。
>>>
>>> "Maintain the security, stability, and resiliency of the
>>> Internet DNS;"
>>>
IETF Response:
IETF応答：
No changes are proposed in this document that affect the security, stability, and resiliency of the DNS.
このドキュメントでは、DNSのセキュリティ、安定性、および復元力に影響を与える変更は提案されていません。
>>>
>>> "Meet the needs and expectation of the global customers and
>>> partners of the IANA services;"
>>>
IETF Response:
IETF応答：
Implementers and their users from around the world make use of the IETF standards and the associated IANA protocol parameters registries. The current IANA protocol parameters registries system is meeting the needs of these global customers. This proposal continues to meet their needs by maintaining the existing processes that have served them well in the past.
世界中の実装者とそのユーザーは、IETF標準と関連するIANAプロトコルパラメータレジストリを利用します。現在のIANAプロトコルパラメータレジストリシステムは、これらのグローバルな顧客のニーズを満たしています。この提案は、過去に役立ってきた既存のプロセスを維持することにより、引き続き彼らのニーズを満たします。
>>>
>>>
>>> "Maintain the openness of the Internet."
>>>
IETF Response:
IETF応答：
This proposal maintains the existing open framework that allows anyone to participate in the development of IETF standards, including the IANA protocol parameters registries policies. Further, an implementer anywhere in the world has full access to the protocol specification published in the RFC series and the protocol parameters registries published at iana.org. Those who require assignments in the IANA protocol registries will continue to have their requests satisfied, as specified by the existing policies for those registries.
この提案は、IANAプロトコルパラメータレジストリポリシーを含むIETF標準の開発に誰でも参加できる既存のオープンフレームワークを維持します。さらに、世界中の実装者は、RFCシリーズで公開されているプロトコル仕様とiana.orgで公開されているプロトコルパラメータレジストリに完全にアクセスできます。 IANAプロトコルレジストリでの割り当てを必要とするユーザーは、それらのレジストリの既存のポリシーで指定されているように、引き続き要求を満たします。
>>>
>>> "The proposal must not replace the NTIA role with a
>>> government-led or an inter-governmental organization solution."
>>>
Policy oversight is performed by the IAB, which is neither a government-led or an intergovernmental organization.
政策監視は、政府主導の組織でも政府間組織でもないIABによって実行されます。
>>>
>>> VI. Community Process
>>>
>>> This section should describe the process your community used for
>>> developing this proposal, including:
>>>
>>> o The steps that were taken to develop the proposal and to
>>> determine consensus.
>>>
IETF Response:
IETF応答：
The IESG established the IANAPLAN working group to develop this response. Anyone was welcome to join the discussion and participate in the development of this response. An open mailing list (ianaplan@ietf.org) has been associated with the working group. In addition, IETF's IANA practices have been discussed in the broader community, and all input has been welcome. Normal IETF procedures
IESGは、この対応を展開するためにIANAPLANワーキンググループを設立しました。だれでもこのディスカッションに参加して、この応答の開発に参加することができました。オープンメーリングリスト（ianaplan@ietf.org）がワーキンググループに関連付けられています。さらに、IETFのIANAの慣行はより広範なコミュニティで議論されており、すべての意見を歓迎しています。通常のIETF手順
[RFC2026] [RFC2418] were used to determine rough consensus. The chairs of the working group reviewed open issues and, after an internal working group last call, determined that all had been satisfactorily addressed, and subsequently the IESG did a formal IETF-wide Last Call followed by a formal review and determined that the document had rough consensus.
[RFC2026] [RFC2418]は、大まかなコンセンサスを決定するために使用されました。ワーキンググループの議長は未解決の問題を検討し、内部ワーキンググループの最後の電話の後、すべてが問題なく対処されたと判断し、その後IESGが正式なIETF全体の最後の電話を行った後、正式なレビューを行い、文書に大まかなコンセンサス。
>>>
>>> Links to announcements, agendas, mailing lists, consultations and
>>> meeting proceedings.
>>>
IETF Response:
IETF応答：
The following list is not exhaustive, as there have been many open discussions about this transition within the IETF community in the past few months.
以下のリストは、過去数か月の間にIETFコミュニティ内でこの移行について多くのオープンな議論があったため、完全ではありません。
Creation of an open mailing list to discuss the transition:
http://mailarchive.ietf.org/arch/msg/ietf-announce/
Ztd2ed9U04qSxI-k9-Oj80jJLXc
Announcement of a public session on the transition:
http://mailarchive.ietf.org/arch/msg/ietf-announce/
M5zVmFFvTbtgVyMB_fjUSW4rJ0c
Announcement by the IESG of the intent to form a working group:
http://mailarchive.ietf.org/arch/msg/ietf-announce/
QsvU9qX98G2KqB18jy6UfhwKjXk
The working group discussion:
http://www.ietf.org/mail-archive/web/ianaplan/current/
maillist.html
2014-10-06 Interim Meeting Agenda, Minutes, and presentations:
http://www.ietf.org/proceedings/interim/2014/10/06/ianaplan/
proceedings.html
Working group last call:
http://mailarchive.ietf.org/arch/msg/ianaplan/
EGF9rfJxn5QpQnRXmS2QxYKYR8k
Agenda from IETF 91 IANAPLAN WG meeting:
http://www.ietf.org/proceedings/91/agenda/agenda-91-ianaplan
Minutes of IETF 91 IANAPLAN WG meeting:
http://www.ietf.org/proceedings/91/minutes/minutes-91-ianaplan
Shepherd write-up:
http://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
shepherdwriteup/
IETF last call:
http://mailarchive.ietf.org/arch/msg/ietf-announce/
i5rx6PfjJCRax3Lu4qZ_38P8wBg
>>>
>>> An assessment of the level of consensus behind your community's
>>> proposal, including a description of areas of contention or
>>> disagreement.
>>>
IETF Response:
IETF応答：
This document has attained rough consensus of the IETF Working Group and of the IETF community as a whole, as judged first by the working group chairs and then by the sponsoring Area Director, and then by the IESG in accordance with [RFC2026] during the 18 December 2014 IESG telechat. The IESG has approved the draft, pending insertion of this answer in this section and the IAB approval note. The IAB approved a statement for inclusion in the document on 19 December 2014.
この文書は、IETFワーキンググループとIETFコミュニティ全体の大まかなコンセンサスを獲得しました。最初にワーキンググループチェア、次にスポンサーエリアディレクター、次に[RFC2026]に従ってIESGが18 2014年12月のIESGテレチャット。 IESGは草案を承認しました。このセクションへの回答とIAB承認メモの挿入は保留されています。 IABは、2014年12月19日に文書に含めるための声明を承認しました。
Over the course of the development of the document, several suggestions were raised that did not enjoy sufficient support to be included. Two general areas of suggestion that generated much discussion were
このドキュメントの作成過程で、十分なサポートが含まれていない提案がいくつか出されました。多くの議論を引き起こした提案の2つの一般的な分野は
o A suggestion for a stronger statement over what terms the IAOC should negotiate.
o IAOCが交渉すべき条件についてのより強力な声明の提案。
o A suggestion that "iana.org" and other associated marks be transferred to the IETF trust.
o 「iana.org」およびその他の関連マークをIETFトラストに譲渡することを提案します。
At the end of the working group process, although there was not unanimous support for the results, the working group chairs concluded that rough consensus existed in the working group. The document shepherd's summary of the WG consensus for this document can be found here:
ワーキンググループプロセスの最後に、結果に対する全会一致のサポートはありませんでしたが、ワーキンググループの議長は、ワーキンググループに大まかなコンセンサスが存在すると結論付けました。このドキュメントに関するWGコンセンサスのドキュメントシェパードの概要は、次の場所にあります。
https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
shepherdwriteup/
During IETF last call, additional people voiced support for the document. There were several editorial comments that resulted in changes, as well as some discussion of more substantial comments some of which resulted in text changes. There was some discussion of comments already discussed earlier in the process, and but no new objections were raised during the IETF last call. A summary of the last call comments can be found from here:
IETFの最後の電話中に、追加の人々が文書のサポートを表明しました。変更をもたらした編集上のコメントがいくつかあり、テキストの変更をもたらしたより重要なコメントについての議論もありました。プロセスの早い段階ですでに議論されたコメントについてのいくつかの議論がありましたが、IETFの最後の呼び出し中に新しい異議は提起されませんでした。最後の呼び出しのコメントの要約はここから見つけることができます：
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html
New draft versions were prepared that took into account all the agreed changes from the last call. The final version was then approved by the IESG.
前回の電話から合意されたすべての変更を考慮した新しいドラフトバージョンが準備されました。その後、最終バージョンはIESGによって承認されました。
This memo is a response to a request for proposals. No parameter allocations or changes are sought.
このメモは、提案の要求に対する応答です。パラメータの割り当てや変更は必要ありません。
While the agreement, supplements, policies, and procedures around the IANA function have shown strong resiliency, the IETF will continue to work with all relevant parties to facilitate improvements while maintaining availability of the IANA registries.
IANA機能に関する合意、補足、ポリシー、および手順は強力な弾力性を示していますが、IETFは引き続きIANAレジストリの可用性を維持しながら、改善を促進するためにすべての関係者と協力します。
The IAB supports the response in this document.
IABは、このドキュメントの応答をサポートしています。
This document describes processes that have been developed by many members of the community over many years. The initial version of this document was developed collaboratively through both the IAB IANA Strategy Program and the IETF IANAPLAN WG. Particular thanks go to Jari Arkko, Marc Blanchet, Brian Carpenter, Alissa Cooper, John Curran, Leslie Daigle, Heather Flanagan, Christer Holmberg, John Klensin, Barry Leiba, Milton Mueller, Andrei Robachevsky, Andrew Sullivan, Dave Thaler, Greg Wood, and Suzanne Woolf.
このドキュメントでは、コミュニティの多くのメンバーが長年にわたって開発してきたプロセスについて説明します。このドキュメントの最初のバージョンは、IAB IANA戦略プログラムとIETF IANAPLAN WGの両方を通じて共同で開発されました。特に、Jari Arkko、Marc Blanchet、Brian Carpenter、Alissa Cooper、John Curran、Leslie Daigle、Heather Flanagan、Christer Holmberg、John Klensin、Barry Leiba、Milton Mueller、Andrei Robachevsky、Andrew Sullivan、Dave Thaler、Greg Wood、スザンヌ・ウルフ。
[BCP9info] "Information on "The Internet Standards Process -- Revision 3"", <http://www.rfc-editor.org/info/rfc2026>.
[BCP9info]「「インターネット標準プロセス-リビジョン3」に関する情報」、<http://www.rfc-editor.org/info/rfc2026>。
[METRICS] IANA, "Performance Standards Metrics Report", <http://www.iana.org/performance/metrics>.
[METRICS] IANA、「Performance Standards Metrics Report」、<http://www.iana.org/performance/metrics>。
[MOUSUP] IAOC, "Supplements to RFC 2860 (the Memorandum of Understanding between the IETF and ICANN)", <http://iaoc.ietf.org/contracts.html>.
[MOUSUP] IAOC、「RFC 2860の補足（IETFとICANNの間の覚書）」、<http://iaoc.ietf.org/contracts.html>。
[NTIA-Announce] NTIA, "NTIA Announces Intent to Transition Key Internet Domain Name Functions", March 2014, <http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions>.
[NTIA-Announce] NTIA、「NTIAが主要なインターネットドメイン名機能を移行する意図を発表」、2014年3月、<http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition- key-internet-domain-name-functions>。
[NTIA-Contract] NTIA, "The NTIA Contract with ICANN", <http://www.ntia.doc.gov/files/ntia/publications/ sf_26_pg_1-2-final_award_and_sacs.pdf>.
[NTIA-契約] NTIA、「ICANNとのNTIA契約」、<http://www.ntia.doc.gov/files/ntia/publications/ sf_26_pg_1-2-final_award_and_sacs.pdf>。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>.
[RFC2026] Bradner、S。、「The Internet Standards Process-Revision 3」、BCP 9、RFC 2026、DOI 10.17487 / RFC2026、1996年10月、<http://www.rfc-editor.org/info/rfc2026> 。
[RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418, September 1998, <http://www.rfc-editor.org/info/rfc2418>.
[RFC2418] Bradner、S。、「IETF Working Group Guidelines and Procedures」、BCP 25、RFC 2418、DOI 10.17487 / RFC2418、1998年9月、<http://www.rfc-editor.org/info/rfc2418>。
[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, <http://www.rfc-editor.org/info/rfc2850>.
[RFC2850]インターネットアーキテクチャボードおよびB.カーペンター編、「インターネットアーキテクチャボード（IAB）のチャーター」、BCP 39、RFC 2850、DOI 10.17487 / RFC2850、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, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.
[RFC2860] Carpenter、B.、Baker、F。、およびM. Roberts、「Internet Assigned Numbers Authorityの技術的作業に関する覚書」、RFC 2860、DOI 10.17487 / RFC2860、2000年6月、<http：// www.rfc-editor.org/info/rfc2860>。
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <http://www.rfc-editor.org/info/rfc3307>.
[RFC3307] Haberman、B。、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、DOI 10.17487 / RFC3307、2002年8月、<http://www.rfc-editor.org/info/rfc3307>。
[RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", RFC 3777, DOI 10.17487/RFC3777, June 2004, <http://www.rfc-editor.org/info/rfc3777>.
[RFC3777] Galvin、J。、編、「IABおよびIESGの選択、確認、およびリコールプロセス：指名委員会およびリコール委員会の運営」、RFC 3777、DOI 10.17487 / RFC3777、2004年6月、<http：// www。 rfc-editor.org/info/rfc3777>。
[RFC3935] Alvestrand, H., "A Mission Statement for the IETF", BCP 95, RFC 3935, DOI 10.17487/RFC3935, October 2004, <http://www.rfc-editor.org/info/rfc3935>.
[RFC3935] Alvestrand、H。、「IETFのミッションステートメント」、BCP 95、RFC 3935、DOI 10.17487 / RFC3935、2004年10月、<http://www.rfc-editor.org/info/rfc3935>。
[RFC4071] Austein, R., Ed. and B. Wijnen, Ed., "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, DOI 10.17487/RFC4071, April 2005, <http://www.rfc-editor.org/info/rfc4071>.
[RFC4071]オースタイン、R。、エド。およびB. Wijnen編、「IETF管理サポート活動（IASA）の構造」、BCP 101、RFC 4071、DOI 10.17487 / RFC4071、2005年4月、<http://www.rfc-editor.org/info/ rfc4071>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.
[RFC5771]コットン、M。、ベゴダ、L。、およびD.マイヤー、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、DOI 10.17487 / RFC5771、2010年3月、<http：//www.rfc -editor.org/info/rfc5771>。
[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, <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、DOI 10.17487 / RFC6220、2011年4月、<http://www.rfc-editor.org/info/rfc6220>。
[RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, <http://www.rfc-editor.org/info/rfc6761>.
[RFC6761] Cheshire、S。およびM. Krochmal、「特殊用途ドメイン名」、RFC 6761、DOI 10.17487 / RFC6761、2013年2月、<http://www.rfc-editor.org/info/rfc6761>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、エド、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、DOI 10.17487 / RFC6890、2013年4月、< http://www.rfc-editor.org/info/rfc6890>。
[RFC7282] Resnick, P., "On Consensus and Humming in the IETF", RFC 7282, DOI 10.17487/RFC7282, June 2014, <http://www.rfc-editor.org/info/rfc7282>.
[RFC7282] Resnick、P。、「IETFにおける合意とハミングについて」、RFC 7282、DOI 10.17487 / RFC7282、2014年6月、<http://www.rfc-editor.org/info/rfc7282>。
[I-D.leiba-cotton-iana-5226bis] Cotton, M., Leiba, B., and D. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", Work in Progress, draft-leiba-cotton-iana-5226bis-17, July 2016.
[ID.leiba-cotton-iana-5226bis] Cotton、M.、Leiba、B。、およびD. Narten、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、作業中、draft-leiba-cotton-iana- 5226bis-17、2016年7月。
[ICG-Response] IANA Stewardship Transition Coordination Group, "Proposal to Transition the Stewardship of the Internet Assigned Numbers Authority (IANA) Functions from the U.S. Commerce Department's National Telecommunications and Information Administration (NTIA) to the Global Multistakeholder Community", 11 March 2016, <https://www.icann.org/en/system/files/files/ iana-stewardship-transition-proposal-10mar16-en.pdf>.
[ICG-Response] IANA Stewardship Transition Coordination Group、「Promotional to Transition the Stewardship of the Internet Assigned Numbers Authority（IANA）Functions from the US Commerce Department's National Telecommunications and Information Administration（NTIA）to the Global Multistakeholder Community」、2016年3月11日、<https://www.icann.org/en/system/files/files/ iana-stewardship-transition-proposal-10mar16-en.pdf>。
[ProtoParamEvo14] IAB Chair, "Subject: Re: [Internetgovtech] Guiding the Evolution of the IANA Protocol Parameter Registries", March 2014, <http://mailarchive.ietf.org/arch/msg/ internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>.
[ProtoParamEvo14] IAB議長、「件名：Re：[Internetgovtech] IANAプロトコルパラメータレジストリの進化の指針」、2014年3月、<http://mailarchive.ietf.org/arch/msg/internetgovtech/4EQ4bnEfE5ZkrPAtSAO2OBZM03k>。
[RFC-INDEX] RFC Editor, "RFC Index", <http://www.rfc-editor.org/rfc/rfc-index.txt>.
[RFC-INDEX] RFC Editor、「RFC Index」、<http://www.rfc-editor.org/rfc/rfc-index.txt>。
[RFC2014] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, October 1996, <http://www.rfc-editor.org/info/rfc2014>.
[RFC2014] Weinrib、A。およびJ. Postel、「IRTF Research Group Guidelines and Procedures」、BCP 8、RFC 2014、DOI 10.17487 / RFC2014、1996年10月、<http://www.rfc-editor.org/info/ rfc2014>。
[RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root Name Server Operational Requirements", RFC 2870, DOI 10.17487/RFC2870, June 2000, <http://www.rfc-editor.org/info/rfc2870>.
[RFC2870] Bush、R.、Karrenberg、D.、Kosters、M.、and R. Plzak、 "Root Name Server Operational Requirements"、RFC 2870、DOI 10.17487 / RFC2870、June 2000、<http：//www.rfc -editor.org/info/rfc2870>。
[RFC3172] Huston, G., Ed., "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172, September 2001, <http://www.rfc-editor.org/info/rfc3172>.
[RFC3172] Huston、G。、編、「アドレスおよびルーティングパラメータエリアドメイン（ "arpa"）の管理ガイドラインおよび運用要件」、BCP 52、RFC 3172、DOI 10.17487 / RFC3172、2001年9月、<http：/ /www.rfc-editor.org/info/rfc3172>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、DOI 10.17487 / RFC4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.
[RFC6793] Vohra、Q。およびE. Chen、「BGP Support for Four-Octet Autonomous System（AS）Number Space」、RFC 6793、DOI 10.17487 / RFC6793、2012年12月、<http：//www.rfc-editor。 org / info / rfc6793>。
[RFC6852] Housley, R., Mills, S., Jaffe, J., Aboba, B., and L. St.Amour, "Affirmation of the Modern Paradigm for Standards", RFC 6852, DOI 10.17487/RFC6852, January 2013, <http://www.rfc-editor.org/info/rfc6852>.
[RFC6852] Housley、R.、Mills、S.、Jaffe、J.、Aboba、B。、およびL. St.Amour、「Affirmation of the Modern Paradigm for Standards」、RFC 6852、DOI 10.17487 / RFC6852、2013年1月、<http://www.rfc-editor.org/info/rfc6852>。
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, 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、DOI 10.17487 / RFC7020、2013年8月、<http：//www.rfc -editor.org/info/rfc7020>。
[RFC7249] Housley, R., "Internet Numbers Registries", RFC 7249, DOI 10.17487/RFC7249, May 2014, <http://www.rfc-editor.org/info/rfc7249>.
[RFC7249] Housley、R。、「インターネット番号レジストリ」、RFC 7249、DOI 10.17487 / RFC7249、2014年5月、<http://www.rfc-editor.org/info/rfc7249>。
Appendix A. The Charter of the IANA Stewardship Coordination Group (ICG)
付録A. IANAスチュワードシップ調整グループ（ICG）の憲章
Charter for the IANA Stewardship Transition Coordination Group V.10
IANAスチュワードシップ移行調整グループV.10の憲章
(August 27, 2014)
（2014年8月27日）
The IANA stewardship transition coordination group (ICG) has one deliverable: a proposal to the U.S. Commerce Department National Telecommunications and Information Administration (NTIA) regarding the transition of NTIA's stewardship of the IANA functions to the global multi-stakeholder community. The group will conduct itself transparently, consult with a broad range of stakeholders, and ensure that its proposals support the security and stability of the IANA functions.
IANAスチュワードシップ移行調整グループ（ICG）には1つの成果物があります。NTIAのIANAスチュワードシップのグローバルなマルチステークホルダーコミュニティへの移行に関する米国商務省のNational Telecommunications and Information Administration（NTIA）への提案です。グループは透明性を持って行動し、幅広い利害関係者と協議し、その提案がIANA機能のセキュリティと安定性をサポートするようにします。
The group's mission is to coordinate the development of a proposal among the communities affected by the IANA functions. The IANA functions are divided into three main categories: domain names, number resources, and other protocol parameters. The domain names category falls further into the country code and generic domain name sub-categories. While there is some overlap among all of these categories, each poses distinct organizational, operational and technical issues, and each tends to have distinct communities of interest and expertise. For those reasons it is best to have work on the three categories of IANA parameters proceed autonomously in parallel and be based in the respective communities.
グループの使命は、IANA機能の影響を受けるコミュニティの間で提案の展開を調整することです。 IANA機能は、ドメイン名、リソース数、その他のプロトコルパラメータという3つの主要なカテゴリに分類されます。ドメイン名のカテゴリは、国コードと一般的なドメイン名のサブカテゴリにさらに分類されます。これらすべてのカテゴリにはいくつかの重複がありますが、それぞれに明確な組織的、運用上、および技術的な問題があり、それぞれに興味と専門知識の異なるコミュニティが存在する傾向があります。これらの理由から、IANAパラメータの3つのカテゴリで作業を自律的に並行して進め、それぞれのコミュニティをベースにすることが最善です。
The IANA stewardship transition process is taking place alongside a parallel and related process on enhancing ICANN accountability. While maintaining the accountability of Internet identifier governance is central to both processes, this group's scope is focused on the arrangements required for the continuance of IANA functions in an accountable and widely accepted manner after the expiry of the NTIA-ICANN contract. Nevertheless, the two processes are interrelated and interdependent and should appropriately coordinate their work.
IANAのスチュワードシップ移行プロセスは、ICANNの説明責任を強化するための並行する関連プロセスと並行して行われています。インターネット識別子ガバナンスの説明責任を維持することは両方のプロセスの中心ですが、このグループの範囲は、NTIA-ICANN契約の満了後、説明責任があり広く受け入れられている方法でIANA機能を継続するために必要な手配に焦点を当てています。それにもかかわらず、2つのプロセスは相互に関連し、相互に依存しており、それらの作業を適切に調整する必要があります。
The coordination group has four main tasks: (i) Act as liaison to all interested parties, including the three "operational communities" (i.e., those with direct operational or service relationship with IANA; namely names, numbers, protocol parameters). This task consists of: a. Soliciting proposals from the operational communities b. Soliciting the input of the broad group of communities affected by the IANA functions (ii) Assess the outputs of the three operational communities for compatibility and interoperability
調整グループには、4つの主なタスクがあります。（i）3つの「運用コミュニティ」（つまり、IANAと直接運用またはサービス関係にあるコミュニティ、つまり名前、番号、プロトコルパラメータ）を含む、すべての利害関係者との連絡役を務めます。このタスクは以下で構成されています。運用コミュニティからの提案の募集b。 IANA機能の影響を受けるコミュニティの幅広いグループのインプットを要請する（ii）互換性と相互運用性について3つの運用コミュニティのアウトプットを評価する
(iii) Assemble a complete proposal for the transition (iv) Information sharing and public communication Describing each in more detail: (i) Liaison a. Solicit proposals
（iii）移行のための完全な提案を組み立てます。（iv）情報の共有とパブリックコミュニケーションそれぞれを詳細に説明します。（i）リエゾンa。勧誘提案
The ICG expects a plan from the country code and generic name communities (possibly a joint one), a plan from the numbers community, and a plan from the protocol parameters community. Members of the ICG will ensure that the communities from which they are drawn are working on their part of the transition plans. This involves informing them of requirements and schedules, tracking progress, and highlighting the results or remaining issues. The role of a coordination group member during this phase is to provide status updates about the progress of his or her community in developing their component, and to coordinate which community will develop a transition proposal for each area of overlap (e.g., special-use registry).
ICGは、国コードと一般名のコミュニティ（おそらく共同コミュニティ）からの計画、番号コミュニティからの計画、プロトコルパラメータコミュニティからの計画を期待しています。 ICGのメンバーは、出身地であるコミュニティが移行計画の一部に取り組んでいることを確認します。これには、要件とスケジュールの通知、進行状況の追跡、結果または残りの問題の強調表示が含まれます。このフェーズでの調整グループメンバーの役割は、コンポーネントの開発におけるコミュニティの進捗状況に関する最新情報を提供し、どのコミュニティが重複の各領域（例：特殊用途レジストリ）の移行提案を作成するかを調整することです）。
While working on the development of their proposals, the operational communities are expected to address common requirements and issues relating to the transition, in as far as they affect their parts of the stewardship of IANA functions.
運用コミュニティは、提案の開発に取り組んでいる間、IANA機能の管理の一部に影響を与える限り、移行に関連する一般的な要件と問題に対処することが期待されます。
b. Solicit broader input
b. 幅広い入力を要求する
The ICG is open for input and feedback from all interested parties. While no set of formal requirements related to a transition proposal will be requested outside the operational communities, everyone's input is welcome across all topics.
ICGは、すべての利害関係者からの入力とフィードバックを受け付けています。移行提案に関連する正式な要件のセットが運用コミュニティの外部に要求されることはありませんが、すべてのトピックにわたって全員の意見を歓迎します。
The ICG expects that all interested parties get involved as early as possible in the relevant community processes. Input received directly by the ICG may be referred to the relevant community discussion.
ICGは、すべての利害関係者が関連するコミュニティプロセスにできるだけ早く関与することを期待しています。 ICGが直接受け取った入力は、関連するコミュニティディスカッションで参照できます。
The ICG members chosen from a particular community are the official communication channel between the ICG and that community.
特定のコミュニティから選ばれたICGメンバーは、ICGとそのコミュニティ間の公式のコミュニケーションチャネルです。
(ii) Assessment
（ii）評価
When the group receives output from the communities it will discuss and assess their compatibility and interoperability with the proposals of the other communities. Each proposal should be submitted with a clear record of how consensus has been reached for the proposal in the community, and provide an analysis that shows the proposal is in practice workable. The ICG should also compile the input it has received beyond the operational communities, and review the impacts of this input.
グループがコミュニティから出力を受け取ると、他のコミュニティの提案との互換性と相互運用性について話し合い、評価します。各プロポーザルは、コミュニティでのプロポーザルのコンセンサスに達した方法の明確な記録とともに提出し、プロポーザルが実際に実行可能であることを示す分析を提供する必要があります。 ICGはまた、運用コミュニティを超えて受け取ったインプットをまとめ、このインプットの影響を検討する必要があります。
The ICG might at some point detect problems with the component proposals. At that point the role of the ICG is to communicate that back to the relevant communities so that they (the relevant communities) can address the issues. It is not in the role of the ICG to develop proposals or to select from among competing proposals.
ICGは、ある時点でコンポーネントの提案に関する問題を検出する可能性があります。その時点で、ICGの役割は、それを関連コミュニティに伝えて、彼ら（関連コミュニティ）が問題に対処できるようにすることです。提案を作成したり、競合する提案の中から選択したりすることは、ICGの役割ではありません。
(iii) Assembling and submitting a complete proposal
（iii）完全なプロポーザルを組み立てて提出する
The assembly effort involves taking the proposals for the different components and verifying that the whole fulfills the intended scope, meets the intended criteria, that there are no missing parts, and that the whole fits together. The whole also needs to include sufficient independent accountability mechanisms for running the IANA function. The ICG will then develop a draft final proposal that achieves rough consensus within the ICG itself. The ICG will then put this proposal up for public comment involving a reasonable period of time for reviewing the draft proposal, analyzing and preparing supportive or critical comments. The ICG will then review these comments and determine whether modifications are required. If no modifications are needed, and the coordination group agrees, the proposal will be submitted to NTIA.
組み立て作業では、さまざまなコンポーネントの提案を取り、全体が目的の範囲を満たしていること、目的の基準を満たしていること、部品が不足していないこと、全体が一致していることを確認します。全体には、IANA機能を実行するための十分な独立した説明責任メカニズムも含める必要があります。 ICGは、ICG自体の中で大まかなコンセンサスを達成する最終案の草案を作成します。 ICGはこの提案を、ドラフト提案をレビューし、支持的または批判的なコメントを分析および準備するための妥当な期間を含むパブリックコメントに向けて提出します。 ICGはこれらのコメントを確認し、変更が必要かどうかを判断します。変更が必要なく、調整グループが同意した場合、提案はNTIAに提出されます。
If changes are required to fix problems or to achieve broader support, the ICG will work with the operational communities in a manner similar to what was described in task (ii) above. Updates are subject to the same verification, review, and consensus processes as the initial proposals. If, in the ICG's opinion, broad public support for the proposal as articulated by the NTIA is not present, the parts of the proposal that are not supported return to the liaison phase.
問題を修正するため、またはより広範なサポートを実現するために変更が必要な場合、ICGは上記のタスク（ii）で説明したのと同様の方法で運用コミュニティと連携します。更新は、最初の提案と同じ検証、レビュー、および合意プロセスの対象となります。 ICGの見解では、NTIAによって明記された提案に対する幅広い公的サポートが存在しない場合、サポートされていない提案の部分は連絡段階に戻ります。
(iv) Information sharing
（iv）情報共有
The ICG serves as a central clearinghouse for public information about the IANA stewardship transition process. Its secretariat maintains an independent, publicly accessible and open website, under its own domain, where status updates, meetings and notices are announced, proposals are stored, the ICG members are listed, etc. As the development of the transition plans will take some time, it is important that information about ongoing work is distributed early and continuously. This will enable sharing of ideas and the detection of potential issues.
ICGは、IANAスチュワードシップ移行プロセスに関する公開情報の中心的な情報センターとして機能します。事務局は、独自のドメインの下で、公的にアクセス可能な独立したオープンなウェブサイトを維持し、そこで、ステータスの更新、会議、通知が発表され、提案が保存され、ICGメンバーがリストされます。移行計画の策定には時間がかかるため、 、進行中の作業に関する情報を早期かつ継続的に配布することが重要です。これにより、アイデアの共有と潜在的な問題の検出が可能になります。
Appendix B. IANA Stewardship Transition Coordination Group Request for Proposals
付録B. IANAスチュワードシップ移行コーディネーショングループの提案依頼書
IANA Stewardship Transition Coordination Group Request for Proposals
IANAスチュワードシップ移行調整グループの提案依頼
8 September 2014
2014年9月8日
Introduction
はじめに
Under the IANA Stewardship Transition Coordination Group (ICG) Charter, the ICG has four main tasks:
IANAスチュワードシップ移行調整グループ（ICG）憲章の下では、ICGには4つの主要なタスクがあります。
(i) Act as liaison to all interested parties in the IANA stewardship transition, including the three "operational communities" (i.e., those with direct operational or service relationships with the IANA functions operator; namely names, numbers, protocol parameters). This task consists of:
（i）3つの「運用コミュニティ」（つまり、IANA機能オペレーターと直接の運用またはサービスの関係にあるコミュニティ、つまり名前、番号、プロトコルパラメーター）を含む、IANAスチュワードシップ移行のすべての利害関係者との連絡役を務めます。このタスクは以下で構成されています。
a. Soliciting proposals from the operational communities b. Soliciting the input of the broad group of communities affected by the IANA functions
a. 運用コミュニティからの提案の募集b。 IANA機能の影響を受けるコミュニティの幅広いグループの意見を求める
(ii) Assess the outputs of the three operational communities for compatibility and interoperability
（ii）互換性と相互運用性について3つの運用コミュニティの成果を評価する
(iii) Assemble a complete proposal for the transition
（iii）移行のための完全な提案をまとめる
(iv) Information sharing and public communication
（iv）情報共有と公開コミュニケーション
This Request for Proposals (RFP) addresses task (i) of the ICG Charter. This RFP does not preclude any form of input from the non-operational communities.
この提案依頼書（RFP）は、ICG憲章のタスク（i）に対応しています。このRFPは、非運用コミュニティからのいかなる形式の入力も排除しません。
0. Complete Formal Responses
0. 完全な正式な回答
The IANA Stewardship Transition Coordination Group (ICG) seeks complete formal responses to this RFP through processes which are to be convened by each of the "operational communities" of IANA (i.e., those with direct operational or service relationships with the IANA functions operator, in connection with names, numbers, or protocol parameters).
IANA Stewardship Transition Coordination Group（ICG）は、IANAの各「運用コミュニティ」（つまり、IANAの機能オペレーターと直接の運用またはサービス関係を持つコミュニティ）によって召集されるプロセスを通じて、このRFPへの完全な正式な応答を求めます。名前、番号、またはプロトコルパラメータとの接続）。
Proposals should be supported by the broad range of stakeholders participating in the proposal development process. Proposals should be developed through a transparent process that is open to and inclusive of all stakeholders interested in participating in the development of the proposal. In order to help the ICG maintain its light coordination role, all interested and affected parties are strongly encouraged to participate directly in these community processes.
プロポーザルは、プロポーザル開発プロセスに参加する幅広いステークホルダーによってサポートされるべきです。プロポーザルは、プロポーザルの作成に参加することに関心のあるすべての利害関係者に開かれ、包括的である透明なプロセスを通じて開発されるべきです。 ICGが軽い調整の役割を維持できるように、関係者や影響を受けるすべての関係者は、これらのコミュニティプロセスに直接参加することを強くお勧めします。
The following link provides information about ongoing community processes and how to participate in them, and that will continue to be updated over time:
次のリンクは、進行中のコミュニティプロセスとそれらへの参加方法に関する情報を提供します。これは、時間の経過とともに更新され続けます。
https://www.icann.org/en/stewardship/community
In this RFP, "IANA" refers to the functions currently specified in the agreement between NTIA and ICANN [http://www.ntia.doc.gov/page/iana-functions-purchase-order] as well as any other functions traditionally performed by the IANA functions operator. SAC-067
このRFPでは、「IANA」は、NTIAとICANNの間の契約で現在指定されている機能[http://www.ntia.doc.gov/page/iana-functions-purchase-order]と、伝統的に他のすべての機能を指しますIANA関数演算子によって実行されます。 SAC-067
[https://www.icann.org/en/system/files/files/sac-067-en.pdf] provides one description of the many different meanings of the term "IANA" and may be useful reading in addition to the documents constituting the agreement itself.
[https://www.icann.org/en/system/files/files/sac-067-en.pdf]は、「IANA」という用語の多くの異なる意味の1つの説明を提供しており、契約自体を構成する文書。
Communities are asked to adhere to open and inclusive processes in developing their responses, so that all community members may fully participate in and observe those processes. Communities are also asked to actively seek out and encourage wider participation by any other parties with interest in their response.
コミュニティは、コミュニティのすべてのメンバーがそれらのプロセスに完全に参加して観察できるように、対応の開発においてオープンで包括的なプロセスを遵守するよう求められます。コミュニティはまた、彼らの対応に関心のある他のいかなる当事者による積極的な参加を積極的に模索し、奨励することも求められています。
A major challenge of the ICG will be to identify and help to reconcile differences between submitted proposals, in order to produce a single plan for the transition of IANA stewardship. Submitted Proposals should therefore focus on those elements that are considered to be truly essential to the transition of their specific IANA functions. The target deadline for all complete formal responses to this RFP is 15 January 2015.
ICGの主な課題は、IANAスチュワードシップの移行に関する単一の計画を作成するために、提出された提案間の差異を特定し、調整を支援することです。したがって、提出された提案は、特定のIANA機能の移行に本当に不可欠であると考えられる要素に焦点を当てるべきです。このRFPへのすべての正式な回答の目標期限は2015年1月15日です。
I. Comments
I.コメント
While the ICG is requesting complete formal proposals through processes convened by each of the operational communities, and that all interested parties get involved as early as possible in the relevant community processes, some parties may choose to provide comments directly to the ICG about specific aspects of particular proposals, about the community processes, or about the ICG's own processes. Comments may be directly submitted to the ICG any time via email to icg-forum@icann.org. Comments will be publicly archived at <http://forum.icann.org/lists/icg-forum/>.
ICGは各運用コミュニティが招集するプロセスを通じて完全な正式な提案を要求し、すべての利害関係者が関連するコミュニティプロセスにできるだけ早く関与するようにしますが、一部の当事者は、コミュニティのプロセス、またはICG自身のプロセスに関する特定の提案。コメントは、icg-forum @ icann.org宛てに電子メールでいつでもICGに直接送信できます。コメントは<http://forum.icann.org/lists/icg-forum/>で公開アーカイブされます。
Commenters should be aware that ICG will direct comments received to the relevant operational communities if appropriate. The ICG will review comments received as time and resources permit and in accordance with the overall timeline for the transition. That is, comments received about specific proposals may not be reviewed until those proposals have been submitted to the ICG. The ICG may establish defined public comment periods about specific topics in the future, after the complete formal responses to the RFP have been received.
コメンターは、必要に応じて、ICGが受け取ったコメントを関連する運用コミュニティに送信することを認識しておく必要があります。 ICGは、時間とリソースが許す限り、移行の全体的なタイムラインに従って、受け取ったコメントを確認します。つまり、特定の提案について受け取ったコメントは、それらの提案がICGに提出されるまでレビューできません。 ICPは、RFPへの完全な正式な回答を受け取った後、特定のトピックについて定義されたパブリックコメント期間を設定する可能性があります。
Required Proposal Elements
必要な提案要素
The ICG encourages each community to submit a single proposal that contains the elements described in this section.
ICGは、各コミュニティがこのセクションで説明されている要素を含む単一の提案を提出することを奨励しています。
Communities are requested to describe the elements delineated in the sections below in as much detail possible, and according to the suggested format/structure, to allow the ICG to more easily assimilate the results. While each question is narrowly defined to allow for comparison between answers, respondents are encouraged to provide further information in explanatory sections, including descriptive summaries of policies/practices and associated references to source documents of specific policies/practices. In this way, the responses to the questionnaire will be useful at the operational level as well as to the broader stakeholder communities.
コミュニティは、ICGが結果をより簡単に吸収できるように、推奨されるフォーマット/構造に従って、可能な限り詳細に以下のセクションで説明されている要素を説明するように要求されています。各質問は回答を比較できるように狭く定義されていますが、回答者は、ポリシー/実践の説明的な要約や、特定のポリシー/実践のソースドキュメントへの関連参照など、説明セクションで詳細情報を提供することをお勧めします。このようにして、アンケートへの回答は、運用レベルだけでなく、より幅広い利害関係者のコミュニティにも役立ちます。
In the interest of completeness and consistency, proposals should cross-reference wherever appropriate the current IANA Functions Contract[3] when describing existing arrangements and proposing changes to existing arrangements.
完全性と一貫性のために、既存の取り決めを説明し、既存の取り決めへの変更を提案する場合、現在のIANA機能契約[3]を適切に参照する必要があります。
0. Proposal type
0. 提案タイプ
Identify which category of the IANA functions this submission proposes to address: [ ] Names [ ] Numbers [ ] Protocol Parameters
この提出が対処することを提案しているIANA機能のカテゴリを特定します：[]名前[]番号[]プロトコルパラメータ
I. Description of Community's Use of IANA Functions
I.コミュニティによるIANA機能の使用の説明
This section should list the specific, distinct IANA functions your community relies on. For each IANA function on which your community relies, please provide the following:
このセクションには、コミュニティが依存する特定の異なるIANA機能をリストする必要があります。コミュニティが依存する各IANA機能について、以下を提供してください。
o A description of the function; o A description of the customer(s) of the function; o What registries are involved in providing the function;
o 関数の説明。 o機能の顧客の説明。 o機能の提供に関与しているレジストリ。
o A description of any overlaps or interdependencies between your IANA requirements and the functions required by other customer communities.
o IANA要件と他の顧客コミュニティが必要とする機能との間の重複または相互依存性の説明。
If your community relies on any other IANA service or activity beyond the scope of the IANA functions contract, you may describe them here. In this case please also describe how the service or activity should be addressed by the transition plan.
コミュニティがIANA機能契約の範囲を超える他のIANAサービスまたはアクティビティに依存している場合は、ここでそれらを説明できます。この場合、移行計画でサービスまたはアクティビティにどのように対処するかについても説明してください。
II. Existing, Pre-Transition Arrangements
II。既存の移行前の取り決め
This section should describe how existing IANA-related arrangements work, prior to the transition.
このセクションでは、移行前に、既存のIANA関連の取り決めがどのように機能するかを説明する必要があります。
[3] http://www.ntia.doc.gov/files/ntia/
publications/sf_26_pg_1-2-final_award_and_sacs.pdf
A. Policy Sources
A.ポリシーソース
This section should identify the specific source(s) of policy which must be followed by the IANA functions operator in its conduct of the services or activities described above. If there are distinct sources of policy or policy development for different IANA functions, then please describe these separately. For each source of policy or policy development, please provide the following:
このセクションでは、IANA機能オペレーターが上記のサービスまたはアクティビティを実施する際に従う必要のあるポリシーの特定のソースを特定する必要があります。 IANAの機能ごとに異なるポリシーソースまたはポリシー開発ソースがある場合は、これらを個別に説明してください。ポリシーまたはポリシー開発の各ソースについて、以下を提供してください。
o Which IANA function (identified in Section I) are affected. o A description of how policy is developed and established and who is involved in policy development and establishment. o A description of how disputes about policy are resolved. o References to documentation of policy development and dispute resolution processes.
o 影響を受けるIANA機能（セクションIで識別）。 oポリシーの開発と確立の方法、およびポリシーの開発と確立に誰が関与しているかの説明。 oポリシーに関する紛争の解決方法の説明。 oポリシー開発および紛争解決プロセスの文書への参照。
B. Oversight and Accountability
B.監視と説明責任
This section should describe all the ways in which oversight is conducted over the IANA functions operator's provision of the services and activities listed in Section I and all the ways in which the IANA functions operator is currently held accountable for the provision of those services. For each oversight or accountability mechanism, please provide as many of the following as are applicable:
このセクションでは、IANA機能オペレーターによるセクションIにリストされたサービスとアクティビティの提供について監視が行われるすべての方法と、IANA機能オペレーターがそれらのサービスの提供に対して現在責任を負うすべての方法について説明する必要があります。見落としや説明責任のメカニズムごとに、該当する次の項目をすべて提供してください。
Which IANA functions (identified in Section I) are affected. If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way.
影響を受けるIANA機能（セクションIで識別）。セクションII.Aで特定されたポリシーソースが影響を受ける場合は、影響を受けるものを特定し、どのように説明するか。
o A description of the entity or entities that provide oversight or perform accountability functions, including how individuals are selected or removed from participation in those entities. o A description of the mechanism (e.g., contract, reporting scheme, auditing scheme, etc.). This should include a description of the consequences of the IANA functions operator not meeting the standards established by the mechanism, the extent to which the output of the mechanism is transparent and the terms under which the mechanism may change. o Jurisdiction(s) in which the mechanism applies and the legal basis on which the mechanism rests.
o 監視を提供する、または説明責任機能を実行する1つまたは複数のエンティティの説明。これらのエンティティへの参加から個人を選択または削除する方法を含みます。 oメカニズムの説明（例：契約、報告スキーム、監査スキームなど）。これには、メカニズムによって確立された基準を満たしていないIANA機能オペレーターの結果、メカニズムの出力が透過的である範囲、およびメカニズムが変更される可能性のある条件の説明を含める必要があります。 oメカニズムが適用される管轄区域、およびメカニズムが適用される法的根拠。
III. Proposed Post-Transition Oversight and Accountability Arrangements
III。提案された移行後の監視と説明責任の取り決め
This section should describe what changes your community is proposing to the arrangements listed in Section II.B in light of the transition. If your community is proposing to replace one or more existing arrangements with new arrangements, that replacement should be explained and all of the elements listed in Section II.B should be described for the new arrangements. Your community should provide its rationale and justification for the new arrangements.
このセクションでは、移行を考慮して、セクションII.Bに記載されている取り決めに対してコミュニティが提案している変更について説明する必要があります。コミュニティが1つ以上の既存の取り決めを新しい取り決めに置き換えることを提案している場合、その取り替えを説明し、セクションII.Bにリストされているすべての要素を新しい取り決めについて説明する必要があります。あなたのコミュニティは、新しい取り決めについてその根拠と正当性を提供する必要があります。
If your community's proposal carries any implications for the interface between the IANA functions and existing policy arrangements described in Section II.A, those implications should be described here.
コミュニティの提案が、IANA機能とセクションII.Aで説明されている既存のポリシーの取り決めとの間のインターフェースに何らかの影響を与える場合、それらの影響をここで説明する必要があります。
If your community is not proposing changes to arrangements listed in Section II.B, the rationale and justification for that choice should be provided here.
コミュニティがセクションII.Bに記載されている取り決めの変更を提案していない場合は、その選択の根拠と根拠をここに記載する必要があります。
IV. Transition Implications
IV。移行の影響
This section should describe what your community views as the implications of the changes it proposed in Section III. These implications may include some or all of the following, or other implications specific to your community:
このセクションでは、セクションIIIで提案した変更の影響として、コミュニティが何を考えているかを説明する必要があります。これらの影響には、以下の一部またはすべて、またはコミュニティに固有のその他の影響が含まれる場合があります。
Description of operational requirements to achieve continuity of service and possible new service integration throughout the transition.
移行を通じてサービスの継続性と可能な新しいサービス統合を実現するための運用要件の説明。
Risks to operational continuity and how they will be addressed. Description of any legal framework requirements in the absence of the NTIA contract. Description of how you have tested or evaluated the workability of any new technical or operational methods proposed in this document and how they compare to established arrangements.
運用継続性に対するリスクとその対処方法。 NTIA契約がない場合の法的枠組み要件の説明。このドキュメントで提案されている新しい技術または運用方法の実行可能性をどのようにテストまたは評価したか、および確立された配置と比較する方法の説明。
Description of how long the proposals in Section III are expected to take to complete, and any intermediate milestones that may occur before they are completed.
セクションIIIの提案が完了するまでにかかると予想される期間の説明、および完了する前に発生する可能性のある中間マイルストーン。
V. NTIA Requirements
V. NTIAの要件
Additionally, NTIA has established that the transition proposal must
meet the following five requirements:
o Support and enhance the multistakeholder model;
o Maintain the security, stability, and resiliency of the Internet
DNS;
o Meet the needs and expectation of the global customers and
partners of the IANA functions;
o Maintain the openness of the Internet;
o The proposal must not replace the NTIA role with a government-led
or an inter-governmental organization solution.
This section should explain how your community's proposal meets these requirements and how it responds to the global interest in the IANA functions.
このセクションでは、コミュニティの提案がこれらの要件をどのように満たし、IANA機能に対する世界的な関心にどのように対応するかを説明する必要があります。
VI. Community Process
我々。コミュニティプロセス
This section should describe the process your community used for developing this proposal, including: o The steps that were taken to develop the proposal and to determine consensus. o Links to announcements, agendas, mailing lists, consultations and meeting proceedings. o An assessment of the level of consensus behind your community's proposal, including a description of areas of contention or disagreement.
このセクションでは、コミュニティがこの提案を作成するために使用したプロセスを説明する必要があります。これには、次のものが含まれます。o提案を作成し、コンセンサスを決定するために行われた手順。 o発表、議題、メーリングリスト、協議、会議の議事録へのリンク。 o競合または不一致の領域の説明を含む、コミュニティの提案の背後にあるコンセンサスのレベルの評価。
The following messages were sent to the ICG:
次のメッセージがICGに送信されました。
From: Jari Arkko <jari.arkko@piuha.net>
Subject: Re: [Internal-cg] Question from the ICG
Date: 20 Feb 2015 23:46:20 GMT+2
To: Alissa Cooper <alissa@cooperw.in>, ICG <internal-cg@icann.org>
Cc: Izumi Okutani <izumi@nic.ad.jp>
Dear Alissa and the ICG,
親愛なるアリッサとICG、
We refer to the question that the ICG asked the IETF community on 9 Feb 2015
2015年2月9日にICGがIETFコミュニティに尋ねた質問を参照します
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html
> The numbers proposal sees these changes as a requirement of the > transition and the protocols parameters proposal does not. If > these aspects of the proposals are perceived as incompatible would > the numbers and protocol parameters communities be willing to > modify their proposals to reconcile them?
>数値の提案では、これらの変更は>移行の要件として認識されますが、プロトコルパラメータの提案ではそうではありません。 >提案のこれらの側面が互換性がないと認識される場合>コミュニティが喜んで数とプロトコルパラメータ>提案を調整して提案を調整するか？
We do not observe incompatibilities between the proposals from the numbers and protocol parameters communities. The numbers community expresses a preference to transfer the trademark and domain, while the IETF proposal does not oppose such transfer. This is not an incompatibility, it is something that can be satisfied by implementation of both number and protocol parameters community's proposals, as already specified.
数値からの提案とプロトコルパラメータコミュニティの間の非互換性は観察されません。数のコミュニティは、商標とドメインを移転することへの選好を表明していますが、IETF提案はそのような移転に反対していません。これは非互換性ではなく、すでに指定されているように、数とプロトコルパラメータの両方のコミュニティの提案を実装することで満たすことができるものです。
To confirm this, and to determine whether the transfer of the trademark and domain would be acceptable, we consulted the community. It is the opinion of the IANAPLAN working group that they would support a decision by the IETF Trust to hold the trademark and domain on behalf of the Internet community. For details, see http://www.ietf.org/mail-archive/web/ianaplan/current/msg01659.html
これを確認し、商標とドメインの譲渡が受け入れられるかどうかを判断するために、コミュニティに相談しました。 IANAPLANワーキンググループは、インターネットコミュニティに代わって商標とドメインを保持するというIETFトラストによる決定を支持するだろうとの見解です。詳細については、http：//www.ietf.org/mail-archive/web/ianaplan/current/msg01659.htmlを参照してください
The IETF Trust also looked at this issue. The trustees decided that
the IETF Trust would be willing to hold intellectual property rights
relating to the IANA function, including the IANA trademark and the
IANA.ORG domain name. For details, see
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01664.html
In short, we find no incompatibility between the proposals and no need to modify the protocol parameters proposal.
つまり、提案間の非互換性はなく、プロトコルパラメータの提案を変更する必要もありません。
Best Regards, Jari Arkko and Russ Housley on behalf of the IETF community and the IETF Trust
IETFコミュニティおよびIETFトラストを代表するJari Arkko氏とRuss Housley氏
From: Jari Arkko <jari.arkko@piuha.net>
Subject: [Internal-cg] IETF response to the time frame inquiry
Date: 5 Jun 2015 13:39:50 GMT+3
To: Alissa Cooper <alissa@cooperw.in>
Cc: ICG <internal-cg@ianacg.org>
This is a response to a query regarding transition finalisation and implementation time frames, sent to the IANAPLAN working group list by the chairs of the IANA Transition Coordination Group (ICG) on May 27th.
これは、5月27日にIANA移行調整グループ（ICG）の議長によってIANAPLANワーキンググループリストに送信された、移行のファイナライズと実装の時間枠に関するクエリへの応答です。
While I am carrying this response back to the ICG, the substance of this response has been discussed in the IANAPLAN working group and the relevant parts of IETF leadership. I believe this response represents the (rough) consensus opinion that emerged in the discussion, as well as the current state of IANA arrangement updates that our leadership bodies have been working on.
私はこの回答をICGに持ち帰っていますが、この回答の内容については、IANAPLANワーキンググループとIETFリーダーシップの関連部分で議論されています。この回答は、議論で浮かび上がった（大まかな）コンセンサスの意見、および私たちのリーダーシップ団体が取り組んでいるIANAの取り決めの更新の現状を表していると思います。
The IETF is ready today to take the next steps in the implementation of the transition of the stewardship. In our case, most of the necessary framework is already in place and implemented in preceding years.
IETFは、スチュワードシップの移行の実装において次のステップを実行する準備ができています。私たちのケースでは、必要なフレームワークのほとんどはすでに導入されており、過去数年で実装されています。
The remaining step is an updated agreement with ICANN which addresses two issues. These issues are outlined in Section 2.III in the Internet Draft draft-ietf-ianaplan-icg-response-09.txt:
残りのステップは、2つの問題に対処するICANNとの最新の合意です。これらの問題は、インターネットドラフトdraft-ietf-ianaplan-icg-response-09.txtのセクション2.IIIで概説されています。
o The protocol parameters registries are in the public domain. It is the preference of the IETF community that all relevant parties acknowledge that fact as part of the transition.
o プロトコルパラメータレジストリはパブリックドメインにあります。すべての関係者が移行の一部としてその事実を認めるのは、IETFコミュニティの好みです。
o It is possible in the future that the operation of the protocol parameters registries may be transitioned from ICANN to subsequent operator(s). It is the preference of the IETF community that, as part of the NTIA transition, ICANN acknowledge that it will carry out the obligations established under C.7.3 and I.61 of the current IANA functions contract between ICANN and the NTIA [NTIA-Contract] to achieve a smooth transition to subsequent operator(s), should the need arise. Furthermore, in the event of a transition it is the expectation of the IETF community that ICANN, the IETF, and subsequent operator(s) will work together to minimize disruption in the use of the protocol parameters registries or other resources currently located at iana.org.
oプロトコルパラメータレジストリの操作がICANNから後続のオペレーターに移行される可能性があります。 NTIA移行の一環として、ICANNがICANNとNTIAの間の現在のIANA機能契約のC.7.3およびI.61に基づいて確立された義務を履行することを認めることは、IETFコミュニティーの好みです[NTIA-Contract ]必要に応じて、後続の演算子にスムーズに移行するため。さらに、移行が発生した場合は、ICANN、IETF、および後続のオペレーターが協力して、現在ianaにあるプロトコルパラメーターレジストリまたはその他のリソースの使用の混乱を最小限に抑えることがIETFコミュニティの期待です。 org。
The IETF Administrative Oversight Committee (IAOC) has decided to use an update of our yearly IETF-ICANN Service Level Agreement (SLA) as the mechanism for this updated agreement. They have drafted the update and from our perspective it could be immediately executed. Once the updated agreement is in place, the transition would be substantially complete, with only the NTIA contract lapse or termination as a final step.
IETF管理監視委員会（IAOC）は、この更新された契約のメカニズムとして、毎年開催されるIETF-ICANNサービスレベル契約（SLA）の更新を使用することを決定しました。彼らはアップデートを起草しました、そして私たちの観点から、それはすぐに実行されることができました。更新された契約が締結されると、移行は実質的に完了し、NTIA契約の失効または終了のみが最終ステップとなります。
Of course, we are not alone in this process. Interactions with other parts of the process may bring additional tasks that need to be executed either before or after the transition. First, the ICG, the RIRs, and IETF have discussed the possibility of aligning the treatment of IANA trademarks and domains. The IETF Trust has signalled that it would be willing to do this, if asked. We are awaiting coordination on this to complete, but see no problem in speedy execution once the decision is made. From our perspective this is not a prerequisite for the transition, however.
もちろん、このプロセスで私たちだけではありません。プロセスの他の部分との相互作用により、移行の前または後に実行する必要がある追加のタスクが発生する場合があります。まず、ICG、RIR、およびIETFは、IANAの商標とドメインの扱いを調整する可能性について議論しました。 IETFトラストは、求められた場合、これを実行する意思があることを通知しました。これで調整が完了するのを待っていますが、決断したらスピーディーに実行しても問題ありません。ただし、これは移行の前提条件ではありません。
In addition, the names community has proposed the creation of a 'Post Transition IANA' (PTI). If the existing agreements between the IETF and ICANN remain in place and the SLAs discussed above are not affected, the IETF transition would take place as described above. That is our preference. If the final details of the PTI plan require further action from the IETF, more work and community agreement would be required. The timeline for that work cannot be set until the scope is known.
さらに、ネームコミュニティは、「移行後のIANA」（PTI）の作成を提案しています。 IETFとICANNの間の既存の合意が適切であり、上記のSLAが影響を受けない場合、上記のようにIETFへの移行が行われます。それが私たちの好みです。 PTI計画の最終的な詳細にIETFからのさらなるアクションが必要な場合は、さらに多くの作業とコミュニティの合意が必要になります。その作業のタイムラインは、範囲がわかるまで設定できません。
Jari Arkko, IETF Chair (reporting his summary of the situation)
Jari Arkko、IETF議長（状況の概要を報告）
From: Jari Arkko <jari.arkko@piuha.net>
Subject: [Internal-cg] Response from IETF IANAPLAN WG regarding the
ICG question on coordination
Date: 8 Oct 2015 10:13:07 GMT+3
To: IANA etc etc Coordination Group <internal-cg@ianacg.org>
The IANAPLAN working group has discussed the coordination question from the ICG. In the working group's opinion, informal coordination exists today and will continue, which is consistent with the commitment requested by the ICG.
IANAPLANワーキンググループは、ICGからの調整に関する質問について議論しました。ワーキンググループの意見では、非公式の調整は今日存在し、今後も継続します。これは、ICGによって要求されたコミットメントと一致しています。
This is also consistent with an overall coordination commitment already indicated in the IANAPLAN proposal. The proposal is a consensus document of the IETF. From the proposal:
これは、IANAPLAN提案ですでに示されている全体的な調整コミットメントとも一致しています。この提案は、IETFの合意文書です。提案から：
The IETF will continue to coordinate with ICANN, the RIRs, and other parties that are mutually invested in the continued smooth operation of the Internet registries.
IETFは、引き続きICANN、RIR、およびインターネットレジストリの継続的な円滑な運用に相互に投資している他の関係者と調整します。
The coordination approach is also consistent with the comments that were sent by the IAB to the ICG during the public comment period. See https://www.iab.org/documents/correspondence-reports-documents/2015- 2/iab-comments-on-icg-proposal/.
調整アプローチは、パブリックコメント期間中にIABからICGに送信されたコメントとも一致します。 https://www.iab.org/documents/correspondence-reports-documents/2015- 2 / iab-comments-on-icg-proposal /を参照してください。
Jari Arkko, IETF Chair and the Area Director for the IANAPLAN WG
Jari Arkko、IETF議長、およびIANAPLAN WGのエリアディレクター
Authors' Addresses
著者のアドレス
Eliot Lear (editor) Richtistrasse 7 Wallisellen, ZH CH-8304 Switzerland
Eliot Lear（編集者）Richtistrasse 7 Wallisellen、ZH CH-8304スイス
Phone: +41 44 878 9200
Email: lear@cisco.com
Russ Housley (editor) 918 Spring Knoll Drive Herndon, VA 20170 United States of America
Russ Housley（編集者）918 Spring Knoll Driveハーンドン、バージニア州20170アメリカ合衆国
Email: housley@vigilsec.com