Skip to main content
Resources

问责机制

本页面还提供其他语种:

ICANN 在其所有实践中,均秉承着对问责制和透明度的承诺。ICANN 认为这些原则是确保自下而上的多利益相关方模型维持有效性的根本保护措施。ICANN 在其组织内部和执行任务的各个层级中,均设立了实现问责制和透明度的机制。这最先体现在它的章程之中,并在问责制和透明度框架与原则(ICANN 董事会于 2008 年采纳)中进行详细阐述,且每年在其战略和运营规划中得到进一步强化。为了强化透明度和问责制,ICANN 设立了用于审核 ICANN 各项行动的问责机制。ICANN 章程第 IV 和 V 条中载有关于问责机制的全文,以下是这些机制的摘要和概述。

重审流程

重审是章程第 IV 条第 2 款中载述的机制,规定受 ICANN 行动(或不作为)严重影响的任何个人或实体可以请求对董事会的行为进行审核或重审。

如果由于下列因素而受到负面影响,任何个人或实体都可以提出请求,要求对 ICANN 的行动或不作为进行重审或审核(以下简称"重审请求"):

  1. 一项或多项员工行动或不作为与已制定的 ICANN 政策相抵触;或
  2. 在 ICANN 董事会所采取或拒绝采取的一项或多项行动或不作为中,没有考虑到某些重要信息,但以下情况例外:提出请求的一方本应在采取行动或拒绝采取行动时,将某些信息提交给董事会进行考虑,但实际上并没有提交;或
  3. ICANN 董事会在依赖错误或不准确重要信息的情况下采取的一项或多项行动或不作为。

如果不展示这些标准,重审流程则会成为仅仅因为个人或实体不同意某项行动(或不作为)便可要求重审的机制。

所有重审请求必须在自以下日期后的 15 日内提出:

  1. 如果是对董事会行动表示异议的请求,则为与有异议的董事会行动相关的信息在决议中首次发布的日期,除非决议发布时未附有相关理由。在这种情况下,必须在首次发布决议理由的 15 日内提交请求。
  2. 如果是对员工行动表示异议的请求,则为提出请求的一方已经意识到或理应意识到有异议的员工行动的日期;或
  3. 如果是对董事会或员工不作为表示异议的请求,则为受影响的人员已经推断出或理应推断出将不会及时采取行动的日期。

重审请求由董事会治理委员会(以下简称"BGC")进行审核和考量。对于所有针对员工行动或不作为提出的重审请求,董事会应授予 BGC 就该事宜作出最终裁决和建议的权力。董事会无需对相关建议进行考量。如果 BGC 认为有必要,可以向董事会提交建议以供考量和采取行动。

除非缺乏实际可行性,否则 BGC 应在收到重审请求后的 30 日内作出最终裁决或向董事会提交建议。如果 BGC 向董事会提交建议,董事会应在收到重审请求后 60 日内或在尽可能快的时间内发布其关于 BGC 建议的决定。

ICANN 已做出以下裁决:在新 gTLD 项目中,对于由第三方争议解决服务提供商组成的专家组提出的专家裁决,如对该专家裁决有争议,并且争议中声称专家组在作出专家裁决时未遵守既有的政策或流程,或该员工在接受该裁决时未遵守其政策或流程,则可以适当地提请重审流程。

有关 ICANN 重审流程的更多信息,请参阅章程第 IV 条 (http://www.icann.org/en/about/governance/bylaws#IV) 或重审页面

独立审核流程(以下简称"IRP")

除了重审流程之外,ICANN 还设立了一个单独的流程,第三方可以通过该流程对那些由受影响方提出的与 ICANN 企业设立章程或章程相抵触的董事会行动(或不作为)进行独立审核。详情请参阅 ICANN 章程第 IV 条第 3 款

对于受到董事会决策或行动(认为与企业设立章程或章程相抵触)重大影响的任何个人,均可以提交请求以对该决策或行动进行独立审核。所谓受到重大影响,是指个人必须因为所指称的董事会违反章程或企业设立章程而受到伤害或损害,两者之间具有直接的因果关系,而不是根据董事会的行动采取行动的第三方导致的结果。

IRP 请求必须在请求方认为可显示 ICANN 违反其章程或企业设立章程的董事会会议记录(以及随附的董事会简报材料,如可用)发布后的 30 日内提出。对于与 BGC 就重审请求所作的裁决相关的 IRP 请求,必须在作出相关裁决的 BGC 会议记录发布后的 30 日内提出此类请求。

在提出独立审核请求之前,对于计划提请 IRP 的问题,我们会出于解决问题或缩小问题范围之目的,促请投诉人与 ICANN 先进入一个合作接触流程。详情请参阅 http://www.icann.org/en/news/irp/cep-11apr13-en.pdf

有关 ICANN 独立审核流程的更多信息,请参阅章程第 IV 条第 3 款 (http://www.icann.org/en/about/governance/bylaws#IV) 或独立审核流程页面

监察官

ICANN 监察官具有独立性和中立性,若 ICANN 社群成员认为在没有成为重审流程或独立审核流程主题的问题上受到 ICANN 员工、董事会或 ICANN 选区机构不公平对待并提出投诉,监察官的职责就是针对他们的投诉提供独立的内部评估。监察官应客观地拥护公正,设法评估并尽可能解决关于受到 ICANN 员工、董事会或 ICANN 选区机构不公正或不当对待的投诉,澄清问题并利用谈判、促进和"穿梭外交"等冲突解决手段实现这些结果。详情请参阅 ICANN 章程第 V 条

监察官无权制定、更改和撤销任何政策、管理决策或董事会决策、作为或不作为。但是监察官有权对这些事项展开调查,并利用替代性纠纷解决方案来解决这些问题。监察官有权向董事会递交自己认为适当的、关于任何特定事项及其解决方案或无法解决的报告。

有关 ICANN 监察官的更多信息,请参阅章程第 V 条 (http://www.icann.org/en/about/governance/bylaws#V) 或监察官页面

什么是赋权社群?

赋权社群是 ICANN 支持组织 (SO) 和咨询委员会 (AC) 依据加利福尼亚州 (California) 法律规定而组织起来用于合法行使社群权力的机制。用于管理赋权社群的社群权力和规定现已写入 ICANN 《企业设立章程 (Articles of Incorporation)》《章程 (Bylaws)》

谁可以加入赋权社群?

所有 ICANN 的支持组织、包括一般会员咨询委员会和政府咨询委员会均可加入赋权社群,具体包括:

赋权社群如何行使权力?

赋权社群拥有一套针对 ICANN 董事会或该组织的作为和不作为提出关切的流程。这套升级流程给予支持组织和咨询委员会与 ICANN 董事会讨论解决方案的机会。

如需更多信息,请点击此处查看赋权社群网页。

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