自互联网名称与数字地址分配机构 (ICANN) 于 1998 年成立以来，NTIA 即与 ICANN 签署了 IANA 职能执行协议，具体包括：管理域名、互联网协议地址、相关数字标识符和协议参数的顶级注册管理机构。在这份合同下，NTIA 负责批准对互联网域名系统 (DNS) 中权威根区文件进行的修改。NTIA 还与威瑞信公司 (Verisign) 签署了一份《合作协议》，要求该公司执行根区管理的相关职能。

2014 年 3 月 14 日，NTIA 宣布有意将其对这些互联网关键职能的管理权移交给全球互联网社群。NTIA 将这一具有历史意义的职责移交出去意味着美国政府终于迈出了其在 1997-98 年间出台的政策声明中的最后一步，即移交对域名系统的监督权。

如需更多有关 IANA 职能的信息，请参见：

• IANA 简介
• IANA：机构人员、职能范围和组织使命分别是什么？
• IANA 职能概览和历史回顾
• SSAC 针对《IANA 职能合同》的报告

移交提案的制定流程由 2014 年 7 月成立的 IANA 管理权移交协调小组 (ICG) 负责领导和协调。

ICG 选择将提案制定的流程下放到与 IANA 职能运营商具有直接运营或服务联系的三大社群。这三大”运营社群 (OC)”即：域名社群（团结在 ICANN 的支持组织和咨询委员会周围）；号码资源社群（团结在地区地址注册管理机构周围）；协议参数社群（团结在互联网工程任务组周围）。

2014 年 9 月 8 日，ICG 发布了《提案征询 (RFP)》，并向各大社群提供了一份参考模版。各社群则针对与其相关的 IANA 职能，通过自身流程编制了一份提案并提交给了 ICG。然后，ICG 根据一系列标准（包括 NTIA 确立的移交标准）对这些提案进行了评估。

本移交提案包含了三大运营社群分别提交的提案。

与上述流程平行存在的是加强 ICANN 问责制跨社群工作组 (CCWG) 的流程。该工作组现已制定了一份提案，确保美国政府退出合同监督权后，ICANN 能够继续履行其责任。这份问责制提案并不直接涉及 IANA 职能的治理，但必须能够获得广泛的社群支持，才能使得 IANA 移交顺利进行。CCWG 制定的 ICANN 层级问责机制的具体推行工作与移交提案中的域名部分有着紧密联系，是该提案的移交条件。ICG 也正在就本提案域名部分的内容征询公众意见。

CCWG 也已发布问责制提案，并启动了公共评议期，截止时间为 2015 年 9月 12 日。

任何有关问责制提案的评论应当提交给 CCWG。任何有关移交提案的评论应当提交给 ICG。

一旦 CCWG 完成了问责制提案的编制工作，ICG 将请求域名社群确认其提案中的要求均已得到满足，并要求该社群对其提案进行最终调整并定稿。

针对移交提案提交评论的公众必须注意：域名提案中的部分内容与 CCWG 的工作成果紧密相关，且将在 CCWG 的工作中得到满足。

运营社群的每份提案已经经历了广泛而深入的公共评论和讨论流程。ICG 启动本轮公共评议期旨在针对整合后的提案、及该提案是否达到了 NTIA 所提的移交标准这两个主题征询公众意见。关键的是，ICG 需要创建一套公开记录，反映社群对本提案的广泛支持，从而展示本提案在提交给 NTIA 之前，已经满足了 NTIA 的标准。因此，即使您对本提案没有其他意见，我们也鼓励您能够发表评论支持本提案。

ICG 希望就以下具体问题征询公众意见。

关于整体提案的问题

1. 完整性和清晰性：整合提案是否完整？运营社群提交的每份提案都包括在未来实施阶段需要完成的方面。整合提案是否提供了充足的细节，可以使用 NTIA 所提标准对其评估呢？
2. 兼容性和互用性：所有运营社群提交的提案是否能够被整合成一份独立的提案呢？是否会出现不兼容的情况，需要进行兼容性调整呢？各职能间出现的冲突是否能够通过可行的方式得到解决？
3. 问责制：所有运营社群的提案整合起来是否能够提供适当且适用的、能够运营 IANA 职能的独立问责机制呢？在这份整合提案中，总体问责机制中是否还有任何缺漏？
4. 可行性：针对运营社群提案进行的可行性测试或评估结果是否出现了冲突，或在整合提案的过程中会造成潜在的担忧呢？

