Skip to main content
Resources

NTIA移交IANA职能管理权

提案制定流程和后续步骤 [PDF, 406 KB]

提案制定流程和后续步骤

概述

2014年3月14日,美国国家电信和信息管理局(NTIA) 宣布有意将互联网号码分配机构(IANA)的职能管理权移交至全球多利益相关方社群。NTIA请求互联网名称与数字地址分配机构(ICANN)作为IANA职能承包商和全球域名系统(DNS)协调人,召集多利益相关方来制定一套移交提案。NTIA在深入考察利益相关方和IANA职能的直接服务对象以解决技术细节问题时,建立了一套引导讨论话题的明确框架,并告知ICANN该移交提案必须获得广泛的社群支持,并符合以下四大原则:

  • 支持和加强多利益相关方模型;
  • 维护互联网域名系统的安全、稳定和弹性;
  • 满足IANA服务全球客户和合作伙伴的需求和期望;和
  • 维护互联网的开放性。

NTIA将不会接受采用以一家政府主导或一家政府间组织来取代NTIA的职责的解决方案。

NTIA发表声明后不久,ICANN启动了一套多利益相关方流程,并讨论如何汇集社群针对移交流程的原则和机制提出的观点和建议。1基于社群提出的初步反馈, 《就NTIA移交IANA职能管理权的提案制定的原则、机制和流程草案广泛征询公众意见》一文已于4月8日发表,并在2014年5月8日前接受公众评议。同时还发表了 范畴文件,以确定流程范畴。

现已获得的针对提案草案的 各类评论均一致强调了透明、包容、具代表性、自下而上的多利益相关方流程的重要性。

本文确定了后续步骤,并对社群建议进行了概述,包括:

  • 社群对组建协调小组(此前建议为“指导小组”)的基本看法;
  • 号召协调小组内的相应社群成员启动内部流程选择其代表人;
  • 社群对与协调小组工作相关的主题(根据适当情况供考量或使用)的基本看法。

值得注意的是,在对NTIA移交IANA职能管理权的讨论中,社群还谈及了一个更为宽泛的话题,即该移交事务对ICANN问责制所带来的影响。重要的是,在社群制定NTIA管理权移交提案的过程中,社群还必须独立应对ICANN问责制这一问题。因此,ICANN另行启动了一项流程,讨论在ICANN原有的签约方美国政府退出合同、不做后盾后,ICANN将如何继续推进其问责制,以及在这样的情况下,ICANN整个组织的问责机制的问题。这些流程都是相互独立(请参见这两个流程的时间表和关系图)。 促进ICANN问责制流程一文已于2014年5月6日正式发表。

行动计划:征召人员组建协调小组

  • 敦促协调小组中的代表社群启动内部流程,根据分配席位选出他们的代表人。
  • 候选人名单应于世界协调时2014年7月2日晚23:59时前通过提交表格的形式提供,该信息将发布到网上。
  • 现鼓励社群在ICANN第50届伦敦会议(2014年6月22日至26日)结束前选出最终候选人。
  • 协调小组将于7月中旬(暂定7月16至18日)确定其运营模式和工作方式,并启动相关工作。
  • 为了确保流程开放透明,协调小组的所有会议均面向全球利益相关方开放;相关会议文稿和录音也将在网站上发布。

针对意见征询和后续步骤的基本看法

在制定NTIA移交IANA职能管理权提案的过程中,ICANN作为这一多利益相关方流程的召集人,在2014年4月8日至5月8日期间,针对社群提出的 《就NTIA移交IANA职能管理权的提案制定的原则、机制和流程草案广泛征询公众意见》 一文征询公众意见,组织对话。

提案草案描述了一系列原则和机制、提出了一套拟定流程,包括需要进一步讨论的问题和活动时间表。与此同时还发表了 范畴文件,以确定流程范畴。

多数意见反映了五花八门的观点,但这也体现了全球多利益相关方社群的多样化。2除了书面评论以外,社群之间的对话也加深了人们对IANA职能、DNS和协议注册的理解。

