Skip to main content
Resources

GNSO 改进

本页面还提供其他语种:

GNSO 委员会在其 10 月 16 日的会议上评审并批准了高级别的 “ GNSO 改进实施计划 ” ( http://www.icann.org/en/topics/gnso-improvements/gnso-improvements-implementation-plan-16oct08.pdf ) 。作为其实施工作的基础 , 委员会批准成立两个专门的筹划指导委员会 , 重点关注 GNSO 和 GNSO 委员会流程和做法。这两个委员会是:

政策流程筹划指导委员会 (PPSC) 该委员会由 Neustar 的 Jeff Neuman 担任主席 , 将监督整体工作以改进政策制定流程 (PDP) , 包括担任独立团队的协调机构 ( 这些团队负责为新的工作组 (WG) 模式和新的 PDP 程序提出建议 ) 。 PPSC 将负责就转换为 WG 模式及 GNSO PDP 修订 ( 与转换为 WG 模式紧密相关 ) 所涉及的流程和方法提出建议。该委员会将以包容而透明的方式运作 , 尽可能从现有选区组织和新选区组织中吸收参与者。

运营筹划指导委员会 (OSC) 该委员会由 Verisign 的 Chuck Gomes 担任主席 , 将监督改进 GNSO 结构、选区组织及沟通的工作。该委员会还会为各类工作团队分配任务 , 以便提议如何实施与这些领域相关的建议 , 并将以包容而透明的方式运作。 OSC 及其各工作团队中的全体成员将尽可能从现有选区组织和新选区组织中吸收。

个人用户的角色

ICANN 董事会已要求社群就商业和非商业互联网个人用户在通用名称支持组织 (GNSO) 中的适当角色和代表权问题提供意见。 面对由各类独立评审和 GNSO 及用户社群团体工作提供的众多不同建议 , 董事会继续考虑这个问题 , 并相信社群 ( 尤其是 GNSO 、 ALAC 和一般会员团体中的利益主体 , 及任何新选区组织的相关申请人 ) 提供的意见会非常有帮助。 为此 , 董事会在其 2008 年 10 月 1 日的会议上通过了一项决议。

GNSO 改进流程目前处于实施阶段 , 也在董事会的积极考虑之中 , 它使得该问题变得刻不容缓。 这个问题得不到解决 , 可能对 GNSO 理事会的重组工作实施产生不利影响 , 并可能对其他 GNSO 改进和其他 ICANN 结构的审核产生更广泛的潜在影响。

通过在 2008 年 2 月、 6 月、 8 月和 10 月会议上做出的一系列决定 , ICANN 董事会为改进通用名称支持组织 (GNSO) 结构和运营的各个方面批准了一系列目的、目标和建议。为改进 GNSO 政策制定活动、结构、运营和沟通的效力 , 进行了为期两年的独立评审、广泛听取社群意见 , 并经董事会马拉松式的反复审议才最终做出了上述决定。

董事会批准的这些建议基于各界提供的意见和提议 , 以及两个主要工作组提出的建议。建议大部分源于由董事会管理委员会 GNSO 评审工作组 (BGC WG) 撰写的 GNSO 改进报告。董事会目前批准的其他想法主要是由 GNSO 委员会重组工作组 (WG-GCR) 建议的 , 该工作组是董事会在巴黎会议上组建的。 上述小组的工作成果可通过以下方式获取 : 有关 BGC WG 的最终报告在 http://www.icann.org/topics/gnso-improvements/gnso-improvements-report-03feb08.pdf 提供 , 有关 WG-GCR 的最终报告在 http://www.icann.org/en/topics/gnso-improvements/gnso-council-restructuring-report-25jul08.pdf 提供

GNSO 委员会组建的 GNSO 改进规划团队 ( 简称 “ 规划团队 ”) 由 GNSO 领导层、选区组织代表、 ICANN 员工以及董事会联络参与人组成 , 该团队制定了组织和管理实施工作的顶级实施计划。 GSNO 委员会于 2008 年 10 月 16 日批准了该计划。计划的重点是组建管理 GNSO 政策流程和 GNSO 运营的两个筹划指导委员会,它们将负责确保 BGC WG 的建议工作得以实施。

ICANN 董事会为 GNSO 委员会重组制定了具体的时间表,并确立了其他实施工作的基准和目标。 ICANN 员工专门创建了一系列网页,旨在对实施工作进行描述和解释。 网址为 http://gnso.icann.org/en/improvements/

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