关于 NTIA 所提标准的问题

5. 您是否认为本提案支持并加强了多利益相关方模型？如果是，请解释原因。如果不是，请解释原因，并指明您认为本提案需要进行哪些修改。
6. 您是否认为本提案维护了域名系统的安全、稳定和弹性？如果是，请解释原因。如果不是，请解释原因，并指明您认为本提案需要进行哪些修改。
7. 您是否认为本提案满足了 IANA 服务全球客户和合作伙伴的需求和期望？如果是，请解释原因。如果不是，请解释原因，并指明您认为本提案需要进行哪些修改。如果您是一名 IANA 服务的客户或合作伙伴，请表明身份。
8. 您是否认为本提案维护了互联网的开放性？如果是，请解释原因。如果不是，请解释原因，并指明您认为本提案需要进行哪些修改。
9. 您是否担忧本提案将使得一国政府或一家政府间组织替代 NTIA 的职责？如果是，请解释原因，并指明您认为本提案需要进行哪些修改。如果不是，请解释原因。
10. 您是否认为本提案的实施工作将在未来继续遵循 NTIA 提出的标准？如果是，请解释原因。如果不是，请解释原因，并指明您认为本提案需要进行哪些修改。

关于 ICG 报告和执行摘要的问题

11. 您是否认为 ICG 报告和执行摘要准确地反映了整合提案的所有必要信息？如果不是，请解释您认为需要进行哪些修改。

一般问题

12. 您是否希望向 ICG 提一些关于这份提案的一般评论？

域名社群提议成立一个新的独立法律实体，即”移交后 IANA (PTI)”。该实体将作为 ICANN 的下属机构（子机构），并与 ICANN 订立合同承接 IANA 职能的运营工作。ICANN 所在地的法定管辖权仍旧保持不变。提案内容还包括：成立客户常任委员会 (CSC)，根据合同要求和服务水平期望负责监督运营商的工作绩效。提案还提议建立一套以多利益相关方为基础的 IANA 职能审核流程 (IFR)，对 PTI 进行审核。

号码社群提议：ICANN 继续担任 IANA 职能运营商，与五大地区互联网注册管理机构 (RIR) 订立协议，提供这类服务。号码社群提议：地区互联网注册管理机构和 IANA 号码服务运营商应签署一份具有合同性质的服务水平协议 (SLA)；一个由来自各大区域的社群代表构成的审核委员会 (RC) 将负责就 IANA 职能运营商的绩效及其对认定服务水平的遵守情况，向 RIR 提出咨询建议。

就协议参数来说，ICANN 目前充当着 IANA 注册管理机构的运营商。IETF 社群表示对目前的安排感到满意，并提议按照过去十几年来的惯例，确保继续日复一日地执行对 IANA 协议参数注册管理机构的调整。协议参数社群提议继续依赖由 IETF、ICANN 和 IAB 制定的与协议参数相关的、用于规范 IANA 职能的协议、政策和监督机制。

整合提案中的监督机制构成请参见以下图表。各大社群与 IANA 职能运营商之间的运营互动并未在本图中展现。

运营社群的每份提案已经经历了广泛而深入的公共评论和讨论流程。

CWG——管理权

• 第 1 轮公共评议期：2014 年 12 月 1 日至 2014 年 12 月 22 日
• 第 2 轮公共评议期：2015 年 4 月 22 日至 2015 年 5 月 20 日（非英文评论发表截止时间被延长至 5 月 26 日）。

CRISP 团队

• 草案第 1 版公共评议期：2014 年 12 月 19 日至 2015 年 1 月 5 日
• 草案第 2 版公共评议期：2015 年 1 月 8 日至 2015 年 1 月 12 日
• 公开存档所有已搜集的反馈意见

IANAPLAN 工作组

• 工作组最后一次征询公众意见
• 文件管理人针对工作组共识意见编写的摘要
• IETF 最后一次征询公众意见：2014 年 11 月 26 日至 2014 年 12 月 15 日

IETF 最后一次公众意见征询摘要