针对协调小组的组建和修订构成的评论,以及针对ICANN担任该流程召集人和协调人的评论,均应秉持着中立态度,针对所有内容的概述请参见下文。

针对协调小组的角色和责任的基本看法旨在作为对协调小组及其工作的建议,符合其 工作范畴。即,该文件并未规定该协调小组的角色与职责。协调小组可在工作中自行考虑是否采纳建议,以确定其运营模式和工作方式。针对范畴或ICANN问责制而提出的意见并不在此处反映。范畴文件提出了本流程的重点。

本流程中立即需要采纳的后续步骤包括征召候选人员组建协调小组。敦促协调小组中的代表社群启动内部流程,在ICANN第50届伦敦会议截止前,根据分配席位选出他们的代表人。提交截止日期为:世界协调时2014年7月2日23:59时。入选候选人将预计在2014年7月中旬(暂定7月16至18日)会面,开始制定运营模式和工作方式。ICANN将提供必要设施和资源。

协调小组将负责根据受到IANA职能影响的各方的不同需求,编制一套移交提案。它还将负责搜集来自不同社群的意见,将其整合进一份提案中,从而满足NTIA提出的标准。换句话说,该小组必须能够获得广泛的社群支持,并遵守以下四大原则:

  • 支持和加强多利益相关方模型;
  • 维护互联网域名系统的安全、稳定和弹性;
  • 满足IANA服务全球客户和合作伙伴的需求和期望;和
  • 维护互联网的开放性。

NTIA将不会接受采用以一家政府主导或一家政府间组织来取代NTIA的职责的解决方案。

一旦提案制定完毕,ICANN将对该提案进行审核,确保其符合既定的框架和标准,并就以下事项做出决定:1)遵守NTIA的原则,和 2)符合社群建议中提出的各项原则。NTIA对是否考虑并(根据适当情况)接受提案拥有专属权。ICANN对该流程是否满足上述要求的评估意见将纳入到本提案中。

协调小组的成员选择和构成

成员选择和构成的原版和修订版比较请参见 附件 I。

“指导小组”更名为“协调小组”

为了反映一系列意见中提出的担忧,认为“指导”一词并不能够恰当地反映该小组的职能,现提议将“指导小组”更名为“协调小组”。3

对协调小组的拟定选取机制和构成做出的调整

针对协调小组的选取方式和构成一题获得了许多社群建议。大部分的建议都指出,从受影响方和未受影响方中选出成员的各种方式中存在着较大差异,并号召采取更为直接的代表选取模式。许多人支持4 由全体社群选出成员的方式。

为了消除担忧、实现更广的平衡,修订后的选择机制能够:

  • 消除受影响和非受影响方之间的区别;5
  • 赋予相关社群通过内部流程选取其协调小组代表人的责任;6
  • ICANN董事会主席和GAC主席不再选取小组的成员;7
  • 极力敦促社群在进行选取时,遵守多样化的标准。8

在协调小组的代表方面,许多意见都9 表示希望小组构成能够代表IANA职能客户、更为广泛的用户社群、以及来自技术界、政府、公民社会和商业社群的利益相关方。各类评论均表示,扩大协商基础,将ICANN和技术社群以外的相关方也纳入进来,将能够确保获得最高水平的全球支持。

修订措辞:

  • 联系ICANN社群以外的相关方,将IANA客户纳入进来,并与互联网组织建立合作关系10
  • 将来自国家和地区代码顶级域名(ccTLD)11 和顶级域名(TLD)12 注册局的代表纳入进来;
  • 许多评论还指出要增加来自GNSO社群的代表人数13
  • 处理一些评论意见,这些评论14 认为来自IP号码社群的代表过多,应对其进行调整,平衡来自地址支持组织(ASO)和号码资源组织(NRO)的代表人数;
  • 将ICANN以外的更多的跨行业商业代表纳入进来; 15
  • 为了提供有关IANA职能的资源信息,应当将一名联系人的职位替换成一名专属IANA员工专家;
  • 留存ICANN社群以外的用户社群代表权。

