Skip to main content
Resources

批准的董事会决议 | ICANN 董事会例行会议

本页面还提供其他语种:

本文档已翻译为多种语言,仅供参考之用。原始官方版本(英文版)可在以下位置找到:https://www.icann.org/resources/board-material/resolutions-2016-09-15-en

  1. 认可议程:
    1. 实施 RSSAC 003 中关于 KSK 签名有效期的建议
    2. 授权代表孟加拉国的孟加拉文域名 .বাংলা(“bangla”)
    3. 2018 年 10 月 ICANN 会议会场和举办地签约
    4. 任命 2017 年提名委员会主席和候任主席
  2. 主要议程:
    1. ICANN 和 PTI 之间的 IANA 域名职能合同
    2. ICANN 和 PTI 之间的服务协议
    3. .COM 注册管理机构协议修正案
    4. PTI 治理事项 — 采纳 PTI 章程;任命首届 PTI 董事会董事;任命 PTI 总裁
    5. 进一步考虑 Dot Registry IRP《最终声明》
    6. 考虑关于 dotgay, LLC 申请 .GAY 的监察官报告
    7. 重审请求 16-3 (dotgay LLC)
    8. 其他事务

 

  1. 认可议程:

    1. 实施 RSSAC 003 中关于 KSK 签名有效期的建议

      鉴于 2015 年 9 月 16 日,ICANN 根服务器系统咨询委员会 (RSSAC) 发布了 RSSAC0003《关于根区 TTL 的报告》。

      鉴于 RSSAC003 报告建议根区管理合作伙伴延长由密钥签名密钥 (KSK) 和域签名密钥 (ZSK) 生成的签名的有效期。而且报告进一步建议,KSK 签名有效期应延长到至少 21 天,ZSK 签名有效期应延长到至少 13 天,并且此时不应对根区 TTL 做出其他更改。

      鉴于在收到 RSSAC003 后,ICANN 工作人员对延长 KSK 签名有效期进行了可行性和成本分析,并制定了一份 KSK 实施计划供董事会审核。

      鉴于董事会已经考虑了 RSSAC 在 RSSAC003 中提出的建议以及实施 KSK 相关建议的可行性和成本。董事会了解到根区维护人也在考虑 RSSAC003 中与 ZSK 有关的建议。

      兹此发布第 2016.09.15.01 号决议:董事会采纳 RSSAC 003 中关于 KSK 签名有效期的 RSSAC 建议,并指示 ICANN 总裁兼首席执行官或其指定人员与根区管理伙伴合作,共同实施 RSSAC 003 中的 KSK 建议。

      第 2016.09.15.01 号决议的理由

      2015 年 9 月 16 日,ICANN 根服务器系统咨询委员会 (RSSAC) 发布了 RSSAC0003《关于根区 TTL 的报告》。在这份报告中,RSSAC 研究了根区 TTL(DNS“存活时间”值)以及当前根区 TTL 在多大程度上仍适合于当今的互联网环境。

      报告指出在根区“起始授权机构 (SOA) 到期”值和根区签名有效期之间的相互作用方面,存在两个潜在问题,并建议由 DNS 运营社群来解决这些问题。特别是,RSSAC 建议根区管理合作伙伴延长由密钥签名密钥 (KSK) 和域签名密钥 (ZSK) 生成的签名的有效期。KSK 签名有效期应延长到至少 21 天。ZSK 签名有效期应延长到至少 13 天。

      由于导致签名有效期问题发生的情况十分罕见,迄今为止还未出现过,而且此时即便发生也不大可能影响到最终用户。因此,RSSAC 相信这一问题并不紧急,在必要的程序文件更新和软件测试之后的合理时间内解决即可。

      收到 RSSAC003 后,ICANN 工作人员对实施 RSSAC003 中的 KSK 建议进行了可行性和成本分析,并制定了一份包含时间表和关键里程碑事件的 KSK 实施计划供董事会审核。

      董事会已经考虑了 RSSAC 在 RSSAC003 中提出的建议以及实施 KSK 相关建议的可行性和成本,并采纳了 RSSAC 003 中关于 KSK 签名有效期的 RSSAC 建议。此外,董事会还指示 ICANN 与根区管理伙伴合作,共同实施 RSSAC 003 中的 KSK 建议。

      该决议属于运营问题,无需征询公众意见。预计不会产生任何财务影响。RSSAC 建议的批准和实施将提高域名系统的安全、稳定与弹性。

      董事会了解到,NTIA 已和根区维护人威瑞信达成协议,由威瑞信更改 ZSK 的签名有效期,这项工作计划在 2016 年 9 月进行。

    2. 授权代表孟加拉国的孟加拉文域名 .বাংলা(“bangla”)

      第 2016.09.15.02 号决议:根据 IANA 职能合同中所述的职责,ICANN 已审核并评估将国家和地区顶级域 .বাংলা 授权给孟加拉国邮电通信与信息技术部邮电通信局的申请。文件材料显示,在评估此申请时,工作人员严格遵守了相应流程。

      第 2016.09.15.03 号决议:董事会指示,根据《ICANN 章程》第 III 条第 5.2 款,为了履行合同义务,决议、初步报告或会议记录中的部分理由目前不宜公诸于众,应等待适当时机再予以公布。

      第 2016.09.15.02 – 2016.09.15.03 号决议的理由

      为什么董事会现在要解决此问题?

      根据 IANA 职能合同的要求,ICANN 工作人员已评估授权 ccTLD 的请求,且目前正在准备报告,以提请董事会审核。提请董事会审核的目的是确保 ICANN 工作人员严格遵守相应流程。

      正在考虑的提案是什么?

      该提案旨在批准向 IANA 提交的一项申请,该申请希望创建国家和地区顶级域并将主办组织(也称为管理者或受托者)的角色分配给孟加拉国邮电通信与信息技术部下属的邮电通信局。

      咨询了哪些利益相关方或其他方?

      在授权申请的评估过程中,ICANN 工作人员咨询了申请人和其他利益相关方。申请过程要求申请人说明其就此 ccTLD 在国内与其他方展开的磋商,并阐述其在本地互联网社群中的适用性。

      社群提出了哪些疑虑或问题?

      工作人员未收到社群成员就此申请提出的重大问题或疑虑。

      董事会审核了哪些重要材料?

      [已删减 — 敏感授权信息]

      董事会认为至关重要的因素有哪些?

      董事会未发现此申请存在任何特定隐患。

      是否会对社群产生积极或者消极影响?

      及时批准符合各种公共利益标准的国家和地区域名经理人对于 ICANN 整体工作会有积极影响,对于此类国家和地区顶级域所服务的当地社群也会有积极作用,同时还可体现 ICANN 积极履行 IANA 职能合同中所述的职责。

      是否会在财务方面对 ICANN(战略规划、运营规划、预算)、社群和/或公众产生影响或不良后果?

      管理 DNS 根区域中的国家或地区代码授权是 IANA 的职责,授权行动不会对预先计划的开支有任何重大影响。评估国家和地区顶级域在特定国家或地区内部所产生的财务影响并不是 ICANN 的职责。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题?

      ICANN 认为此申请不会对安全、稳定或弹性造成明显不利影响。这属于组织管理职能,无需征询公众意见。

    3. 2018 年 10 月 ICANN 会议会场和举办地签约

      鉴于 ICANN 拟将 2018 年第三场公共会议的地点选在欧洲地区。

      鉴于工作人员已完成了对欧洲所有拟议会场的全面评估,认为西班牙巴塞罗那的一个会场最为合适。

      兹此发布第 2016.09.15.04 号决议:董事会授权总裁兼首席执行官或其指定人员参与并促进与 2018 年 10 月在西班牙巴塞罗那举办的 ICANN 公共会议的主会议中心相关的所有必要的合同签订和费用支付工作,总金额不超过[协商一致后确定的金额],并将 2018 年 10 月的 ICANN 公共会议指定为 2018 年年度大会。

      第 2016.09.15.05 号决议:出于协商目的,该决议中的具体条款应按照《ICANN 章程》第 III 条第 5.2 款的规定进行保密,保密期截至总裁兼首席执行官认为可以发布保密信息为止。

      第 2016.09.15.04 – 2016.09.15.05 号决议的理由

      作为 ICANN 公共会议日程安排的一部分,目前 ICANN 每年在世界不同地理区域(按《ICANN 章程》中的定义)召开三次会议。ICANN 第 63 届会议定于 2018 年 10 月 20-26 日在欧洲地区召开。为此,ICANN 于 2015 年 3 月 23 日发布了有关欧洲会议举办地点的建议征询书。各个相关方向 ICANN 发送了提案。工作人员对所有提案及其他会场进行了全面分析并编制了一份报告,以确定符合“会议选址标准”(参见 https://meetings.icann.org/en/host)的会场。依据提案和分析,ICANN 确认将西班牙巴塞罗那作为第 63 届 ICANN 会议的举办地。

      董事会审核了工作人员关于在西班牙巴塞罗那召开 2018 年 10 月 ICANN 公共会议以及所选设施相关成本的简报,认为提案符合“会议选址标准”的重要因素。

      主办会议并提供必要的差旅补助会对 ICANN 产生财务影响,承担会议差旅成本也会给社群带来财务影响。但是,无论会议的举办地点和会场在何处,都必须面临这些影响。此项行动不会对 DNS 的安全性或稳定性造成任何影响。

      董事会感谢对 ICANN 第 63 届会议的选址提出建议的所有人员。

      这属于组织管理职能,无需征询公众意见。

    4. 任命 2017 年提名委员会主席和候任主席

      鉴于 BGC 审核了 2017 年度提名委员会 (NomCom) 主席和候任主席的意向书,考量了 2016 年度 NomCom 领导人的全方位评估结果,并与候选人进行了面谈。

      鉴于 BGC 建议任命汉斯·彼得·赫伦 (Hans Petter Holen) 为 2017 年度 NomCom 主席,扎希德·贾米尔 (Zahid Jamil) 为 2017 年度 NomCom 候任主席。

      兹此发布第 2016.09.15.06 号决议:董事会在此任命汉斯·彼得·赫伦为 2017 年度提名委员会主席,扎希德·贾米尔为 2017 年度提名委员会候任主席。

      第 2016.09.15.06 号决议的理由

      ICANN 章程要求董事会任命提名委员会 (NomCom) 主席和候任主席。请参阅第 VII 条第 2.1 款和第 2.2 款:http://www.icann.org/en/general/bylaws.htm#VII董事会已授权董事会治理委员会 (BGC) 负责推荐 NomCom 主席和候任主席供董事会批准。(请参阅 BGC 章程:http://www.icann.org/en/committees/board-governance/charter.htm。)2016 年 5 月 24 日,BGC 发布了征求意向书 (EOI) 的公告,要求在 2016 年 6 月 10 日前提交意向书(请参阅 https://www.icann.org/news/announcement-2016-05-24-enn)。后来,意向书征求公告又将提交期限延长到了 2016 年 7 月 30 日(请参阅 https://www.icann.org/news/announcement-2016-06-10-en)。BGC 收到并审核了多份意向书,查看了 2016 年度 NomCom 领导层的全方位评估,并在提出建议前与候选人进行了面谈。董事会已考量并同意 BGC 推荐的 2017 年度 NomCom 主席和 2017 年度 NomCom 侯任主席。董事会还想感谢所有有意成为 2017 年度 NomCom 领导人并提交了意向书的人士。

      通过公开 EOI 流程选拔并任命 NomCom 主席和候任主席对 ICANN 的透明度和问责制产生了积极影响,同时符合公共利益。采纳 BGC 的建议不会对 ICANN 产生额外的财务影响,并且不会对域名系统的安全、稳定与弹性产生负面影响。

  2. 主要议程:

    1. ICANN 和 PTI 之间的 IANA 域名职能合同

      鉴于域名职能合同 <https://www.icann.org/en/system/files/files/proposed-iana-naming-function-agreement-10aug16-en.pdf> [PDF, 283 KB] 的完成满足了董事会于 2016 年 3 月 10 日批准的一揽子提案当中的一项要求,以便向全球多利益相关方社群移交 NTIA 的 IANA 职能管理权。

      鉴于起草域名职能合同旨在满足 IANA 管理权移交协调小组的 IANA 管理权移交提案中的要求。

      鉴于通过域名职能合同,ICANN 将以合同形式规定由公共技术标识符机构担任 IANA 域名职能运营商并履行 IANA 域名相关职能。

      鉴于 ICANN 已于 2016 年 8 月 10 日至 2016 年 9 月 9 日就拟定的域名职能合同征求了公众意见 <https://www.icann.org/public-comments/iana-naming-function-agreement-2016-08-10-en>。

      鉴于有关拟议域名职能合同的公众意见论坛已于 2016 年 9 月 9 日关闭,ICANN 共收到个人和组织/团队提交的八条意见。意见总结和分析已经公布 <https://www.icann.org/en/system/files/files/report-comments-iana-naming-function-agreement-15sep16-en.pdf> [PDF, 497 KB] 并提交到董事会。

      兹此发布第 2016.09.15.07 号决议:批准拟议的域名职能合同,并授权总裁兼首席执行官或其指定人员采取适当行动来最终确定并签署该协议。

      第 2016.09.15.07 号决议的理由

      为什么董事会现在要解决此问题?

      完成域名职能合同是董事会 2016 年 3 月 10 日批准的一揽子提案当中的一项要求,以便向全球多利益相关方社群移交 NTIA 的 IANA 职能管理权。自 2016 年 7 月 15 日起,ICANN 便与管理权 CWG 及其外部法律顾问合作,共同完成域名职能合同的编写。在纳入管理权 CWG 的初步意见反馈后,该协议于 2016 年 8 月 10 日公布,并启动了一项为期 30 天的公共评议期。30 天的评议期已于 2016 年 9 月 9 日结束。今天,董事会被要求考虑批准拟议的协议。

      正在考虑的提案是什么?

      拟议的域名职能合同指定 PTI 作为 IANA 域名职能运营商,并授权 PTI 履行 IANA 域名职能。该协议包含对 IANA 域名职能表现的服务水平期望,这些期望已在 ICANN 和管理权 CWG 之间达成一致。协议将在 IANA 管理权移交成功完成后立即生效。

      咨询了哪些利益相关方或其他方?

      2016 年 8 月 10 日至 2016 年 9 月 9 日,ICANN 就拟议的域名职能合同展开了一项公共评议期。ICANN 还与管理权 CWG 及其外部法律顾问密切合作,共同解决所有问题。公共评议期结束后,对收到的意见进行了总结和分析。

      社群提出了哪些疑虑或问题?

      管理权 CWG 审核过程中提出了两个主要问题。

      第一个问题是关于 ccTLD 根区管理的适用政策,由 ccTLD 社群的部分成员提出。在与 ccTLD 社群及参与管理权 CWG 讨论的 GAC 成员商议后,对协议进行了更新以体现适用的政策,其中包括:(1) ccNSO 定义的政策;以及 (2) RFC 1591(“域名系统结构和授权”),参照 2014 年 10 月《关于授权和重新授权国家和地区顶级域的当前政策与指导方针解释框架》对其作出的解释。除了这些政策外,PTI 还应适时参考 2005 政府咨询委员会有关授权与管理国家和地区顶级域的原则与指导方针。

      第二个问题也是由 ccTLD 社群的部分成员提出,即,未与 ICANN 签订合同的 ccTLD“不想指定 ICANN 来管理他们的根区条目”,并且这一点应体现在协议中。ICANN 指出,在提案中,管理权 CWG 其实希望 ICANN 和根区维护人的根区管理角色在移交后保持不变。管理权 CWG 提案第 1158 段提到:

      目前,根区更新需要三方积极参与,分别为:IFO、根区维护人和 NTIA。IFO 接收来自多个来源的调整请求,并将它们发送给根区维护人,根区维护人在得到 NTIA 授权后更新根区文件,然后 DNSSEC 签署该文件并分发给根运营商。

      移交后将仅剩 IFO 和根区维护人。管理权 CWG 不建议在此时对这两个角色所执行的职能做出任何调整。管理权 CWG 建议,如果有人提议对根区修改相关角色做出调整,则此类提案应进行广泛的社群意见征询。

      董事会审核了哪些重要材料?

      在审议过程中,董事会审核了诸多材料,包括但不限于以下材料和文档:

      董事会认为至关重要的因素有哪些?

      董事会考查了公众意见在多大程度上被纳入到了拟议的域名职能合同中。在域名职能合同附加更改的审核及确认过程中,管理权 CWG 的参与以及外部法律顾问的意见尤为重要。ICANN 同意采纳管理权 CWG 提出的修改,这有助于确保继续与 IANA 管理权移交提案保持一致。此外,董事会还考虑了协议的条款,以确保 IANA 域名职能将继续安全、稳定和可靠地运行,满足客户的需求。

      是否会对社群产生积极或者消极影响?

      拟议的域名职能合同规定 PTI 有义务安全、稳定、可靠地履行 IANA 域名职能。协议也包含对 IANA 域名职能表现的服务水平期望。董事会对拟议协议的批准,将满足由社群制定并由董事会于 2016 年 3 月 10 日批准的 IANA 管理权移交提案的一项关键要求,确保 IANA 域名职能将继续安全、稳定、可靠地运行,满足客户的需求。

      是否会在财务方面对 ICANN(战略规划、运营规划、预算)、社群和/或公众产生影响或不良后果?

      预计董事会批准拟议的域名职能合同后不会产生重大的财务影响。ICANN 将为 PTI 提供必要的服务,以便其履行此协议草案下的义务。这些服务及其相关成本在 ICANN 和 PTI 单独签署的服务协议中进行规定。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题?

      董事会批准拟议的域名职能合同,将确保 IANA 域名职能在管理权移交后继续安全、稳定、可靠地运行。

    2. ICANN 和 PTI 之间的服务协议

      鉴于服务协议 <https://www.icann.org/iana_imp_docs/111-services-agreement-v-14sep16> [DOCX, 47 KB] 的完成满足了董事会于 2016 年 3 月 10 日批准的一揽子提案当中的一项要求,以便向全球多利益相关方社群移交 NTIA 的 IANA 职能管理权。

      鉴于起草服务协议旨在满足 IANA 管理权移交协调小组的 IANA 管理权移交提案中的要求,履行 ICANN 在域名职能合同下应尽的义务。

      鉴于 ICANN 已咨询管理权 CWG、其外部法律顾问、IETF 和 RIR 的意见,以解决所有问题并最终确定协议。

      兹此发布第 2016.09.15.08 号决议:批准拟议的服务协议,并授权总裁兼首席执行官或其指定人员采取适当行动来最终确定并签署该协议。

      第 2016.09.15.08 号决议的理由

      为什么董事会现在要解决此问题?

      董事会于 2016 年 3 月 10 日批准了一揽子提案,以便向全球多利益相关方社群移交 NTIA 的 IANA 职能管理权。提案中要求 ICANN 向 PTI 提供必要的服务和资源,以便后者履行 IANA 职能。这一要求被纳入了 ICANN 和 PTI 之间的域名职能合同中。

      ICANN 已集中与管理权 CWG、其外部法律顾问、IETF 和 RIR 合作,以便对今天提交给董事会考虑和批准的服务协议进行最终确认。

      正在考虑的提案是什么?

      协议要求 ICANN 向 PTI 提供必要的服务和资源,以便后者履行 IANA 职能。

      专项资源包括目前在 ICANN 下属 IANA 部门直接开展 IANA 职能服务的员工。共享资源包括其他 ICANN 部门中开展或参与与 IANA 职能履行直接相关的流程的员工。支持服务包括 ICANN 各部门为支持 PTI 运营而提供的服务(例如人力资源、财务、采购等)。

      所有提供给 PTI 的服务和资源,费用都将从 ICANN 向 PTI 分配的拨款中支取。PTI 也将完全由 ICANN 独家资助。预计所有服务的年均成本将达到 900 万美元(基于 2017 财年预算)。

      由于涉及到专项资源,协议规定目前在 IANA 部门供职的 ICANN 员工将被借调到 PTI。协议进一步要求自协议生效之日起三 (3) 年内,PTI 须推出必要的项目、流程和政策以便将借调员工转为全职员工。前提是 PTI 提供的条件有利于这一雇用关系的转变。

      根据协议,ICANN 将尽合理努力提供服务,例如会计、沟通和人力资源等,标准与 ICANN 为自身运营所确立的服务一致。协议允许 ICANN 变更、暂停或终止某项服务的提供,但前提是此类变更、暂停或终止不会对域名系统的安全性和稳定性造成任何实质影响。例如,如果 ICANN 变更了其牙科保险产品,那么,那些在 PTI 工作的员工享受的牙科保险也应相应地变更。

      咨询了哪些利益相关方或其他方?

      由于协议是对支持 PTI 所需的特定服务和资源的详细运营承诺,因而此文件不适合公开征求意见。但是,ICANN 咨询了 IETF 和 RIR 来解决所有问题,并集中与管理权 CWG 以及外部法律顾问合作,共同完成协议的最终定稿工作。

      社群提出了哪些疑虑或问题?

      社群没有提出重大问题,因为关于条款阐述恰当性的问题大都为法律性质。

      董事会审核了哪些重要材料?

      在审议过程中,董事会审核了诸多材料,包括但不限于以下材料和文档:

      董事会认为至关重要的因素有哪些?

      董事会认为协议的要求符合 ICANN 财务规划流程,且协议为 PTI 提供了履行 IANA 职能所必需的资源。

      是否会对社群产生积极或者消极影响?

      协议确保了 PTI 将拥有必要资源来为域名、号码和协议参数社群履行 IANA 职能。

      是否会在财务方面对 ICANN(战略规划、运营规划、预算)、社群和/或公众产生影响或不良后果?

      服务费用将从 ICANN 向 PTI 的拨款中支取,换言之,PTI 完全由 ICANN 独家资助。预计所有服务的年均成本将达到 900 万美元(基于董事会批准的 ICANN 2017 财年预算 <https://www.icann.org/resources/board-material/resolutions-2016-06-25-en#2.c)。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题?

      董事会批准拟议的服务协议,将确保 PTI 拥有必要的资源,能够在管理权移交后继续安全、稳定、可靠地运行 IANA 域名职能。

    3. .COM 注册管理机构协议修正案

      鉴于 ICANN 和威瑞信讨论了 2012 年 12 月 1 日 .COM 注册管理机构协议的拟议修正案(“修正案”),并同意为增强根区运营的安全、稳定和弹性将协议期限延长至 2024 年 11 月 30 日,以便与根区维护人服务协议的期限相吻合。

      鉴于拟议的修正案也要求威瑞信和 ICANN 满怀诚意地展开合作与谈判,以便:(1) 在拟议修正案届满两周年之前修订 .COM 注册管理机构协议,从而维护并增强互联网或 TLD 的安全性;并 (2) 使其符合威瑞信和美国商务部签署的合作协议的变更。现有注册管理机构协议中的所有其他条款和条件保持不变。

      鉴于 ICANN 在 2016 年 6 月 30 日至 8 月 12 日启动了关于拟议修正案的公共评议期 <https://www.icann.org/public-comments/com-amendment-2016-06-30-en>。总共收到了由个人和组织/团队提交的九十九 (99) 条意见。

      鉴于董事会认真考虑了这些意见以及工作人员提供的意见总结和分析。

      鉴于 ICANN 根据当前 .COM 注册管理机构协议,对威瑞信的近期表现开展了一项审核,发现威瑞信大体上满足合同要求。

      兹此发布第 2016.09.15.09 号决议:只要 RZMA 得到签署,即批准拟议的 .COM 注册管理机构协议修正案 <https://www.icann.org/sites/default/files/tlds/com/com-amend-1-pdf-30jun16-en.pdf> [PDF, 100 KB],并授权总裁兼首席执行官或其指定人员采取适当行动来最终确定并签署该修正案。

      第 2016.09.15.09 号决议的理由

      为什么董事会现在要解决此问题?

      2012 年 12 月 1 日,ICANN 与威瑞信签订了注册管理机构协议,威瑞信根据此协议运营 .COM 顶级域。此协议定于 2018 年 11 月 30 日到期。ICANN 和威瑞信讨论了一项拟议的修正案,并于 2016 年 6 月 30 日至 8 月 12 日为该修正案启动了一项为期 42 天的 ICANN 公共评议期。现在,董事会决定批准拟议的修正案,延长威瑞信运营 .COM TLD 的期限。

      正在考虑的提案是什么?

      拟议的修正案:(1) 将 .COM 注册管理机构协议期限延长至 2024 年 11 月 30 日,以便与 ICANN 和威瑞信签订的根区维护人服务协议 (RZMA) 的期限相吻合;(2) 要求威瑞信和 ICANN 满怀诚意地展开合作与谈判,以便在拟议修正案届满两周年之前修订 .COM 注册管理机构协议,从而维护并增强互联网或 TLD 的安全性;(3) 要求威瑞信和 ICANN 满怀诚意地展开合作与谈判,以便修订 .COM 注册管理机构协议的条款,使其符合威瑞信和美国商务部签署的合作协议的变更。现有注册管理机构协议的所有其他条款和条件保持不变。

      咨询了哪些利益相关方或其他方?

      ICANN 与威瑞信展开了双边谈判,以期对拟议修正案的条款达成一致。而后在 2016 年 6 月 30 日至 8 月 12 日期间,对拟议的修正案公开征求了意见。公共评议期结束后,对收到的意见进行了总结和分析。

      社群提出了哪些疑虑或问题?

      在为期 42 天的公共评议期间,总共收到了由个人和组织/团队提交的 99 条意见。有的评论者总体支持拟议的修正案,还有的评论者提出了一些关切。意见总结和分析在下文提供,并且已发布到 <https://www.icann.org/en/system/files/files/report-comments-com-amendment-09sep16-en.pdf> [PDF, 200 KB]。

      董事会审核了哪些重要材料?

      在审议过程中,董事会审核了诸多材料,包括但不限于以下材料和文档:

      董事会认为至关重要的因素有哪些?

      董事会认真考虑了针对拟议修正案提出的公众意见,以及关于这些意见的总结和分析。

      董事会承认,有的评论者总体支持拟议的修正案,还有的评论者虽然表示总体支持,但也要求 ICANN 和/或威瑞信说明合作协议与拟议修正案之间的关系,特别是围绕定价方面,并说明哪些条款或议题会成为拟议的修正案生效日期届满两周年之前诚意谈判的主题。

      董事会承认,有人建议更改拟议的修正案,规定在拟议的修正案届满两周年之前必须讨论哪些条款。但董事会同时也指出,拟议修正案中的语言做到了良好的平衡,既承诺展开谈判,又留有一定余地,以便将来就在形势不断变化的情况下如何维护和增强互联网或 TLD 安全性和稳定性的相关话题进行讨论。

      关于修改拟议的修正案,以便将威瑞信与美国商务部之间合作协议的潜在变更或取消情况纳入考虑,董事会指出拟议的修正案已经将该合作协议纳入了考虑范围。拟议的修正案包含相关内容,即,要求 ICANN 和威瑞信满怀诚意地展开谈判,以便对 .COM 注册管理机构协议做出必要的更改,使其符合合作协议变更、终止或到期的情况。

      董事会还承认,有若干意见与 .COM 域名的价格有关。有的评论者建议,当前注册管理机构协议中的价格上限必须保留,还有的人建议必须降价。董事会注意到,.COM 注册管理机构协议第 7.3(d) 款规定了威瑞信可以为注册管理机构服务收取的最高价格。拟议的修正案未更改此条款。

      董事会还承认,有人对 .COM 注册管理机构协议中推定性续约权利条款提出了反对意见;也有人建议如果发生某些情况,例如对注册管理机构协议的实质性违反行为未予处治,则应剥夺推定性续约权利。还有人建议,不应延长 .COM 注册管理机构协议的期限,而应针对该协议举行公开竞标,以确保注册人可以支付更低的价格。董事会指出,.COM 注册管理机构协议第 4.2 款中的推定性续约权利条款是 ICANN 所有注册管理机构协议中都有的一项条款。此条款允许注册管理运行机构享有在协议到期时续约的权利,只要该注册管理运行机构在续约时信誉良好,满足推定性续约条款下的规定即可。此推定性续约条款的纳入,旨在确保 TLD 运营的稳定性、安全性和可靠性,即鼓励对稳健的 TLD 运营进行长期投资。通过鼓励对 TLD 注册管理机构基础设施进行投资,提升 TLD 运营的可靠性,可以使广大公众受益。ICANN 曾阐述过注册管理机构推定性续约的理由:“如果没有反面原因,频繁更换注册管理运行机构不但不能使公众受益,而且还极有可能造成服务中断。此外,如果短期后即很有可能丧失运行注册管理机构的权利,运行机构的积极性将受挫,从而更注重短期收益而非着眼长期投资。另一方面,社群必须能够通过 ICANN,来换掉那些在运行注册管理机构的过程中不能充分为社群服务的注册管理运行机构。”

      董事会承认,有意见认为应调整 .COM 注册管理机构协议,使其符合新 gTLD 注册管理机构协议中对新安全措施和知识产权保护措施的规定。一些评论者指出,某些传统 gTLD 注册管理运行机构采用了通用形式的新 gTLD 注册管理机构协议(例如 .PRO、.CAT、.TRAVEL),其中包含附加的增强和安全措施,故此也应要求 .COM 采取这些措施。有人提出,如果不要求 .COM 采用新 gTLD 注册管理机构协议中的新增强措施、安全措施及知识产权保护措施,将会引发人们对 ICANN 是否恪守其相关核心价值的担忧,包括无歧视性或优惠待遇、服务公众利益、透明和竞争等。董事会指出,公开征求意见的拟议修正案仅提出了延长当前协议的期限,而转换到新 gTLD 注册管理机构协议形式则需要进行更长时间的讨论与社群意见征询。此时提出旨在延长 .COM 注册管理机构协议期限的简单修正案是为了让 .COM TLD 保持稳定、安全和可靠的运营。

      董事会也指出,拟议的修正案提供了一项条款,要求 ICANN 和威瑞信满怀诚意地展开合作与谈判,以便在拟议修正案届满两周年之前修订 .COM 注册管理机构协议,从而维护并增强互联网或 TLD 的安全性。这一内容经商议后成文,为将来根据需要讨论潜在变化提供了一个机会,以维护并增强互联网或 .COM TLD 的安全性。

      董事会承认,有意见要求确认威瑞信必须实施未来可能制定的共识性政策,按规定提供附加的安全和增强措施。董事会指出,.COM 注册管理机构协议第 3.1 (b) 款规定:“自本协议生效之日起,协议期间注册管理运行机构应始终根据此处的条款完全遵守并执行 http://www.icann.org/en/general/consensus-policies.htm 中载明的所有共识性政策,以及将来按照 ICANN 章程可能制定和采纳的政策及其下的规定。”

      董事会承认,有意见反对 .COM 注册管理机构协议提前续约,并反对将该协议与根区维护人服务协议 (RZMA) 联系起来。这些意见指出,根区维护人基础设施绝不能与威瑞信的 .COM 运营“紧密地交织在一起”。有人质疑将这两份协议联系起来如何增强根运营的安全、稳定与弹性,并认为这一联系就意味着单一故障源。这些评论者敦促 ICANN 技术人员开始探讨如果发生不测事件,如何实现根区和 .COM 技术运营的实际分离,并确保此类行动不会对 DNS 安全性和稳定性构成威胁。

      董事会指出,多年来,威瑞信一直根据与 NTIA 签订的合作协议提供“注册服务”,这些服务在广义上包括根区维护人职能和 .COM 顶级域注册管理机构服务。鉴于合作协议中这两项职能的统一性,许多支持根区维护人职能的基础设施与威瑞信的 .COM 的 TLD 运营“交织在一起”。确保根运营安全的一大关键点在于:考虑到这类运营与 .COM 运营之间的传统联系,这类运营应能从这种联系中持续获益。我们对 .COM 注册管理机构协议的期限进行了简单延伸,从而使其能够与新编制的 RZMA 的条款保持一致。尽管从协议将同时到期的意义上说,二者的条款相互联系,但它们并未包含任何条款将 .COM 注册管理机构协议下的义务履行同 RZMA 下的义务联系到一起。事实上,ICANN 董事会 2016 年 8 月 9 日批准根区维护人服务协议(“RZMA”)包含一些条款,赋予了社群一项权能,即自协议生效之日起三年后,社群可以通过基于共识、以社群为主导的流程,要求 ICANN 将根区维护人职能移交给其他服务提供商。

      董事会承认,有意见提出,如果不要求 .COM 采用新 gTLD 注册管理机构协议中的新增强措施、安全措施及知识产权保护措施,将会引发人们对 ICANN 是否恪守其相关核心价值的担忧,包括无歧视性或优惠待遇、服务公众利益、透明和竞争等。

      董事会指出,章程中列举了 ICANN 在工作过程中应遵循的核心价值,并以此来指导其决策和行动,ICANN 高度重视对这些价值的承诺。如章程中所述,这些“核心价值均体现在最基本的条款中,因此可以在尽可能具体的情况中提供有用的相关指导。这些核心价值并未给出详尽的指示,因此将这些价值应用到每种新情况的具体方式,无论是以个别方式还是以全体方式,都必然会取决于许多无法完全预料或列举的因素;这些核心价值所陈述的是原则,并非实际做法,因此不可避免地会出现一些无法完全同时忠于所有这十一条核心价值的情况。任何提出建议或做出决定的 ICANN 机构都应当做出判断,确定哪些核心价值最为相关,以及如何将它们应用到当下的具体环境中,必要时还要合理平衡一些价值之间的冲突。”考虑对拟议修正案提出的意见和批准时,董事会考虑了相关的核心价值,以平衡各项重点。

      董事会进一步承认收到了关于竞争问题和提供公平竞争环境的意见。ICANN 章程第 II 条第 3 款规定,“除非有实质性的正当原因(如促进有效竞争),否则 ICANN 不得以不公正的方式应用其标准、政策、程序或做法,也不得挑出任何特定一方加以区别对待。”董事会指出,.COM 注册管理机构协议包含许多其他注册管理机构协议所没有的条款。这些特殊条款可能会被认为是有利的或不利的,具体取决于个人的视角。例如,.COM 注册管理机构协议第 7.3 款价格控制条款严格控制注册管理运行机构以其他任何注册管理机构协议中所没有的方式提高价格的能力。

      是否会对社群产生积极或者消极影响?

      ICANN 根据当前 .COM 注册管理机构协议,对威瑞信的近期表现开展了一项审核,认为威瑞信大体上满足合同要求。

      董事会对拟议的修正案予以批准,旨在确保 .COM TLD 持续稳定、安全、可靠地运营。

      是否会在财务方面对 ICANN(战略规划、运营规划、预算)、社群和/或公众产生影响或不良后果?

      预计董事会批准拟议的修正案后不会产生重大的财务影响。

      是否存在与 DNS 相关的任何安全、稳定或弹性问题?

      预计董事会批准拟议的修正案不会造成任何与 DNS 有关的安全、稳定或弹性问题。

    4. PTI 治理事项 — 采纳 PTI 章程;任命首届 PTI 董事会董事;任命 PTI 总裁

      PTI 章程

      鉴于采纳章程被认为最符合加利福尼亚州非营利性公益组织 PTI 的利益。

      鉴于首个 PTI 章程是按照 ICANN 董事会 2016 年 3 月 10 日收到的 ICG 提案要求编制,而且编制期间与管理权 CWG 及其外部法律顾问进行了协调。

      鉴于针对首个 PTI 章程,已于 2016 年 7 月 12 日至 8 月 11 日启动了为期 30 天的公共评议期,期间共收到了四条意见。ICANN 工作人员编制了总结分析和报告,指出了每条意见的考虑和解决方式,据此 ICANN 已同管理权 CWG 的外部法律顾问协调,对章程进行了修订。

      鉴于 ICANN 的总法律顾问声称,拟议的 PTI 章程仍符合 ICG 提案,并建议 PTI 的唯一成员 ICANN 予以批准。

      鉴于 PTI 章程在得到 PTI 董事会及其唯一成员 ICANN 双方的批准前将不会生效。

      兹此发布第 2016.09.15.10 号决议:作为 PTI 唯一成员,ICANN 董事会批准将此处 <https://www.icann.org/iana_imp_docs/109-revised-pti-bylaws_18aug16-v-v1> [DOCX, 72 KB])载明的章程作为首个 PTI 章程。

      PTI 总裁

      鉴于根据 PTI 章程第 7.2 款的规定,ICANN 作为 PTI 唯一成员有权任命 PTI 总裁。

      兹此发布第 2016.09.15.11 号决议:作为 PTI 唯一成员,ICANN 董事会特此任命爱丽丝·格里琪 (Elise Gerich) 为 PTI 总裁。

      PTI 董事会 — 首届董事

      鉴于 ICANN 作为 PTI 唯一成员,有义务按照 PTI 章程第 5 条的要求,对 PTI 董事会的所有成员进行任命。

      鉴于 PTI 章程第 5.2.1 款授权 PTI 董事会拥有五名董事。

      鉴于按照 PTI 章程第 5.2.2.2 款的要求,ICANN 作为 PTI 唯一成员必须任命首届 PTI 董事会的四名董事,其中两名必须是 ICANN 或 PTI 的员工,另外两名必须是负责编制 IANA 域名职能管理权移交提案的跨社群工作组指定的候选人。

      鉴于 ICANN 作为 PTI 唯一成员,必须任命 PTI 总裁加入 PTI 董事会。爱丽丝·格里琪被任命为 PTI 总裁。PTI 总裁依其职权加入 PTI 董事会,任期与她作为 PTI 总裁的服务任期一致。

      鉴于 ICANN 推荐 ICANN 全球域名分部总裁阿克兰·阿特拉 (Akram Atallah) 和 ICANN 首席技术官戴维·康纳德 (David Conrad) 作为 ICANN 或 PTI 员工出任首届董事。

      鉴于管理权 CWG 推荐利兹·富尔 (Lise Fuhr) 和乔纳森·罗宾逊 (Jonathan Robinson) 出任首届董事。

      兹此发布第 2016.09.15.12 号决议:ICANN 作为 PTI 唯一成员,任命阿克兰·阿特拉、戴维·康纳德、利兹·富尔和乔纳森·罗宾逊为首届 PTI 董事,任期如 PTI 章程第 5.5 款所规定。

      设立人

      鉴于 2016 年 8 月 9 日,ICANN 董事会批准向加利福尼亚州州务卿提交公共技术标识符(简称 PTI)企业设立章程进行备案。

      鉴于为完成这一备案,ICANN 指定阿克兰·阿特拉担任 PTI 设立人,负责签发 PTI 企业设立章程。

      鉴于 2016 年 8 月 10 日,加利福尼亚州州务卿收到了 PTI 企业设立章程。

      鉴于阿克兰·阿特拉作为 PTI 设立人的职责已经完成,并且已递交辞呈请求辞去 PTI 设立人职务。

      兹此发布第 2016.09.15.13 号决议:迄今为止授权人员为实现或证明前述决议的目的和意图所采取的任何或所有行动,均被批准、认可和确认为公司或其附属机构的契据以及董事会的契据。

      第 2016.09.15.14 号决议:作为 PTI 唯一成员,ICANN 董事会接受 PTI 设立人阿克兰·阿特拉的辞职,该辞职于上述首届 PTI 董事选举时生效。

      第 2016.09.15.10 – 2016.09.15.14 号决议的理由

      今日在此通过的这些决议,是为履行 ICANN 作为 PTI 唯一成员的职责,让 PTI 确立治理结构并做好运营准备,以便在 IANA 管理权移交成功完成后开展必要的活动。接受设立人辞职后,ICANN 即可以透明和对其社群负责的方式,推进 PTI 章程的采纳,并完成 PTI 董事会成员(含 PTI 总裁)的任命。这样,PTI 董事会就能在不久的将来完成必要的组织活动,包括接受 PTI 章程、完成人事任命,以及采纳诸如《利益冲突政策》等治理文件。PTI 董事会也能确定如何对必要的 PTI 运营合同的批准和执行进行授权,例如 PTI 域名职能协议、与 ICANN 达成的服务协议以及 PTI 与 ICANN 之间的其他分包安排。

      这些决议未授权 PTI 在 IANA 管理权移交完成之前履行任何 IANA 职能。这也是问责制的一个重要方面。

      PTI 章程是内部和外部法律团队通力合作以及管理权 CWG 努力工作所得出的成果。针对 PTI 章程开启了为期 30 天的公共评议期,期间共收到了四条意见。每条意见均得到了考虑和分析,并说明是否需要修改 PTI 章程,以反映意见中提出的事项。在修改 PTI 章程的过程中,ICANN 与管理权 CWG 及其外部法律顾问密切合作,所有修订都是为了确保社群提名到 PTI 董事会的董事始终出席 PTI 董事会和董事会委员会会议,并适当地参与到比简单多数票门槛更高的关键决策中。修改后的 PTI 章程仍与 ICG 的移交提案保持一致。PTI 章程还必须经由 PTI 董事会采纳,然后才能生效。

      PTI 总裁和董事会的任命完全按照 PTI 章程中规定的义务进行,充分尊重了社群对拟议董事会构成的建议。

      采取这些行动时,董事会依赖:

      此外,董事会还依赖总法律顾问兼秘书长的确认,即 PTI 章程反映了移交提案,以及独立法律顾问的意见,即应起草 PTI 章程来支持 ICG 提案。

      这些行动继续确认了 ICANN 对实施移交提案以及这些提案中的所有要素的承诺。

      今日采取的所有行动预计不会对 DNS 的安全、稳定或弹性产生任何影响,但 PTI 将对 ICANN 为 DNS 安全、稳定与弹性所做的努力起到决定性作用。支持 PTI 董事会将带来资源方面的影响,同时要支持一个新的附属机构也需要大量资源。

      批准 PTI 章程属于组织管理职能,已为其征询了公众意见。

      接受设立人辞职、任命 PTI 总裁及任命 PTI 董事属于组织管理职能,无需征询公众意见。

    5. 进一步考虑 Dot Registry IRP《最终声明》

      鉴于在采纳多数小组成员的审核结果即“在 Dot Registry 针对 ICANN 提起的独立审核流程 (IRP) 诉讼 (Dot Registry IRP) 中,Dot Registry LLC 是胜诉方”后,董事会决定,考虑在董事会采取任何进一步行动之前,就 Dot Registry 的重审请求或相关新 gTLD 采取后续行动。(请参阅 https://www.icann.org/resources/board-material/resolutions-2016-08-09-en - 2.g。)

      鉴于董事会注意到,Dot Registry IRP 中的多数小组成员并未就后续行动向董事会提出任何具体建议。

      鉴于董事会也注意到,Dot Registry 和其他方就此事发出了多封信函和不同的意见。

      鉴于 Dot Registry IRP 中的多数小组成员宣称,在评估重审请求 14-30、14-32 和 14-33 的过程中,董事会治理委员会 (BGC) 的行事方式不符合企业设立章程或 ICANN 章程。(请参阅《最终声明》第 ¶151 款:https://www.icann.org/en/system/files/files/irp-dot-registry-final-declaration-redacted-29jul16-en.pdf [PDF, 12.9 MB]。)

      鉴于,具体来说,多数小组成员宣称“董事会(通过 BGC 采取行动)在获取合理数量事实的过程中未能恪尽职守并做到合理谨慎,并且未能履行其透明度义务,包括既未能提供 EIU 和 ICANN 工作人员依赖的调查研究信息,又未能公开 BGC 所依赖的 ICANN 工作人员的工作成果。多数小组成员进一步总结,小组获得的证据不支持以下决定:董事会(通过 BGC 采取行动)在做出重审决定时进行了独立判断。”同上,第 ¶152 款。

      兹此发布第 2016.09.15.15 号决议:考虑到 Dot Registry IRP 中多数小组成员发表的《最终声明》以及其所指出的 BGC 在评估这些重审请求的过程中存在的行动问题,董事会指示董事会治理委员会重新评估 Dot Registry 的重审请求 14-30、14-32 和 14-33。

      第 2016.09.15.15 号决议的理由

      Dot Registry, LLC (Dot Registry) 发起独立审核流程 (IRP) 诉讼,质疑董事会治理委员会 (BGC) 拒绝 Dot Registry 对社群优先评估 (CPE) 报告的重审请求,该报告裁定 Dot Registry 对 .INC、.LLC 和 .LLP 的申请均未通过 CPE (Dot Registry IRP)。

      Dot Registry 申请运营新的顶级域 .LLC、.INC 和 .LLP。Dot Registry 是 .LLC 的九名申请人之一,.INC 的十一名申请人之一,.LLP 的四名申请人之一。但是,Dot Registry 是唯一为这些 gTLD 提交了基于社群的申请的申请人。

      评估 Dot Registry 申请的 CPE 小组(下称“CPE 小组”)裁定,这些申请不符合通过 CPE 的标准,仅授予了 5 分,而通过 CPE 却需要 14 分(CPE 报告)。Dot Registry 提交了重审请求 14-30、14-32 和 14-33,希望重审 CPE 报告。2014 年 7 月 24 日,董事会治理委员会 (BGC) 拒绝了这些重审请求,认为 Dot Registry“未能证明小组在提供其各份 CPE 报告时违反了既定政策或程序…”。

      Dot Registry 于 2014 年 9 月 22 日发起 Dot Registry IRP,对 BGC 拒绝 Dot Registry 的重审请求、ICANN 任命经济学人智库 (EIU) 作为执行 CPE 的第三方提供商以及董事会对 ICANN 政府咨询委员会关于 .LLC、.INC 和 .LLP 建议的回复提出质疑。

      在一项 2-1 决定中,多数小组成员声称 Dot Registry 为胜诉方,并认定“董事会的行动和不作为不符合《ICANN 企业设立章程》和章程”。(《最终声明》第 ¶151 款。)具体来说,多数小组成员声称“董事会(通过 BGC 采取行动)在获取合理数量事实的过程中未能恪尽职守并做到合理谨慎,并且未能履行其透明度义务”,而且没有充分的证据“支持董事会(通过 GAC 采取行动)在做出重审决定时进行了独立判断的决定。”(同上,第 ¶¶151-152 款。)多数小组成员进一步声称,ICANN“应在确定发生的费用已全部付清后,向 Dot Registry, LLC 支付 235,294.37 美元,以补偿 Dot Registry, LLC 此前产生的上述费用、开支和薪酬”。(同上,第 ¶154 款。)

      董事会注意到,多数小组成员声称“在得出这些结论时,小组未评估 ICANN 员工或 EIU 自身是否未履行企业设立章程、章程或[申请人指导手册(下称“指导手册”)]所规定的义务。”(同上,第 ¶152 款。)此外,董事会还注意到,“关于 Dot Registry 是否有资格获得社群优先,多数小组成员拒绝用其判断取代 CPE 的判断。”(同上,第 ¶153 款。)

      在初步考虑《最终声明》的过程中,董事会接受了《最终声明》中的以下结果:(i) 在 Dot Registry 针对 ICANN 提起的 IRP 中,Dot Registry 是胜诉方;并且 (ii) ICANN 应在证实这些发生的费用已全部付清后,向 Dot Registry 支付 235,294.37 美元。(请参阅 https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.g。)

      董事会也“注意到声明中的其它审核结果,以及多数小组成员就上文提及的重审请求审核标准所做声明中的结果,并将考虑在董事会采取任何进一步行动之前,就 Dot Registry 的重审请求或相关新 gTLD 采取后续行动。”(参考信息同上。)此外,董事会注意到多数小组成员并未就董事会后续行动提出任何具体的建议。

      由于董事会现在有机会全面评估《最终声明》中的一些其他结果,考虑到 Dot Registry IRP 中多数小组成员发表的《最终声明》以及其所指出的 BGC 在评估这些重审请求的过程中存在的行动问题,董事会认为目前最好的做法是让 BGC 重新评估 Dot Registry 的重审请求 14-30、14-32 和 14-33。

      在采取此项行动的审议过程中,董事会审核了诸多材料,包括但不限于以下材料和文档:

      • 重审请求 14-30:Dot Registry, LLC(2014 年 6 月 25 日)
      • 重审请求 14-32:Dot Registry, LLC(2014 年 6 月 26 日)
      • 重审请求 14-33:Dot Registry, LLC(2014 年 6 月 26 日)
      • Dot Registry 针对 ICANN 提起的独立审核流程
      • 史蒂夫·克罗克致希瑟·德莱顿 (Heather Dryden) 的信函 [PDF, 1.13 MB],主题:2014 年 2 月 5 日的 NGPC 会议(2014 年 2 月 10 日)
      • 杰弗里·W.·布洛克 (Jeffrey W. Bullock) 致 ICANN 董事会的信函 [PDF, 148 KB],主题:Dot Registry LLC 诉 ICANN 的 IRP 声明(2016 年 8 月 8 日)
        沙乌尔·乔利斯 (Shaul Jolles) 致 ICANN 董事会的信函 [PDF, 1.5 MB],主题:2016 年 8 月 9 日 ICANN 董事会关于议程事项“2016 年 7 月 29 日 Dot Registry LLC 诉 ICANN (01-14-0001-5004) 的独立审核流程(“IRP”)声明”的特别会议(2016 年 8 月 6 日)

      该行动预计不会对组织造成任何重大直接财务影响。该行动不会对域名系统的安全、稳定或弹性产生直接影响。

      这属于组织管理职能,无需征询公众意见。

    6. 考虑关于 dotgay, LLC 申请 .GAY 的监察官报告

      未达成任何决议。

    7. 重审请求 16-3 (dotgay LLC)

      未达成任何决议。

    8. 其他事务

      未达成任何决议。

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."