互联网名称与数字地址分配机构章程 | 修正案生效日为 2008 年 2 月 15 日
Note: this page is an archive of an old version of the bylaws. The current ICANN bylaws are always available at: https://www.icann.org/resources/pages/governance/bylaws-en
加利福尼亚的一家公益性非营利组织
修正案生效日为 2008 年 2 月 15 日
| 翻译须知: 本文档的原始版本是英文版，可从以下网址获得：http://www.icannhttp://www.icann.org/en/general/bylaws.htm。如果本文档的非英文版本与原始文档在理解上存在出入，或者发现到这种出入，请以原始文档为准。 |
第 I 条：使命与核心价值
第 II 条：权力
第 III 条：透明度
第 IV 条：责任与审核
第 V 条：监察官
第 VI 条：董事会
第 VII 条：提名委员会
第 VIII 条：地址支持组织
第 IX 条：国家和地区代码名称支持组织
第 X 条：通用名称支持组织
第 XI 条：咨询委员会
第 XI-A 条：其他咨询机制
第 XII 条：董事会委员会和临时委员会
第 XIII 条：高级职员
第 XIV 条：董事、高级职员、雇员及其他代理人的保障
第 XV 条：总则
第 XVI 条：财政事项
第 XVII 条：成员
第 XVIII 条：办事处和印章
第 XIX 条：修正
第 XX 条：移交条款
附件 A：GNSO 政策制定流程
附件 B：ccNSO 政策制定流程 (ccPDP)
附件 C：ccNSO 的范围
互联网名称与数字地址分配机构（The Internet Corporation for Assigned Names and Numbers，简称 ICANN）的使命是对全球互联网的唯一标识符系统进行总体协调，特别是确保互联网唯一标识符系统稳定安全地运行。具体来说，ICANN 应做到以下几点：
1. 协调互联网的三组唯一标识符的分配和指定。这三组唯一标识符是：
在履行使命的过程中，ICANN 应将以下核心价值作为决策和行动的指南：
1. 保持并加强互联网的运行稳定性、可靠性、安全性和全球互用性。
2. 将 ICANN 的活动限制在 ICANN 使命中那些需要全球协调或能从全球协调中显著受益的事件，以此尊重互联网带来的发明创造、技术创新和信息流动。
3. 在可行和适当的范围内，将协调任务授权给其他反映相关方各种利益的责任实体来执行，或认可其他责任实体的政策角色。
4. 寻求并支持广泛的知情参与，在各个层面的政策制定以及决策方面反映出互联网功能、地域以及文化的多样性。
5. 在可行和适当的时候，依靠市场机制来维持和促进公平竞争环境。
6. 出于公众利益考虑，为域名注册引进并促进切实可行的良性竞争。
7. 采用公开透明的政策制定机制，以此 (i) 推动建立在专家意见基础之上的知情决策，并且 (ii) 确保那些受影响最大的实体可以参与政策制定过程。
9. 对互联网的需求做出积极快速的反应，同时在决策过程中采纳那些受影响最大的实体的广泛意见。
10. 通过各种能提高 ICANN 效力的机制，坚守对互联网社群的责任。
11. 虽然一直属于私营性质，但 ICANN 仍然意识到政府和公共权威机构有责任制定公共政策，并会适当地考虑政府或公共权威机构的意见。
我们特意非常笼统地对这些核心价值进行说明，目的是使这些核心价值尽可能为最广泛的情况提供有价值的相关指导。这些核心价值并未给出详尽的指示，因此将这些价值应用到每种新情况的具体方式，无论是以个别方式还是以全体方式，都必然会取决于许多无法完全预料或列举的因素；这些核心价值所陈述的是原则，并非实际做法，因此不可避免地会出现一些无法完全同时忠于所有这十一条核心价值的情况。凡是提出建议或制定决策的 ICANN 机构，都应通过自己的判断来确定哪些核心价值最具有相关性，以及如何将这些价值应用到当前的具体情况，还应确定如何在必要时对无法同时接受的价值进行适当合理的权衡。
除非公司条款或本章程中另有规定，否则应由董事会行使 ICANN 的权力，支配其财产，以及管理或指导其业务与事务。凡是属于第 III 条第 6 款规定的事项，董事会可以只按照董事会全体成员中大多数人的表决意见来执行。对于所有其他事项，除非本章程或法律另有规定，否则董事会可以按照那些出席董事会所有年度会议、例行会议或特殊会议的人员中大多数人的表决意见来执行。本章程中任何提到董事会表决的地方，都意味着参加表决的人只是那些出席符合法定人数限制的会议的成员，但如果本章程中有特别提到“董事会全体成员”，则另当别论。
ICANN 不得作为域名系统注册机构或注册商，也不得作为互联网协议地址注册机构，与那些受 ICANN 政策影响的实体进行竞争。本款中提供的任何内容，不用于阻止 ICANN 在注册机构或注册商发生财务失败或其他紧急状况时，采取任何必要的措施来保护互联网的运作稳定性。
除非有实质性的正当原因（如促进有效竞争），否则 ICANN 不得以不公正的方式应用其标准、政策、程序或做法，也不得挑出任何特定一方加以区别对待。
ICANN 及其任命机构的运作方式应最大程度地体现公开性和透明性，并应与那些为确保公正性而设计的程序保持一致。
ICANN 应维护一个公众可以通过互联网进行访问的万维网站，其中可包括 (i) 有关董事会、支持组织和咨询委员会会议安排的日历；(ii) 所有未决政策制定事项的摘要，包括日程安排和当前状态；(iii) 下文描述的具体会议通知和议程；(iv) 有关 ICANN 预算、年度审计、财政贡献者与贡献金额以及相关事项的信息；(v) 有关是否提供责任机制的信息，包括重审、独立审核和监察官活动，以及有关实行这些机制的特定请求和投诉结果的信息；(vi) 宣布与 ICANN 社群中各重要部分利益相关的 ICANN 活动；(vii) 社群对正在制定的政策及其他事项的意见；(viii) 有关 ICANN 实际会议和公共论坛的信息；(ix) 与 ICANN 社群利益相关的其他信息。
应指派人员来担任“公众参与事务经理”一职或授予人员其他由总裁确定的类似职称，担当这一职务的人员应在总裁的指导下负责协调 ICANN 中公众参与事务的各个方面，包括网站以及其他各种与一般互联网用户社群进行沟通和从该社群获取意见的方式。
对于每次的董事会会议，至少应提前七天公布会议通知和已知的会议议程，有时可能无法提前七天，但只要尽量提前进行通知即可。
1. 发起机构应即时对董事会和支持组织（及其所有理事会）的所有会议记录进行批准，然后将其提交给 ICANN 秘书长以发布到网站上。
2. 每次会议结束后五 (5) 个工作日之内（这是根据 ICANN 总部所在地的当地时间进行计算），董事会所采取的任何行动都应以预备报告的形式发布到网站上供公众参阅；但如果与以下事项相关的任何行动不适合公开发布，请不要包含在预备报告中以供公众参阅：人事或雇用事项、法律事项（达到董事会确定有必要或应当保护 ICANN 利益的程度）、法律或合同中禁止 ICANN 公开披露的事项，以及其他由董事会确定的事项，也就是由四分之三 (3/4) 出席会议并参加表决的董事同意确定的事项。凡是董事会决定不予以披露的事项，董事会都应在相关预备报告中大致说明不予以披露的原因。
3. 在董事会正式批准会议记录的当天（根据 ICANN 总部所在地的当地时间进行计算，如果这一天不是工作日，则为紧接着的下一个工作日），应将这些会议记录发布到网站上供公众参阅；但如果与以下事项相关的任何会议记录不适合公开发布，请不要包含会议记录中以供公众参阅：人事或雇用事项、法律事项（达到董事会确定有必要或应当保护 ICANN 利益的程度）、法律或合同中禁止 ICANN 公开披露的事项，以及其他由董事会确定的事项，也就是由四分之三 (3/4) 出席会议和参加表决的董事同意确定的事项。凡是董事会决定不予以披露的事项，董事会都应在相关会议纪录中大致说明不予以披露的原因。
1. 凡是董事会正在考虑予以采用且对互联网或第三方运营有重大影响的政策，其中包括强制收取任何费用，ICANN 都应做到：
a. 至少在董事会采取任何行动前的二十一天（如果情况允许，可以更早），在网站上公开发布通知，说明目前正在考虑采用的政策及相关原因；
b. 在董事会采取任何行动之前，为各方提供一个合理的机会以便对采用提议的政策发表意见，了解其他各方的意见以及针对这些意见予以回复；
c. 当政策行动影响到公共政策问题时，主动地或依照董事会的要求，请政府咨询委员会给出意见，并适当地将政府咨询委员会适时提出的意见纳入考虑范围。
2. 在董事会采取最终行动之前，只要是切实可行并符合相关政策制定流程，就应举办公众可以亲自参加的公共论坛，以便讨论本条第 6 款第 (1)(b) 项中所描述的任何提议的政策。
3. 针对本款所涉及的任何政策采取行动之后，董事会应在会议记录中公布采取任何行动的原因、每位董事对该行动的表决意见，以及任何要求发布此声明的董事的单独声明。
如果适用且在 ICANN 预算范围之内，ICANN 应帮助将最终发布的文件翻译成各种相应的语言。
为完成本章程中制定的任务，ICANN 应负责确保社群依照符合本章程的方式运作，并充分考虑到 本章程第 I 条中所阐明的核心价值。本条款中的规定，即制定有关 ICANN 行动的重审和独立审核流程，以及有关 ICANN 结构和程序的定期审核流程，旨在加强本章程中另行提到的各种责任机制，其中包括第 III 条 中有关透明度的规定，以及本章程通篇提到的董事会及其他选择机制。
1. ICANN 应具备适当的流程，通过该流程，任何在很大程度上受 ICANN 行动影响的个人或实体都可以要求对董事会所采取的行动进行审核或重审。
2. 如果由于下列因素而受到负面影响，任何个人或实体都可以提出请求，要求对 ICANN 行动或无行动进行重审或审核（“重审请求”）：
a. 一项或多项员工行动或无行动与已制定的 ICANN 政策相抵触；
b. 在 ICANN 董事会所采取或拒绝采取的一项或多项行动或无行动中，没有考虑到某些重要信息，但以下情况例外：提出请求的一方本应在采取行动或拒绝采取行动时，将某些信息提交给董事会进行考虑，但实际上并没有提交。
3. 应设立一个由不少于三位董事组成的董事会委员会，以便对此类请求进行审核和考量（“重审委员会”）。重审委员会应有权执行以下操作：
4. ICANN 应承担重审流程所带来的正常管理成本。ICANN 保留从提出审核或重审请求的一方收回任何被视为本质上不寻常的成本的权利。如果可以预知此类不寻常的成本，应向提出重审请求的一方说明将产生此类成本的事实以及为什么此类成本对于评估重审请求而言是必要而且合适的，之后提出请求的一方可以选择撤回请求或同意承担这些成本。
5. 所有重审请求都必须提交到由董事会重审委员会指定的电子邮件地址，期限为以下日期后的三十天之内：
a. 如果是对董事会行动表示异议的请求，则为在董事会会议的预备报告或会议记录中首次发布有异议的董事会行动相关信息的日期；
6. 所有重审请求都必须包括重审委员会所需的信息，具体应至少包括以下信息：
a. 请求方的姓名、地址和联系信息，包括邮政地址和电子邮件地址；
b. 被要求进行审核或重审的具体 ICANN 行动或无行动；
e. 在提交重审请求的一方看来，被投诉的行动或无行动对他人造成负面影响的程度；
f. 是否请求暂时延缓提出抗议的任何行动，如果是的话，在行动没有得到延缓的情况下将产生什么样的伤害；
g. 如果是员工行动或无行动，则提供一份详细说明，以便向员工阐明员工行动或无行动与所制定的 ICANN 政策不符的事实及其原因；
h. 如果是董事会行动或无行动，则提供一份董事会没有经过考虑的重要信息的详细说明，如果董事会没有收到此类信息，说明为何提交请求方没有在董事会采取行动或拒绝采取行动之前将信息提交给董事会；
i. 请求方要求 ICANN 采取的具体措施，也就是，是否应该撤销、取消或修改行动以及如何进行，或者应该采取什么样的具体行动；
8. 重审委员会有权以同样的方式对不同各方的重审请求进行考虑，条件是：(i) 请求包含相同的常规行动或无行动；(ii) 提交重审请求的各方因这类行动或无行动而受到类似的影响。
9. 重审委员会在收到重审请求后应立即对其进行审核，并在 30 天之内宣布其在收到重审请求后拒绝进行考虑或同意进行考虑的意图所在。此公告应在网站上发布。
10. 重审委员会关于没有遵循重审请求的决策公告必须说明做出这种决策的理由。
11. 重审委员会可以要求提交重审请求方提供额外信息或进行说明。
12. 重审委员会可以要求 ICANN 员工就该事项提出自己的意见，这些意见应在网站上公开发布。
13. 如果还需要其他信息，重审委员会可以选择通过电话或电子邮件与请求重审方举行会议，如果请求重审方接受，也可以邀请该方亲自参加会议。如果在此类会议中所收集到的任何信息与重审委员会提出的任何建议相关，则该信息应在重审委员会的建议中如实写明。
14. 重审委员会还可以要求第三方提供有关请求的信息。如果收集到的任何信息与重审委员会提出的任何建议相关，则该信息应在重审委员会的建议中如实写明。
15. 重审委员会应根据公众书面记录（包括由请求重审或审核的一方、ICANN 员工和任何第三方提交的信息）对重审请求采取行动。
16. 为防止滥用重审流程，如果重审请求重复、无关紧要、不真实或具有诽谤性，或者受影响方在收到通知的情况下，没有利用这次机会参加有关争议性行动的公众评论（如果适用），则重审委员会可以解除重审请求。同样，如果请求方没有显示出将受到 ICANN 行动的影响，则重审委员会可以解除请求。
17. 重审委员会在收到重审请求之后的 90 天内应向董事会就该请求提出最终建议，如果行不通，则应向董事会报告阻止其提出最终建议的情况，并对提出此类最终建议所需要的时间做出最准确的估计。最终建议应在网站上公布。
18. 董事会并不是必须得遵循重审委员会的建议。董事会的最终决策应作为董事会会议（在该会议上采取行动）的初步报告和会议记录的一部分公开发布。
19. 重审委员会应每年向董事会提交一份报告，其中至少包含前一个日历年的下列信息：
c. 在日历年年终时仍处于未决状态的重审请求数量，以及此类重审请求处于未决状态的平均时间长度；
d. 在日历年年终时未决状态超过九十 (90) 天的重审请求的描述，以及委员会尚未对其采取行动的原因；
e. 委员会拒绝进行考虑的重审请求的数量和性质，原因是这些请求不满足本政策中所制定的标准；
f. 任何其他可用机制应针对遭到拒绝的重审请求做出解释，以确保 ICANN 对受到其决策重大影响的人员负责；
g. 从委员会的观点来看，是否应修订可以请求重审的标准，或者是否应采用或修改其他流程，以确保受到 ICANN 决策重大影响的所有人员都可以有意义地参与审核流程，从而在限制产生滋扰性主张的同时能够确保公平性。
20. 每个年度报告还应汇总本款第 19(a)-(e) 项 所列出的自 2003 年 1 月 1 日起这段时间的主题的相关信息。
1. 除了本条第 2 款中所述的重审流程之外，ICANN 目前还应实施一个单独的流程，第三方可以通过该流程对那些由受影响方提出的与公司条款或章程相抵触的董事会行动进行独立审核。
2. 对于受到董事会决策或行动（认为与公司条款或章程相抵触）重大影响的任何个人，均可以提交请求以对该决策或行动进行独立审核。
3. 此类独立审核请求应提交到独立审核组（“IRP”），该审核组负责将有争议性的董事会行动与公司条款和章程进行比较，并负责声明董事会行动是否与公司条款和章程中的规定相一致。
4. IRP 应由 ICANN 不定期指定的国际仲裁供应商（“IRP 供应商”）进行运作，同时采用合同中规定的或由该供应商提名的仲裁人员。
5. 在获得董事会批准的情况下，IRP 供应商将确立运营规则和程序，这些规则和程序应贯彻本条款第 3 款中的规定并与其保持一致。
6. 任何一方均可以选择由三名成员组成的审核组对独立审核请求进行考虑；如果没有任何类似的选择，应由一名成员组考虑此事项。
7. IRP 供应商应确定一个程序以将成员分配到各个审核组中；如果 ICANN 作出此类规定，则 IRP 供应商应设立一个常务组来听取此类主张。
a. 要求审核请求方、董事会、支持组织或其他各方提交额外的书面提议；
c. 建议董事会延缓任何行动或决策，或者在董事会根据 IRP 的意见进行审核并采取行动之前，建议董事会采取任何临时行动。
9. 在 ICANN 组织结构中担任官职的个人没有资格在 IRP 供职。
10. 为了尽量减少独立审核的费用和负担，IRP 应尽最大可能通过电子邮件或互联网处理其事务。如果需要，IRP 可以召开电话会议。
11. IRP 应遵守由董事会批准的 IRP 供应商运营规则和程序中所规定的利益冲突政策。
12. IRP 的声明应采用书面形式。IRP 应仅以各方所提交的文档、支持材料和意见为基础发表声明，并且应在其声明中特别指明胜诉方。败诉方通常应负责承担 IRP 供应商的所有费用，但在特殊情况下，IRP 可以根据具体情况在其声明中指出将 IRP 供应商的一半费用分派给胜诉方，这些情况包括：考虑到各方职位的合理性及其对公众利益的贡献。参与 IRP 行动的各方均应承担其自己的费用。
13. IRP 运作程序以及所有请求、主张和声明在其可用时均应在网站上进行公布。
1. 董事会应通过与接受审核的组织无关的一个或多个实体对各支持组织、各支持组织理事会、各咨询委员会（除了政府咨询委员会外）及提名委员会的业绩和运作情况进行定期审核，如果切实可行的话，审核频率不低于每三年一次。根据采取董事会规定的标准所采取的审核目标应是为了确定 (i) 作为 ICANN 组织结构的一部分，该组织是否具有长期的目标，(ii) 如果有的话，那么对其结构或运作方式的任何更改是否有助于提高其效力。此类审核的结果应在网站上公布以进行公开审核和评论，董事会应于审核结果公布 30 天之后，于第二次董事会计划会议之前对此审核结果进行考虑。董事会考虑的事项包括经全体董事会成员 2/3 投票同意对 ICANN 组成部分的结构或运作进行修订的能力。
2. 首次进行此类审核应不迟于 2003 年 12 月 15 日，并应及时完成审核过程，以供董事会在 2004 年 ICANN 年会上对其进行考虑。进行此次审核的机构应包括 GNSO 理事会和 ICANN 根服务器系统咨询委员会。第二次进行此类审核应不迟于 2004 年 11 月 15 日，并应及时完成审核过程，以供董事会在 2005 年 ICANN 年会上对其进行考虑。进行此次审核的机构应包括 ccNSO、ccNSO 理事会以及董事会可以指定的此类其他组织。
1. 应设立监察官办公室，由监察官管理，包括由董事会确定的适当可行的人力支持。监察官应担任全职工作，并领取由董事会确定的与该职能相应的薪水和福利。
2. 监察官应由董事会任命，首任期为两年，并由董事会决定是否可以连任。
3. 监察官应由董事会罢免，前提是整个董事会中有四分之三 (3/4) 多数的成员投票表决同意罢免。
4. 董事会应将监察官办公室的年度预算作为 ICANN 年度预算流程的一部分。监察官应向总裁提交一份预算提案，然后由总裁把收到的预算提案原封不动地并入整个 ICANN 总裁预算建议，并呈交董事会讨论。本条款没有禁止总裁就监察官的预算提案的主旨、规模或其他特性方面向董事会提出不同意见。
监察官的特权是作为中立的争议解决执行者，处理在第 IV 条第 2 款 的重审政策或第 IV 条第 3 款 的独立审核政策中的各项规定尚未指出的事宜。监察官的主要职能是对 ICANN 社群成员提出的认为自己受到 ICANN 员工、董事会或 ICANN 组成机构不公正对待的投诉进行独立的内部评估。监察官应客观地拥护公正，设法评估并尽可能解决关于受到 ICANN 员工、董事会或 ICANN 组成机构不公正或不当对待的投诉，澄清问题并利用谈判、促进和“穿梭外交”等冲突解决手段实现这些结果。
监察官办公室应做到以下几点：
1. 促进公平、公正、及时地解决由于董事会或 ICANN 员工所采取的特定行动或无法采取行动而受到影响的 ICANN 社群成员（不包括 ICANN 员工和供应商）可能提出的问题和投诉。另外，这些事项尚未成为重审政策或独立审核政策的主题；
2. 行使自由裁量权，接受或拒绝对投诉或问题采取行动，包括制定程序处理由于不够具体、缺少实质性或和 ICANN 与社群互动关联不大而成为监察官要处理的不当问题的投诉。此外，在没有上述限制时，监察官无权对内部管理事务、员工事务、董事会成员相关问题或供应商关系相关问题采取任何行动；
3. 有权从 ICANN 员工和组成机构获得所有必要信息和记录，但不得公布任何机密内容，以实现对投诉进行有根据的评估以及在解决争议时提供适当援助（只需承担投诉者强加的保密义务或遵守 ICANN 采用的任何适用的保密政策）；
1. 所有 ICANN 员工、董事会成员或其他支持组织或顾问委员会的参与者都不得阻止或妨碍监察官与 ICANN 社群（包括 ICANN 员工）保持联系。ICANN 员工和董事会成员应引导提出与 ICANN 有关的问题、担心或投诉的 ICANN 社群成员与监察官联系，监察官将向投诉者建议各种可行选项以审查这些问题、担心或投诉。
2. ICANN 员工和其他 ICANN 参与者应遵守和尊重监察官办公室做出的关于对办公室收到的投诉保密的决定。
3. 与监察官联系并不能视为向 ICANN 通知任何具体诉讼或案由。
4. 应专门授权监察官向董事会递交自己认为适当的、关于任何特殊事宜及其解决措施或无法解决的报告。如果监察官未根据自行判断确定报告不符合规定，则应在网站上公布上述报告。
5. 监察官不得采取任何本章程中未授权的行动，尤其不应以任何方式提起、参与或支持任何挑战 ICANN 结构、程序、流程或任何 ICANN 董事会、员工或组成机构行为的法律诉讼。
监察官办公室应每年公布对这一年中的投诉和解决措施的综合分析，并适当处理好保密义务和顾虑。上述年度报告应对这一期间内收到投诉的任何趋势或共同因素进行说明，并建议可以采取的措施以将未来投诉减到最少。年度报告将在网站上公布。
ICANN 董事会（以下称“董事会”）应包括 15 名具有表决权的成员（以下称“董事”）。此外，应根据本条第 9 款中规定的需要，指派 6 名无表决权的联络员（以下称“联络员”）。只有董事能确定是否达到法定人数和 ICANN 董事会表决的有效性。
a. 由提名委员会（根据本章程第 VII 条设立）选出的 8 名具有表决权的成员。这些董事会席位在本章程中由席位 1 到 8 表示。
b. 由地址支持组织根据本章程第 VIII 条的规定选出的 2 名具有表决权的成员。这些董事会席位在本章程中由席位 9 到 10 表示。
c. 由国家和地区代码名称支持组织根据本章程第 IX 条的规定选出的 2 名具有表决权的成员。这些董事会席位在本章程中由席位 11 到 12 表示。
d. 由通用名称支持组织根据本章程第 X 条的规定选出的 2 名具有表决权的成员。这些董事会席位在本章程中由席位 13 到 14 表示。
2. 在履行其职责填补 1 到 8 席位空缺时，提名委员会应通过采用本条第 3 款中规定的标准，努力确保 ICANN 董事由在总体上代表不同地域、文化、技能、经验和观点的成员组成。提名委员会任何时候都不得推选董事填补任何席位空缺或届满的任期，因为选择他们将导致作为任一地理区域（请参见本条第 5 款）中各国家/地区公民的董事（不包括总裁）的总人数超过 5 人；提名委员会应通过选举确保董事会始终在各 ICANN 地理区域都有一位董事（身为各地理区域内国家/地区的公民）。
3. 在履行职责填补 9 到 14 席位空缺时，支持组织应通过采用本条第 3 款中规定的标准，努力确保 ICANN 董事由在总体上代表不同地域、文化、技能、经验和观点的成员组成。在任何特定时间内，由任何支持组织选出的两名董事均不应为来自同一国家/地区或位于同一地理区域内的国家/地区的公民。
ICANN 董事应：
1. 兼具正直、客观、机智等品质，以正确的判断和开明的思想闻名，并经证明有能力制定考虑周到的团队决策；
2. 了解 ICANN 使命和 ICANN 决策对全球互联网社群的潜在影响，并致力于实现 ICANN 的成功；
3. 在董事会实现最广泛的文化和地域多样性，并符合本款规定的其他标准；
4. 总的说来，熟悉 gTLD 注册机构和注册商运营；ccTLD 注册机构；IP 地址注册机构；互联网技术标准和协议；政策制定程序、法律传统和公众利益；各类企业、个人、学术和非商业互联网用户；
1. 无论有无与本条款规定相反的情况，国家/地区政府官员或通过国家/地区政府之间签订的条约或其他协议成立的跨国实体的官员都不得担任董事。在本章程中，“官员”一词指 (i) 经选举而担任政府职务的人员或 (ii) 由政府或跨国实体雇用的人员，而且其在政府或机构的主要职能是制定或影响政府或公共政策。
2. 任何支持组织理事会中的任何任职人员（包括联络员）均不应同时担任董事会董事或董事会联络员。如果此人接受了由支持组织理事会选为董事的提名，则不应在此之后参与支持组织理事会关于理事会选举董事的讨论或表决，直到理事会选出由其负责推选的所有董事。如果支持组织理事会中的任职人员接受了被选为董事的提名，则推选该人的选区组织或其他团体或实体可以根据理事会筛选流程的需要选择一名替代者。
3. 支持提名委员会中的任何任职人员都没有资格竞选董事会职位，如第 VII 条第 8 款所述。
为确保董事会能够体现广泛的国际代表性，提名委员会和各支持组织推选董事时应遵守本章程或本章程中提及的与支持组织相关的谅解备忘录中所有适用的多样条款。制定这些多样条款的目的之一就是确保任何时候各地理区域都拥有至少一名董事，而且任何地区在董事会的董事（不包括总裁）始终都不超过 5 名。在本章程中，下列各项分别被视为一个“地理区域”：欧洲；亚洲/澳大利亚/太平洋地区；拉丁美洲/加勒比海岛；非洲；和北美地区。各地理区域中包括的特定国家/地区应由董事会确定，董事会应间或（但至少每三年）审查本款，以确定是否应根据互联网的发展进行某些适当的更改。
董事会应通过为满足该目的而设的委员会，要求各董事至少每年提交一份声明，阐明以任何形式与 ICANN 的业务和其他附属业务关联的所有业务和其他附属业务。各董事应负责向 ICANN 公开任何依《加州非营利性公益社团法》（以下称“CNPBCL”）第 5233 款的含义被合理认为可能使该董事成为“利害关系董事”的事项。此外，每位董事应向 ICANN 公开任何依 CNPBCL 的 5227 款的含义可能导致该董事被合理认为是“利害关系人”的关系或其他因素。董事应采用各种政策专门解决董事、官员和支持组织的利益冲突。其实质利益或直接财务利益受某一表决结果影响的任何董事不得参加针对该事项的表决。
各董事应以个体身份行事，一切以 ICANN 利益为重，而不是代表选择他们的实体、雇主或任何其他组织或选区组织。
1. 根据本章程移交条款中的规定，董事席位 1 到 14 的正常任期开始时间如下：
a. 席位 1 到 3 的正常任期应从 2003 年 ICANN 年会以及以后每次 ICANN 年会（2003 年后每隔三年举行一次）结束时开始；
b. 席位 4 到 6 的正常任期应从 2004 年 ICANN 年会以及以后每次 ICANN 年会（2004 年后每隔三年举行一次）结束时开始；
c. 席位 7 和 8 的正常任期应从 2005 年 ICANN 年会以及以后每次 ICANN 年会（2005 年后每隔三年举行一次）结束时开始；
d. 席位 9 和 12 的正常任期应从 2002 年 ICANN 年会以及以后每次 ICANN 年会（2002 年后每隔三年举行一次）结束后的六个月开始；
e. 席位 10 和 13 的正常任期应从 2003 年 ICANN 年会以及以后每次 ICANN 年会（2003 年后每隔三年举行一次）结束后的六个月开始；
f. 席位 11 和 14 的正常任期应从 2004 年 ICANN 年会以及以后每次 ICANN 年会（2004 年后每隔三年举行一次）结束后的六个月开始。
2. 每位担任 1 到 14 席位的董事，包括被选出填补空缺的董事，其任职期限应持续至该席位的下一任期开始，直到选出合格的接任者为止，或直到该董事根据本章程辞职或免职为止。
3. 在每次年会开始之前，提名委员会应至少提前一个月书面通知 ICANN 秘书长选举任期从年会结束时开始的董事席位。
4. 在每次年会结束后五个月内，负责选举任期从年会结束后六个月开始的董事席位的任何支持组织应将其选举书面通知 ICANN 秘书长。
a. 一名由政府咨询委员会任命的联络员；
b. 一名由根服务器系统咨询委员会（根据本章程第 XI 条设立）任命的联络员；
c. 一名由安全性和稳定性咨询委员会（根据本章程第 XI 条设立）任命的联络员；
d. 一名由技术联络组（根据本章程第 XI-A 条设立）任命的联络员；
e. 一名由一般会员咨询委员会（根据本章程第 XI 条设立）任命的联络员；
2. 根据本章程移交条款中的规定，无表决权联络员的任期应从每次年会结束时开始。在每次年会开始之前，负责任命无表决权联络员的机构应至少提前一个月将其任命书面通知 ICANN 秘书长。
3. 无表决权的联络员应作为志愿者提供服务，除了报销某些费用之外，没有任何报酬。
4. 每一位无表决权的联络员都可以重新任命，并应继续担任该职位直到已任命接任者或直到该联络员根据本章程辞职或免职。
5. 无表决权的联络员应有权出席董事会会议、参与董事会讨论和商讨，并可获得（根据董事会制定的条件）供董事用于董事会讨论、商讨和会议的材料，但不应享受董事权利和特权。无表决权的联络员应有权（根据董事会制定的条件）将根据本款规定向其提供的材料用于与其各自的委员会或组织进行商议。
根据 CNPBCL 第 5226 款，任何董事或无表决权的联络员都可以随时辞职，通过在任何董事会会议上提出口头辞呈（随后立即向 ICANN 秘书长提交书面通知），或者向 ICANN 总裁或秘书长提交书面通知。上述辞呈应在指定间内生效，除非另有说明，接受辞呈并不一定使其生效。应根据本条第 12 款选出接任者。
1. 任何董事可以在通知该董事后被免职，如果由支持组织选出，只需通过该支持组织四分之三 (3/4) 董事多数投票表决即被免职；但是，前提是作为免职行动对象的董事应无权对该行动表决或在计算所需的四分之三 (3/4) 投票表决时，不应将其视为董事会表决成员；此外，前提还包括免除董事的每次表决应该就免除该特定董事这一单一问题进行的单独表决。
2. 除非无表决权的联络员由政府咨询委员会任命，任何无表决权联络员都可以在通知该联络员和选举该联络员的组织后免职，如果选举组织在得到上述通知后无法马上免除该联络员，只需通过四分之三 (3/4) 董事多数投票表决即可免职。如果董事会通过四分之三 (3/4) 董事多数投票表决确定适合采取该行动，则董事会可以请求政府咨询委员会考虑替换由委员会任命的无表决权联络员。
1. 在下列情况下，应视为董事会产生空缺：董事死亡、辞职或免职；董事法定人数增加；根据 CNPBCL 第 5230 款等规定，董事被法庭最终宣布精神失常、宣判重罪、因刑事定罪而监禁 90 天以上或由法庭最终裁定渎职。董事会产生的任何空缺应由提名委员会填补，除非 (a) 该董事由支持组织选出，在这种情况下，此空缺应由该支持组织填补，或 (b) 该董事为总裁，在这种情况下，该空缺应根据本章程第 XIII 条中的规定填补。选举机构应将其填补空缺的任命书面通知 ICANN 秘书长。被选出填补董事会空缺的董事应继续完成前任未满的任期，直到选出合格的接任者为止。在董事任职期满之前，如果减少董事法定人数不得免除董事职位。
2. 在本条第 9 款 中规定的选择无表决权联络员的组织负责确定这些职位是否存在空缺并进行填补。这些组织应将填补空缺的任命书面通知 ICANN 秘书长。
ICANN 每年召开年会，以满足选举官员的需要，并处理年会开会前出现的其他类似事务。每次 ICANN 年会应在 ICANN 总部或其他任何符合董事会时间和选择的适当地点召开，而且该年会必须在上一次年会结束后的 14 个月内马上召开。如果董事会认为可行，则年会应通过互联网实时发布，并以视频和音频格式存档。
董事会按照其确定的日期举行例会。如果未指定其他地点，例会应在 ICANN 总部召开。
经董事会四分之一 (1/4) 成员、董事会主席或总裁的要求，董事会应召开特别会议。特别会议由 ICANN 秘书长召集。如果未指定其他地点，特别会议应在 ICANN 总部召开。
所有会议的举行时间和地点应采取当面、电话或电子邮件形式通知每位董事和无表决权的联络员，或按照 ICANN 记录的地址通过预付费的一类邮件（通过航空邮件寄往美国以外地区）或传真发送给每位董事或无表决权联络员。如果以邮寄方式传达通知，至少应在会议召开时间前十四 (14) 天从美国寄出。如果采取当面通知或电话、传真或电子邮件通知形式，至少应在会议召开时间前四十八 (48) 小时进行。无论有无与本款规定相反的情况，会议通知不必送达任何签署过弃权书、召开会议书面同意书或相关会议记录批准书（无论会议召开前后）的董事，或者虽然没有得到正式通知，但在会议举行之前或会议开始时对会议的举行没有异议并出席会议的董事。上述所有弃权书、同意书或批准书都应记入公司记录或包括在会议记录中。
除非本章程或法律另有规定，否则在董事会的所有年会、例会和特别会议上，多数在职的董事即构成了对商业事务进行表决的法定人数；在任何符合法定出席人数的董事会会议上，多数董事投票通过的决定就是董事会的决定。如果出席任何董事会会议的董事未能达到法定人数，则出席会议的董事有时可以请求休会，并另行决定会议的地点、时间或日期。如果会议休会超过二十四 (24) 小时，应通知休会时未出席会议的董事。
董事会或董事会任何委员会的成员可以通过使用 (i) 会议电话或类似通讯设备（前提是所有出席该会议的董事都可以互相讨论与听取意见）或 (ii) 电子显示屏通讯或其他通讯设备参与董事会或董事会委员会会议，前提是 (a) 所有出席该会议的董事都可以讨论与听取意见，(b) 所有参加会议的董事在董事会或董事会委员会开始之前均了解完全参与所有事宜的方法，且 (c) ICANN 所采用和实施的手段能够证实：(x) 出席该会议的人员是董事或具有参会资格的其他人员，以及 (y) 董事会或董事会委员会的所有行动或表决均仅由董事会或委员会成员，而不是由非成员开展或进行。根据本款规定参与此类会议，视为自出席会议。ICANN 应在董事会会议召开地点提供允许董事会成员通过电话参与会议所必需的电信设备。
只要具有表决权的全体董事单独或集体以书面形式表示同意，则凡董事会或董事会委员会要求或允许采取的行动均可实行，而不必通过开会决定。上述书面同意与上述董事的无异议表决具有同等效力。上述书面同意或同意应记入董事会会议记录中。
除非要求采取书面形式，否则如果适用法律允许，则应认为以电子邮件进行的交流与任何交流方式具有同等的效力。在这种情况下，ICANN 应采取其认为适当的措施，确保其以电子邮件进行的交流的真实性。
每位董事都有权在合理的时间内查阅和复制所有书籍、记录和文件，检查 ICANN 的实物资产。ICANN 应制定合理程序以防止机密信息不当泄露。
董事在任职期间没有任何报酬。但是，有关董事和无表决权联络员在履行其相应职责时产生的实际而必要的合理费用，董事会可以批准报销。
一般应推定出席董事会会议的董事赞成会议对任何社团事宜采取的行动，但如果会议记录中有该董事的异议或弃权意见，或者该董事在休会前以书面形式向担当会议秘书工作的人员提出对上述行动的异议或弃权意见，或者在休会后立即以挂号邮件方式向 ICANN 秘书长提出上述异议或弃权意见，则另当别论。上述表示异议或弃权的权利不适用于在表决中投赞成票的董事。
应设立 ICANN 提名委员会，负责所有 ICANN 董事（总裁和由 ICANN 支持组织选举的董事除外）的选举工作，还负责本章程中规定的其他选举工作。
提名委员会由以下人员组成：
3. 一名由 ICANN 根服务器系统咨询委员会任命的无表决权联络员，该委员会是根据本章程第 XI 条成立的；
4. 一名由 ICANN 安全性和稳定性咨询委员会任命的无表决权联络员，该委员会是根据本章程第 XI 条成立的；
5. 一名由政府咨询委员会任命的无表决权联络员；
6. 根据本章程移交条款中的规定，由一般会员咨询委员会选出的五名有表决权的代表，该委员会是根据本章程第 XI 条成立的；
7. 由通用名称支持组织的商业用户选区组织选出的两名有表决权的代表（一名代表小型企业用户，另一名代表大型企业用户），该支持组织是根据本章程第 X 条成立的；
a. 通用名称支持组织的 gTLD 注册机构选区组织，该支持组织是根据本章程第 X 条成立的；
b. 通用名称支持组织的 gTLD 注册商选区组织，该支持组织是根据本章程第 X 条成立的；
c. 国家和地区代码名称支持组织的理事会，该支持组织是根据本章程第 IX 条成立的；
d. 通用名称支持组织的互联网服务提供商选区组织，该支持组织是根据本章程第 X 条成立的；
e. 通用名称支持组织的知识产权选区组织，该支持组织是根据本章程第 X 条成立的；
f. 地址支持组织的理事会，该支持组织是根据本章程第 VIII 条成立的；
h. 消费者和民间社团组织，由通用名称支持组织的非商业用户选区组织选出，该支持组织是根据本章程第 X 条成立的；
j. ICANN 技术联络组，该联络组是根据本章程第 XI-A 条成立的；
9. 无表决权的副主席，可由主席自行任命，并在主席的整个或部分任职期间行使权利。副主席可以不是该提名委员会的成员。副主席应协助主席履行主席职责，但不能暂时地或以其他方式代理主席工作。
根据本章程移交条款中的规定：
1. 每位有表决权的代表的任期应为一年。代表最多可连任一次，且任期也为一年，这之后必须满两年才有资格再次担任代表。
2. 对于每位有表决权的代表，其正常任期应从一次 ICANN 年会结束时开始，并于下次 ICANN 年会结束时终止。
3. 无表决权联络员的任期由指定这些联络员的实体指定。主席、担任顾问的前任主席和任意一位现任副主席的任期到下次 ICANN 年会结束时终止。
4. 代表、无表决权联络员或主席职位出现空缺时，应由负责选举这些职位的实体来提供人选。无表决权顾问（前任主席）职位出现空缺时，可由董事会从前董事会成员或前提名委员会成员中选出。副主席职位出现空缺时，可由主席遵照本条第 2 款第 9 项规定的标准提供人选。
ICANN 提名委员会的代表应符合以下标准：
1. 正直、客观和高智商的全面型人才，在判断力准确、思想开放以及具备在大学大型组织内制定决策的经验和能力方面都得到很高的评价；
2. 交际广泛，拥有丰富的互联网社群经验，并致力于实现 ICANN 的成功；
3. 选举机构确信在履行相应职责时能够广泛征求和接纳意见的人才；
4. 在履行相应提名委员会职责时，能够保持中立和客观的态度，对特定的个人、组织或商业对象没有任何固定的个人承诺；
5. 理解 ICANN 使命和 ICANN 活动对自愿提供服务的更广泛互联网社群的潜在影响，另外，除了报销某些费用之外，没有任何报酬；
提名委员会在履行其职责来选拔 ICANN 董事会成员，以及根据本章程规定的职责来选拔任何其他 ICANN 机构的成员时，应将 ICANN 董事会和其他类似机构的连续成员资格纳入考虑范围，并力求确保用来填补 ICANN 董事会及其他每个类似机构中各空缺的所选人员能够在适合并符合本条第 4 款规定的其他标准的情况下，按照第 I 条第 2 款 核心价值 4 的指导原则做出选择。
ICANN 为提名委员会履行其职责提供必要的管理和运营支持。
提名委员会应采纳确实必要的运营程序，并将其发布到网站上。
对于提名委员会中的任职人员，如果 ICANN 年会的结束时间等于或晚于相应人员的任职到期时间，则相应人员有资格以任何方式参选董事会或以下任何其他 ICANN 机构中的任何职位，这些机构中的一个或多个成员职位由提名委员会负责派人担任。
ICANN 的任何员工或收费顾问（包括监察官）不得同时担任提名委员会的任何职务（请参见本条第 2 款）。
1. 地址支持组织 (ASO) 须向董事会就有关互联网地址操作、分配和管理的政策问题提出建议。
2. ASO 是依据由 ICANN 和号码资源组织 (NRO) 于 2004 年 10 月 21 日签署的谅解备忘录设立的实体，NRO 是由各个现有区域互联网注册机构 (RIR) 构成的一个组织。
应设立政策制定机构，即国家和地区代码名称支持组织 (ccNSO)，该组织负责：
1. 制定与国家和地区代码顶级域相关的全球政策并上报董事会；
根据 ccNSO 成员资格，适用于该组织成员的政策仅指根据本条第 4.10 款和 4.11 款制定的政策。但 ccNSO 也可以参与由其成员授权的其他活动。是否遵守上述活动成果取决于自愿，这些活动可以包括：设法为 ccTLD 经理制定志愿者最佳做法、帮助在全球 ccTLD 经理社群中加强技能，以及促进 ccTLD 经理之间的运营和技术协作。
ccNSO 应由以下两部分组成：(i) 已书面同意成为 ccNSO 成员的 ccTLD 经理（请参见本条第 4 款第 2 项）；(ii) 负责管理 ccNSO 的政策制定流程的 ccNSO 理事会。
1. ccNSO 理事会应由以下几部分组成：(a) 三名 ccNSO 理事会成员，由每个 ICANN 地理区域 的 ccNSO 成员按照本条第 4 款第 7 至 9 项规定的方式选出；(b) 由 ICANN 提名委员会选出的三名 ccNSO 理事会成员；(c) 本款第 2 段所述的联络员；(iv) 本款第 3 段所述的观察员。
2. 以下每个组织至少还应各选出并任命一名人员，作为 ccNSO 理事会的联络员：(a) 政府咨询委员会；(b) 一般会员咨询委员会；以及 (c) 本条第 5 款所述的各区域组织。上述联络员不能是 ccNSO 理事会成员，也不可在该理事会具有表决权，但享有与 ccNSO 理事会成员同等的参与资格。联络员的任命应以书面通知的形式提交给 ICANN 秘书长，同时向 ccNSO 理事会主席发送该通知副本，任期遵照任命组织在书面通知上的指示。任命组织可随时罢免或替换其联络员，但需要向 ICANN 秘书长提交罢免或替换的书面通知，同时向 ccNSO 理事会主席发送该通知副本。
3. ccNSO 理事会可与其他任何 ICANN 支持组织的理事会就交换观察员达成一致协议。上述观察员不能是 ccNSO 理事会成员，也不可在该理事会具有表决权，但享有与 ccNSO 理事会成员同等的参与资格。任命理事会可随时向 ccNSO 理事会指派（罢免或替换）其观察员，但需要向 ICANN 秘书长提交书面通知，同时向 ccNSO 理事会主席发送该通知副本。
4. 根据本章程移交条款中的规定：(a) 所有 ccNSO 理事会成员的正常任期应从一次 ICANN 年会结束时开始，并于其后第三次 ICANN 年会结束时终止；(b) 由每个 ICANN 地理区域的 ccNSO 成员选出的三位 ccNSO 理事会成员的正常任期是相互交错的，即一位成员的任期从一个可被三整除的年份开始，第二位成员的任期从该年（可被三整除的年份）的下一年开始，第三位成员的任期从该年（可被三整除的年份）以后的第二年开始；(c) 提名委员会选出的三名 ccNSO 理事会成员的正常任期也应采用相同的交错方式。每位 ccNSO 理事会成员应在其正常任期内任职，直到接任者选出并证明合格，或者该成员依据本章程辞职或离开。
5. ccNSO 理事会成员可随时辞职，但需要向 ICANN 秘书长提交书面通知，并向 ccNSO 理事会主席发送该通知副本。
6. ccNSO 理事会成员被免职的原因包括：无故连续三次不参加 ccNSO 理事会的会议；或做出严重的不当行为。上述两项原因均通过至少 66% 的全体 ccNSO 理事会成员投赞成票来确定。
7. 在下列情况下，应视为 ccNSO 理事会产生空缺：任何 ccNSO 理事会成员死亡、辞职或免职。提名委员会选出的三位成员出现空缺时，应由提名委员会通过向 ICANN 秘书长提交人选的书面通知，同时向 ccNSO 理事会主席发送该通知副本，来填补未满的任期。ccNSO 成员选出的 ccNSO 理事会成员出现空缺时，应根据本条第 4 款第 7 至 9 项规定的程序填补未满的任期。
8. ccNSO 理事会的职责是管理和协调 ccNSO 事务（包括协调本条第 4 款第 6 项所述的 ccNSO 成员会议，包括年会），以及依据本条第 6 款管理政策建议的制定。ccNSO 理事会还应承担其他职责，如 ccNSO 经常需要确定各种成员的人选。
9. ccNSO 理事会应通过书面投票或会议决议的形式选举董事会席位 11 和 12；任何类似选举必须经过当时 ccNSO 理事会全体在职成员的多数投赞成票才能通过。ccNSO 理事会的人选通知应由 ccNSO 理事会主席以书面形式提交给 ICANN 秘书长，这一程序须遵照第 VI 条， 第 8 款第 4 项 和第 12 款第 1 项。
10. ccNSO 理事会应从其成员中选举 ccNSO 理事会主席和适当数量的副主席。ccNSO 理事会主席和副主席职位应通过书面投票或以会议决议的形式选举；任何类似选举必须经过当时 ccNSO 理事会全体在职成员的多数投赞成票才能通过。ccNSO 理事会主席和任何副主席职位的任期应由 ccNSO 理事会在选举时或选举之前指定。ccNSO 理事会主席或任何副主席的罢免可以采用与选举相同的程序。
11. ccNSO 理事会应根据 ccNSO 成员的指导采纳视为必要的 ccNSO 规则和程序，前提是这些规则和程序符合本章程。ccNSO 理事会应将采纳的 ccNSO 成员规则和运营程序发布到网站上。
12. 除了本款第 9 段和第 10 段中的说明，ccNSO 理事会应在会议中发挥作用。ccNSO 理事会应按照自身确定的日程定期开会，但每个日历年不得少于四次。根据 ccNSO 理事会的意见，会议可以现场或其他方式举行，前提是 ccNSO 理事会全体成员都可以通过本款第 14 段中所述的至少一种方式参加会议。除非 ccNSO 理事会出席成员多数投赞成票确定适合召开封闭性会议，否则现场会议应向所有相关人员开放。在可行范围内，ccNSO 理事会会议应与董事会会议或 ICANN 其他支持组织的一个或多个会议同时进行。
13. ccNSO 理事会所有会议的举行时间和地点（以及除亲自参加外其他参加方式的相关信息）应以电子邮件、电话、传真或书面通知（直接送达或邮寄）的方式，通知每位 ccNSO 理事会成员、联络员和观察员。如果以邮寄方式传达通知，至少应在会议召开日期前 21 天寄出。如果采取直接送达或者通过电话、传真或电子邮件方式传达通知，至少应在会议召开日期前七天发送。每次召开 ccNSO 理事会会议，应至少提前七天（如果不可行，则尽量提前）公布关于此次会议及其已知日程的通知。
14. ccNSO 理事会成员可通过现场参加或使用电子通讯方式（如电话或视频会议）参加 ccNSO 理事会会议，前提是 (a) 所有参加会议的 ccNSO 理事会成员可互相讨论与听取意见，(b) 所有参加会议的 ccNSO 理事会成员在 ccNSO 理事会开始之前均了解完全参与所有事宜的方法，(c) 提供合理的方式对参加会议的 ccNSO 理事会成员身份及其投票进行验证。除非本章程另有规定，否则多数在职的 ccNSO 理事会成员（即有表决权的成员）即构成了对商业事务进行表决的法定人数；在任何符合法定出席人数的 ccNSO 理事会会议上，多数理事会成员投票通过的决定就是 ccNSO 理事会的决定。ccNSO 理事会应将其会议记录传送给 ICANN 秘书长，会后由 ICANN 秘书长将这些记录尽快发布到网站上，但不迟于会议后 21 天。
1. ccNSO 的成员资格包括 ccTLD 经理。任何 ccTLD 经理如果符合本款第 2 段 中所述的成员资格，均有资格成为 ccNSO 成员。就本条款而言，ccTLD 经理是负责管理 ISO 3166 国家和地区代码顶级域的组织或实体，在 IANA 数据库中当前名为“赞助组织”的标题下，或在以后其他形式的该标题下，会提到由此组织或实体来管理该国家和地区代码顶级域。
2. 任何 ccTLD 经理通过向 ccNSO 理事会指定受理申请的人员提交申请，均可成为 ccNSO 成员。根据本章程移交条款中的规定，申请人应书面填写 ccNSO 理事会的指定表格。申请包括 ccTLD 经理对其在 ICANN 结构中担任 ccNSO 职务的认可，以及 ccTLD 经理对其在担任 ccNSO 成员期间的以下行为表示同意：(a) 遵守 ccNSO 规则，包括成员规则，(b) 遵守由 ccNSO 制定和建议并经董事会以本款第 10 段和第 11 段中说明的方式采纳的政策，(c) 支付 ccNSO 理事会在本条第 7 款第 3 项规定的 ccNSO 会员费。ccNSO 成员可随时辞职，但需要向 ccNSO 理事会指定接收辞职报告的人员提交书面通知。ccTLD 经理辞职后，将不再需要 (a) 遵守 ccNSO 规则，包括成员规则，(b) 遵守由 ccNSO 制定和建议并经董事会以本款第 10 段和第 11 段中说明的方式采纳的政策，(c) 支付 ccNSO 理事会在本条第 7 款第 3 项规定的 ccNSO 会员费。如果 ccNSO 理事会未指定受理申请和辞职报告的人员，可将受理申请和辞职报告发送给 ICANN 秘书长，ICANN 秘书长再将收到申请和辞职报告等事宜通知 ccNSO 理事会。
3. ccNSO 成员或本条第 5 款 所述的任何区域组织的成员均不具有访问或注册 IANA 数据库的资格。ccTLD 经理与 ICANN 之间的任何个人关系或 ccTLD 经理接受 IANA 服务，与 ccNSO 成员资格无任何关系。
4. ccTLD 的地理区域说明请参见本章程第 VI 条第 5 款。就本条款而言，如果某个地理区域内的 ccTLD 经理是 ccNSO 成员，无论该经理实际处于何地，都称其为该地理区域“内”的 ccNSO 成员。如果 ccNSO 成员所属的地理区域不确定，ccTLD 成员应根据 ccNSO 理事会采用的程序进行自主选择。
5. 每个 ccTLD 经理均可以书面形式指定人员、组织或实体代表 ccTLD 经理。如果没有指定，则应由 IANA 数据库中列示为管理联系人的人员、组织或实体来代表 ccTLD 经理。
6. ccNSO 成员应举行年会，该大会由 ccNSO 理事会进行协调。年会应允许所有人员参加，并为不是 ccNSO 成员的 ccTLD 经理以及其他非 ccNSO 成员提供合理的参与机会。在可行范围内，ccNSO 成员的年会应以现场形式举行，并且应与董事会会议或 ICANN 其他支持组织的一个或多个会议同时进行。
7. 每个地理区域的 ccNSO 成员选举的 ccNSO 理事会成员（请参见本条第 3 款第 1(a) 项）通过提名选出，如需进行选举，可由该地理区域的 ccNSO 成员执行。如果是由 ccNSO 成员选出的 ccNSO 理事会成员，至少在其正常任期结束 90 天前，或上述 ccNSO 理事会成员席位出现空缺时，ccNSO 理事会成员应建立提名和选举计划，然后将其发送给地理区域内的所有 ccNSO 成员并发布到网站上。
8. 任何 ccNSO 成员均可提名一人代表 ccNSO 成员的地理区域组织担任 ccNSO 理事会成员。提名必须获得同一地理区域另一名 ccNSO 成员的赞同。获得 ccNSO 理事会成员提名的人员如果接受上述成员提名，即表示同意支持 ccNSO 成员所遵守的政策。
9. 如果提名结束时某特定地理区域内的（获得赞同和认可的）提名候选人数未超过 ccNSO 理事会的空缺席位数，则应推选提名候选人担任 ccNSO 理事会成员。否则，该地理区域内具有选举表决权的 ccNSO 成员将通过其指定代表以书面投票方式（可能是通过电子邮件）进行选举，从（获得赞同和认可的）提名候选人中选出 ccNSO 理事会成员。在上述选举中，地理区域内具有表决权的全体 ccNSO 成员的多数应与所需的法定人数相等，而且选定候选人必须获得该地理区域内 ccNSO 成员的多数投票。ccNSO 理事会主席应就选举 ccNSO 理事会成员（依据本段规定）事宜向 ICANN 秘书长提交即时的书面通知。
10. 根据第 4(11) 项，按照 ccNSO 成员资格适用于 ccNSO 成员的 ICANN 政策仅限于以下四项：(a) 依据第 IX 条第 6 款和附件 C 仅解决 ccNSO 范围内问题的政策，(b) 通过 ccPDP 制定的政策（请参见本条第 6 款），(c) 由 ccNSO 向董事会建议的政策，(d) 由董事会采纳的政策，前提是上述政策与 ccTLD 经理的适用法律（始终高于其他政策）没有冲突。另外，上述政策应适应于 ICANN 举办的与 ccTLD 相关的活动。
11. ccNSO 成员如果向 ccNSO 理事会做出了以下声明：(a) 实施政策需要成员违反习俗、信仰或公共政策（未在本款第 10 段说明的适用法律中提及），(b) 不实施政策不会削弱 DNS 运营或交互协作能力，并提供支持其声明的详细理由，则该成员不应受到限制。经过调查后，ccNSO 理事会应针对 ccNSO 成员的声明做出反馈。如果 ccNSO 理事会就否决该声明达成共识（可以通过不少于 14 名的 ccNSO 理事会成员投票来证明），则反馈应该说明 ccNSO 理事不同意该声明以及不同意的理由。否则，反馈应说明 ccNSO 理事会同意该声明。如果 ccNSO 理事会不同意，则 ccNSO 理事会应该在六个月的期限后对该情况进行评审。在此期限结束时，ccNSO 理事会应就以下问题提供调查结果：(a) ccNSO 成员实施政策是否需要成员违反习俗、信仰或公共政策（未在本款第 10 段说明的适用法律中提及），(b) 不实施政策是否会削弱 DNS 运营和交互协作能力。在做出任何与声明不一致的调查结果的过程中，ccNSO 理事会应采用达成共识的意见，这可以通过不少于 14 名的 ccNSO 理事会成员投票来证明。
ccNSO 理事会可以为每个 ICANN 地理区域指定一个区域组织，前提是该区域组织允许该地理区域内所有具有 ccNSO 完全成员资格的成员加入。指定或取消指定区域组织的决策需要全体 ccNSO 理事会成员中 66% 的成员投赞成票，并且根据董事会制定的程序进行评审。
1. ccNSO 制定政策的职责范围可参见本章程附件 C；对范围的任何修改都应由 ccNSO 通过 ccPDP 程序向董事会建议，并且由董事会批准。
2. ccNSO 在制定 ccNSO 范围内的全球政策并向董事会建议的过程中，应该遵循 ccNSO 政策制定流程 (ccPDP)。ccPDP 可参见本章程附件 B；修改应由 ccNSO 通过 ccPDP 程序向董事会建议，并且由董事会批准。
1. 应 ccNSO 理事会的请求，可指派 ICANN 员工支持 ccNSO 并任命其为 ccNSO 员工事务经理。另外，ccNSO 理事会也可以自费指定其他人担任 ccNSO 员工事务经理。ccNSO 人力经理的实质性工作应由 ccNSO 理事会主席指派，并且可包括 ccPDP 问题管理人的职责。
2. 应 ccNSO 理事会的请求，ICANN 应为 ccNSO 履行其职责提供必要的管理和运营支持。上述支持不包括 ICANN 报销 ccNSO 因参加任何 ccNSO 会议或出于其他任何目的而产生的差旅费用。ccNSO 理事会可以另外自费提供管理和运营支持，或替代由 ICANN 提供的支持。
3. ccNSO 理事会须制定由 ccNSO 成员缴纳的会费，以支付本款第 1 段和第 2 段中提及的自费，但须获得 ccNSO 成员的赞成。
4. 依据本条款，提交给 ICANN 秘书长的书面通知应永久保留，并在 ccNSO 理事会请求时供其评审。ICANN 秘书长还应维护公布在网站上的 ccNSO 成员名单，该名单包括每个 ccTLD 经理的指定代表的姓名。
应设立政策制定机构，即通用名称支持组织 (GNSO)，该机构负责制定与通用顶级域名相关的基本政策并上报 ICANN 董事会。
GNSO 应包括 (i) 代表特殊利益主体团体的各种选区组织（如本条第 5 款 所述），以及 (ii) 负责管理 GNSO 政策制定流程的 GNSO 理事会。
1. 根据本章程移交条款的规定，GNSO 理事会应由本条第 5 款中所述的各选区组织选出的三名代表以及 ICANN 提名委员会选出的三名人员组成。由选区组织选出的两名代表不得为来自同一国家/地区的公民，也不得为来自同一地理区域内国家/地区的公民。还应设立两名 GNSO 理事会联络员，分别由政府咨询委员会和一般会员咨询委员会随时各指定一名，这两名联络员不得为 GNSO 理事会的成员，也不得具有参与 GNSO 理事会表决的资格，但在其他方面应享有与 GNSO 理事会成员同等的参与资格。负责人员选派的咨询委员会应通过向 GNSO 理事会主席和 ICANN 秘书长提供书面通知来指定（罢免或替换）其在 GNSO 理事会的联络员。按照本款第 9 项规定，GNSO 理事会也可以有观察员。
2. 根据本章程移交条款的规定：(a) 对于每位 GNSO 理事会成员，其正常任期应从一次 ICANN 年会结束时开始，并于其后第二次 ICANN 年会结束时终止；(b) 对于每个选区组织选出的代表，其中一名代表的正常任期应从偶数年开始，而另一名代表的正常任期应从奇数年开始；(c) 对于提名委员会选出的三名成员，其中一名成员的正常任期应从偶数年开始，而其他两名成员的正常任期应从奇数年开始。每位 GNSO 理事会成员应在其正常任期内任职，直到选出可胜任的继任者为止，或者直到该成员依据本章程辞职或被罢免为止。
3. GNSO 理事会成员可以随时辞职，但需要向 ICANN 秘书长提交书面通知。由选区组织选出的 GNSO 理事会成员，可由选区组织依据其已公布的程序罢免。由提名委员会选出的 GNSO 理事会成员，可由 GNSO 理事会全体成员（但要被罢免的成员除外）的四分之三 (3/4) 多数投票表决说明理由来罢免（请参见本条第 5 款第 2 项），最终还要经过 ICANN 董事会批准。出现以下情况时，应视为 GNSO 理事会存在职位空缺：任何成员死亡、辞职或被罢免。关于填补职位空缺以使未尽任期完成的事宜，应由提名委员会向 ICANN 秘书长提交其选举结果的书面通知，但如果在出现职位空缺之前任职的成员是由选区组织选出，则应由选区组织向 ICANN 秘书长提交其选举结果的书面通知。
4. GNSO 理事会负责管理 GNSO 的政策制定流程。该理事会应采用其认为适合履行上述职责的程序，但前提是此类程序已经过董事会批准，而且在 GNSO 理事会提出任何修改建议并经过董事会批准之前，适用的程序应符合本条第 6 款中的规定。此外，GNSO 理事会还负责管理开放论坛，采用邮件列表或其他形式向愿意为 GNSO 工作做出贡献的所有人员提供参与机会；应适度地对此类论坛进行控制，以确保尽可能将重点放在 GNSO 业务方面，并最大限度地减少无实质意义和具有诽谤性质的发帖。
5. 对于来自任何特定企业或其他组织（包括其分支和附属机构）的高级职员、董事或雇员，在任何规定时间内，于 GNSO 理事会任职的人数不得超过一人。
6. GNSO 理事会应通过书面选票或会议决议的形式选出适当人员，填补 ICANN 董事会的第 13 和 14 个席位；任何类似选举必须经过 GNSO 理事会全体成员过半数投赞成票才能通过。根据第 VI 条 第 8 款第 4 项 和第 12 款第 1 项，GNSO 理事会的选举通知应由 GNSO 主席以书面形式提交给 ICANN 秘书长。
7. GNSO 理事会应通过书面选票或会议决议的形式选出 GNSO 主席，任期由 GNSO 理事会指定，但不得超过一年。任何类似选举必须经过 GNSO 理事会全体成员过半数投赞成票才能通过。
8. 除了本款第 6 项所述的情况之外，GNSO 理事会还应参与各项会议。GNSO 理事会的成员可以通过使用以下设备参与 GNSO 理事会会议：(i) 会议电话或类似通讯设备，前提是所有出席该会议的成员都可以互相讨论与听取意见；或 (ii) 电子视频显示屏通讯或其他通讯设备，前提是 (a) 所有出席该会议的成员都可以互相讨论与听取意见，(b) 所有成员在 GNSO 理事会开会之前均了解完全参与所有事宜的方法，且 (c) ICANN 所采用和实施的手段能够证实：(x) 出席该会议的人员是 GNSO 理事会的成员或具有参会资格的其他人员，以及 (y) GNSO 理事会的所有行动或表决均仅由 GNSO 理事会成员，而不是由非成员开展或进行。除非本章程另有规定，否则多数在职的 GNSO 理事会成员（即有表决权的成员）即构成了对商业事务进行表决的法定人数；在任何符合法定出席人数的 GNSO 理事会会议上，多数理事会成员投票通过的决定就是 GNSO 理事会的决定。（有关 GNSO 理事会成员可以投出的票数，请参见本条第 5 款第 2 项 。）在合理且切实可行的情况下，至少应在会议前 7 天于网站上发布此类会议的预先通知。除非 GNSO 理事会出席成员多数投赞成票（请参见本条第 5 款第 2 项）确定适合召开封闭性会议，否则会议应向所有相关人员开放，并允许他们现场参加或以电子方式参加。GNSO 理事会应将其会议记录传送给 ICANN 秘书长，会后由 ICANN 秘书长尽快将这些记录发布到网站上，最晚不得超过会议后 21 天。
9. GNSO 理事会可与任何其他 ICANN 支持组织理事会就交换观察员事宜达成协议。上述观察员不得为 GNSO 理事会的成员，也不得具有参与 GNSO 理事会表决的资格，但在其他方面应享有与 GNSO 理事会成员同等的参与资格。负责人员选派的理事会应通过向 GNSO 理事会主席和 ICANN 秘书长提供书面通知来指定（罢免或替换）其在 GNSO 理事会的观察员。
1. 应指定一名 ICANN 工作人员来支持 GNSO，由 GNSO 理事会主席指定该名工作人员应处理的实质性事务，其职称应为 GNSO 员工事务经理（以下称“员工事务经理”）。
2. ICANN 应为 GNSO 履行其职责提供必要的管理和运营支持。上述支持不包括 ICANN 报销 GNSO 参与者因参加任何 GNSO 会议或出于其他任何目的而产生的差旅费用的义务。
1. 在本章程中，以下自行组织的选区组织代表特定、重要的利益主体团体，根据本章程移交条款的规定，各选区组织应选出两名代表加入 GNSO 理事会：
a. gTLD 注册机构（代表所有与 ICANN 签有合同的 gTLD 注册机构）；
b. 注册商（代表所有经 ICANN 认定并与其签有合同的注册商）；
2. GNSO 理事会成员可以投出的票数应均衡分布，这样对于与 ICANN 签有合同并有义务执行 ICANN 所批准政策的选区组织（当前为 gTLD 注册机构和注册商），其所选出代表的总票数等于其他选区组织所选出代表的投票数。最初，由 gTLD 注册机构选区组织或注册商选区组织所选出的各位 GNSO 理事会成员应有权投出两票，而所有其他成员（包括那些由提名委员会选出的成员）应均有权投出一票。在那些有权选出 GNSO 理事会表决成员的选区组织发生变化的情况下，董事会应对形势变化做出审查，并通过决议采用与本款第 2 项一致的方式来修订均衡投票数的程序。
3. 只有当本款第 1 项 中确定的各个选区组织都确实代表其意在代表的利益主体社群的全局利益时，该选区组织才能继续保持其公认状态，从而能够继续选择 GNSO 理事会代表；这些选区组织还应在最大的可行范围内进行运作，并遵循既定程序以确保公平。不得仅因加入其他选区组织就剥夺任何个人或实体加入某一选区组织的资格。
4. 任何个人或实体团体均可请求董事会认可其作为新选区组织或单独选区组织的资格。所有此类请求应包括以下内容的详细说明：
任何寻求认可新选区组织的请求都应予以公布来征询公众意见。
5. 董事会可以应此类请求或自行创建新选区组织，前提是确定此项行动有助于实现 ICANN 目标。在考虑自行创建新选区组织的情况下，董事会应公布一份详细的说明，解释需要创建或值得创建新选区组织的原因，同时设定征询公众意见的合理时间，并在审核收到的所有意见之后做出是否创建新选区组织的最终决定。无论何时为征询公众意见而公布新选区组织创建请求或建议，董事会均通知 GNSO 理事会，并应在采取行动之前评价该通知的任何反馈。
最初，GNSO 须遵循的政策制定程序应如本章程附件 A 所述。这些程序可以通过本条第 3 款第 4 项中所述的方式进行补充或修订。
除本条款中的规定以外，董事会可设立一个或多个咨询委员会。咨询委员会的成员可以仅包括董事、董事和非董事或仅包括非董事，也可以包括无表决权成员或候补成员。咨询委员会在法律上无权代表 ICANN，但应向董事会报告其调查结果并提供建议。
至少应设立以下咨询委员会：
a. 政府咨询委员会应就与政府关注问题相关的 ICANN 活动做出考量并提供建议。政府关注的问题尤其体现在以下两方面：ICANN 政策和各种法律及国际协议之间可能存在相互作用；ICANN 政策可能影响公共政策问题。
b. 政府咨询委员会的成员资格应向各个国家/地区政府开放。应政府咨询委员会主席的邀请，政府咨询委员会的成员资格也应向国际论坛所认可的不同经济体、多个国家/地区政府组织和条约组织开放。
c. 政府咨询委员会可以采用自己的章程和内部运作原则或程序来指导其运作，并应在网站上公布。
d. 政府咨询委员会主席应由政府咨询委员会成员遵循其表决通过的既定程序选出。
e. 政府咨询委员会的每位成员应各指定一名授权代表进入委员会。由成员指定的授权代表须在该成员的公共管理层担任高级职员职位。“高级职员”包括以下人员：在由选举产生的政府中担任公职的一名人员；由此类政府、公共权力机构或多个国家/地区政府组织或条约组织所雇用，其在政府、公共机构或组织中的主要职责是制定或影响政府或公共政策的一名人员。
f. 政府咨询委员会每年应为 ICANN 董事会和 ICANN 提名委员会分别指定一名无表决权的联络员，联络员在董事会的连任不受限制。
g. 如果政府咨询委员会认为适当且有益，则可以为每个支持组织理事会和咨询委员会各指定一名无表决权的联络员。
h. 董事会应及时就任何它或 ICANN 的任何支持组织或咨询委员会征询公众意见的公共政策相关提议通知政府咨询委员会主席，并应在采取行动之前适当地将任何针对该通知适时提出的反馈纳入考虑范畴。
i. 政府咨询委员会可以将问题直接呈交给董事会，途径为进行评论或预先提出意见；提出特别行动建议、制定新政策或修订现有政策。
j. 在制定政策和表决通过政策过程中，应适当地将政府咨询委员会就公共政策事项的意见纳入考虑范畴。若 ICANN 董事会决定采取的与政府咨询委员会意见相抵触，则董事会应如实向委员会报告并说明其决定不采纳该意见的理由。政府咨询委员会和 ICANN 董事会随后将及时、有效且诚恳地尝试寻求双方都可接受的解决办法。
k. 若找不到这样的解决办法，ICANN 董事会将在其最终决策中说明未采纳政府咨询委员会意见的理由，该说明将无损于政府咨询委员会成员就其职责范围内公共政策问题的权利或义务。
a. 安全性和稳定性咨询委员会（以下称“SAC”）的职责是就互联网命名和地址分配系统的安全性及完整性相关事宜向 ICANN 社群和董事会提出意见。委员会应行使以下职责：
1. 针对互联网命名和地址分配服务制定安全性计划，以便明确关注的主要领域并确定各个领域的职责所在。该委员会应重点对关键命名基础设施的运作做出考量。
2. 就安全性事宜与互联网技术社群和关键 DNS 基础设施服务的运营商和经管人进行沟通，其中包括根名称服务器运营商社群、顶级域名注册机构和注册商、in-addr.arpa 和 ip6.arpa 等反向解析域名树系统的运营商，以及其他由事件和进展情况所要求的机构。委员会应收集并阐明各种要求，以便将其提供给那些参与 DNS 和地址分配相关协议的技术修订的机构，以及那些参与制定运营计划的机构。
3. 持续对互联网命名和地址分配服务进行威胁评估和风险分析，以便评估稳定性和安全性的主要威胁所在，并相应对 ICANN 社群提出意见。委员会应就任何必要的审核活动提出建议，以便评估与已确定的风险和威胁相比，当前的 DNS 和地址分配安全性的状态。
4. 与那些直接负责互联网命名和地址分配安全性事宜的机构（IETF、RSSAC、RIR、域名注册机构等）进行沟通，以便确保现有的标准化、部署、运营和协调等活动适当采取了其就安全方面的风险、问题和工作重点而提出的建议。委员会应对这些活动加以监督，并将其进展情况通知给 ICANN 社群和董事会（如果适用）。
c. 依据第 VI 条第 9 款，SAC 应每年向 ICANN 董事会指定一名无表决权的联络员。
a. 根服务器系统咨询委员会（以下称“RSSAC”）的职责是就域名系统根名称服务器的运作向董事会提出意见。RSSAC 应就根名称服务器的运行要求做出考量并提供建议，其中包括主机硬件容量、操作系统和名称服务器软件的版本、网络连接与物理环境。RSSAC 应对根名称服务器系统的安全性方面进行检查并提出意见。此外，RSSAC 还应根据整体系统性能、稳健性和可靠性对根名称服务器的数量、位置和分布情况进行审核。
b. RSSAC 的成员应包括 (i) 权威根名称服务器的各个运营商（如 <> 所列）以及 (ii) 由 ICANN 董事会指定的其他人员。>
c. DNS 根服务器系统咨询委员会的首任主席应由董事会指定；续任主席应由 DNS 根服务器系统咨询委员会成员遵循其表决通过的既定程序选出。
d. 根服务器系统咨询委员会每年应为 ICANN 董事会和 ICANN 提名委员会分别指定一名无表决权的联络员，联络员在董事会的连任不受限制。
a. 一般会员咨询委员会（以下称“ALAC”）的职责是就任何与互联网个人用户利益相关的 ICANN 活动做出考量并提供建议。
b. ALAC 应包括 (i) 由各个依据本款第 4(g) 项创建的地区性一般会员组织（以下称“RALO”）选出的两名成员，以及 (ii) 由提名委员会选出的五名成员。由提名委员会选出的五名成员应分别为来自五个依据第 VI 条第 5 款确定的地理区域中的国家/地区公民。
c. 依据本章程移交条款的规定，ALAC 成员的正常任期应如下所述：
1. 由各 RALO 选出的其中一名成员的任期应于偶数年中 ICANN 年会结束时开始。
2. 由各 RALO 选出的另一名成员的任期应于奇数年中 ICANN 年会结束时开始。
3. 由提名委员会选出的三名成员中其中一名的任期应于奇数年中年会结束时开始，而其他两名成员的任期应于偶数年中年会结束时开始。
d. ALAC 主席应由 ALAC 成员遵循委员会表决通过的既定程序选出。
e. ALAC 每年应为 ICANN 董事会指定一名无表决权的联络员（其连任不受限制），并应在与各 RALO 协商之后，为提名委员会指定五名有表决权的代表（依据第 VI 条第 5 款中的规定，其中任何两名代表不得为来自同一地理区域内国家/地区的公民）。
f. 根据本章程移交条款的规定，一般会员咨询委员会可以为各个 ccNSO 理事会和 GNSO 理事会指定无表决权的联络员。
g. 每个依据第 VI 条第 5 款确定的地理区域均应设有一个 RALO。每个 RALO 应充当该地理区域内收集公众对 ICANN 意见的主要论坛和协调点，并应是经 ICANN 依据既定标准而认证的非营利组织，这些标准由董事会根据一般会员咨询委员会建议而设定。一个组织要成为其地理区域内的认可 RALO，应与 ICANN 就 ICANN 和 RALO 各自职责和责任的以下各方面达成谅解备忘录：ALAC 成员的选出流程，RALO 结构与程序的公开性、参与机会、透明度、责任和多样性要求，以及 RALO 有选举权一般会员结构的认证标准。
h. 各 RALO 均应包括其地理区域内自行支持的一般会员结构，这些结构经过认证，依据本款第 4(i) 项的规定符合 RALO 与 ICANN 的谅解备忘录的要求。若与 ICANN 达成的谅解备忘录有相应规定，RALO 还可以包括那些作为该 RALO 地理区域内国家/地区公民或居民的互联网个人用户。
- 各地理区域内一般会员结构的认证标准应由董事会依据 ALAC 建议设定，并应在 ICANN 与各地理区域的 RALO 之间达成的谅解备忘录中予以说明。
- 一般会员结构的认证标准应采用以下方式设定：作为 RALO 地理区域内国家/地区（参见 第 VI 条第 5 款）公民或居民的互联网个人用户的参与将在 RALO 各个一般会员结构的运营中占主导地位，但并不一定排除其他人员的参与，前提是这些人员应与该区域内的互联网个人用户的利益一致。
- 各个 RALO 的谅解备忘录还应包括旨在承认以下内容的规定：作为该 RALO 地理区域内国家/地区公民的每位互联网个人用户最大程度上参与至少一个该 RALO 的一般会员结构。
- 就与这些目标保持一致而言，标准还应向各个 RALO 提供最适于其地理区域习惯和特性的结构类型。
- 按此条款 i 所述设定标准之后，ALAC 应负责将组织认证为符合一般会员结构认证标准，而申请结构所在的 RALO 负责提供建议并参与其中。
- 认证或撤销认证一般会员结构的决定应由 ALAC 根据其程序规则做出，但任何就 ALS 申请对程序规则做出的更改均应由 RALO 和 ICANN 董事会进行审核。
- 关于对一般会员结构进行授权、不授权或撤销授权的决策应依据由董事会确定的既定程序进行审核。
- ALAC 还可以不断针对潜在的一般会员结构是否满足适用标准提出建议。
j. ALAC 还负责与 RALO 进行协作，协调以下活动：
2. （通过帖子或其他方式）分发 ICANN 的最新日程、新闻，以及 ICANN 政策制定流程事项的相关信息；
4. 制定并维护关于 ICANN 及其工作的目前信息和教育项目；
5. 在各个 RALO 区域中制定有关 ICANN 事宜的外延活动策略；
6. 公布并分析 ICANN 的政策提议及其决策，以及这些政策和决策对区域和区域内的个人造成的影响/潜在影响；
7. 提供基于互联网的机制，确保一般会员结构中的成员之间能够开展讨论；
8. 制定机制和流程，确保一般会员结构成员和参与 ICANN 政策制定的人员之间能够进行双向沟通，使感兴趣的个人能够分享其关于未决 ICANN 问题的看法。
各个咨询委员会应确定自己的程序规则和法定人数要求。
委员会主席和各位成员的任期至其继任者被任命为止，或者至委员会提前终止，或被罢免、主动辞职或因其他原因不再具备委员会成员资格为止。
任何委员会的空缺职位应依原先的任命方式填补。
委员会成员在任职期间没有任何报酬。但董事会可以批准补偿委员会成员，包括董事在内，因执行其委员会成员职务而支出的实际且必要的费用。
1. 目标。外部专家意见的寻求目标在于使 ICANN 的政策制定流程能够利用 ICANN 以外公共或私营部门中现有的专业知识。如果相关的公共机构可以提供专业知识，或使用私有的专业知识有所助益，那么董事会及其任命机构应积极向这些专业机构或个人寻求建议。
a. 董事会可以自行或根据任何 ICANN 结构的建议指定（或授权总裁指定）由公共或私营部门、个人或实体组成的专家咨询小组。如果从此类小组征求到的意见与公共政策问题相关，则应运用本条第 1 款第 3(b) 项 中的规定。
b. 此外，依据本条第 1 款第 3 项，董事会可以就 ICANN 使命事宜相关的公共政策问题咨询多个国家/地区政府组织或条约组织。
a. 政府咨询委员会可以随时建议董事会就公共政策的一个或多个事宜向外部资源寻求意见，参见上文。
b. 如果董事会依据此类建议或通过其他方式确定应就公共政策的一个或多个事宜寻求外部意见，则董事会应在适当的情况下就从中吸取意见和决定的合适资源与政府咨询委员会进行协商（包括范围定义和流程），以便寻求和获取该意见。
c. 董事会应在适当的情况下将任何向多个国家/地区政府组织或条约组织寻求意见的请求（包括特定委任范围）发送给政府咨询委员会，并建议政府咨询委员会应将该请求发送给多个国家/地区政府组织或条约组织。
4. 寻求其他事项相关意见的流程。任何由董事会或总裁依据本条第 1 款第 2(a) 项 向专家咨询小组就与公共政策无关的事项做出的意见咨询，应依据委任范围（描述寻求意见的事项）进行，并应遵循既定程序和计划。
5. 外部意见的接收及其作用。依据本款所述而收到的外部意见应采用书面形式提供。此类意见为建议性意见而非必须遵守，旨在为董事会或其他 ICANN 结构在履行其职责方面提供更多的可用信息。
6. 评论机会。除支持组织和其他咨询委员会以外，政府咨询委员会也应有机会在董事会做出任何决策之前对收到的任何外部意见进行评论。
1. 目标。ICANN 工作质量的优劣取决于是否能获取与那些作为 ICANN 活动基础的技术标准相关的完整权威性信息。ICANN 与制定这些标准的组织之间的关系因此尤为重要。技术联络小组 (TLG) 就 ICANN 活动相关具体事项联络着董事会与能够提供此类技术意见的适当资源。
2. TLG 组织。TLG 应由以下四种组织构成：欧洲电信标准协会 (ETSI)、国际电信联盟远程通信标准化组 (ITU-T)、万维网联盟 (W3C) 和互联网架构理事会 (IAB)。
3. 职责。TLG 组织的职责是向董事会和其他 ICANN 实体传达技术信息和指导。该职责由响应请求和积极监视相关情况两部分组成，具体责任如下：
a. 响应获取信息的请求，使董事会或其他 ICANN 机构与提供技术性专业知识的适当来源进行联络。这一 TLG 职责组成部分考虑到了 ICANN 就特定技术问题寻求权威性解答的情况。如果就某个在 TLG 组织责任范围内的特定技术标准请求相关信息，则此请求应提交给该 TLG 组织。
b. 持续监视相关情况，就技术开发（可能影响董事会决策或其他 ICANN 行动，且发生在每个组织的各个领域中）的相关性和进展向董事会提出建议，并使其注意那些对遵循 ICANN 使命制定政策产生影响的全球技术标准问题。这一 TLG 职责组成部分考虑到了 ICANN 未意识到新的发展并因此未认识到应询问问题的情况。
4. TLG 程序。TLG 不得设有高级职员或举行会议，也不得作为委员会向董事会提供政策建议（尽管董事会在 TLG 组织独立章程相关领域内有需要时，可能会特别要求 TLG 组织向其提供政策建议）。TLG 不得在各 TLG 组织间讨论或以其他方式协调技术问题；不得设立或尝试设立统一的职位；不得出于制定技术标准或任何其他目的在 TLG 内部创建或尝试创建更多层次或结构。
5. IANA 的技术工作。如 2000 年 3 月 10 日由董事会批准的有关互联网编号分配机构技术工作的谅解备忘录中的规定，TLG 不得参与互联网工程任务组、互联网研究任务组或互联网架构理事会的 IANA 工作。
6. 个人技术专家。各个 TLG 组织应分别指定两名熟悉 ICANN 活动相关技术标准事宜的个人技术专家。在 ICANN 未直接向特定 TLG 组织询问的情况下，这 8 位专家应在必要时通过电子邮件信息交流，确定 ICANN 的技术问题应提交至何处。
7. 董事会联络员和提名委员会代表。依据第 VI 条第 9 款第 1(d) 项，各个 TLG 组织每年应轮流向董事会指定一名无表决权的联络员。依据第 VII 条第 2 款第 8(j) 项，各个 TLG 组织每年应轮流选出一名有表决权的代表进入 ICANN 提名委员会。向董事会指定无表决权的联络员的轮流次序应为 ETSI、ITU-T 和 W3C。为提名委员会选出代表的轮流次序应为 W3C、ETSI 及 ITU-T。（IAB 不参与这种轮流过程，理由是 IETF 会另外向董事会指定一名无表决权的联络员并选出一名代表进入 ICANN 提名委员会。）
董事会可以下设一个或多个委员会，这些委员会将一直存在，直到董事会决定撤消为止。只有董事才能被任命为董事会委员会的委员。如果已任命到董事会委员会的人员不再担任董事职务，则其董事会委员会的成员身份也应随即解除。每个董事会委员会应由两名或两名以上的董事构成。董事会可以指定一名或多名董事作为任何此类委员会的候补成员，这些候补成员可以代替任何缺席成员出席该委员会的任何会议。在董事会全体成员投票表决以三分之二 (2/3) 的多数通过情况下即可随时免去委员会成员的成员资格；然而，如果任何一名或多名董事是免职行动的对象，则其没有资格在此类行动中进行投票，或者在计算所需的三分之二 (2/3) 投票时，不应将其视为董事会成员；此外，在任何情况下都不得罢免某位董事的委员会成员资格，除非在全体董事会成员当中不少于过半数的成员赞成此项罢免。
1. 除了有关以下方面外，董事会可以将其所有合法权力授予董事会委员会：
c. 修正或废除董事会明示条款中规定不可修正或废除的任何决议；
e. 批准任何自我交易以及 CNPBCL 的第 5233(a) 款中规定的交易；
f. 批准第 XVI 条中规定的年度预算；或者
g. 补偿第 XIII 条中所述的任何高级职员。
2. 董事会应有权规定任何董事会委员会活动的执行方式。如果没有任何此类规定，则董事会委员会有权规定各自活动的执行方式。除非本章程、董事会或此类委员会另有规定，否则定期会议和特殊会议应按照第 VI 条 中适用于董事会会议和行动的规定进行管理。每个委员会应保留定期活动记录，并随时应董事会要求向其进行如实报告。
董事会可以在适当时设立临时委员会，并且在设立此类委员会时应在其所采用的决议或章程中规定成员资格、职责和责任。
ICANN 的高级职员应包括一名总裁（担任首席执行官）、一名秘书长和一名首席财务官。ICANN 还可以按照董事会的决定设立其认为合适的任何其他高级职员职位。除了董事会成员（不包括总裁）不得同时兼任 ICANN 高级职员之外，总裁以外的其他任何人均可担任多项职务。
ICANN 的高级职员应由董事会按照总裁的建议每年选举一次，如果是选举总裁，则按照 ICANN 董事会主席的建议进行。每位此类高级职员的任职期限应直到其辞职、被免职、不再胜任该职务或已选举出接任者为止。
如果董事会全体成员投票表决并以三分之二 (2/3) 的多数通过，就可以无条件地免去任何一个高级职员的职务。如果因死亡、辞职、免职、不能胜任工作或任何其他原因而使任何办公职位出现空缺，则在选举出职位接任者之前，董事会可以将此类职务的权力和职责授权给任何高级职员或任何董事。
总裁应担任 ICANN 的首席执行官 (CEO)，负责 ICANN 的所有活动和业务。除非本章程中另行规定，否则所有其他高级职员和员工都应向总裁或其代表进行报告。总裁应依照职权担任董事会成员，并且与任何董事会成员享有所有相同的权利和特权。总裁应有权召开此处规定的董事会特殊会议，同时履行本章程中规定的所有其他职责以及董事会有时指派的任务。
秘书长应亲自负责或让他人使用记录专用的工作簿来记录董事会会议内容，检查所有通知是否均已按照本章程的规定或法律规定适时发出，并且通常应执行总裁或董事会有时指示的所有任务。
首席财务官 (CFO) 是指 ICANN 的主要财务负责人。应董事会要求，CFO 应按照董事会确定的形式并在其指定的一名或多名担保人的担保下，承诺忠实履行自己的职责。CFO 应掌管和保管 ICANN 的所有资金，亲自或让他人在 ICANN 专用的帐簿上完整无误地记录所有收据和支出数目，并且以 ICANN 的名义将所有资金和其他贵重物品都存放到董事会所指定的专用存放处。CFO 应遵照董事会或总裁的指示支付 ICANN 的资金，并且随时应董事会和总裁的要求，向他们说明自己作为首席财务官所负责的一切事务以及 ICANN 的财务状况。CFO 应负责 ICANN 的财务计划和预测，并协助总裁准备 ICANN 的年度预算。CFO 应负责协调和监督 ICANN 的资金，包括对 ICANN 或其支持组织的任何审计或其他评审。CFO 应负责所有与 ICANN 财务运营相关的其他事务。
除了上述高级职员外，由董事会选举或任命的任何其他或辅助高级职员应执行总裁或董事会指派给他们的任务。
任何 ICANN 高级职员的报酬应由董事会批准。对于高级职员因履行其办公职责而产生的相关费用，可以获得补偿，但前提是要获得总裁的批准（在高级职员不是总裁的情况下），或通过董事会指定的其他高级职员的批准（高级职员是总裁的情况下），或者通过董事会批准。
董事会应通过专门指定的委员会制定一项政策，即要求各高级职员至少每年向其作出一次陈述，阐明以任何方式与 ICANN 的业务和其他从属业务存在关联的所有业务和其他从属业务。
ICANN 应在 CNPBCL 允许的范围内，最大限度地补偿每个代理人的费用、由判决确定的债务、罚款、结算债务以及其他因作为或曾经作为 ICANN 代理人所采取的任何行为而发生的实际并且合理的支出。补偿前提有两个：第一，补偿对象的行为是诚实的；第二，补偿对象有理由认为自己的行为方式是出于 ICANN 的最大利益并且是合法的。在本条款中，ICANN 的“代理人”包括：目前或曾经担任董事、高级职员、员工的任何人员或在其职责范围内行事的任何其他 ICANN 代理人（包括任何支持组织、任何咨询委员会、提名委员会、任何其他 ICANN 委员会或技术联络组中的成员），或者是目前或曾经应 ICANN 的请求担任董事、高级职员、员工的任何人员或其他公司、合伙企业、合资企业、信赖企业或其他企业的代理人。董事会可以采纳一项决议，授权为 ICANN 的所有代理人购买保险，以使其免受因担任代理人职务或因代理人身份本身而宣称或发生的任何债务的损失，无论根据本条款的规定 ICANN 是否有权补偿代理人的债务损失。
董事会可以授权任何高级职员和代理以 ICANN 的名义或代表 ICANN 签订任何合同或者签署或移交任何文书，而此类授权可以是一般性授权，也可以局限于具体实例。在不违反董事会授权的情况下，合同和文书只能由以下高级职员进行签署：总裁、任何副总裁或 CFO。除非获得董事会的授权或批准，否则任何其他高级职员、代理或员工均无权对 ICANN 进行约束或使其承担任何债务或义务的责任。
ICANN 尚未使用的所有资金应不时地存入 ICANN 在银行、信托公司或其他受托人处开立的户头上，这些受托人由董事会选择或由总裁受董事会委派选择。
所有支票、汇票、需要付款的定单、票据或其他以 ICANN 名义发出的债务证据均应由 ICANN 的高级职员和代理进行签字，并且有时应通过董事会的决议来确定。
未经董事会决议授权，ICANN 不得贷款或发放贷款，并且不得以 ICANN 的名义签发任何债务证据。此类授权可以是一般性授权，也可以局限于具体实例；但前提是 ICANN 不得向其董事或高级职员办理贷款。
ICANN 的财政年度结束应由董事会决定。
在财政年度结束时，应终结 ICANN 的帐簿并由注册会计师进行审计。董事会应负责指定财政审计员。
董事会应至少每年向董事发布一份说明其活动的报告，该报告包括经过审计的财务报表和 ICANN 支付的所有款项（包括费用报销）的说明。ICANN 应负责准备年度报告和 CNPBCL 要求提供的某些交易的年度报表，并将其发送给董事会的每位成员和董事会可以指定的其他人员，时间最晚不迟于 ICANN 财政年结束后的 120 天。
至少在每个财政年开始前的 45 天内，总裁应准备 ICANN 下一个财政年的年度预算方案，并将其提交给董事会，该年度预算将在网站上进行发布。提出的预算方案应确定预期收入来源和水平，并且在可行的范围内，逐项确定预期的具体费用项目。董事会应采用一份年度预算并将其发布到网站上。
董事会可以对 ICANN 提供的服务和援助确定收费标准，以便能够完全补偿 ICANN 的合理运营成本，并设立合理的储备金以用来支付未来开支和与 ICANN 合法活动相关的正当或有费用。此类费用和收费应本着公平公正的原则，并且在采用前应进行公布以征求公众意见，而在采用后应十分详细地发布在网站上以便于进行访问。
尽管在本章程、任何 ICANN 文件或 ICANN 董事会或员工的任何活动中都使用“成员”一词，但根据加利福尼亚非营利公共利益公司法 (CNPBCL) 中的规定，ICANN 应没有成员。
ICANN 进行事务处理的总部应设在美国加利福尼亚州洛杉矶郡内。ICANN 还可随时在美国境内或境外设立其他办事处。
董事会可以采用公司印章，用印章或其复制件盖章或另行复制。
除非公司条款或本章程中另有规定，否则可以改动、修订或废除 ICANN 的公司条款或章程，并且仅由董事会全体成员三分之二 (2/3) 投票通过即可采用新的公司条款或章程。
本移交条款阐明了从 ICANN 章程中定义的流程和结构（“旧章程”）过渡到本条款所属章程中定义的流程和结构（“新章程”）的规定，前者于 1999 年 10 月 29 进行修订和重申，并于 2002 年 2 月 12 日再次修订。
1. 对于从采用本移交条款开始到新董事会的生效日期和时间结束这段期间（如第 2 款第 5 段中所定义），公司的董事会（“移交董事会”）应包括在实施旧章程期间于 2002 年的年会结束后立即开始任职董事的董事会成员，除此之外，在实施旧章程期间选举为董事（途径如下：于 2002 年 12 月 15 日以书面形式或通过电子邮件方式通知给董事会秘书长，最晚不迟于 2002 年 12 月 23 日）的董事会一般会员成员也将担任移交董事会的成员。尽管新章程第 VI 条第 12 款有规定，但移交董事会中的职位空缺无需填补。依据新章程第 VI 条第 9 款规定，移交董事会不设联络员。在采用本移交条款之日就已存在董事会委员会应继续保留，并且遵循移交董事会通过决议可能对董事会委员会或其成员资格采取的任何更改。
2. 移交董事会应选出一名主席和一名副主席，一直任期到新董事会的生效日期和时间为止。
3. “新董事会”即新章程第 VI 条第 2 款第 1 项中所述的董事会。
4. 在采用本移交条款之后，应立即成立提名委员会，在可行范围内该委员会包括新章程第 VII 条第 2 款中所述的代表和联络员，任期到 2003 年 ICANN 年会结束后为止。提名委员会应立即选举董事以填充新董事会 1 到 8 的席位，这些董事的任期直到针对新章程第 VI 条第 8款第 1(a)-(c) 项中那些席位指定的第一个正常任期开始时为止，并且应将本次选举情况以书面通知的形式呈送给 ICANN 秘书长。
5. 新董事会的生效日期和时间应是由移交董事会在 2003 年 ICANN 第一次常规会议期间指定的时间，并且应在 ICANN 秘书长收到书面通知要选举董事来填充新董事会 1 至 14 席位中的至少十位之后不少于七个日历天开始。自生效日期和时间起，新董事会将从移交董事会那里接管 ICANN 董事会的所有权利、职责和义务。根据本条第 4 款，ICANN 秘书长已收到其选举通知的董事（第 VI 条第 2 款第 1(a)-(d) 项）和无表决权的联络员（第 VI 条第 9 款），以及总裁（第 VI 条第 2款第 1(e) 项）应在新董事会的生效日期和时间起就职，而其后的其他任何董事和无表决权的联络员应在 ICANN 秘书长收到其选举通知后就职。
6. 新董事会的首要任务是选出一名主席和副主席。这些董事会职务的任期将于 2003 年的年会结束时终止。
7. 根据现行章程，自新董事会的生效日期和时间起就已存在的董事会委员会应继续保留，但这些委员会的所有成员将从新董事会的生效日期和时间起结束任期。自新董事会的生效日期和时间起就已存在的临时委员会应与其现行章程和成员资格一同继续保留，并且遵循新董事会通过决议可能采取的任何更改。
8. 根据 第 VI 条第 8 款第 5 项的任期限制规定，在新董事会的生效日期和时间之前，董事在董事会任职这段期间应视为一个任期。
地址支持组织应根据 ICANN 与一组地区性互联网注册机构 (RIR) 之间最初在 1999 年 10 月 18 日签署 并在 2000 年 10 月进行修订的谅解备忘录继续运营，直到替换谅解备忘录生效时为止。在采用本移交条款之后，地址支持组织应立即进行选举，并将以下选举情况以书面通知形式呈送给 ICANN 秘书长：
1. 用来填补新董事会席位 9 和 10 的董事，任期到为新章程第 VI 条第 8 款第 1(d) 和 (e) 项中各个席位指定的第一个正常任期开始时为止；以及
2. 由地址支持组织的理事会选出的提名委员会代表（如新章程第 VII 条第 2 款第 8)(f) 项中规定）。
对于有选举权的 ICANN 董事，考虑到需要快速选举以确保新董事会尽快发挥作用，地址支持组织可以从先前依据旧章程选举为 ICANN 董事的人员中选出这些董事。如果在 2003 年 3 月 31 日或之前地址支持组织未向 ICANN 秘书长提交有关对席位 9 和 10 选举的书面通知，则认为地址支持组织已将依据旧章程选出的 ICANN 董事分别作为席位 9 和席位 10 的人选，前者的任期从 2001 年开始，后者的任期从 2002 年开始。
1. 在三十位 ccTLD 经理（每个地理区域至少四位）作为 ccNSO 成员入职后，应在网站上发布书面通知。一旦该通知发布之后，ccNSO 成员应根据第 IX 条第 4 款第 8 和 9 项尽快选出最初 ccNSO 理事会的成员。该选举过程完成之后，应在网站上发布一个说明 ccNSO 理事会已组成的书面通知。ccNSO 成员应在每个地理区域选出三名 ccNSO 理事会成员，其中一名成员的任期到 ccNSO 理事会成立后的第一次 ICANN 年会结束时为止，第二名成员的任期到 ccNSO 理事会成立后的第二次 ICANN 年会结束时为止，而第三名成员的任期到 ccNSO 理事会成立后的第三次 ICANN 年会结束时为止。（第 IX 条第 4 款第 1 项 中所述的“ccTLD 经理”定义和第 IX 条第 4 款第 4 项 中所述的定义均应适应于第 XX 条第 4 款。）
2. 在采用本章程第 IX 条之后，提名委员会应选出第 IX 条第 3 款第 1(b) 项中所述的三名 ccNSO 理事会成员。选出三名个人在 ccNSO 理事会任职时，提名委员会应指定其中一名成员的任期到 ccNSO 理事会成立后的第一次 ICANN 年会结束时为止，第二名成员的任期到 ccNSO 理事会成立后的第二次 ICANN 年会结束时为止，而第三名成员的任期到 ccNSO 理事会成立后的第三次 ICANN 年会结束时为止。这三名由提名委员会选出的 ccNSO 理事会成员应在 ccNSO 理事会成立后任职。
3. 在 ccNSO 理事会成立后，一般会员咨询委员会和政府咨询委员会可以向 ccNSO 理事会各指派一名联络员（如 第 IX 条第 3 款第 2(a) 和 (b) 项中所规定）。
4. 在 ccNSO 理事会成立后，该理事会可以指定区域组织（如第 IX 条第 5 款中所规定）。在指定区域组织后，该组织可以向 ccNSO 理事会指派一名联络员。
5. 在 ccNSO 理事会成立之前，新董事会的席位 11 和 12 应保持空缺。在 ccNSO 理事会成立后，ccNSO 应立即通过 ccNSO 理事会选出予以填充新董事会席位 11 和 12 的董事，任期到为新章程第 VI 条第 8 款第 1(d) 和 (f) 项中各席位指定的下一个正常任期开始时为止，并且应将本次选举情况以书面通知的形式呈送给 ICANN 秘书长。
6. 在 ccNSO 理事会成立之前，依据新章程设立的提名委员会代表指定由 ccNSO 选举产生，并且应通过移交董事会或新董事会（视需要进行任何特定任命时存在的组织而定）与 ccTLD 社群的成员进行直接磋商后进行任命。在 ccNSO 理事会成立后，由移交董事会或新董事会根据当时生效的本条第 4 款第 9 项指定的提名委员会代表应继续任职，但是当 ccNSO 理事会以在 ICANN 年会结束后三个月内选出的新代表来替换该代表或职位出现空缺的情况下除外。提名委员会代表（如第 VII 条第 2 款第 8(c) 项所述）的后续任命应由 ccNSO 理事会执行。
1. 在采用本移交条款后，域名支持组织 应终止运营，但是对于域名支持组织的名称理事会 授权转移为通用名称支持组织的利益而收集的所有资金的情况除外。
2. 在采用本移交条款后，通用名称支持组织 (GNSO) 应开始着手运营，而且最初根据现行章程，以下六个 DNSO 选区组织将自动成为 GNSO 的选区组织：
a. DNSO 的商业实体选区组织 将成为 GNSO 的商业用户选区组织。
b. DNSO 的 gTLD 注册机构选区组织 将成为GNSO 的 gTLD 注册机构选区组织。
c. DNSO 的 ISP 和连接提供商选区组织 将成为GNSO 的互联网服务和连接提供商选区组织。
d. DNSO 的非商业域名持有人选区组织 将成为 GNSO 的非商业用户选区组织。
e. DNSO 的注册商选区组织 将成为GNSO 的注册商选区组织。
3. 尽管采用了新章程或已使新章程生效，但本条第 5 款第 2 段 中所述的每个 GNSO 选区组织都应继续一如既往地运营，并且在选区组织开展进一步行动之前不得更改任何选区职员、任务组或其他活动，但每个 GNSO 选区组织都应向 ICANN 秘书长提交一份根据选区组织流程和新章程采用的新运营程序章程和声明，最晚不迟于 2003 年 7 月 15 日。
4. 在 2003 年 ICANN 年会结束之前，GNSO 理事会应由每个 GNSO 选区组织选出的三名代表和提名委员会完成选举后选出的三名人员组成。还可能包括由政府咨询委员会和（临时）一般会员咨询委员会指派的联络员（如新章程第 X 条第 3 款第 1 项中所规定）。此后，GNSO 理事会的组成结构应符合新章程中的规定，因为新章程可能随时进行修订，而不遵守本移交条款。对于由 DNSO 名称理事会设立并在采用本移交条款之前就已存在的所有委员会、任务组、工作组、起草委员会和类似团体，应继续作为具有相同章程、成员资格和活动的 GNSO 理事会团体存在，并且遵循因 GNSO 理事会行动而引起的任何更改。
5. 在采用本移交条款后，六个 DNSO 选区组织各自在域名支持组织 (DNSO) 名称理事会的三名代表应担任 GNSO 理事会的选区组织代表，如下所述：
a. DNSO 商业实体选区组织的三名代表将担任 GNSO 商业用户选区组织的代表。
b. DNSO 的 gTLD 注册机构选区组织的三名代表将担任 GNSO 的 gTLD 注册机构选区组织的代表。
c. DNSO 的 ISP 和连接提供商选区组织的三名代表将担任 GNSO 的互联网服务和连接提供商选区组织的代表。
d. DNSO 非商业域名持有人选区组织的三名代表将担任 GNSO 非商业用户选区组织的代表。
6. GNSO 理事会成员的任期（如本条第 5 款第 5 段 中所述）应持续到旧章程中所规定的任期结束时为止，但对于所有那些 GNSO 理事会成员任期将在 2003 年 ICANN 年会结束时终止的情况除外。在此之前 GNSO 理事会中出现的任何职位空缺（如本条第 5 款第 5 段中所述）应由该职位所代表的选区组织填补，剩余任期可持续到 2003 年 ICANN 年会结束时为止。在选出三名人员于 GNSO 理事会任职时，初期提名委员会应指定一名人员的任期到 2004 年 ICANN 年会结束时终止，而指定另外两名人员的任期到 2005 年 ICANN 年会结束时终止。
7. 在采用本移交条款之后，通用名称支持组织应立即通过 GNSO 理事会选出予以填充新董事会席位 13 和 14 的董事，任期到为新章程第 VI 条第 8 款第 1(d) 和 (e) 项中各席位指定的第一个正常任期开始时为止，并且应将本次选举情况以书面通知的形式呈送给 ICANN 秘书长。
8. 如果新董事会没有针对主题开展进一步行动，则每个 GNSO 选区组织均应选出两名代表在 GNSO 理事会任职，最晚不迟于 2003 年 10 月 1 日，并且应将本次选决情况以书面通知的形式呈送给 ICANN 秘书长。每个选区组织应指定其中一名代表的任期为一年，另一名代表的任期为两年。这些代表的每位接任者的任期都将为两年。
9. 在采用本移交条款之后，并在 ICANN 董事会采取进一步行动之前，GNSO 理事会应负责处理网域名称支援组织 (DNSO) 大会电子邮件通知和讨论列表。
10. 在采用本移交条款之后， 本条第 5 款第 5 段 中确定的每个选区组织（指定根据新章程第 VII 条第 2 款 来选出提名委员会代表）应立即将选出担任代表的人选报告给 ICANN 秘书长。
对于旧章程中引用的协议支持组织， 将不再使用。
1. 在采用新章程之后，政府咨询委员会应根据其现有的经营原则和实践继续运营，直到采取进一步行动为止。政府咨询委员会可以通过向 ICANN 秘书长提供书面通知，根据新章程指定联络员以在其他 ICANN 机构中任职。在采用本移交条款之后，政府咨询委员会应立即将选出担任提名委员会代表的人选报告给 ICANN 秘书长（如新章程第 VII 条第 2 款中所规定）。
2. 根据新章程第 XI-A 条第 2 款第 2 项 指定为技术联络组成员的组织应各自指定两名技术专家（如新章程第 XI-A 条第 2 款第 6 项中所述），但需要向 ICANN 秘书长提交书面通知。在可行的范围内，由技术联络组指派到提名委员会的代表应根据新章程第 XI-A 条第 2 款第 7 项尽快选出。
3. 在采用新章程之后，安全性和稳定性咨询委员会 应根据其现有的经营原则和实践继续运营，直到采取进一步行动为止。在采用本移交条款之后，安全性和稳定性咨询委员会应立即将选出担任提名委员会代表的人选报告给 ICANN 秘书长（如新章程第 VII 条第 2 款第 4 项中所规定）。
4. 在采用新章程之后，根服务器系统咨询委员会 应根据其现有的经营原则和实践继续运营，直到采取进一步行动为止。在采用本移交条款之后，根服务器系统咨询委员应立即将选出担任提名委员会代表的人选报告给 ICANN 秘书长（如新章程第 VII 条第 2 款第 3 项中所规定）。
a. 在 ICANN 通过谅解备忘录条目认可新章程第 XI 条第 2 款第 4 项中确定的所有区域性一般会员组织 (RALO) 之前，应存在临时一般会员咨询委员会。临时一般会员咨询委员会应包括 (i) 十名成员（每个 ICANN 地区各两名，由 ICANN 董事会根据一般会员组织委员会的提名选出）和 (ii) 五名额外成员（每个 ICANN 地区各一名，由初期提名委员会根据 新章程第 VII 条第 5 款中确立的原则尽快选出）。初期提名委员会应指定其中两名成员的任期到 2004 年 ICANN 年会结束时终止，其中三名成员的任期到 2005 年 ICANN 年会结束时终止。
b. 在将每个 RALO 条目写入此类谅解备忘录后，该实体将有资格从该地区的居民中选出两名作为一般会员咨询委员会的成员（如新章程第 XI 条第 2 款第 4 项中所规定）。在该实体将此类选举情况以书面通知的形式提交给 ICANN 秘书长后，这些人员应立即担任先前由董事会从 RALO 地区选出的临时一般会员咨询委员会成员的职位。
c. 在所有五个 RALO 选出当选人员后，临时一般会员咨询委员会将成为一般会员咨询委员会（如新章程第 XI 条第 2 款第 4 项中所规定）。由提名委员会选出在临时一般会员咨询委员会任职的五名人员将成为一般会员咨询委员会的成员，并在各自选出后相应的剩余任期内任职。
d. 在临时一般会员咨询委员会成立后，应立即将选出担任提名委员会代表的人选报告给 ICANN 秘书长（如新章程第 VII 条第 2 款第 6 项中所规定）。
ICANN 高级职员（如新章程第 XIII 条中所定义）应由当时的 ICANN 董事会在 2002 年的年会上选出，任期到 2003 年的年会为止。
尽管采用了新章程或已使新章程生效，但由 ICANN 总裁指定的任务组和其他团体在总裁做出更改之前仍会继续保持成员资格、范围和运营不变。
尽管采用了新章程或已使新章程生效，但由 ICANN 达成的所有协议（包括雇佣协议和咨询协议）将按照各自的条款继续生效。
在向 ICANN 董事会建议修改或得到董事会批准之前，以下流程应对 GNSO 政策制定流程 (PDP) 起到约束作用。
可以通过以下任何方式，提出问题作为 PDP 的一部分进行考虑：
a.董事会启动。 董事会可以通过指示 GNSO 理事会着手开始本附件中概括的流程来启动 PDP。
b.理事会启动。 在提议启动 PDP 的任何会议上，如果出席会议的理事会成员当中至少有百分之二十五 (25%) 投赞成票，GNSO 理事会即可启动 PDP。
c.咨询委员会启动。 咨询委员会可以提出有关政策制定的问题，方法是通过此类委员会的行动着手开始 PDP，并将请求发送至 GNSO 理事会。
在收到 (i) 董事会指示；(ii) 理事会成员完全支持的提议；或 (iii) 咨询委员会完全支持的提议后的十五 (15) 个日历天内，员工事务经理将制订一份报告（“问题报告”）。每份问题报告应至少包含以下内容：
e. 员工事务经理关于理事会是否应就此问题启动 PDP 的建议（“员工建议”）。关于就提议的问题启动 PDP 是否完全属于 ICANN 政策流程范围和 GNSO 范围，每位员工建议均应包括 ICANN 法律总顾问的意见。在确定该问题是否完全属于 ICANN 政策流程范围过程中，法律总顾问应检查此类问题是否：
f. 在十五 (15) 天的截止日期之日或之前，员工事务经理应将问题报告分发给整个理事会以投票决定是否要启动 PDP（如下面所讨论）。
理事会应按以下流程启动 PDP：
a.董事会提出的问题。 如果董事会指示理事会启动 PDP，则理事会应在收到问题报告后十五 (15) 个日历天内召开会议，并且无需进行理事会中间投票即可启动 PDP。
b.由董事会以外的其他机构提出的问题。 如果通过问题报告将有关政策的问题提交给理事会进行考虑，则理事会应在收到此类报告后十五 (15) 个日历天内召开会议，以投票决定是否要启动 PDP。此类会议可以按照理事会认为合适的任何方式进行召开，包括现场会议、电话会议或通过电子邮件。
c.理事会的投票。 在理事会中，如果有 33% 以上的成员投票赞成启动 PDP，即满足启动 PDP 的条件；除非员工建议指出该问题不完全属于 ICANN 政策流程的范围或 GNSO 的范围，在这种情况下，只有极大多数理事会成员投票赞成启动 PDP 时才可以启动 PDP。
在理事会启动 PDP 的会议上，理事会应根据会议出席成员的多数投票决定是否任命一个任务组来解决问题。如果理事会的表决：
a. 赞成召集任务组，则理事会应依据下文第 7 项的规定成立任务组。
b. 反对召集任务组，则理事会应依据下文第 8 项的规定收集有关政策问题的信息。
a. 通过投票方式确定任命任务组之后，理事会应邀请 GNSO 的各个选区组织分别指定一名人员加入任务组。另外，理事会还可最多指定三名外部顾问在任务组中任职。（每个任务组成员在本附件中称为“代表”，全体任务组成员称为“代表们”）。理事会可自行判断在其视为必要或适当的情况下，增加每个选区组织指派到任务组的代表数。
b. 为加入任务组，任何要向任务组指派代表的选区组织须在收到上述邀请后十 (10) 个日历天内向员工事务经理提交选区组织指定人员的姓名。此类指定人员无需是理事会成员，但必须对要制定政策的领域感兴趣、具有理论知识和专业技能，并有足够的时间参加任务组活动。
c. 理事会还可以采用其他自己认为适合辅助 PDP 的意见征集途径，包括任命特定的人员或组织收集有关问题的信息，或者计划召开商讨会议或汇报会议。所有此类信息应在 PDP 启动后三十五 (35) 个日历天内提交给员工事务经理。
启动 PDP 后，ICANN 应在网站上公布此类行为的通知。应为该问题设定公众意见征询期，即启动 PDP 后二十 (20) 个日历天内。员工事务经理或其他某位由 ICANN 指定的代表应对公众意见进行评审，并将其汇总为一份报告（以下称“公众意见报告”），并视情况将该报告收录到任务组预备报告或初始报告中。
a.任务组的职责。 如果设立任务组，其职责通常包括：(i) 收集详细说明 GNSO 内正式选区组织和临时选区组织（如果有）立场的信息；(ii) 获取其他尽可能完善和补充任务组报告的相关信息。
任务组没有任何正式的决策权。更确切地说，任务组的职责应为收集那些尽可能具体详细地说明各方或各团体立场的信息，从而使理事会对问题的审议更加富有意义且具有更广泛的消息。
b.任务组的章程或委任范围。 理事会应在员工事务经理的协助下，于 PDP 启动后十 (10) 个日历天内制定出任务组的章程或委任范围（以下称“章程”）。上述章程包括以下内容：
1. 需要任务组解决的问题，理事会启动 PDP 前须通过此类问题的投票；
任务组应制定其报告并依据章程指导其活动。任何违背章程的请求须正式提交给理事会，经过理事会出席成员多数投票通过后任务组方可执行该请求。
c.任务组主席的任命。 员工事务经理应在收到章程后的五 (5) 个日历天内召开任务组的第一次会议。在初次会议上，任务组成员的首要任务是以投票方式任命一位任务组主席。主席应负责组织任务组的活动，包括编制任务组报告。任务组主席无需是理事会的成员。
1. 选区组织报告书。 代表们将分别负责征求其所在选区组织的立场（最低要求）以及每位代表视为适当的与所考虑问题有关的其他意见。上述立场及其他意见（如适用）应以正式报告书（以下称“选区组织报告书”，每位代表分别一份）的形式在 PDP 启动后三十五 (35) 个日历天内提交给任务组。每份选区组织报告书应至少包括以下内容：
(i) 如果获得极大多数投票，则明确陈述选区组织就问题的立场；
(ii) 如果未获得极大多数投票，则明确陈述选区组织成员拥护的所有立场；
(iii) 明确陈述选区组织如何达成其立场。具体而言，该声明应详细说明特定的选区组织会议、电话会议或其他商讨问题的方式，并细列出所有参与其中或以其他方式提交其看法的成员；
2. 外部顾问。 除了选区组织成员外，任务组可在其视为适当或有益的情况下，向外部顾问、专家或其他公众成员征求意见。由上述外部顾问制定的报告中应阐明此类意见，并应 (i) 清楚地标明来自外部顾问；(ii) 另外详细声明顾问的以下信息：(A) 资历和相关经验；(B) 潜在的利益冲突。这些报告应以正式报告书的形式在 PDP 启动后三十五 (35) 个日历天内提交给任务组主席。
e.任务组报告。 任务组主席应与员工事务经理协作，将选区组织报告书、公众意见报告和其他信息或报告（如适用），汇总到一个文档中（以下称“任务组预备报告”），并在 PDP 启动后四十 (40) 个日历天内将任务组预备报告分发给整个任务组。任务组应在任务组预备报告分发后五 (5) 天内召开最后一次任务组会议，以便商讨问题并力争获得极大多数投票。最后一次任务组会议闭会后五 (5) 个日历天内，任务组主席和员工事务经理应制定任务组最终报告（以下称“任务组报告”），并将其在评论站点上公布。每份任务组报告须包括以下内容：
1. 如果获得极大多数投票，则明确陈述任务组就问题的任何立场；
2. 如果未获得极大多数投票，则明确陈述所有在提交选区组织报告的二十天时间限制内所提交的且任务组成员拥护的立场。每种声明均应明确指出 (i) 持有该立场的理由，以及 (ii) 持有该立场的一个或多个选区组织；
3. 分析问题对各个任务组选区组织的影响程度，包括任何对选区组织的财务影响；
5. 理事会指定给任务组的任何外部顾问的意见，另外详细声明顾问的以下信息：(i) 资历和相关经验；(ii) 潜在的利益冲突。
a. 如果决定不召集任务组，则理事会将要求各个选区组织在其后十 (10) 个日历天内指定一名代表征求选区组织对问题的看法。上述各位代表应在 PDP 启动后三十五 (35) 个日历天内向员工事务经理提交选区组织报告书。
b. 理事会还可以采用其他自己认为适合辅助 PDP 的意见征集途径，包括任命特定的人员或组织收集有关问题的信息，或者计划召开商讨会议或汇报会议。所有此类信息应在 PDP 启动后三十五 (35) 个日历天内提交给员工事务经理。
c. 员工事务经理将接纳所有选区组织报告书、公众意见报告书和其他信息，并在 PDP 启动后五十 (50) 个日历天内汇总一份初始报告（并在评论站点上公布）。此后，PDP 应遵循下文有关制定最终报告的第 9 项规定进行。
a. 公众意见征询期为公布任务组报告或初始报告后的二十 (20) 个日历天内。任何个人或组织（包括未加入任务组的任何选区组织）均可在公众意见征询期内提交意见。所有意见均应附带说明意见提出者的姓名、相关经验及问题对其产生的利害关系。
b. 在二十 (20) 天公众意见征询期结束时，员工事务经理将负责评审收到的各种意见，并在任务组报告或初始报告（总称为“最终报告”）中适当添加员工事务经理视为合理的内容。员工事务经理没有义务向报告中加入意见征询期内所征集到的所有意见，包括由任何个人或组织提交的各种意见。
a. 收到最终报告之后，无论是任务组还是其他机构的工作成果，理事会主席均会 (i) 将最终报告分发给所有理事会成员，并 (ii) 在此后十 (10) 个日历天内召开理事会会议。理事会可在正式会议开会之前着手商讨问题，其方式包括现场会议、电话会议、电子邮件讨论或任何其他理事会可以选择的方式。商讨流程应最终在正式的理事会会议（现场会议或电话会议）中展开，会上理事会将力争获得极大多数投票以提交给董事会。
b. 理事会可选择在其最后一次会议上向外部顾问征求意见。如果理事会采纳由这些顾问提出的意见，则应 (i) 在提交给董事会的理事会报告中具体阐明这些意见；(ii) 特别指明这些意见由外部顾问提出；(iii) 另外详细声明顾问的以下信息：(x) 资历和相关经验；(y) 潜在的利益冲突。
员工事务经理将出席理事会的最后一次会议，并闭会后五 (5) 个日历天内将理事会的意见汇总为一份应提交给董事会的报告（以下称“董事会报告”）。董事会报告须至少包含以下内容：
b. 如果未获得极大多数投票，则明确陈述理事会成员持有的所有立场。每种声明均应明确指出 (i) 各个立场的持有理由，以及 (ii) 持有该立场的一个或多个选区组织；
c. 分析问题对各个选区组织的影响程度，包括任何对选区组织的财务影响；
e. 对于由任何外部顾问提出且予以采纳的意见，应另外详细声明顾问的以下信息：(i) 资历和相关经验；(ii) 潜在的利益冲突；
理事会成员极大多数投票的意见将视为理事会的意见反映，可作为理事会的建议呈送至董事会。所有理事会成员不得缺席，因此全体成员均必须投票，但成员与政策问题结果存有财务利益关系的情况除外。尽管有前述规定，PDP 期间所有理事会成员提出的意见均须收录到董事会报告中。
a. 收到员工事务经理的董事会报告之后，董事会将尽快开会讨论 GNSO 理事会建议。
b. 在理事会获得极大多数投票的情况下，董事会应依据理事会获得极大多数投票的建议表决通过该政策，除非董事会超过百分之六十六 (66%) 的投票确定上述政策并非符合 ICANN 社群或 ICANN 的最佳利益。
c. 在董事会决定不按照理事会获得极大多数投票的建议采取行动的情况下，董事会应 (i) 在提交给理事会的报告（以下称“董事会报告书”）中说明其决定的原因；并 (ii) 向理事会提交董事会报告书。
d. 理事会应评审董事会报告书，并在收到董事会报告书后二十 (20) 个日历天内与董事会进行讨论。董事会应确定理事会与董事会讨论董事会报告书的方式（例如，电话会议、电子邮件或其他方式）。
e. 在理事会和董事会讨论结束后，理事会应开会证实或修改其建议，并向董事会传达该结论（“补充建议”），包括其当前建议的说明。在理事会就补充建议获得极大多数投票的情况下，董事会应表决通过该建议，除非董事会超过百分之六十六 (66%) 的投票确定此类政策并非符合 ICANN 社群或 ICANN 的最佳利益。
f. 在理事会无法获得极大多数投票的任何情况下，董事会的多数投票均足以生效。
g. 如果适时就 GNSO 理事会建议或补充建议做出最终决定，董事会应进行预备投票，如果可行，将发布临时性决策，决定在董事会做出最终决定前留出十 (10) 天的公众意见征询期。
做出最终决定后，董事会应向 ICANN 员工批准或说明实施政策所需的所有措施（如果适用）。
在从政策建议到董事会最终决策的整个 PDP 期间，ICANN 将在网站上维护一个详细说明每个 PDP 问题进展的状态网页，具体内容如下：
“评论站点”和“网站”指一个或多个由 ICANN 指定且在上面公布 PDP 相关通知和意见的网站。
“员工事务经理”指一名或多名管理 PDP 的 ICANN 员工。
“极大多数投票”指在适用机构的会议中，超过百分之六十六 (66) 的出席成员投赞成票。
以下流程应对 ccNSO 政策制定流程（以下称“PDP”）起到指导作用。
1. 请求制定问题报告
以下任何对象都可以请求制定问题报告：
a.理事会。 ccNSO 理事会（在本附件 B 中，以下称为“理事会”）可以通过由出席任何会议或通过电子邮件表决的至少七名理事会成员投赞成票，请求制定问题报告。
b.董事会。ICANN 董事会可以通过要求理事会开始政策制定流程，请求制定问题报告。
c.区域组织。 在 ICANN 认可的区域中代表 ccTLD 的一个或多个区域组织可以通过要求理事会开始政策制定流程，请求制定问题报告。
d.ICANN 支持组织或咨询委员会。 ICANN 支持组织或 ICANN 咨询委员会可以通过要求理事会开始政策制定流程，请求制定问题报告。
e.ccNSO 成员。 ccNSO 成员可以通过由出席任何会议或通过电子邮件表决的至少十名 ccNSO 成员投赞成票，请求制定问题报告。
任何问题报告请求必须采用书面形式，并且必须详细阐明请求制定问题报告的问题，以便制定问题报告。理事会可以要求提供更多信息或开展进一步研究或调查，以便确定是否应制定请求的问题报告。
2. 制定问题报告和启动阈值
在获得上文第 1(a) 项中所述的赞成票数或收到上文第 1 (b)、(c) 或 (d) 项所述的请求后七天内，理事会应任命一名问题管理人。问题管理人可以是 ICANN 的工作人员（在这种情况下，问题管理人的费用应由 ICANN 承担），也可以是由理事会选出的一名或多名其他人员（在这种情况下，问题管理人的费用应由 ccNSO 承担）。
在任命后十五 (15) 个日历天（或理事会与问题管理人协商后认为适当的其他时间）之内，问题管理人应制定问题报告。每份问题报告应至少包含以下内容：
a. 需要考虑的提议问题；
b. 提出问题的团体身份；
c. 此问题对该团体有何影响；
d. 对启动 PDP 问题的支持；
e. 问题管理人对于理事会是否应为此问题启动 PDP 的建议（以下称“管理人建议”）。关于该问题是否完全属于 ICANN 政策流程范围和 ccNSO 范围，每项管理人建议应包括 ICANN 法律总顾问的意见并受其支持。在得出自己意见的过程中，法律总顾问应检查以下内容：
1) 该问题是否属于 ICANN 使命声明的范围；
2) 根据第 IX 条第 6 款第 2 项 和附件 C 对相关因素进行的分析是否肯定地说明了该问题属于 ccNSO 的范围；
如果法律总顾问就上述第 1 点和第 2 点获得了肯定的结论，那么还应考虑以下内容：
3) 该问题是否涉及或影响现有的 ICANN 政策；
4) 该问题是否可能具有持续价值或适用性（尽管该问题偶尔需要更新），以及是否可能建立一个指导或框架以利于未来制定决策。
在所有情况下，考虑对 ccPDP（本附件 B）或对 ccNSO 的范围（附件 C）进行修订都应属于 ICANN 和 ccNSO 的范围。
如果法律总顾问认为问题不属于 ccNSO 的范围，那么问题管理人应向理事会告知此观点。如果根据第 IX 条第 6 款和附件 C 对相关因素进行分析之后，10 名或更多理事会成员中的多数认为该问题属于相应范围，那么 ccNSO 主席应相应地告知问题管理人。法律总顾问和 ccNSO 理事会应根据经过协商的规则和程序进行对话，以处理该事务。如果法律总顾问与理事会之间就该问题是否属于 ccNSO 范围未达成任何协议，则理事会可通过 15 名或更多成员的表决来决定该问题是否属于相应范围。ccNSO 主席应相应地告知法律总顾问和问题管理人。问题管理人随后应继续对理事会是否应启动 PDP 提出建议，并将法律总顾问和理事会的观点和分析都添加到问题报告中。
f. 如果管理人建议赞成启动 PDP，此处应列出执行 PDP 各阶段工作的建议时间表（以下称“PDP 时间表”）。
g. 在可能的情况下，问题报告应指出该报告提交后是否可能促使 ICANN 董事会批准某项政策。在某些情况下，只有对问题进行实质性讨论之后，才可能做到这一点。在这些情况下，问题报告中应说明这种不确定性。问题报告完成后，问题管理人应将它分发给整个理事会，以对是否启动 PDP 进行表决。
3. 启动 PDP
理事会应根据以下内容确定是否启动 PDP：
a. 在收到来自问题管理人的问题报告后 21 天内，理事会应对是否启动 PDP 进行表决。此类表决可以在以理事会认为适当的任何方式举行会议（包括现场会议或电话会议）时进行，但如果无法举行会议，也可以通过电子邮件进行表决。
b. 如果问题报告说明该问题完全属于 ICANN 使命声明范围和 ccNSO 范围，则必须要有十名或更多理事会成员表决赞成启动 PDP，PDP 才能启动。
4. 决定是否指定任务组；建立时间表
在根据上文第 3 项启动 PDP 的理事会会议上（或当理事会采用电子邮件表决时，在该表决过程中），理事会应根据出席会议成员（或通过电子邮件表决）的多数票决定是否指定任务组来解决该问题。如果理事会的表决：
a. 赞成召集任务组，则理事会应根据下文第 7 项成立任务组。
b. 反对召集任务组，则理事会应根据下文第 8 项收集有关政策问题的信息。
理事会还应根据成员出席会议或通过电子邮件表决的多数票，批准或修改并批准问题报告中所述的 PDP 时间表。
5. 任务组的构成和选举
a. 通过表决确定要指定任务组之后，理事会应邀请各区域组织（请参见第 IX 条第 6 款）指定两位人员加入任务组（以下称“代表”）。另外，理事会还可指定最多三位来自 ccNSO 外部的顾问（以下称“顾问”），并遵循 GAC 加入任务组的正式请求，接受最多两名来自政府咨询委员会的代表在任务组中任职。理事会可在其认为必要或适当的情况下，自行决定增加指派到任务组的代表人数。
b. 任何要向任务组指派代表的区域组织须在收到上述邀请后十 (10) 个日历天内向问题管理人提交代表姓名，以便将他们加入任务组中。这些代表无需是理事会成员，但每位代表都必须对此主题感兴趣，且具有相关知识和专业技术，并有足够的时间参加任务组活动。
c. 理事会还可以采取其他自己认为适合辅助 PDP 的行动，包括任命特定的个人或组织收集有关问题的信息，或者计划召开商讨会议或总结会议。所有此类信息均应根据 PDP 时间表提交给问题管理人。
6. PDP 启动和意见征询期的公开通知
启动 PDP 后，ICANN 应在网站上公布此类行动的通知，并告知其他 ICANN 支持组织和咨询委员会。随后应就问题开始意见征询期（根据 PDP 时间表，通常至少为 21 天）。应接受从 ccTLD 经理、其他支持组织、咨询委员会和公众征求的意见。问题管理人或其他某位指定的理事会代表应对意见进行评审，并将这些意见汇总为一份报告（以下称“意见报告”），并视情况将该报告收录到任务组预备报告或初始报告中。
7. 任务组
a.任务组的职责。 如果设立任务组，其职责应为负责 (i) 收集说明地理区域以及其他方和团体内 ccNSO 成员立场的信息；(ii) 以其他方式获取相关信息，以便使任务组报告尽可能完整并包含丰富的信息，促使理事会基于广泛的信息进行有意义的商讨。
任务组没有任何正式的决策权。更确切地说，任务组的职责应为收集那些尽可能具体详细地说明各方或团体立场的信息，从而使理事会能够基于广泛的信息对问题进行有意义的商讨。
b.任务组的章程或委任范围。 理事会应在问题管理人的协助下，在 PDP 时间表指定的时间内制定任务组的章程或委任范围（以下称“章程”）。上述章程应包括以下内容：
1. 需要任务组解决的问题，理事会启动 PDP 前须通过此类问题的表决；
2. 任务组须遵循的特定时间表（参见下文），除非理事会确定能够提供具有说服力的理由来延长时间表；
3. 理事会对任务组的任何特定指示，包括任务组是否应就问题征求外部顾问的意见。
任务组应制定其报告并依据章程指导其活动。任何违背章程的请求须正式提交给理事会，经过出席会议或通过电子邮件表决的理事会成员多数表决后任务组方可执行该请求。在第 IX 条第 3 款第 14 项 中要求的法定人数适用于本项（第 7(b) 项）中的理事会决议。
c.任务组主席的任命。 问题管理人应在 PDP 时间表指定的时间内召开任务组的第一次会议。在初次会议上，任务组成员的首要任务是通过表决任命一位任务组主席。主席应负责组织任务组的活动，包括编制任务组报告。任务组主席无需是理事会的成员。
d.信息的收集。
1. 区域组织报告书。 各代表应分别负责征求所在地理区域的区域组织的立场（最低要求），并可在自己认为适当时就考虑的问题征求其他意见，包括该区域内不是区域组织成员的 ccNSO 成员的意见。区域组织的立场和代表收集的任何其他意见应在 PDP 时间表指定的时间内以正式报告书（每份报告书都称为“区域报告书”）的形式提交给任务组主席。每份区域报告书应至少包括以下内容：
(i) 如果获得极大多数投票（按照区域组织所定义），则明确陈述该区域组织关于此问题的立场；
(ii) 如果未获得极大多数投票，则明确陈述该区域组织成员拥护的所有立场；
(iii) 明确陈述区域组织如何达成其立场。具体而言，该陈述应详细说明特定会议、电话会议或其他商议问题的方式，并细列出所有参与其中或以其他方式提交其看法的成员；
(iv) 陈述不是区域组织成员的所有 ccNSO 成员关于此问题的立场；
(v) 分析问题对该区域造成影响的程度，包括对该区域的任何财务影响；
(vi) 分析可能需要实施政策的时间段。
2. 外部顾问。 任务组可自行决定向外部顾问、专家或其他公众征求意见。由上述外部顾问制定的报告中应阐明此类意见，并应 (i) 清楚地标明来自外部顾问；(ii) 另外详细陈述该顾问的以下信息：(a) 资历和相关经验；(b) 潜在的利益冲突。这些报告应以正式报告书的形式在 PDP 时间表指定的时间内提交给任务组主席。
e.任务组报告。 任务组主席应与问题管理人协作，将区域报告书、意见报告和相应的其他信息或报告汇总到一个文件（以下称“任务组预备报告”）中，并在 PDP 时间表指定的时间内将任务组预备报告分发给整个任务组。任务组应召开任务组最终会议讨论这些问题，并尝试获得极大多数投票。任务组最终会议之后，任务组主席和问题管理人应制定任务组最终报告（以下称“任务组报告”），并将其公布在网站上，并告知其他 ICANN 支持组织和咨询委员会。每份任务组报告须包括以下内容：
1. 如果任务组关于此问题的任何立场获得了极大多数投票（占任务组的 66%），则对其进行明确陈述；
2. 如果未获得极大多数投票，则明确陈述任务组成员拥护的所有立场（在选区组织报告提交时间表内提交的）。每种陈述均应明确指出 (i) 持有该立场的理由，以及 (ii) 持有该立场的各区域组织；
3. 分析问题对各区域的影响程度，包括对各区域的任何财务影响；
4. 分析可能需要实施政策的时间段；
5. 理事会指定给任务组的任何外部顾问的意见，另外详细陈述该顾问的以下信息：(i) 资历和相关经验；(ii) 潜在的利益冲突。
8. 未成立任务组情况下的程序
a. 如果理事会决定不召集任务组，那么每个区域组织应在 PDP 时间表指定的时间内指定一位代表，征求该区域对问题的看法。要求每位代表在 PDP 时间表指定的时间内将区域报告书提交给问题管理人。
b. 理事会可以自行决定采取其他辅助 PDP 的措施，包括任命特定的个人或组织收集有关问题的信息，或者计划召开商讨会议或汇报会议等。所有此类信息均应在 PDP 时间表指定的时间内提交给问题管理人。
c. 理事会应正式请求 GAC 主席提供意见或建议。
d. 问题管理人应在 PDP 时间表指定的时间内接纳所有区域报告书、意见报告和其他信息，汇总一份初始报告并在网站上公布。随后，问题管理人应根据下文第 9 项制定最终报告。
9. 对任务组报告或初始报告的意见
a. 应针对任务组报告或初始报告开始意见征询期（根据 PDP 时间表，通常至少为 21 天），以获取意见。应接受从 ccTLD 经理、其他支持组织、咨询委员会和公众征求的意见。所有意见应包括提出者的姓名、相关经验及问题对其产生的利害关系。
b. 意见征询期结束时，问题管理人应对收到的意见进行评审，并根据问题管理人的合理判断向任务组报告或初始报告添加适当的意见，以制定“最终报告”。问题管理人没有义务将意见征询期内征集到的所有意见都添加到报告中，也没有义务将任何个人或组织提交的所有意见都添加到报告中。
c. 问题管理人应在 PDP 时间表指定的时间内制定最终报告，并将其提交给理事会主席。
10. 理事会商讨
a. 收到无论是任务组还是其他方式生成的最终报告后，理事会主席应 (i) 将最终报告分发给所有理事会成员；(ii) 在 PDP 时间表指定的时间内请求召开理事会会议，在会议上理事会应形成建议提交给董事会；(iii) 正式邀请 GAC 主席提供意见或建议。此类会议可以采用理事会认为适当的任何方式召开，包括现场会议或电话会议。问题管理人应出席会议。
b. 理事会可在正式会议开会之前着手商讨问题，其方式包括现场会议、电话会议、电子邮件讨论或任何其他理事会可以选择的方式。
c. 理事会可选择在其最后一次会议上向外部顾问征求意见。如果理事会采纳由这些顾问提出的意见，则应 (i) 在提交给董事会的理事会报告中具体阐明这些意见；(ii) 特别指明这些意见由外部顾问提出；(iii) 另外详细陈述该顾问的以下信息：(a) 资历和相关经验；(b) 潜在的利益冲突。
11. 理事会建议
在考虑是否就该问题提出建议（以下称“理事会建议”）方面，理事会应遵循达成共识的意见。如果少数人反对达成共识的意见，这些少数人应制定一份说明反对理由的报告书，并将它分发给理事会成员。如果理事会对该报告的讨论未达成共识，那么应将由 14 名或更多理事会成员支持的建议视为理事会看法的反映，并作为理事会建议传达给各成员。尽管如此（如下文所述），PDP 期间理事会成员提出的意见均须收录到成员报告中。
12. 提交给成员的理事会报告
如果根据第 11 项采用了理事会建议，则问题管理人应在理事会会议后七天内将理事会的建议与理事会成员的任何其他意见汇总为一份报告，在通过理事会批准后提交给各成员（以下称“成员报告”）。成员报告必须至少包含以下内容：
a. 对理事会建议的明确陈述；
b. 提交给理事会的最终报告；
c. 一份理事会就政策问题的商讨记录的副本（请参见第 10 项），包括此类商讨期间收集到的所有意见，并附带意见发表人的说明。
13. 成员表决
在成员报告提交之后和 PDP 时间表指定的时间内，ccNSO 成员应获得对理事会建议进行表决的机会。成员应通过电子方式表决，成员的投票应在 PDP 时间表指定的时间（至少 21 天）内提交。
如果在表决期内投票的 ccNSO 成员不少于 50%，那么将采用产生的表决结果而不进行进一步处理。如果在第一轮表决中投票的 ccNSO 成员少于 50%，将不采用第一轮结果，而在通知 ccNSO 成员至少三十天后进行的第二轮（最终）表决中，如果投票的 ccNSO 成员不少于 50%，结果将被采用。如果表决期结束时收到的票数有 66% 以上支持理事会建议，那么根据下文第 14 项该建议将作为 ccNSO 建议传达给董事会。
14. 董事会报告
问题管理人应在根据第 13 项采用 ccNSO 建议后七天内将 ccNSO 建议汇总为一份报告，在通过理事会批准后提交给董事会（以下称“董事会报告”）。董事会报告须至少包含以下内容：
a. 对 ccNSO 建议的明确陈述；
b. 提交给理事会的最终报告；
c. 成员报告。
15. 董事会表决
a. 根据需要董事会考虑的程序，在从问题管理人收到董事会报告后，董事会应尽快在合理的时间召开会议对 ccNSO 建议进行讨论。
b. 董事会应采纳 ccNSO 建议，除非董事会超过 66% 的投票确定上述政策并非符合 ICANN 社群或 ICANN 的最佳利益。
1. 在董事会决定不按照 ccNSO 建议采取行动的情况下，董事会应 (i) 在提交给理事会的报告（以下称“董事会报告书”）中说明决定不按照 ccNSO 建议采取行动的原因，并 (ii) 向理事会提交董事会报告书。
2. 理事会应在董事会报告书提交给理事会后三十天内与董事会就董事会报告书进行讨论。董事会应确定理事会与董事会讨论董事会报告书的方式（例如，电话会议、电子邮件或其他方式）。讨论应通过及时有效的方式诚恳地寻求双方都可接受的解决办法。
3. 在理事会和董事会讨论结束后，理事会应开会证实或修改其理事会建议。应将由 14 位或更多理事会成员支持的建议视为理事会看法的反映（理事会的“补充建议”）。该补充建议应通过成员补充报告传达给各成员，其中包括对补充建议的说明。成员应获得对补充建议进行表决的机会（在与第 13 项中所述相同的条件）。如果表决期内 ccNSO 成员支持补充建议的票数超过 66%，那么该建议应作为 ccNSO 补充建议传达给董事会，而董事会应采纳该建议，除非董事会超过 66% 的投票确定接受上述政策将违反董事会对公司的诚信义务。
4. 如果董事会不接受 ccNSO 补充建议，则应在最终决定（以下称“董事会补充报告书”）中说明此决定的原因。
5. 如果董事会决定不接受 ccNSO 补充建议，那么董事会将无权对建议中涉及的问题制定政策；而在 ccNSO 根据 ccPDP 对该问题做出董事会认为可接受的建议之前，应维持现状。
16. 政策的实施
如果董事会采纳了 ccNSO 建议或 ccNSO 补充建议，董事会就应在适当时指导或授权 ICANN 工作人员实施该政策。
17. 记录的维护
对于请求问题报告的每个 ccPDP（请参见第 1 项），ICANN 应在网站上设立一个状态网页，详细描述每个 ccPDP 的进展，该网页不但提供 ccPDP 的相关日期列表，还将提供到以下文件的链接（具体取决于这些文件依据 ccPDP 的制定情况）：
a. 问题报告；
b. PDP 时间表；
c. 意见报告；
d. 区域报告书；
e. 任务组预备报告；
f. 任务组报告；
g. 初始报告；
h. 最终报告；
i. 成员报告；
j. 董事会报告；
k. 董事会报告书；
l. 成员补充报告；
m. 董事会补充报告书。
此外，ICANN 应将所收到的明确建议启动 ccPDP 的电子书面意见公布在网站上。
本附件说明了 ccNSO 的范围，以及在 ccNSO 政策制定角色范围的进一步发展过程中要使用的分析原则和方法。如本章程第 IX 条第 6 款第 2 项 所述，应根据 ccPDP 的程序来定义该范围。
ccNSO 的权力和责任范围必须认可在政策问题方面 ICANN 和 ccTLD 经理/注册机构之间的复杂关系。本附件对 ccNSO、ccNSO 理事会以及 ICANN 董事会和工作人员描述相关全球政策问题很有帮助。
政策范围
ccNSO 的政策角色应基于对以下 DNS 功能模型的分析：
1. 注册/维护数据来生成区域文件。
2. 而区域文件会用在 TLD 名称服务器中。
在 TLD 中，必须执行两项功能（下文将对此进行更详细的描述）：
1. 将数据输入数据库（数据输入功能）；
2. 维护并确保 TLD 名称服务器的正常运行（名称服务器功能）。
这两项核心功能必须在 ccTLD 注册机构级别以及 DNS 层次结构的较高级别（IANA 功能和根服务器）和较低级别执行。正如 RFC 1591 所指出，这种机制是递归性的：
任何对顶级域子域的要求都不会超越对更高级域的要求。也就是说，此备忘录中的要求将以递归方式应用。具体来说，应允许所有子域运行自己的域名服务器，其中提供子域管理员认为适当的任何信息（只要真实正确即可）。
核心功能
1. 数据输入功能 (DEF)：
从更详细的角度来看，第一种功能（在数据库中输入和维护数据）应由命名策略进行完整的定义。此命名策略必须指定用于以下情况的规则和条件：
(a) 收集数据并将数据输入数据库，或更改数据库中的数据（尤其是那些在 TLD 级别能反映从注册人转移到注册人或不断变化的注册商的数据）。
(b) 开放某些数据以供普通大众使用（例如，通过 Whois 或名称服务器实现）。
2. 名称服务器功能 (NSF)
名称服务器功能涉及域名系统核心部分的基本互操作性和稳定性问题。此功能的重要性可延伸至 ccTLD 级别的名称服务器，也可延伸至更低级别的根服务器（和根服务器系统）以及名称服务器。
从正常运行的名称服务器的自身价值以及互操作性和稳定性方面来考虑，这种名称服务器对于个人以及本地和全球互联网社群来说极为重要。
因此，需要定义并建立有关名称服务器功能方面的政策。大多数相关方（包括大多数 ccTLD 注册机构）都承认在遵守相关 RFC（尤其是 RFC 1591）的情况下，有必要制定有关此方面的通用政策。
关于政策角色、职责角色和责任角色
为了 ICANN 和 ccTLD 经理的利益，必须确保域名系统能够正常稳定地运行。在这一点上，ICANN 和 ccTLD 注册机构各有不同的角色，这些角色可根据相关政策进行定义。如果对 ICANN 和 ccTLD 注册机构之间的权力分配没有达成共识，则无法确定 ccNSO 的范围。
从针对任何给定问题必须指定何种职责来说，可分为三个角色：
- 政策角色：也就是定义政策的能力和权力；
- 执行角色：也就是遵照政策行事和实施政策的能力和权力；
- 责任角色：也就是让责任实体对行使其权力尽职尽责的能力和权力。
首先，职责需要有一个政策作为前提，而这可以说明政策角色的内容。根据需要解决的问题，有必要确定和定义一些人员来从事政策的定义和订立工作。其次，这需要先有一个执行角色，用于定义在政策界限内实施政策和遵照政策行事的权力。最后，为了与执行角色抗衡，需要定义和确定责任角色。
以下信息有助于：
1. 说明和确定特定政策范围；
2. 定义和确定有关这些特定政策范围的角色。
本附件定义了 ccNSO 有关制定政策的范围。该范围限制为 ccNSO 政策制定流程在下文明确阐述的功能和级别方面所具有的政策角色。在为 ccPDP 流程定义范围的过程中，预计会将是否准确地指定下文所示的政策角色、执行角色和责任角色纳入考虑范围。
名称服务器功能（关于 ccTLD）
级别 1：根名称服务器
政策角色：IETF、RSSAC (ICANN)
执行角色：根服务器系统运营商
责任角色：RSSAC (ICANN)、(US DoC-ICANN MoU)级别 2：ccTLD 注册机构名称服务器（关于互操作性）
政策角色：ccNSO 政策制定流程 (ICANN)（为获得可使 ccNSO 流程有条理的最佳做法）
执行角色：ccTLD 经理
责任角色：部分 ICANN (IANA)、部分本地互联网社群，包括本地政府级别 3：用户的名称服务器
政策角色：ccTLD 经理、IETF (RFC)
执行角色：注册人
责任角色：ccTLD 经理
数据输入功能（关于 ccTLD）
级别 1：根级别注册机构
政策角色：ccNSO 政策制定流程 (ICANN)
执行角色：ICANN (IANA)
责任角色：ICANN 社群、ccTLD 经理、US DoC、国家/地区权威机构（在某些情况下）级别 2：ccTLD 注册机构
政策角色：本地互联网社群，包括本地政府和/或 ccTLD 经理（取决于本地结构）
执行角色：ccTLD 经理
责任角色：本地互联网社群，包括国家/地区权威机构（在某些情况下）级别 3：第二和更低级别
政策角色：注册人
执行角色：注册人
责任角色：注册人、低级别域名的用户