Skip to main content

改进 ICANN 多利益相关方模型效率的后续步骤

董事会在 2020 年间的一项头等要务是在社群现已完成的工作基础上,继续推进改进 ICANN 多利益相关方模型效率这一倡议。因"2019 冠状病毒病 (COVID-19)"疫情所引发的这段充满挑战性的时刻提醒着我们:互联网在确保全球人民相互联系、获取资讯这方面扮演着重要角色,而 ICANN 协调互联网唯一标识符系统的职责也是极为关键的。为了继续成功履行这一职责,我们的自下而上的多利益相关方治理模型必须能够与时俱进,不断发展。作为当前工作的一项阶段性成果,我们编制了《改进 ICANN 的多利益相关方模型——后续步骤》,并于今天公开发布以征询公众意见。我们期待着大家踊跃发表反馈意见。

工作计划最新版

在 ICANN 发布了《2021-2025 财年运营和财务规划草案》和《2021 财年运营规划和预算草案》附录 C 中的《改进 ICANN 的多利益相关方模型工作计划》草案后,我们根据现已收到的社群评论,编制了《改进 ICANN 的多利益相关方模型——后续步骤》一文,旨在找到一条前进道路。董事会听取了社群意见,并同意需要采取一套整体方案来改进多利益相关方模型,期间不得重复当前的工作,且不应给志愿者们带来额外压力。原工作计划草案中提出了六大工作领域,但毫无疑问,社群、董事会或 ICANN 组织都无法同时应对这六大工作领域和 ICANN 当前的重点事务和工作量。鉴于此,董事会提议把焦点放在社群在公共评议期间选取的三大重点之上,即:1) 确定工作重点,有效利用资源; 2) 准确定位工作范围;和 3) 共识性、代表性和包容性。这份文件第 II 部分中列出的拟定工作计划把焦点放在社群确定的这三大重点主题之上,描述了当前正在进行的工作,识别了这些工作中的缺漏,并提出了弥补缺漏的措施建议。其总体目标是,在 ICANN 社群当前工作的基础上实现必要平衡,从而确保循序渐进地改进多利益相关方模型,并提高每个人在未来工作中的效率。

第 III 部分:剩余工作领域也代表着社群关注的一些重要领域。但鉴于时间和资源的限制,董事会建议社群能够在《2021-2025 财年运营和财务规划》的五年期限内的晚些时候再讨论这些领域,因为在解决前三项重点领域时和社群持续工作期间所采取的措施可能会给这些剩余领域带来好处。

我们期待着听取您的建议

在持续推进这项工作时,董事会将针对以下三大重点领域征询社群的反馈意见:

  1. 工作计划:我们希望大家能够针对重点工作领域提出您的看法,看看目前列出的机制或措施是否足以解决已经发现的缺漏。我们鼓励大家针对工作计划中识别的缺漏发表反馈意见,并告知我们是否还有其他缺漏应当加以考量。
  2. 剩余工作领域:尽管我们把工作计划最新版的焦点放在前文所述的重点领域上,我们还愿意看到社群采取任何措施来帮助应对剩余工作领域。我们希望了解您所在的社群团体是否愿意启动或协调任何其他措施。
  3. 评估机制:这份工作计划还囊括了一套拟定评估机制,来评定本项目完成既定目标的情况。我们希望听取大家的意见,看看是否应当进行定期评估,如果是,这类评估是否应当使用现有流程(例如战略规划审核流程)进行,或您是否认为应当考虑采用其他更恰当的方式。

董事会鼓励大家发表反馈意见,并已将本轮公共评议期延长至 60 日,从而能够给予利益相关方们充足的时间来对这份工作计划加以考量。本轮公共评议期的开放时间为:2020 年 6 月 4 日,截止时间为:2020 年 8 月 2 日。

马修·希尔斯 (Matthew Shears) 和曼蒂娜·米斯曼 (Mandla Msimang) 将在这项工作上充当董事会责任人,在本项目和未来发展期间配合社群的工作。我们期待着在 ICANN68 筹备会议网络研讨会上与大家探讨这份文件。本研讨会预计在 6 月 15 日召开,详情即将发布。在本轮网络研讨会期间,我们将向大家简要介绍正在征询公众意见的这份文件,并回答大家的疑问。

我还想重点强调大家在这项工作中表现出的高度合作精神。这展示了各方坚定承诺参与 ICANN 生态系统,从而不断加强多利益相关方模型。这展现了不论周遭世界的情况如何,我们的社群都能勇于面对,灵活适应。我们衷心感谢大家在推动 ICANN 多利益相关方模型的演进和成就方面所做出的卓越贡献。

在我们持续应对 COVID-19 全球疫情带来的各种影响时,我要祝愿您与您的亲朋好友一切顺遂、平安健康。我期待着与大家就改进多利益相关方模型的效率一题继续展开讨论。

Comments

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