协调小组构成

本协调小组将由27名个人成员构成,这些成员将由他们各自所属的社群和流程选取出来。敦促大家严格遵守多样化的标准,防止出现任何利益冲突。

协调小组构成(请参见图表):

协调小组构成

代表社群

席位

一般会员咨询委员会(ALAC

2

地址支持组织(ASO

1

国家和地区代码支持组织(ccNSO 和非-ccNSO 国家和地区代码顶级域名 [ccTLD] 运营商,由ccNSO选取)

4

通用名称支持组织(GNSO)来自非注册局社群的GNSO代表席位

3

通用顶级域名注册局(gTLD注册局)

2

政府咨询委员会(GAC

2

国际商会/商界支持信息社会行动组织(ICC/BASIS

1

互联网架构委员会(IAB

2

互联网工程任务组(IETF

2

互联网协会(ISOC

2

号码资源组织(NRO

2

根服务器系统咨询委员会(RSSAC

2

安全和稳定咨询委员会(SSAC

2

总数

27

协调小组下将设两名联系人:

  • 针对ICANN的召集人职责设立ICANN董事会联系人;
  • 另一名联系人则是一名专业的IANA员工专家,以提供所需信息。

此外,建议中还参考了:

支持服务

该协调小组将由一个小型独立秘书处提供支持(由ICANN出资,通过公开流程选取),从而为该小组提供行政和后勤支持,整合社群提交的建议和意见。

合作与外展

通过与相关组织建立伙伴关系,合作与外展工作正在全球范围内如火如荼地展开。 活动时间表是这类活动清单的范例,但并不囊括所有内容。协调小组和相关组织应致力于在制定其合作战略时,确保充分推进外展和16合作。

预算

许多评论认为,应当设立一份公众可查看17和访问的预算,确保流程完全透明。

差旅补助

协调小组成员将不会获得报酬。但依据旅行者的请求,按照ICANN社群差旅补助规则指南的规定,协调小组成员在参加协调小组会议时的差旅、住宿和餐饮成本将由ICANN负责支付。

获得补助的旅行者必须从ICANN授权旅行社那里订购机票,该机票账单将直接发送至ICANN。根据每位获得补助的旅行者的授权抵达和出发日期,ICANN将为每人安排并支付每次具体会议的酒店住宿费用和税费。ICANN仅负责预订并支付不可退票的、费用最低最合理的经济舱机票。参会期间所需费用和其他合理杂费将可以申请报销。

如有其他问题,或需要进行必要的差旅安排,请联系:cgtravel@icann.org

针对协调小组的原则、机制和责任的基本看法。

此外,许多评论还针对协调小组的原则、机制和责任提出了看法。这些看法请见下文,它们将作为向协调小组提出的建议。原版和修订版流程的比较请参见附件 I。 原则和机制

大家一致认为,拟定的原则和机制18体现了恰当的特性,以确保设立一套公开、兼容、透明和负责的流程,并通过自下而上的方式推行。19根据多项建议的要求,现将多样化原则加入到这一20清单,使得该流程更具合理性。 这不仅符合移交流程的全球范畴,还符合多利益相关方模型的价值观。暂未添加任何新的机制。

原则

机制

  • 包容性
  • 透明性
  • 全球性
  • 问责制
  • 多利益相关方
  • 关注范畴
  • 注重实用性和实证性
  • 向所有声音开放
  • 避免伤害(维护安全性、稳定性和弹性)
  • 以共识为基础
  • 多样性
  • 以网络为平台
  • 工作方式
  • 有组织的对话
  • 现有信息和流程
  • 压力测试
  • 清晰可见的时间表
  • 对其他领域的讨论
  • 采取广泛参与的合作平台
  • 多语言支持
  • 多种评论场所

独立秘书处

许多评论中都强调了设立一个由非ICANN员工管理的独立21秘书处的重要性,为协调小组的工作提供支持。独立秘书处(由ICANN出资)将根据需要和适当情况,提供行政和其他支持。作为召集人,ICANN致力于在整个流程中秉持公正无私的态度。

社群建议的协调小组角色和职责

如上文所述,我们暂时还没有针对小组的角色和职责所做的评论进行任何处理。以下是社群提出的建议清单(并未囊括全部内容)22 ,供协调小组自行决定是否加以考量或使用:

  • 设立流程,在流程原则和机制的基础上,制定以社群为导向的提案;23
  • 在社群内外通过适当形式鼓励并促进组建广泛而多样的工作组,确保移交过程中的关键问题得到讨论,获得理解;24
  • 协调小组成员应能将各自所属社群的意见和共识向其他成员进行展示;25
  • 针对每个重叠领域,协调并确定应由哪个社群来制定移交提案(例如:每个具有特殊用途的注册局),同时确保这些领域能够得到其他社群的审核;26
  • 在相关社群内部肯定已完成的提案;27
  • 在制定移交提案过程中,定期提供有关IANA客户相关社群的进度最新报告; 28
  • 采纳以共识为基础的运营模式,并记录反对意见;29
  • 推行外展和合作;30
  • 确保协调小组中没有任何利益冲突,并能够推行适当的问责制。31

考虑到向社群发布的相关问题,本概述文件应能起到有益作用。

问题1:在制定IANA职能管理权向全球多利益相关方移交的提案的过程中,这些是否是能够指导本流程的正确原则?如不是,请说明理由,并指出还需考虑哪些其他原则?

所获评论均支持32 拟定的原则,但建议添加一条关注多样化的原则33依照这些评论,多样化原则现已添加到本流程的指导原则清单中。

问题2:在制定IANA职能管理权向全球多利益相关方移交的提案的过程中,这些是否是本流程中应当使用的正确机制?如不是,请说明理由,并指出还需考虑哪些其他机制?

所获评论基本上对拟定机制表示支持34

问题3:在制定IANA职能管理权向全球多利益相关方移交的提案的过程中,ICANN作为流程召集人是否还须考虑与可用原则和机制相关的其他因素?如是,请进行描述:

所获评论中要求ICANN维持中立角色35

问题4:在制定IANA职能管理权向全球多利益相关方移交的提案的过程中,设立一个指导小组是否是管理本流程的正确方式?如不是,请说明理由,并指出此处还需采用哪些其他方式?

评论支持这一理念,但请求调整术语表和构成36。根据所获评论,作出以下修改:

  • “指导小组”一词已经修订为“协调小组”,从而更加准确地反映该小组的预期职责和目的37
  • 受影响方的类型区别现已被移除,这是因为这方面并未达成共识意见38
  • 小组的构成已经按上述方式进行了修改。
  • 鉴于评论中要求采取以社群为基础的选取流程,因而重新设计了代表选取流程,使得社群成员得以选取其代表人39。加强多样化标准,以反映目前就多样化提出的各类评论40

问题5:在制定IANA职能管理权向全球多利益相关方移交的提案的过程中,上文中描述的设立一个指导小组并启动运营以管理该流程的步骤是否正确?如不是,请说明理由,并指出还缺少哪些步骤?

评论中指出,小组的运营模式应当以共识为基础,但记录任何反对意见。41

问题6:在制定IANA职能管理权向全球多利益相关方移交的提案的过程中,ICANN作为流程召集人是否还须考虑与设立指导小组管理本流程相关的其他因素?如是,请进行描述。

评论中建议成立一个独立的、非ICANN管理的秘书处42。收到这类评论后,提案中强调要按照上述要求设立一个由ICANN出资的独立秘书处。

时间表

Transition Timeline

协调小组构成

附件 I

类型

原始建议文本

修订文本

(将社群建议纳入进来,供协调小组参考)

术语表

指导小组

协调小组

原则和机制

  • 包容性
  • 透明性
  • 全球性
  • 问责制
  • 多利益相关方
  • 关注范畴
  • 注重实用性和实证性
  • 开放性[所有人均可发表看法]
  • 无害性
  • 以共识为基础
  • 添加“多样性”至原则清单。
  • 避免伤害得到进一步界定“(维护安全性、稳定性和弹性)。”

构成

  1. 支持组织/咨询委员会和受影响方之间的区别。
  2. 22个席位,1名联系人
  3. 2名ALAC代表
  4. 2名GAC代表
  5. 2名RSSAC代表
  6. 2名SSAC代表
  7. 2名GNSO代表
  8. 2名ASO代表
  9. 2名IETF代表
  10. 2名IAB代表
  11. 2名NRO代表
  12. 2名ISOC代表
  13. 2名ccNSO代表
  14. 不适用
  15. 不适用
  16. 1名ICANN董事会联系人
  17. 不适用
  1. 无区别
  2. 27个席位、1名联系人、1名专家
  3. 2名ALAC代表
  4. 2名GAC代表
  5. 2名RSSAC代表
  6. 2名SSAC代表
  7. 3名来自非注册局社群的GNSO代表
  8. 1名ASO代表
  9. 2名IETF代表
  10. 2名IAB代表
  11. 2名NRO代表
  12. 2名ISOC代表
  13. 4名来自ccNSO和非-ccNSO ccTLD运营商的代表
  14. 2名gTLD注册局代表
  15. 1名ICC/BASIS代表
  16. 1名ICANN董事会联系人
  17. 1名专业IANA员工专家,按需提供相关信息。

选取

ICANN董事会主席和GAC主席选取‘未受影响方’的小组成员。

社群自行选取各自代表。

运营模式

以共识为基础。

以共识为基础,记录反对意见。

支持

ICANN秘书处。

该协调小组将由一个独立秘书处提供支持(由ICANN出资,通过公开流程选取),从而为该小组提供行政和后勤支持,整合社群提交的建议和意见。该秘书处可能还会根据协调小组的要求提供其他服务。

日历

a. 与流程相关的活动时间表。

b. ICANN第50届会议:组建协调小组。

a. 参与性日历表(社群得以选择活动添加至个人日历)。

b. 候选人名单应在世界协调时2014年7月2日晚23:59时前提交。协调小组将于7月中旬(暂定7月16至18日)确定其运营模式和工作方式,并启动相关工作。

职责

指导小组的职责是:协调并确保按照适当的方式推进本流程。受到影响的相关方将指导各自社群的相关流程,以确定任何适当的必要机制。然而,指导小组必须协调这些结果,并将其整合到整体拟定机制中去。

指导小组还将确立一套流程,制定以社群为主导的提案。

由协调小组确定。针对这一主题获得的社群反馈应视作建议。


1 在ICANN第49届新加坡会议 3月24日举行的一场会议上,ICANN启动了一套多利益相关方流程,以搜集社群的看法与意见,讨论如何制定NTIA移交IANA职能管理权的机制。除了ICANN召开的公共会议以外, 我们还同时在网上接受 公众意见,并在NETMundial大会上召开了 一场会议,讨论这一流程。

2 公众意见完整清单请查看公开 存档 ,即 ianatransition@icann.org 邮件清单,该邮件清单机制的设立旨在用以搜集社群意见。

3 意见征询期间,评论者表示,本文措辞应当偏中性。例如, 商业选区(BC)指出:“ICANN管理提案流程,组建‘指导委员会’这种措辞是对ICANN作为召集人职责的误解。为了确保ICANN在这一流程中保持作为召集人的客观性和可信度,ICANN必须处在一个中立的角色。因而更为恰当的标题应为:‘召集委员会’或‘协调委员会’。互联网架构委员会(IAB)也指出,该小组应更名为‘协调小组’或类似名称,因为‘指导’一词不能恰当地描述该小组的职能。”

4 建议中均强调,通过社群进行选择的重要性。例如, 非商业利益相关方团体(NCSG)指出:“协调小组应由社群来领导,且小组成员的任命无须得到ICANN董事会或GAC主席的批准。”请参见范例中有关补救 auDARySGCENTR.之间不一致内容的评论。

5 许多建议都表示,社群中必须要有受影响方的代表。例如, 注册局利益相关方团体(RySG)指出:“我们认为这一清单并不完整,因为它并未纳入IANA职能的直接客户,例如:gTLD、nTLD和ccTLD注册局,这使我们很费解,似乎该清单仅适用于召集人本身”。

6 意见征询期间,人们认为各大社群有必要通过内部流程选取其协调小组代表人。 拉丁美洲和加勒比海地区顶级域名(LACTLD) 指出:“每个受到影响的社群都是IANA职能(例如:协议、域名和号码)的客户,我们支持这些受影响方通过内部流程讨论并选用他们的自身机制和代表流程,并将其整合进‘指导委员会’中。”

7 大部分评论都反对候选人名单由董事会主席和GAC主席提出。例如, 欧洲国家顶级域名注册局理事会(CENTR)指出:“在指导小组的成员选取方面,ICANN和GAC不应作为守门人。”

8 许多评论均号召遵循多样化的原则,因此现将这一原则确立为一个关键选取要求。例如, 中国网络信息中心(CNNIC)指出:“我们想再次强调‘多样化’原则的重要性。特别地,我们十分担忧该指导小组的成员多样化问题,他们是否能够反映地域多样化和发展水平多样化。”

9 正如 美国国际工商理事会(USCIB)指出的:“决策流程和协商/评论流程均应包含那些将会受到移交流程影响的非ICANN成员。”另请参见来自以下机构的评论意见: 日本网络信息中心(JPNIC)软件和信息产业协会(SIIA)美国国际工商理事会(USCIB)美国商务部

10 同前, 脚注 5。

11请参见范例:以下组织支持将ccNSO和ccTLD注册局的代表纳入到协调小组中去: CENTRCIRA亚太国家和地区代码顶级域名理事会(APTLD)。例如, CIRA指出:“作为IANA的直接客户,ccTLD运营商必须能在整个移交协调和管理流程中起到完全而直接的作用,至少要能够和号码和地址社群中的利益相关方们一样拥有平等的参与机会。”

12 参见范例:以下组织要求gTLD的代表权: ARIDNAInternetNZARI指出:“目前的小组构成也没有充足地体现来自gTLD注册局运营商的代表权,而它们也在NTIA的声明中被视为是受影响方。”

13 谷歌(Google)公司明确指出:“[…] 限制通用名称支持组织(GNSO)只派出两名代表是远远不够的,因此应当增加来自GNSO的代表人数。GNSO理事会目前由23名代表构成,代表着来自ICANN旗下的不同利益相关方团体——包括来自商业利益、注册局、注册商和非商业利益相关方的代表。为了确保在IANA的讨论中,这些社群的重要观点能够得到更为平等的代表权,我们建议将这一人数增加到四名[…]”。

14 参见范例:以下组织和个人提出要精简来自地址社群的代表人数: 知识产权选区(IPC)戴维•康纳德(David Conrad)。戴维•康纳德指出:“在组建指导小组的描述中指出,地址社群拥有四名代表(2名来自ASO和2名来自NRO,但根据ASO的《理解备忘录》,第1条是相同的)。”

15 参见范例:以下组织要求纳入更多来自商界的代表: JPNICSIIA美国商会美国商会特别指出:“为了确保真正能够实现兼容并蓄,我们建议该指导委员会纳入更多来自商业社群的代表。”

16 参见范例: 波斯互联网治理论坛(Persian IGF)USCIB此前发表评论指出:“[…]在代表不够充分的地区,通过扩大合作与参与,支持与在互联网治理领域相当活跃的组织和项目加强合作。”

17 参见范例:戴维•康纳德请求“公开预算(及其构成)。”

18 拟定的原则和机制是在基于在ICANN第49届新加坡会议(2014年3月23日至27日)上获得的反馈意见,并参考成功的社群制定的流程和机制而最终确定下来,包括对《义务确认书》(AoC)的流程进行审核。

19 许多评论者都认为拟定的原则和机制是恰当的。 SIIA auDA波兰管理和数字化部(Polish Ministry of Administration and Digitization)印度国际商标协会(INTA)均特别强调了某些具体的原则和/或机制。

20 同前, 脚注 8。

21 为了履行ICANN作为一名中立召集人的承诺,评论者要求该秘书处也应独立于ICANN的员工, InternetNZ还特别指出:“员工资源应当独立于ICANN,由指导小组自行聘请,但ICANN应当提供资金。”

22 请参见链接查看以下组织针对协调小组的角色和职责提出的看法: ARIIAB艾芙里•多利亚(Avri Doria)CENTR (并未囊括全部内容)。

23 IAB 提议,“自移交流程讨论之初起,应当允许所有相关社群充分利用其现有的以社群为导向、以共识为基础的流程。”

24 艾芙里•多利亚(Avri Doria)指出:“ICANN流程中的缺漏之一是:确立广泛而多样的工作组,以真正讨论和理解这一移交流程中的关键问题。这一点需要得到社群的集中讨论”。

25 这一建议由 IAB提出:“协调小组成员在制定移交提案过程中的职责应当限制在[…] 向其他协调小组成员反映其所在社群所提出的共识意见上。”

26 这一建议由 IAB提出:“协调小组成员在制定移交提案的过程中的职责应当限制在[…]协调哪个社群应当制定某一重叠领域的移交流程(例如:每个具有特殊用途的注册局),并同时确保这些领域能够得到其他社群的审核[...]

27 这一建议由 IAB提出:“首先,当三大社群中的协调小组成员完成了报告,并表明‘本社群一致支持该拟定提案’后,即可视为第一步已经完成。”

28 IAB 建议:“协调小组应定期发布进度报告,使得对此感兴趣的相关方们能够了解最新进展。”这一建议获得了以下组织的支持: SIIALACTLDAPTLD

29 人们普遍支持以共识为基础的运营方式,并号召确立记录任何反对意见的流程,正如 IAB指出的:“为了避免出现以偏概全[...] ,协调小组应当采取基本共识的原则,并公开记录导致无法实现完全共识的反对意见。”

30 各方意见均一致表示,在整个流程中,外展和合作至关重要。

31 评论者强调,这一流程需要获得来自全球利益相关方社群的意见。例如, 国际互联网协会(ISOC)指出:“鉴于问题的复杂性和观点的多样性,这一流程应能方便地进行适时调整,并有能力应对来自所有利益相关方的看法和需求,这是至关重要的。”

32 例如, 波兰管理和数字化部指出:“我们支持本流程的各项原则。”

33 同前, 脚注 8。

34 例如, 号码资源组织(NRO)表示:“NRO支持拟定的指导原则和机制[…]。我们认为它们与本社群内部这类流程的既定规则相一致,并符合目前从ICANN社群获取的大部分建议。”

35 评论者强调ICANN必须秉持中立态度。例如, 商业选区(BC)指出:“为了确保ICANN在这一流程中保持作为召集人的客观性和可信度,ICANN必须处在一个中立的角色。”

36 同前, 脚注 5。

37 同前, 脚注 3。

38 同前, 脚注 5。

39 同前,脚注 4。

40 同前, 脚注 8。

41 人们普遍支持以共识为基础的运营方式,并号召确立记录任何反对意见的流程,正如 IAB指出的:“为了避免出现以偏概全[...] ,协调小组应当采取基本共识的原则,并公开记录导致无法实现完全共识的反对意见。”

42 同前, 脚注 22。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."