Internet Engineering Task Force (IETF) E. Lear, Ed.
Request for Comments: 7979 R. Housley, Ed.
Category: Informational August 2016
ISSN: 2070-1721
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管理过渡协调小组（ICG）关于IANA协议参数登记册提案请求的回应
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管理过渡协调小组。该小组就IANA的三个主要功能（名称、编号和协议参数）征求了建议。本文件包含IETF对该协议参数请求的响应。它与各自运营社区正在开发的名称和编号资源一起包含在对NTIA的总体响应中。在导言中可以找到对该答复的引用，附录中还包括其他信函。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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）的产品。它代表了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.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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）宣布打算将对互联网分配号码管理局（IANA）职能的监督过渡[NTIA宣布]。在该公告中，NTIA要求互联网名称和号码分配公司（ICANN）建立一个流程，以提交过渡提案。作为该进程的一部分，成立了IANA管理过渡协调小组（ICG）。ICG章程见附录A。ICG反过来从名称、编号和协议参数社区征求关于过渡后安排的建议，以便向NTIA提出建议。最终投标邀请函（RFP）可在附录B中找到。ICG对NTIA的回复可在[ICG回复]中找到。
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”的许多不同含义进行了说明，除构成协议本身的文件外，可能还有助于阅读。
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:
>>>
>>>
>>> 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.
>>>
>>>
>>> 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域名的引用访问协议参数注册表，并在协议参数注册表过程中使用术语“iana”[RFC5226]。
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顶级域名。此区域用于在其下委托的某些Internet基础设施服务。IETF将.ARPA作为协议参数注册表的一部分，用于响应。
>>>
>>> A description of the customer(s) of the service or activity.
>>>
>>>
>>> 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协议参数注册运营商根据谅解备忘录[RFC2860]和相关补充协议（包括IETF和ICANN[MOUSUP]之间建立的服务水平协议（SLA））维护IETF的协议参数注册，以符合所有相关IETF政策。
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]。标准流程可以按照批准标准的方式进行修改。也就是说，有人通过提交一份称为“互联网草案”的临时文件来提出变更，社区对此进行讨论，如果能找到大致的共识，则该变更由互联网工程指导小组（IESG）批准，IESG还负责宣布IETF对技术决策的共识，包括那些影响IANA协议参数注册表的参数。任何人都可以在最后一次通话中提出更改，任何人都可以参加社区讨论。
>>>
>>> What registries are involved in providing the service or
>>> activity.
>>>
>>>
>>> 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.
>>>
>>>
>>> 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
o IETF已经指定了一些关于域名的特殊用途注册。这些注册中心需要与作为DNS根目录政策机构的ICANN进行协调，包括负责ICANN域名政策的社区团体，如通用名支持组织（GNSO）和国家代码名支持组织（ccNSO）。有
already mechanisms in place to perform this coordination, and the capacity to modify those mechanisms to meet new conditions as they might arise. [RFC6761]
已经建立了执行这种协调的机制，以及修改这些机制以满足可能出现的新条件的能力。[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地址的另一个示例是唯一本地地址（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和服务提供商的运营。最近的一个例子是对BGP的扩展，它将自治系统编号作为四个八位组实体进行携带[RFC6793]。值得注意的是，这一变化是出于运行需要而发生的，它证明了RIRs和IETF之间的强烈一致性。
>>> II. Existing, Pre-Transition Arrangements
>>> 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.
>>>
>>>
>>> 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.
>>>
>>>
>>> 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
[RFC6220]和[RFC5226]中说明了协议参数注册表的总体管理策略。这些文件中的第一份解释了登记处如何运作、政策如何制定以及监督如何进行的模式。RFC 5226规定了规范编写者在每个规范的“IANA注意事项”部分中定义新协议注册表时可能采用的策略。IETF的所有政策都以互联网草案形式的提案开始。任何人都可以提交这样的提案。如果有足够的兴趣，其范围包括拟定工作的工作组可以选择采用该工作组，IESG可以选择创建一个工作组，或者区域主管可以选择赞助该草案。在任何情况下，任何人都可以对提案的进展发表意见。除非获得足够的社区支持以表明大致共识，否则IESG无法通过提案[RFC7282]。在每种情况下，都会发出“最后一次呼叫”，以便通知对策略或流程的任何拟议更改。任何人都可以
comment during a Last Call. For example, this process is currently being used to update RFC 5226 [I-D.leiba-cotton-iana-5226bis].
在最后一次通话中发表评论。例如，目前正在使用此过程更新RFC 5226[I-D.leiba-cotton-iana-5226bis]。
>>>
>>> A description of how disputes about policy are resolved.
>>>
>>>
>>> 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.
>>>
>>>
>>> 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中进行了修订，如[RFC-INDEX]所示。
>>>
>>> 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.
>>>
>>>
>>> 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:
IETF响应：
The protocol parameters registries.
协议参数注册。
>>>
>>> If not all policy sources identified in Section II.A are
>>> affected, identify which ones are affected.
>>>
>>>
>>> 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.
>>>
>>>
>>> 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成员是通过提名委员会（NOMCOM）程序选出并召回的，该程序在[RFC3777]及其更新中有描述。这一过程规定选择社区中的积极成员，他们自己同意候选人名单。活跃成员是从有参与IETF历史的志愿者中随机选择的，限制了太多具有相同从属关系的活跃成员。选择活动成员时，任何人都可以验证是否遵循了正确的程序。由活跃成员选出的候选人名单将发送给互联网协会董事会确认。一般来说，成员的任期为两年。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
IAB监督IETF的协议参数注册表，并负责选择适当的操作员和相关的每个注册表安排。尤其是在人际关系方面
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认为需要特殊处理，否则注册运营商目前是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.
>>>
>>>
>>> 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]中找到。谅解备忘录规定了IETF的IANA功能运营商和互联网研究工作队（IRTF）将开展的工作。IRTF是IETF的一个对等组织，专注于研究。[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]和运营程序，产生的文件作为每年谅解备忘录的补充[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
迄今为止，IETF与当前IANA职能运营商之间没有无法解决的争议或问题。[RFC2860]规定，如果出现技术争议，“IANA应专门寻求并遵循IESG的技术指导。”在不太可能出现更困难的情况下，IAOC和IAB将聘请ICANN管理层解决该问题。谅解备忘录还为任何一方提供了在提前六个月发出通知后终止协议的选择权。显然，这样的行动只会
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.
经过认真考虑后才能进行。在这种情况下，将选择新的IANA功能运营商，并与该运营商签订新协议。
>>>
>>> Jurisdiction(s) in which the mechanism applies and the legal
>>> basis on which the mechanism rests.
>>>
>>>
>>> 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
>>>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.
>>>
>>>
>>> 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
IANA协议参数注册表更新将继续日常运行，就像他们在过去十年或更长时间所做的那样。IETF社区对目前的安排非常满意
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.
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转移到后续运营商。IETF团体倾向于，作为NTIA过渡的一部分，ICANN承认其将履行ICANN与NTIA【NTIA合同】之间现行IANA职能合同C.7.3和I.61规定的义务，以便在需要时顺利过渡到后续运营商。此外，在过渡的情况下，IETF社区期望ICANN、IETF和后续运营商共同努力，最大限度地减少协议参数注册表或当前位于iana.org的其他资源的使用中断。
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. Internet体系结构需要并接收Internet注册中心提供的功能强大的服务。
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名称是需要密切协调的两个示例。IETF将继续与ICANN、RIRs和其他各方协调，共同投资于互联网注册中心的持续平稳运行。我们完全理解合作的必要性。
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
RFC 6220规定了协议参数注册表的作用和功能，它对IETF标准过程和IETF协议至关重要。IAB代表IETF负责定义和管理与协议注册中心操作员角色的关系。这一责任包括选择和
management of the protocol parameter registry operator, as well as management of the parameter registration process and the guidelines for parameter allocation.
管理协议参数注册表操作员，以及管理参数注册过程和参数分配指南。
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.
RFCs中规定了创建协议参数注册表的说明以及后续添加和更新的策略。协议参数注册中心对每个人都是可用的，其发布形式允许其内容包含在其他作品中，无需进一步许可。这些工作包括但不限于互联网协议及其相关文档的实现。
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.
这些原则将指导IAB、IAOC和IETF社区的其他成员与ICANN合作建立未来IANA性能指标和操作程序。
>>> IV Transition Implications
>>> 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.
>>>
>>>
>>> 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.
协议参数的处理不需要结构更改。上述原则将指导IAB、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第三节中我方回复中概述的要求。
>>>
>>> V. NTIA Requirements
>>>
>>> Additionally, NTIA has established that the transition proposal
>>> must meet the following five requirements:
>>>
>>> "Support and enhance the multistakeholder model;"
>>>
>>>
>>> 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对所有人开放，所以所有利益相关者都可以参与。第一节中概述的IETF过程用于制定本提案。这些相同的过程已经并将用于修改协议参数功能的管理。如前所述，任何人都可以对这些过程提出修正案，任何人都可以参与决策过程。
>>>
>>> "Maintain the security, stability, and resiliency of the
>>> Internet DNS;"
>>>
>>>
>>> "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;"
>>>
>>>
>>> "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
来自世界各地的实施者及其用户使用IETF标准和相关的IANA协议参数注册表。当前IANA协议参数注册系统
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.
正在满足这些全球客户的需求。这项建议继续满足他们的需求，保持了过去为他们提供良好服务的现有流程。
>>>
>>>
>>>
>>> "Maintain the openness of the Internet."
>>>
>>>
>>> "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.
该提案维护了现有的开放框架，允许任何人参与IETF标准的开发，包括IANA协议参数注册策略。此外，世界上任何地方的实施者都可以完全访问RFC系列中发布的协议规范和iana.org上发布的协议参数注册表。那些需要在IANA协议登记处进行分配的人，将按照这些登记处现行政策的规定，继续满足他们的要求。
>>>
>>> "The proposal must not replace the NTIA role with a
>>> government-led or an inter-governmental organization solution."
>>>
>>>
>>> "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执行，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.
>>>
>>>
>>> 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.
>>>
>>>
>>> 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
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 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
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
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
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
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
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
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/
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
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.
>>>
>>>
>>> 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社区的大致共识，首先由工作组主席判断，然后由发起区域主任判断，然后由IESG根据[RFC2026]在2014年12月18日IESG Telecohat期间进行判断。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
在编写该文件的过程中，提出了一些建议，但这些建议没有得到足够的支持，无法列入。引起广泛讨论的两个一般性建议领域是：
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:
在工作组进程结束时，虽然结果没有得到一致支持，但工作组主席得出结论认为，工作组内存在着大致的共识。本文件工作组共识的文件摘要可在以下位置找到：
https://datatracker.ietf.org/doc/draft-ietf-ianaplan-icg-response/
shepherdwriteup/
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
在IETF的最后一次通话中，其他人表示支持该文件。有几篇社论评论导致了一些变化，也有一些讨论更实质性的评论
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的最后一次通话中没有提出新的反对意见。上一次通话评论的摘要可在此找到：
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01500.html
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工作组共同开发的。特别感谢贾里·阿尔科、马克·布兰切特、布赖恩·卡彭特、艾莉莎·库珀、约翰·科伦、莱斯利·戴格尔、希瑟·弗拉纳根、克里斯特·霍姆伯格、约翰·克莱辛、巴里·莱巴、米尔顿·穆勒、安德烈·罗巴切夫斯基、安德鲁·沙利文、戴夫·泰勒、格雷格·伍德和苏珊娜·伍尔夫。
[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，“绩效标准指标报告”<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宣布]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-最终奖和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.，“互联网标准过程——第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工作组指南和程序”，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.Carpenter，编辑，“互联网架构委员会（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，“关于互联网分配号码管理局技术工作的谅解备忘录”，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.，Ed.，“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]Austein，R.，Ed.和B.Wijnen，Ed.，“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，“在RFCs中编写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]Cotton，M.，Vegoda，L.，和D.Meyer，“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.，和互联网架构委员会，“定义IETF协议参数注册操作员的角色和功能”，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]Cotton，M.，Vegoda，L.，Bonica，R.，Ed.，和B.Haberman，“特殊用途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.
[I-D.leiba-cotton-iana-5226bis]cotton，M.，leiba，B.和D.Narten，“在RFC中编写iana考虑事项部分的指南”，正在进行的工作，草案-leiba-cotton-iana-5226bis-172016年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回应]IANA管理过渡协调小组，“将互联网分配号码管理局（IANA）职能的管理从美国商务部国家电信和信息管理局（NTIA）过渡到全球多利益相关者社区的建议”，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编辑器，“RFC索引”<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研究小组指南和程序”，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.，和R.Plzak，“根名称服务器操作要求”，RFC 2870，DOI 10.17487/RFC2870，2000年6月<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.，Ed.“地址和路由参数区域域（“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，“唯一本地IPv6单播地址”，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对四个八位组自治系统（AS）数字空间的支持”，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，“对现代标准范式的肯定”，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，“互联网号码注册系统”，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）有一个可交付成果：向美国商务部国家电信和信息管理局（NTIA）提交的关于NTIA管理IANA职能向全球多方利益相关者社区过渡的提案。该小组将以透明的方式行事，与广泛的利益相关者协商，并确保其提案支持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功能分为三大类：域名、数字资源和其他协议参数。域名类别进一步分为国家代码和通用域名子类别。虽然所有这些类别之间都有一些重叠，但每个类别都提出了不同的组织、运作和技术问题，而且每个类别往往都有不同的兴趣社区和专门知识。出于这些原因，最好让三类IANA参数的工作并行进行，并以各自的社区为基础。
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职能所需的安排。然而，这两个进程是相互关联和相互依存的，应当适当协调它们的工作。
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
协调小组有四项主要任务：（i）与所有相关方保持联络，包括三个“运营社区”（即与IANA有直接运营或服务关系的社区；即名称、编号、协议参数）。这项任务包括：a。征求运营社区的建议b。征求受IANA功能影响的广泛社区的意见（ii）评估三个运营社区的兼容性和互操作性输出
(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
（二）评估
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.
这项建议在实践中是可行的。全球导航卫星系统国际委员会还应汇编其在作战社区以外收到的投入，并审查这一投入的影响。
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可能在某个时候发现组件提案的问题。在这一点上，全球导航卫星系统国际委员会的作用是将这一点反馈给相关社区，以便他们（相关社区）能够解决这些问题。全球导航卫星系统国际委员会的职责不是制定提案或从相互竞争的提案中进行选择。
(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随后将审查这些意见，并确定是否需要修改。如果不需要修改，且协调小组同意，提案将提交给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认为NTIA所阐述的提案没有得到广泛的公众支持，提案中未得到支持的部分将返回联络阶段。
(iv) Information sharing
（四）信息共享
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作为国际航空航天协会管理过渡过程公共信息的中央信息交换所。其秘书处在其自己的领域内维持一个独立、可公开访问和开放的网站，在该网站上公布最新情况、会议和通知、储存提案、列出国际导航卫星委员会成员等，因为制定过渡计划需要一段时间，重要的是，有关正在进行的工作的信息应尽早、持续地分发。这将有助于分享想法和发现潜在问题。
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有四项主要任务：
(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) 作为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）评估三个运营社区的兼容性和互操作性
(iii) Assemble a complete proposal for the transition
（iii）汇编一份完整的过渡提案
(iv) Information sharing and public communication
（四）信息共享和公共传播
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管理过渡协调小组（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.
强烈鼓励直接参与这些社区进程。
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
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”的许多不同含义进行了说明，除构成协议本身的文件外，可能还有助于阅读。
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.
全球导航卫星系统国际委员会面临的一个主要挑战将是确定并帮助协调所提交提案之间的差异，以便为国际航空航天协会管理权的过渡制定单一计划。因此，提交的提案应侧重于那些被认为对其特定IANA职能过渡真正至关重要的要素。本RFP所有完整正式回复的目标截止日期为2015年1月15日。
I. Comments
一、评论
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-forum@icann.org. 评论将公开存档于<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可在收到对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.
请社区根据建议的格式/结构，尽可能详细地描述以下章节中描述的要素，以使全球导航卫星系统国际委员会能够更容易地吸收这些结果。虽然每个问题都有狭义的定义，以便在答案之间进行比较，但鼓励受访者在解释部分提供进一步的信息，包括政策/实践的描述性总结以及对特定政策/实践源文件的相关参考。这样，对调查表的答复将在业务层面以及更广泛的利益相关者群体中发挥作用。
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
二,。现有的、过渡前的安排
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
[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功能（见第一节）。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职能运营商提供第一节所列服务和活动进行监督的所有方式，以及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功能（见第一节）受到影响。如果第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 对提供监督或履行问责职能的一个或多个实体的描述，包括如何选择或取消个人参与这些实体。o机制说明（如合同、报告方案、审计方案等）。这应包括对IANA职能运营商不符合机制规定标准的后果、机制输出的透明程度以及机制可能变更的条款的描述。o该机制适用的司法管辖区以及该机制所依据的法律基础。
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.
本节应说明贵社区根据过渡情况对第II.B节所列安排提出的变更。如果您所在社区提议用新安排替换一个或多个现有安排，则应解释替换情况，并说明第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
四、 过渡含义
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:
本节应描述您的社区对第三节中提出的变更的影响。这些影响可能包括以下部分或全部，或您的社区特有的其他影响：
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.
说明第三节中的提案预计需要多长时间才能完成，以及在完成之前可能出现的任何中间里程碑。
V. NTIA Requirements
五、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.
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>
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,
亲爱的Alissa和ICG，
We refer to the question that the ICG asked the IETF community on 9 Feb 2015
我们提到ICG于2015年2月9日向IETF社区提出的问题
http://www.ietf.org/mail-archive/web/ianaplan/current/msg01610.html
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
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>
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:
剩下的步骤是与ICANN的更新协议，该协议解决了两个问题。互联网草案草案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
o 将来，协议参数注册的操作可能会从ICANN转移到后续运营商。IETF团体倾向于，作为NTIA过渡的一部分，ICANN承认其将履行ICANN与NTIA【NTIA合同】之间现行IANA职能合同C.7.3和I.61规定的义务，以便在需要时顺利过渡到后续运营商。此外，在过渡的情况下，IETF社区期望
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.
ICANN、IETF和后续运营商将共同努力，最大限度地减少协议参数注册表或当前位于iana.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、RIRs和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)
IETF主席Jari Arkko（报告情况摘要）
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>
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,
IANAPLAN工作组讨论了ICG的协调问题。工作组认为，
informal coordination exists today and will continue, which is consistent with the commitment requested by the 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、RIRs和其他各方协调，共同投资于互联网注册中心的持续平稳运行。
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对icg提案的评论/。
Jari Arkko, IETF Chair and the Area Director for the IANAPLAN WG
Jari Arkko，IETF主席和IANAPLAN工作组区域主任
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
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 Herndon，弗吉尼亚州，美利坚合众国，20170
Email: housley@vigilsec.com
Email: housley@vigilsec.com