董事会的活动和会议
会议记要 | ICANN 理事会特别会议 2011 年 01 月 25 日
本文档已翻译为多种语言，仅供参考之用。原始官方版本（英文版）可在以下位置找到： http://www.icann.org/en/minutes/minutes-25jan11-en.htm
ICANN 理事会于 2011 年 1 月 25 日世界标准时间 20:00 以电话会议形式召开了一次特别会议。
Peter Dengate Trush 及时预定了本次会议。
除 Peter Dengate Thrush 主席外 ， 以下理事也参加了全部或部分会议 ： Rod Beckstrom （ 总裁兼首席执行官 ） 、 Steve Crocker （ 副主席 ） 、 Sébastien Bachollet 、 Cherine Chalaby 、 Bertrand de La Chapelle 、 Rita Rodin Johnston 、 Erika Mann 、 Gonzalo Navarro 、 Raymond A. Plzak 、 Rajasekhar Ramaraj 、 George Sadowsky 、 Mike Silber 、 Bruce Tonkin 、 Katim Touray 和 Kuo-Wei Wu 。
以下理事会联络员参加了全部或部分会议 ： Heather Dryden （ GAC 联络员 ） 、 Ram Mohan （ SSAC 联络员 ） 、 Thomas Narten （ IETF 联络员 ） 和 Suzanne Woolf （ RSSAC 联络员 ） 。
Reinhard Scholl （ TLG 联络员 ） 致歉。
还有以下 ICANN 管理层和工作人员参加了全部或部分会议 ： John Jeffrey （ 总顾问和秘书长 ） 、 Akram Atallah （ 首席运营官 ） 、 Kurt Pritz （ 高级副总裁 ） 、 Diane Schroeder （ 理事会支持部主管 ） 和 Amy Stathos （ 副总顾问 ） 。
-
执行会议
理事会秘密举行了一次执行会议。在执行会议期间未采取任何行动。
-
认可议程
理事会主席向新理事会成员介绍了设计的议程，并指出任何理事会成员都可以请求从“认可议程”中删除项目。理事会请求将三个项目移至 “ 主要议程 ” 中 ： 对 “ 更改由支持组织和网络普通用户选出的理事会成员的任期结束日期的提议章程修正案 ” 的考虑 ， VeriSign RSEP （ 针对 .NAME ） 对发布全数字型字符串和带连字符的数字型字符串的请求 ， 以及 Telnic RSEP 对发布全数字型字符串 （ 单字符标签除外 ， 已将其移至主要议程优先考虑的项目中 ） 的请求。
以 16-0 一致通过以下决议。这些决议均由主席提出 ， 且 George Sadowsky 支持该动议。
-
批准 2010 年 12 月 8 日的 ICANN 理事会特别会议记录
第 2011.01.25.01 号决议： 理事会特此批准 2010 年 12 月 8 日的 ICANN 理事会特别会议记录。
-
批准 2010 年 12 月 10 日的 ICANN 理事会例行会议记录
第 2011.01.25.02 号决议： 理事会特此批准 2010 年 12 月 10 日的 ICANN 理事会例行会议记录。
-
批准 2010 年 12 月 10 日的 ICANN 理事会组织会议记录
第 2011.01.25.03 号决议： 理事会特此批准 2010 年 12 月 10 日的 ICANN 理事会组织会议记录。
-
批准财务委员会章程修订版
理事会财务委员会 (BFC) 目前遵循的是 2000 年通过的章程，发布在 http://www.icann.org/en/committees/finance/ 。
BFC 的一项职责是审核其运作，然后提出合适的更新或改进建议； 2010 年 12 月 5 日， BFC 批准了其章程修订版，以更如实地反映 BFC 的目前运作。该章程修订版还原样引入了理事会管理委员会之前批准通过的《理事会管理委员会章程》的标准文本。请参见 http://www.icann.org/en/minutes/resolutions-06mar09.htm#10 。
第 2011.01.25.04 号决议： 批准理事会财务委员会章程修订版。
2011.01.25.04 号决议理由
此次批准修订版理事会财务委员会 (BFC) 章程是合适的，因为修订版比前一版更如实地反映了 BFC 目前的运作。该修订版还符合理事会管理委员会批准的所有其他章程的最新修订版。此外，章程修订版还反映了 BFC 与 ICANN 2011 年的规模和覆盖范围相关的工作活动，并指出 BFC 的运作符合最佳做法。在制定章程修订版期间，理事会审核了 ICANN BFC 的最佳做法及实际运作，并认为这两方面对于批准章程修订版十分重要。
BFC 章程修订版的批准预计会产生积极的公共影响，因为该修订版提高了委员会的责任性和透明性，并且如实反映了 BFC 目前的工作活动和最佳做法。修订 BFC 章程对于 ICANN 或机构群体不会产生财务影响。通过修订其章程而确认 BFC 的职责不会对 DNS 的系统安全、稳定性和灵活性造成任何影响。
-
来自 SSAC － 任命 SSAC 主席
ICANN 章程中第 XI 条第 2 款的 2 小节对安全与稳定咨询委员会 (SSAC) 做出了规定。
ICANN 章程中第 XI 条第 2 款的 2 小节规定理事会应负责任命 SSAC 的主席和成员。
Steve Crocker 于 2010 年 12 月 10 日宣布自己将辞去 SSAC 主席一职，但将留任到 SSAC 推举出新主席并获得理事会批准任命。
Ray Plzak 已于 2010 年 12 月 22 日辞去 SSAC 副主席职务。
SSAC 自 2010 年 12 月 10 日开始从委员会成员中推选主席和副主席，选举于 2011 年 1 月 7 日结束。
委员会推举 Patrik Fältström 出任主席，推举 James Galvin 出任副主席。
第 2011.01.25.05 号决议： 理事会接受了 SSAC 的推选建议，任命 Patrik Fältström 担任 SSAC 主席，并对 Patrik Fältström 和 James Galvin 各自出任新的要职表达了最良好的祝愿。
-
来自 SSAC － 感谢即将离任的 SSAC 成员 － Christophe Reverd
2009 年 6 月 26 日， Christophe Reverd 被任命为 ICANN 安全与稳定咨询委员会成员。
ICANN 积极肯定并真诚感谢 Christophe Reverd 在担任安全与稳定咨询委员会成员期间为机构群体提供的服务。
第 2011.01.25.06 号决议： 理事会谨对 Christophe Reverd 在担任安全与稳定咨询委员会成员期间为 ICANN 提供的服务致以诚挚的谢意，并真诚祝愿 Christophe Reverd 将来的事业顺利如意。
-
来自 SSAC － 感谢即将离任的 SSAC 成员兼副主席 － Ray Plzak
2002 年 5 月 17 日， Ray Plzak 被任命为 ICANN 安全与稳定咨询委员会成员。
ICANN 积极肯定并真诚感谢 Ray Plzak 在担任安全与稳定咨询委员会成员兼副主席期间为机构群体提供的服务。
第 2011.01.25.07 号决议： 理事会谨对 Ray Plzak 在担任安全与稳定咨询委员会成员兼副主席期间为 ICANN 提供的服务致以诚挚的谢意，并真诚祝愿 Ray Plzak 将来的事业顺利如意。
-
来自 SSAC － 感谢即将离任的 SSAC 主席 － Steve Crocker
2002 年 3 月 14 日， Stephen Crocker 博士被任命为 ICAN 安全与稳定咨询委员会主席。
Crocker 博士在担任 SSAC 主席期间，以其卓越的才干和全心的投入，出色地完成了使命。
Crocker 博士带领建立了 SSAC 运作的结构和工作内容，并引领委员会成功完成了重大的里程碑事件，如 SiteFinder 和根区域升级。
Crocker 博士扩充了 SSAC 的成员构成，吸纳了多种领域的主题专家，从而既拓展了委员会的地理多样性，也提升了人员配备的广度。
在 Crocker 博士的引领下， SSAC 通过了其第一次外部综合审核，确保了各项建议的及时实施。
在 Steve Crocker 的努力下，安全与稳定咨询委员会完成了从概念阶段到出色实际运作的大转变，无论是在委员会内部还是在 ICANN 群体都提高了自己的声誉。
Crocker 博士于 2010 年 12 月 10 日宣布自己将辞去 SSAC 主席一职，但将留任到 SSAC 推举出新主席并获得理事会批准任命。
SSAC 自 2010 年 12 月 10 日开始从委员会成员中推选主席和副主席，选举于 2011 年 1 月 7 日结束。
委员会推举 Patrik Fältström 出任主席，推举 James Galvin 出任副主席。
2011 年 1 月 25 日，理事会任命 Patrik Fältström 为 SSAC 新任主席。
第 2011.01.25.08 号决议： 理事会谨对 Crocker 博士在担任安全与稳定咨询委员会主席期间为 ICANN 提供的不懈服务与全心投入致以最诚挚的谢意，并真诚祝愿 Crocker 博士将来的事业顺利如意。
-
批准跟进 IPv4 耗尽后的全球政策流程
理事会对 ASO 地址委员会根据 ASO 谅解备忘录提交供审批的全球互联网号码资源政策的审核程序 中规定“当负责联络地址分配群体的 ICANN 工作人员根据 ASO 谅解备忘录的全球政策制定流程中的步骤 1 （附件 A ，第 1 条）了解到发生了属于 ASO 谅解备忘录范围内的全球政策制定时，应该就此通知 ICANN 理事会 。 理事会决定，在适当时机， ICANN 工作人员应该跟进这种政策制定，并指示 ICANN CEO 委任负责工作人员。受委任负责此项工作的 ICANN 工作人员应该通知所有 ICANN 支持组织和咨询委员会，并且应该建立一个 ICANN 网页发布最新信息，还应该拟具一份背景报告，提供关于此全球政策制定的最新信息。若理事会要求，应该向其提供此背景报告。”
ICANN 工作人员已通知理事会，一项题为 "IANA 关于 IPv4 耗尽后 IPv4 地址分配的全球政策提议”的政策提议正在制定之中，现已进入各个地区互联网注册机构 (RIR) 的初步讨论阶段，并被 ASO 地址委员会认可为有效的全球政策提议。
该项提议被视为属于 ICANN 与 ASO 之间达成的谅解备忘录范围的全球政策制定。
第 2011.01.25.09 号决议： 理事会要求 "IANA 关于 IPv4 耗尽后 IPv4 地址分配的全球政策提议”的制定应由 ICANN 工作人员根据理事会关于此类政策提议的审核程序进行跟进，并指示 ICANN CEO 委任负责此项工作的工作人员。
2011.01.25.09 号决议理由
此项全球政策提议已进入在各个地区互联网注册管理机构中展开讨 论的阶段， 现在开始拟具和发布关于提议状态的背景报告的时机已经成熟。指导工作人员开展必要的跟进工作，是 ICANN 与 ASO 的谅解备忘录中以及理事会全球互联网号码资源政策审核程序中规定的一项 ICANN 衍生职责。
指导 ICANN 工作人员跟进提议的工作只会产生很小的预算影响，因为工作人员已经分配给 ASO ，使得这一阶段的提议跟进只需要有限的工作量。如果提议获得批准，后续的实施可能会对预算、公共和安全 / 稳定性相关问题产生更多影响，但现在并不是评估这些影响的成熟时机。要求工作人员在此阶段跟进还有利于在 ASO 要求审批提议之前做好前期准备工作。
-
批准 RSSAC 审核实施计划
2010 年 8 月 5 日，理事会决议接受 RSSAC 审核工作组的最终报告，并指示机构改进委员会 (SIC) “提交一套建议的举措，在 2010 年 10 月召开的理事会会议上进行审批，以实施该工作组最终报告中提出的结论和建议”，参见 http://www.icann.org/en/minutes/resolutions-05aug10-en.htm#2.f 。
负责为组织审核提供支持的 ICANN 工作人员在 "RSSAC 审核工作组最终报告：实施步骤”文档中（ 2010 年 12 月发布）提议了一套举措，以实施工作组提出的建议并将其提交给 SIC 。
SIC 认为提议的举措很充分，并建议工作人员与 SIC 协作，根据提议的实施步骤最终确定一份实施计划，并将最终实施计划提交给理事会进行讨论审批。
第 2011.01.25.10 号决议： 理事会批准了 SIC 提交的 "RSSAC 审核工作组最终报告：实施步骤”，并指示 SIC 与工作人员协作，向理事会提交一份最终实施计划，以实施 RSSAC 审核工作组最终报告中提出的结论和建议。
2011.01.25.10 号决议理由
应理事会 2010 年 8 月 5 日关于提交此提议的决议要求，向理事会提交了提议的实施步骤。实施步骤旨在实现审核工作组最终报告中提出的建议。最终报告草案已发布征询公众意见，没有收到意见或建议，也没有收到关于如果采纳建议会产生负面影响的意见。此外，采纳 RSSAC 审核工作组最终报告的实施计划将会创造一个有利条件，以委任一位专门的工作人员，促进 ICANN 与根服务器运营机构在 RSSAC 结构框架内的协作与沟通。
指导制定最终实施计划会产生稍许预算影响，因为需要分配额外工作人员资源来支持 ICANN 的组织审核。最终实施步骤的确定预计由现有人员资源来完成。实施工作的进一步影响根据实际情况确定。
-
批准为提名委员会设立非投票当选主席的章程修正提案
ICANN 章程中第 VII 条第 2 款和第 3 款规定了提名委员会 (NomCom) 的构成和 NomCom 成员的任期。
在 2010 年 1 月 29 日发布的最终报告 http://www.icann.org/zh/reviews/nomcom/nomcom-review-finalization-wg-final-report-29jan10-zh.pdf [PDF, 461 KB] 中， NomCom 终审工作组建议提前一年选举 NomCom 主席，这需要修订 ICANN 章程的第 VII 条第 2 款和第 3 款，参见 http://www.icann.org/en/general/bylaws.htm#VII 。
2010 年 3 月 12 日，理事会收到 NomCom 审核最终报告，并指示机构改进委员会 (SIC) 确定实施报告中建议的必要举措，参见 http://www.icann.org/en/minutes/resolutions-12mar10-en.htm#1.6 。
SIC 在其 2010 年 10 月 14 日召开的会议上，提议应该修订 ICANN 章程，以实施 NomCom 终审工作组关于提前一年选举 NomCom 主席的建议，同时强调相关的章程修订必须容许适当的灵活性，允许理事会审核。
理事会在其 2010 年 10 月 28 日召开的会议上决定应发布章程修正提案以征询公众意见。
章程修正提案发布在 http://www.icann.org/en/general/proposed-bylaws-revision-vii-10nov10-en.pdf [PDF, 64 KB] ，公众意见征询期从 2010 年 11 月 10 日开始到 12 月 10 日结束，在此期间没有收到任何建议和意见。
第 2011.01.25.11 号决议： 理事会批准章程修正提案，并指示工作人员与机构改进委员会协作，为新条款对 2013 年提名委员会生效做好实施准备工作。
2011.01.25.11 号决议理由
章程修正提案旨在实施 NomCom 终审工作组提出的提前一年任命 NomCom 主席的建议，同时保留适当的灵活性，允许理事会审核主席候选人。
到目前为止，尚未收到关于此项修正不会对提名委员会及其流程产生积极影响的任何公众意见。此修正产生的预算影响可以忽略，因为从主席身边无投票权的顾问到当选主席的转变，并不会导致需要通过提名委员会预算支持的提名委员会成员人数的变化。
-
感谢 2010 年提名委员会
2009 年 8 月 27 日， ICANN 任命 Wolfgang Kleinwächter 担任提名委员会主席。
2010 年提名委员会由来自每个 ICANN 社群和咨询机构的代表组成。
第 2011.01.25.12 号决议： ICANN 理事会谨对 Wolfgang Kleinwächter 与 2010 年提名委员会全体成员的全心投入、辛勤努力和工作成果致以深深的谢意。
-
批准重新授权表示布基纳法索的域名 .BF
BF 是分配给 布基纳法索 的 ISO 3166-1 双字母国家或地区代码。
ICANN 收到了将 .BF 重新授权给 Autorité de Régulation des Communications Electroniques 的申请。
ICANN 在审核此申请后，认为提议的重新授权会符合当地和全球互联网群体的利益。
第 2011.01.25.13 号决议： 批准将域名 .BF 重新授权给 Autoritéde Régulation des Communications Electroniques 的提议。
2011.01.25.13 号决议理由
为什么理事会现在要解决此问题？
如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整，有获得理事会批准的前景时，会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能（尤其是 DNS 根区域）相关的请求的承诺， ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。
讨论的提议是什么？
提议是批准向 IANA 提交的一项申请，请求变更或指定某个国家或地区代码顶级域名的主办组织（也称为管理者或受托者）。根据现行做法，在这个多步骤流程中，一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。
咨询了哪些利益主体或其他相关方？
在评估授权申请期间， ICANN 工作人员咨询了申请人、当前运营商（如适用），以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例， ICANN 尚未对此问题进行公开的咨询。
机构群体提出了哪些担心或问题？
所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理，将在 IANA 网站 http://www.iana.org/ 上发布该报告，通常是在理事会作出决定后的 1 到 2 个月后。
理事会审核了哪些重要材料？
理事会依据各种公众利益标准来评估申请。此类标准包括：确保国家或地区代码合法（例如在 ISO 3166-1 标准中列出）；确保当地互联网群体支持提议的管理者；确保提议的运营商在运作及技术方面有足够能力；确保提议的管理者以当地为基础并且受当地法律制约；确保提议的管理者秉承公平的运营原则；确保当发生运营方变更时存在一个适当的计划，能够保持域名的持续稳定性；并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间，会要求申请人提供各种材料来支持上述各方面。
来自这些材料及其他工作人员研究的相关信息结果将提交给理事会，并在实施获批申请后在一份公开报告中发布这些信息。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。
是否会对机构群体产生积极或负面影响？
及时批准符合各种公共利益标准的国家或地区代码域名管理者对于 ICANN 整体工作会有积极影响，对于该域名所服务的当地机构群体也会有积极作用。
对于 ICANN （战略规划、运营计划、预算）、机构群体和 / 或公众是否会产生财务影响或后果？
管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责，授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责， ICANN 负责确保运营商总部位于该国，并有相应的机制允许当地互联网群体适当监督域名的持续运营。
是否有与 DNS 相关的任何安全性、稳定性或灵活性问题？
对于国家或地区代码顶级域名授权， ICANN 倾向于只批准此类申请：令人满意地解决了有合理理由担心的问题，并且提议的新管理者展示出足够高的运营和技术能力水平，使这些问题不会成为担心的问题。
-
批准重新授权表示刚果民主共和国的域名 .CD
CD 表示分配给刚果民主共和国的 ISO 3166-1 双字母国家或地区代码；
ICANN 收到了将 .CD 重新授权给 Office Congolais des Postes et Telecommunications 的申请；
ICANN 在审核此申请后，认为提议的重新授权会符合当地和全球互联网群体的利益。
第 2011.01.25.14 号决议： 批准将域名 .CD 重新授权给 Office Congolais des Postes et Telecommunications 的提议。
2011.01.25.14 号决议理由
为什么理事会现在要解决此问题？
如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整，有获得理事会批准的前景时，会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能（尤其是 DNS 根区域）相关的请求的承诺， ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。
讨论的提议是什么？
提议是批准向 IANA 提交的一项申请，请求变更或指定某个国家或地区代码顶级域名的主办组织（也称为管理者或受托者）。
根据现行做法，在这个多步骤流程中，一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。
咨询了哪些利益主体或其他相关方？
在评估授权申请期间， ICANN 工作人员咨询了申请人、当前运营商（如适用），以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例， ICANN 尚未对此问题进行公开的咨询。
机构群体提出了哪些担心或问题？
所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理，将在 IANA 网站 http://www.iana.org/ 上发布该报告，通常是在理事会作出决定后的 1 到 2 个月后。
理事会审核了哪些重要材料？
理事会依据各种公众利益标准来评估申请。
此类标准包括：确保国家或地区代码合法（例如在 ISO 3166-1 标准中列出）；确保当地互联网群体支持提议的管理者；确保提议的运营商在运作及技术方面有足够能力；确保提议的管理者以当地为基础并且受当地法律制约；确保提议的管理者秉承公平的运营原则；确保当发生运营方变更时存在一个适当的计划，能够保持域名的持续稳定性；并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间，会要求申请人提供各种材料来支持上述各方面。
来自这些材料及其他工作人员研究的相关信息结果将提交给理事会，并在实施获批申请后在一份公开报告中发布这些信息。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。
是否会对机构群体产生积极或负面影响？
及时批准符合各种公共利益标准的国家或地区代码域名管理者对于 ICANN 整体工作会有积极影响，对于该域名所服务的当地机构群体也会有积极作用。
对于 ICANN （战略规划、运营计划、预算）、机构群体和 / 或公众是否会产生财务影响或后果？
管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责，授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责， ICANN 负责确保运营商总部位于该国，并有相应的机制允许当地互联网群体适当监督域名的持续运营。
是否有与 DNS 相关的任何安全性、稳定性或灵活性问题？
对于国家或地区代码顶级域名授权， ICANN 倾向于只批准此类申请：令人满意地解决了有合理理由担心的问题，并且提议的新管理者展示出足够高的运营和技术能力水平，使这些问题不会成为担心的问题。
-
批准重新授权表示阿拉伯叙利亚共和国的域名 .SY
SY 是分配给阿拉伯叙利亚共和国的 ISO 3166-1 双字母国家或地区代码。
ICANN 收到了将 .SY 重新授权给 National Agency for Network Services 的申请；
ICANN 在审核此申请后，认为提议的重新授权会符合当地和全球互联网群体的利益。
第 2011.01.25.15 号决议： 批准将域名 .SY 重新授权给 National Agency for Network Services 的提议。
2011.01.25.15 号决议理由
为什么理事会现在要解决此问题？
如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整，有获得理事会批准的前景时，会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能（尤其是 DNS 根区域）相关的请求的承诺， ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。
讨论的提议是什么？
提议是批准向 IANA 提交的一项申请，请求变更或指定某个国家或地区代码顶级域名的主办组织（也称为管理者或受托者）。
根据现行做法，在这个多步骤流程中，一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。
咨询了哪些利益主体或其他相关方？
在评估授权申请期间， ICANN 工作人员咨询了申请人、当前运营商（如适用），以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例， ICANN 尚未对此问题进行公开的咨询。
机构群体提出了哪些担心或问题？
所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理，将在 IANA 网站 http://www.iana.org/ 上发布该报告，通常是在理事会作出决定后的 1 到 2 个月后。
理事会审核了哪些重要材料？
理事会依据各种公众利益标准来评估申请。此类标准包括：确保国家或地区代码合法（例如在 ISO 3166-1 标准中列出）；确保当地互联网群体支持提议的管理者；确保提议的运营商在运作及技术方面有足够能力；确保提议的管理者以当地为基础并且受当地法律制约；确保提议的管理者秉承公平的运营原则；确保当发生运营方变更时存在一个适当的计划，能够保持域名的持续稳定性；并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间，会要求申请人提供各种材料来支持上述各方面。
来自这些材料及其他工作人员研究的相关信息结果将提交给理事会，并在实施获批申请后在一份公开报告中发布这些信息。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。
是否会对机构群体产生积极或负面影响？
及时批准符合各种公共利益标准的国家或地区代码域名管理者对于 ICANN 整体工作会有积极影响，对于该域名所服务的当地机构群体也会有积极作用。
对于 ICANN （战略规划、运营计划、预算）、机构群体和 / 或公众是否会产生财务影响或后果？
管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责，授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责， ICANN 负责确保运营商总部位于该国，并有相应的机制允许当地互联网群体适当监督域名的持续运营。
是否有与 DNS 相关的任何安全性、稳定性或灵活性问题？
对于国家或地区代码顶级域名授权， ICANN 倾向于只批准此类申请：令人满意地解决了有合理理由担心的问题，并且提议的新管理者展示出足够高的运营和技术能力水平，使这些问题不会成为担心的问题。
-
批准授权以韩语表示大韩民国的域名 .한국 ("Hanguk")
한국 ("Hanguk") 的编码为 "xn--3e0b707e"，被视为是通过 IDN 快速通道流程表示大韩民国的合适字符串。
ICANN 收到了将 .한국 授权给韩国互联网与安全局 ( Korea Internet & Security Agency) 的申请。
ICANN 在审核此申请后，认为提议的授权会符合当地和全球互联网群体的利益。
第 2011.01.25.16 号决议： 批准将域名 .한국 重新授权给韩国互联网与安全局 (Korea Internet & Security Agency) 的提议。
2011.01.25.16 号决议理由
为什么理事会现在要解决此问题？
如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整，有获得理事会批准的前景时，会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能（尤其是 DNS 根区域）相关的请求的承诺， ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。
讨论的提议是什么？
提议是批准向 IANA 提交的一项申请，请求变更或指定某个国家或地区代码顶级域名的主办组织（也称为管理者或受托者）。
根据现行做法，在这个多步骤流程中，一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。
咨询了哪些利益主体或其他相关方？
在评估授权申请期间， ICANN 工作人员咨询了申请人、当前运营商（如适用），以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例， ICANN 尚未对此问题进行公开的咨询。
机构群体提出了哪些担心或问题？
所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理，将在 IANA 网站 http://www.iana.org/ 上发布该报告，通常是在理事会作出决定后的 1 到 2 个月后。
理事会审核了哪些重要材料？
理事会依据各种公众利益标准来评估申请。
此类标准包括：确保国家或地区代码合法（例如在 ISO 3166-1 标准中列出）；确保当地互联网群体支持提议的管理者；确保提议的运营商在运作及技术方面有足够能力；确保提议的管理者以当地为基础并且受当地法律制约；确保提议的管理者秉承公平的运营原则；确保当发生运营方变更时存在一个适当的计划，能够保持域名的持续稳定性；并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间，会要求申请人提供各种材料来支持上述各方面。
来自这些材料及其他工作人员研究的相关信息结果将提交给理事会，并在实施获批申请后在一份公开报告中发布这些信息。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。
是否会对机构群体产生积极或负面影响？
及时批准符合各种公共利益标准的国家或地区代码域名管理者对于 ICANN 整体工作会有积极影响，对于该域名所服务的当地机构群体也会有积极作用。
对于 ICANN （战略规划、运营计划、预算）、机构群体和 / 或公众是否会产生财务影响或后果？
管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责，授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责， ICANN 负责确保运营商总部位于该国，并有相应的机制允许当地互联网群体适当监督域名的持续运营。
是否有与 DNS 相关的任何安全性、稳定性或灵活性问题？
对于国家或地区代码顶级域名授权， ICANN 倾向于只批准此类申请：令人满意地解决了有合理理由担心的问题，并且提议的新管理者展示出足够高的运营和技术能力水平，使这些问题不会成为担心的问题。
-
批准授权以中文和泰米尔语表示新加坡的域名 .新加坡 ("Singapore") 和 .சிங்கப்பூர் ("Singapore")
目前 ISO 3166-1 标准中列出的是 Singapore ；
新加坡 ("Singapore") 的编码为 "xn--yfro4i67o"， சிங்கப்பூர் ("Singapore") 的编码为 "xn--clchc0ea0b2g2a9gcd"，被视为是通过 IDN 快速通道流程表示新加坡的两个合适字符串；
ICANN 收到了将 .新加坡 和 .சிங்கப்பூர் 授权给新加坡网络信息中心 (Singapore Network Information Centre Pte Ltd) 的申请。
ICANN 在审核此申请后，认为提议的授权会符合当地和全球互联网群体的利益。
第 2011.01.25.17 号决议： 批准将上述顶级域名授权给新加坡网络信息中心 (Singapore Network Information Centre Pte Ltd) 的提议。
2011.01.25.17 号决议理由
为什么理事会现在要解决此问题？
如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整，有获得理事会批准的前景时，会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能（尤其是 DNS 根区域）相关的请求的承诺， ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。
讨论的提议是什么？
提议是批准向 IANA 提交的一项申请，请求变更或指定某个国家或地区代码顶级域名的主办组织（也称为管理者或受托者）。
根据现行做法，在这个多步骤流程中，一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。
咨询了哪些利益主体或其他相关方？
在评估授权申请期间， ICANN 工作人员咨询了申请人、当前运营商（如适用），以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例， ICANN 尚未对此问题进行公开的咨询。
机构群体提出了哪些担心或问题？
所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理，将在 IANA 网站 http://www.iana.org/ 上发布该报告，通常是在理事会作出决定后的 1 到 2 个月后。
理事会审核了哪些重要材料？
理事会依据各种公众利益标准来评估申请。
此类标准包括：确保国家或地区代码合法（例如在 ISO 3166-1 标准中列出）；确保当地互联网群体支持提议的管理者；确保提议的运营商在运作及技术方面有足够能力；确保提议的管理者以当地为基础并且受当地法律制约；确保提议的管理者秉承公平的运营原则；确保当发生运营方变更时存在一个适当的计划，能够保持域名的持续稳定性；并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间，会要求申请人提供各种材料来支持上述各方面。
来自这些材料及其他工作人员研究的相关信息结果将提交给理事会，并在实施获批申请后在一份公开报告中发布这些信息。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。
是否会对机构群体产生积极或负面影响？
及时批准符合各种公共利益标准的国家或地区代码域名管理者对于 ICANN 整体工作会有积极影响，对于该域名所服务的当地机构群体也会有积极作用。
对于 ICANN （战略规划、运营计划、预算）、机构群体和 / 或公众是否会产生财务影响或后果？
管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责，授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责， ICANN 负责确保运营商总部位于该国，并有相应的机制允许当地互联网群体适当监督域名的持续运营。
是否有与 DNS 相关的任何安全性、稳定性或灵活性问题？
对于国家或地区代码顶级域名授权， ICANN 倾向于只批准此类申请：令人满意地解决了有合理理由担心的问题，并且提议的新管理者展示出足够高的运营和技术能力水平，使这些问题不会成为担心的问题。
-
批准授权以阿拉伯语表示阿拉伯叙利亚共和国的域名 .سورية ("Sourya")
目前 ISO 3166-1 标准中列出的是 Syrian Arab Republic ；
.سورية ("Sourya") 的编码为 "xn--ogbpf8fl"，被视为是通过 IDN 快速通道流程表示阿拉伯叙利亚共和国的合适字符串。
ICANN 收到了将 .سورية 授权给国家网络服务局 (National Agency for Network Services) 的申请；
ICANN 在审核此申请后，认为提议的授权会符合当地和全球互联网群体的利益。
第 2011.01.25.18 号决议： 批准将域名 .سورية ("Sourya") 授权给国家网络服务局 (National Agency for Network Services) 的提议。
2011.01.25.18 号决议理由
为什么理事会现在要解决此问题？
如果工作人员认为申请人提供的国家或地区代码域名的授权和重新授权申请足够全面完整，有获得理事会批准的前景时，会将其申请提交给理事会进行审批。根据 ICANN 对于及时处理与 IANA 职能（尤其是 DNS 根区域）相关的请求的承诺， ICANN 理事会将尽力在其下次安排的特殊会议上评估此类申请。
讨论的提议是什么？
提议是批准向 IANA 提交的一项申请，请求变更或指定某个国家或地区代码顶级域名的主办组织（也称为管理者或受托者）。
根据现行做法，在这个多步骤流程中，一个步骤是 ICANN 理事会参与决策是否继续处理此类申请。
咨询了哪些利益主体或其他相关方？
在评估授权申请期间， ICANN 工作人员咨询了申请人、当前运营商（如适用），以及其他直接相关的各方。根据 ICANN 关于对不完整的根区域变更申请进行保密的惯例， ICANN 尚未对此问题进行公开的咨询。
机构群体提出了哪些担心或问题？
所有担心或问题在将与此举措一起发布的公开报告中提出。如果根区域变更申请成功完成了最终处理，将在 IANA 网站 http://www.iana.org/ 上发布该报告，通常是在理事会作出决定后的 1 到 2 个月后。
理事会审核了哪些重要材料？
理事会依据各种公众利益标准来评估申请。
此类标准包括：确保国家或地区代码合法（例如在 ISO 3166-1 标准中列出）；确保当地互联网群体支持提议的管理者；确保提议的运营商在运作及技术方面有足够能力；确保提议的管理者以当地为基础并且受当地法律制约；确保提议的管理者秉承公平的运营原则；确保当发生运营方变更时存在一个适当的计划，能够保持域名的持续稳定性；并确保举措遵循任何适用的当地法律法规。在工作人员整理申请期间，会要求申请人提供各种材料来支持上述各方面。
来自这些材料及其他工作人员研究的相关信息结果将提交给理事会，并在实施获批申请后在一份公开报告中发布这些信息。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家或地区代码域名授权基本原则相关的因素。
是否会对机构群体产生积极或负面影响？
及时批准符合各种公共利益标准的国家或地区代码域名管理者对于 ICANN 整体工作会有积极影响，对于该域名所服务的当地机构群体也会有积极作用。
对于 ICANN （战略规划、运营计划、预算）、机构群体和 / 或公众是否会产生财务影响或后果？
管理 DNS 根区域中的国家或地区代码授权属于 IANA 的一项职责，授权工作不应对预定的预算开支产生重大影响。评估国家或地区代码顶级域名的内部运作在国内产生的财务影响并不是 ICANN 的职责， ICANN 负责确保运营商总部位于该国，并有相应的机制允许当地互联网群体适当监督域名的持续运营。
是否有与 DNS 相关的任何安全性、稳定性或灵活性问题？
对于国家或地区代码顶级域名授权， ICANN 倾向于只批准此类申请：令人满意地解决了有合理理由担心的问题，并且提议的新管理者展示出足够高的运营和技术能力水平，使这些问题不会成为担心的问题。
-
批准授权以 各种 语言表示印度的七个顶级域
目前 ISO 3166-1 标准中列出的是 India ；
编码为 “ xn--h2brj9c ” 的 भारत ("Bharat") 、编码为 “ xn--mgbbh1a71e ” 的 بھارت ("Bharat") 、编码为 “ xn--fpcrj9c3d ” 的 భారత్ ("Bharat") 、编码为 “ xn--gecrj9c ” 的 ભારત ("Bharat") 、编码为 “ xn--s9brj9c ” 的 ਭਾਰਤ ("Bharat") 、编码为 “ xn--xkc2dl3a5ee0h ” 的 இந்தியா ("Bharat") 和编码为 “ xn--45brj9c ” 的 ভারত ("Bharat") 被视为是通过 IDN 快速通道流程表示印度的七个合适字符串 ；
ICANN 收到了将上述七个字符串作为顶级域授权给印度国家互联网交换中心 (National Internet Exchange of India) 的请求 ；
ICANN 审查了此请求 ， 并确定提议的授权符合地方和全球互联网群体的利益。
第 2011.01.25.19 号决议 ： 批准将上述七个顶级域授权给印度国家互联网交换中心 (National Internet Exchange of India) 的提案。
第 2011.01.25.19 号决议 的 理由
为什么理事会现在要解决此问题 ？
如果工作人员认为申请人提供的国家代码域的授权和重新授权请求足够全面完整，有获得理事会批准的合理预期，就会将此请求提交给理事会审批。根据 ICANN 对及时处理与 IANA 职能 （ 尤其是 DNS 根区域 ） 相关请求的承诺 ， ICANN 理事会将力争在下次安排的特别会议上评估此类请求。
正在考虑的提案是什么？
提案是批准 IANA 职能部门更改或指定某个国家代码顶级域主办组织 （ 也称为管理者或受托者 ） 的请求。
根据现行做法 ， ICANN 理事会将参与决策来继续处理此类请求 ， 作为这个多步骤流程的其中一步。
咨询了哪些利益主体或其他各方？
在评估授权申请过程中 ， ICANN 工作人员咨询了申请人、当前运营商 （ 如适用 ）， 以及其他直接相关的各方。根据 ICANN 对未完成的根区域更改请求保密的实务 ， ICANN 尚未对此问题进行公开咨询。
机构群体担心或提出了哪些问题？
将在与此行动一起发布的公开报告中提出所有担心的问题。 如果根区域更改请求成功完成了最终处理 ， 将在 IANA 网站 http://www.iana.org/ 上发布该报告 ， 通常是在理事会做出决定后的 1 到 2 个月 。
理事会审查了哪些重要材料？
理事会依据各种公众利益标准来参与评估请求。
此类标准包括 ： 确保国家代码合法 （ 例如在 ISO 3166-1 标准中列出 ）； 确保地方互联网群体支持提议的管理者 ； 确保提议的运营商有足够的运营和技术能力 ； 确保提议的管理者以地方为基础并受地方法律约束 ； 确保提议的管理者公平公正地运营 ； 确保在发生运营移交时有适当的计划来保持域的持续稳定性 ； 以及确保行动遵守任何适用的地方法律和法规。在工作人员处理请求期间，会要求申请人提供各种材料来支持上述各方面。
从这些支持材料和其他工作人员研究得出的相关信息将提供给理事会，并在获批请求实施结束时发布在公开报告中。
理事会认为哪些因素很重要？
理事会将考虑公开报告中描述的与之前介绍的国家代码域授权基本原则相关的因素。
对机构群体产生积极影响还是负面影响 ？
及时批准符合各种公共利益标准的国家代码域名管理者对 ICANN 的整体使命和国家代码顶级域服务的地方机构群体均有积极影响。
是否对 ICANN （ 战略计划、运营计划、预算 ） 、机构群体和 / 或公众产生财政影响或后果 ？
管理 DNS 根区域中的国家代码授权是 IANA 的职责 ， 授权行动不应对预算的开支产生重大影响。评估国家代码顶级域内部运营在国内产生的财政影响不是 ICANN 的职责 ， ICANN 负责确保运营商以国家为基础 ， 并有适当的机制让地方互联网群体适当监督域的持续运营。
是否存在与 DNS 相关的任何安全性、稳定性或灵活性问题 ？
对于国家代码顶级域授权 ， ICANN 力求只批准此类请求 ： 令人满意地解决了有理由担心的问题 ， 并且提议的新管理者已充分展示出高水平的运营和技术能力 ， 使这些问题最小化。
按照单次投票批准认可议程项目的方式批准了第 2011.01.25.01 、 2011.01.25.02 、 2011.01.25.03 、 2011.01.25.04 、 2011.01.25.05 、 2011.01.25.06 、 2011.01.25.07 、 2011.01.25.08 、 2011.01.25.09 、 2011.01.25.10 、 2011.01.25.11 、 2011.01.25.12 、 2011.01.25.13 、 2011.01.25.14 、 2011.01.25.15 、 2011.01.25.16 、 2011.01.25.17 、 2011.01.25.18 和 2011.01.25.19 号决议。所有出席的理事会成员一致批准了这些决议。
Ram Mohan 感谢 Steve Crocker 和 Ray Plzak 为 SSAC 提供的服务 ， 并对他们引导 SSAC 取得目前的成就所做的工作致以诚挚的谢意。
主席同意 Ram 的意见 ， 并向理事会指出 ， 应主席的要求 ， Steve 在整个组织审查周期内继续担任 SSAC 主席。主席指出 ， 感谢 Steve 和 Ray 为 SSAC 提供服务的决议在一片掌声中通过。
-
主要议程
-
批准 更 改 由 支持组织 和 网络普通用户选 出 的理事会成员 的 任期结束日期的章程修正 案 提案
主席介绍了对章程提议的更改：使支持组织和网络普通用户机构群体任命的理事任期结束（任职 9-15 个月）与 ICANN 会议相符，以便进行交接。此建议是通过理事会审查工作组建议提出的。目前的交接周期处于两次会议之间，该建议将允许更好地移交工作。发布了提议的章程修订内容以征询公众意见 ， 并延长了意见征询期 ， 此后才会将修订意见提交给理事会批准。主席指出 ， 虽然 SO 任命的理事不必投弃权票 ， 但他明白某些成员可能选择对该项目投弃权票。主席随后请求通过提名委员会任命的理事会成员提出并支持此决议。
Steve Crocker 提出此决议且 George Sadowsky 支持此决议。
主席鼓励大家开展讨论。
Sébastien Bachollet 询问 ， 相对于提案中确定的八个月限期 ， 为何该建议不考虑在年度全体会议九个月内的某次会议上进行交接的可能性。 Sébastien 指出 ， 在某些情况下 ， 虽然在八个月期间内没有召开会议 ， 但在九个月期间内会召开会议 ， 增加一个月并没有多大区别。 Sébastien 还指出 ， 他将对此项目投弃权票 ， 因为如果此项目得到批准 ， 将会影响他的任期长度。
Amy Stathos 解释说机构改进委员会已将此问题提交给理事会监管委员会 (BGC) 予以实施 ， BGC 讨论了将交接时间范围届定为六到九个月而不是六到八个月的可能性。 BGC 认为 AGM 过后八个月是交接前应经历的最大时限。如果在八个月时间范围之外召开了年中会议 ， 任期将按照目前的做法在 AGM 闭会后六个月进行交接。
主席指出 ， 实施此建议的流程是持续性的 ， 我们应该持续考虑。
理事会随后采取了以下行动 ：
章程目前要求并非由提名委员会 (NomCom) 选出的所有即将就任的 ICANN 理事会成员于上一年的年度全体会议 (AGM) 后在理事会任职六个月。
上一年的年度全体会议之后的六个月通常介于两次 ICANN 国际公开会议 （“ 会议 ”） 之间。
理事会审查工作组 (BRWG) 建议 [PDF, 299 KB] 并非由提名委员会任命的理事会成员在年中会议上就职 ， 以促进理事会成员的顺利交接。
理事会监管委员会 ("BGC") 考虑了此问题 ， 同意 BRWG 的理由 ， 但确认年中会议并非经常召开 ， 因此建议修改 BRWG 的建议 ， 以便让新理事及时就职。
反映 BRWG 建议的提议章程修正案发布在 http://www.icann.org/en/public-comment/public-comment-201012-en.htm#bylaws-amend-article-vi8 ， 在两个月内 （ 2010 年 11 月 8 日至 2011 年 1 月 8 日 ） 征询公众意见。
在公众意见征询期内，只收到了一条公众意见，表示支持提议的修正案。
第 2011.01.25.20 号决议 ： 理事会批准提议的必要章程修正案 ， 以促进由支持组织或网络普通用户机构群体选出的理事会成员的交接。
九位理事会成员投票支持第 2011.01.25.20 号决议。主席、 Sébastien Bachollet 、 Rita Rodin Johnston 、 Gonzalo Navarro 、 Ray Plzak 、 Mike Silber 和 Bruce Tonkin 对该决议投弃权票。决议已通过。
第 2011.01.25.20 号决议的理由
在 ICANN 理事会的波士顿咨询组 (BCG) 独立审查 ( http://www.icann-ombudsman.com/en/reviews/board/report-02nov08-en.pdf [PDF, 921 KB] ) 后，成立了理事会审查工作组 (BRWG) 来帮助确定关于实施 BCG 建议的可行性。 BRWG 在召开多次会议并进行大量电子邮件沟通和文档分析后 ， 于 2010 年 1 月发布了《最终报告》 ( http://www.icann.org/zh/reviews/board/board-review-final-26jan10-zh.pdf [PDF, 299 KB] ) 。理事会考虑的一项 BRWG 建议是，在 ICANN 中期会议上使并非提名委员会选出的所有理事会成员就职。理事会相信，在针对可能不召开中期会议的情况进行少量修改后， BRWG 的建议就很合理了，可进一步确保理事会成员的顺利交接。从机构群体收到的唯一一条意见来自 ALAC ，表示支持提议的章程修正案。（请参阅 http://forum.icann.org/lists/bylaws-amend-article-vi8/msg00000.html “关于理事会成员任期交接的提议章程修正案符合 ALAC 与交接相关的理念。因此 ALAC 对这些修正案表示欢迎和支持。”）
理事会预计这将产生积极的公众影响，因为通常新理事会成员将在会议结束时就职，这就允许即将离任的理事会成员在该次会议结束时结束任期。设立交接期间比在两次理事会会议之间更改任期能更顺利地进行交接。即将离任的理事会成员将能完成工作周期，即简要了解然后处理有待于在下一次会议上讨论和决定的问题。同样，新理事会成员将能在任期开始时从头处理后续问题。
理事会的此项决策可能对 ICANN 产生少许的财务影响 ， 因为需要支付即将离任和继任的理事会成员参加交接会议的差旅和住宿费用。但根据目前的组织结构，需要为不超过四位理事会成员支付额外费用，通常会更少。可能需要支付的额外差旅费用金额不可能对预算或机构群体产生影响。理事会认为这不会对 DNS 的系统安全性、稳定性和灵活性产生影响。
-
批准 VeriSign RSEP （ 针对 .NAME ） 对发布全数字型字符串和带连字符的数字型字符串的请求
主席要求 George Sadowsky 陈述此项目 ， 因为 George 请求将其从认可议程中删除。
George 声明 他 已经看过 关于 .NAME 和 .TEL 的 请求 材料 ， 并指 明 他支持 .TEL 请求 ， 但反对 .NAME 请求。 George 指出这些是使用现有规则建立的商业性 TLD ， 其中 包括二者都不能有全数字型名称的规则。 对于 .TEL 请求 ， George 指出他明白该请求要扩展一位以上的数字型名称 ， 但不明白在可以注册数位的仲裁字符串时 ， 如何使 .NAME 内的用户不会混淆。这将导致直接混淆 .NAME 与 .TEL 之间的用户 ，且 它仅适用于 .TEL 。
主席请求 George 阐述可能发生的混淆 ， 因为许多其他 TLD 已能够有数字型字符串 ， 因此 ， 为何在 .NAME 中使用全数字型字符串时要特别关注混淆情况。
George 回应说用户不能从语义上搞清楚数字后面跟的 .NAME 扩展名是什么意思 ； 它可能是个电话号码 ， 也可能不是。
主席重申 ， 其他 TLD 中已存在相同的可能性 ， 但并不存在混淆的风险。
George 确定他仍然认为有关 .NAME 的请求存在混淆的风险。
Mike Silber 指出 ， 他并不关注任何注册管理机构申请的详细信息 ， 而是如 Tim Ruiz 所指出的 ， 他关注的是通过 RSEP 修正案流程处理这些请求的流程。 Mike 指出 RSEP 流程可能不适用于这种类型的更改 ， 并且他更愿意工作人员对这种类型修正案的适当机制提出建议。
Suzanne Woolf 对 George 提出的问题进行了一些说明。商业性 TLD 背后隐含的理念是可从名称推断出某种意思 ； 并不是平等创建所有 TLD 。有些概念在一个 TLD 中可以很好地实现 ， 但用在另一个 TLD 中则会引起混淆 ， 因为人们对扩展名含义的理解有差异。 Mike 关于存在流程问题的建议是正确的 ， 但是商业性 TLD 理念无法在长期实践中解决这个问题的情况也可能存在。
Bruce Tonkin 声称 .NAME 是受限制的 TLD ， 并非商业性 TLD 。
主席指出，当注册管理机构力求更改可能是运营的基础性条件时，两者可能并无实质差别。主席指出 ， 他认为 .TEL 请求没有问题 ， 仅认为 .NAME 请求有问题。如果关键元素是名称的定义 ， 那么现在正在更改定义。主席指出他批准一些能够促进企业发展和商业增长的流程 ， 但必须符合政策。主席指出理事会可能将此项目单独提出来展开进一步讨论，并要求以建立评估此种类型的更改框架为工作导向。主席指出理事会并非试图阻碍发展 ， 而是确保有清晰的途径以产生可预测的结果。
Bruce 阐述了 .TEL 和 .NAME 的概念。 .TEL 与其他 sTLD 一样 ， 是通过 ICANN 理事会将政策制定责任授权给主办组织而建立的。在此基础上 ， 批准 .TEL 更改是合理的 ， 因为它是由主办组织提出的 ， 并且从技术上来说也不存在强烈反对的理由。 .NAME 则不同 ， 因为政策管理本质上是由 ICANN 负责的。它们已请求进行更改，并且已为此发布了通知并征询公众意见。 Bruce 指出 ， 除非有机构群体担心通过该流程提出的更改有问题 ， 否则他倾向于批准该请求 ， 因为这与其他更开放 TLD 中的流程一致。其他 TLD 能分配数字型字符串 ， 所以可能没有理由在这里加以限制。
Kurt Ritz 对公众意见征询期进行了总结 ， 在此期间收到了四条意见 ， 包括一条反对意见。该反对意见对数字如何处理商标所有者的权利保护问题提出了质疑。这些意见和此更改是否会改变 .NAME 章程性质的问题都提交给了 VeriSign ， 它对这些问题做出了回应。相关信件已提供给理事会。已对此申请考虑了一段时间。
主席认为该回应并未陈述在注册管理机构中进行基础性更改的差异。
Sébastien Bachollet 指出这是个重大更改 ， 还指出以数字表示我们的名称 （ 例如护照号码 ） 存在的问题。他表示自己不会同意此更改。
在理事会询问时 ， 大多数理事表示他们希望推迟考虑 .NAME 请求 ， 以便留出更多的考虑时间。
理事会讨论了与发布全数字型字符串相关的 VeriSign 对 .NAME 的请求和 RSEP 对 .TEL 的请求 ， 还讨论了理事会考虑每个请求时可能存在的差异。
主席询问了理事会 ， 理事会认为大多数理事希望推迟对 .NAME 请求的进一步讨论 ， 以便留出更多的考虑时间。主席指出，理事会可以跟进工作人员关于此项目的任何问题，并要求秘书处将此项目推迟到下一次理事会会议的议程中。
-
批准 Telnic RSEP 对发布 除单字符标签 以 外 的全数字型 字符串的 请求
主席接下来询问理事会是否推迟考虑 .TEL 请求。大多数理事会成员表示准备投票决定此问题。
然后 ， 主席提出此决议并得到 Bruce Tonkin 的支持 ， 理事会接下来采取了以下行动 ：
Telnic 根据 ICANN 注册管理机构服务评估政策提交了一份请求 ， 即请求修正 .TEL 注册管理机构协议 ， 以允许在 .TEL 中分配全数字型 （ 单位数字除外 ） 域名。
.TEL 是目前仅有的两个不允许分配全数字型域名的 gTLD 之一。
ICANN 根据注册管理机构服务评估政策将 .TEL 注册管理机构协议的提议修正案作为新注册管理机构服务进行评估后 ， 未发现任何安全性、稳定性或竞争问题 ， 并发布了修正案以征询公众意见 ，并 供理事会考虑 （ 请参阅 http://www.icann.org/en/announcements/announcement-14oct10-en.htm ） 。
在公众意见征询期内以及由 ICANN 提出的潜在问题已通过 Telnic 的回应得到妥善解决。
批准该提案是对注册人在 .TEL 中注册名称时可用选项的补充。
第 2011.01.25.21 号决议 ： 批准旨在允许在 .TEL 中分配全数字型 （ 单位数字除外 ） 域名的修正案 ， 并授权总裁和总顾问适当采取行动来实施此修正案。
十二位理事会成员已经投票支持第 2011.01.25.21 号决议。 Sébastien Bachollet 、 Bertrand de La Chapelle 、 Rita Rodin Johnston 和 Mike Silber 对此决议投弃权票。决议已经通过。
Thomas Narten 请求修改提议理由 ， 以包含关于在 TLD 中引入单字符名称的某些历史信息 ， 主席和 Bruce Tonkin 确认了此请求。工作人员同意在与提议的会议记要一同提交给理事会的理由陈述中提供更多信息。
第 2011.01.25.21 号决议的理由
为什么理事会现在要解决此问题？
2010 年 10 月 8 日， Telnic 根据 ICANN 注册管理机构服务评估政策提交了一份请求，即请求修正 .TEL 注册管理机构协议，以允许在 .TEL 中分配全数字型（单位数字除外）域名。 ICANN 建议 Telnic 有必要修正附录 6 “ 保留名称的安排 ” 和附录 S “ 章程 ” 来实施新服务。 ICANN 认为该修正案是对注册管理机构协议的重大更改 ， 因此 ， 必须由理事会考虑。 Telnic 在 2010 年 8 月 11 日提交了关于分配单字符和双字符 ASCII 名称的 RSEP 请求 ， 该请求在 2010 年 11 月 18 日获得批准。
正在考虑的提案是什么 ？
理事会考虑了是否批准提议的修正案 ， 即是否允许在 .TEL 中分配全数字型 （ 单位数字除外 ） 域名。
咨询了哪些利益主体或其他各方 ？
提议的修正案在 2010 年 10 月 14 日至 2010 年 11 月 13 日期间征询公众意见 ； 收到了四条意见 ， 一条表示支持 ， 一条未陈述提案的优点但提出了改进建议 ， 还有一条提出了潜在问题 ， 最后一条是 Telnic 的回应。 ICANN 要求 Telnic 处理公众意见论坛中出现的问题以及由 ICANN 提出的问题 ， 为此 ， Telnic 和 .TEL 委托的政策制定权威机构 “ IPAG ” 针对每个问题向 ICANN 分别提交了一封信。
单字母域名的历史是怎样的 ？
正如 2007 年 5 月 23 日 GNSO 的保留名称工作组最终报告 （“ RN-WG 报告 ”） 中所述 ，“ 保留单字符的最初目的似乎是为了解决技术问题 ”，该 报告得出的 此 结论已不再适用。技术问题基本上集中于在第二级上保留单字母字符串，以便将来扩展名称空间。根据此结论 ， RN-WG 报告建议 “ 单一字母和数位发布在未来 gTLD 的第二级上 ， 并且目前保留在现有 gTLD 中的单一字母和数位也应发布出来 ” 。 RN-WG 报告发布在 http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm 上。
自从 RN-WG 于 2007 年发布报告后 ， 与 ICANN 签订合同的十七家通用顶级域名注册管理机构中 ， 有八家 （ 即 ： .BIZ 、 .COOP 、 .INFO 、 .JOBS 、 .MOBI 、 .PRO 、 .TEL 和 .TRAVEL ） 已 （ 通过 RSEP 请求 ） 力争 在第二级上发布单字符名称 ， 且已经 获得批准。 已批准分配这些之前保留名称的注册管理机构正在通过请求提案、拍卖和先到先得等机制加以实施。
有人在公众意见论坛中提出了以下问题 ： 1) 提案能否构成对 TLD 的基础性更改 ； 以及因此 2) 是否跟进了委托的政策制定权威机构。
理事会审查了哪些重要材料 ？
考虑提议的修正案时 ， 理事会审查了下列材料 ： Telnic 提交的关于新注册管理机构服务的请求 <http://www.icann.org/en/registries/rsep/telnic-request-08oct10-en.pdf> [PDF, 33 KB]； 理事会决议的提议修正案主题 <http://www.icann.org/en/tlds/agreements/tel/proposed-tel-amendment-2-14oct10-en.pdf> [PDF, 65 KB]； 与修正案相关的公众意见 <http://forum.icann.org/lists/tel-numeric-only-domains/> ； .TEL 的 IPAG 提交的关于解决所提问题的信函 <http://www.icann.org/en/registries/rsep/conroy-to-pritz-25nov10-en.pdf> [PDF, 644 KB] ； 以及 Telnic 提交的关于解决所提问题的信函 <http://www.icann.org/en/registries/rsep/mahdavi-to-schwartz-07jan11-en.pdf> [PDF, 80 KB]。
理事会认为哪些因素很重要 ？
-
ICANN 根据 RSEP 对提议的服务进行了阈值安全性、稳定性和竞争审查 ， 且并未发现任何重大问题。全数字型名称已在 14 个 gTLD 和多个 ccTLD 中使用多年 ， 没有对互联网的安全性或稳定性造成不良影响。单纯从技术角度而言 ， 哪些 TLD 允许使用全数字型名称并无差别 ， 因此该提案不会产生任何新问题。 ICANN 建议 Telnic 有必要修正附录 6 “ 保留名称的安排 ” 和附录 S “ 章程 ” 来实施新服务。
此外 ， RN-WG 关于新 gTLD 的建议 （ 在上文历史部分中已指出 ） 还包括应根据技术方面的要求将单字符和双字符的 全 数字型字符串保留在顶级上。 RN-WG 进一步指出 “ 如果日后通过充分研究表明所担心的技术问题已得到解决 ， 便可以重新考虑发布保留状态的主题 ” 。 RN-WG 建议还包括在未来 gTLD 的第二级中发布这些名称 ， 以及目前保留在现有 gTLD 中的那些名称也应该发布出来。 RN-WG 未提及超过两个字符的全数字型字符串 ， 因为在大多数 gTLD 注册管理机构中已允许使用此类字符串 ， 并且未发生技术问题。对全数字型字符串有所限制的注册管理机构可在与 ICANN 签订的《注册管理机构协议》中作为合同元素约定注册管理机构可自主决定这么做。
-
提议的修正案在 2010 年 10 月 14 日至 2010 年 11 月 13 日期间征询公众意见 ； 收到了四条意见 ， 一条表示支持 ， 一条未陈述提案的优点但提出了改进建议 ， 还有一条提出了潜在问题 ， 最后一条是来自 Telnic 的回应。在意见征询期内没有对是否应批准修正案形成清晰一致的观点；每个提意见的人建议的途径各不相同，并指出了上文描述的某些问题。
-
来自 Tim Ruiz （ 注册服务商 GoDaddy.com, Inc. ） 的意见表明该提案可能会从根本上改变 TLD 的目的。 Ruiz 进一步补充说 ， Telnic 承诺不允许全数字型二级注册是其申请的基础方面 ， 也是 .TEL 被判定给 Telnic 而不是 Pulver （ 当时的另一个 .TEL sTLD 竞标方 ） 的主要原因。 他的结论是 ， 如果要同意此请求 ， 必须要求重新竞标 .TEL sTLD ， 为其他机构提供竞标的机会。
-
Telnic Limited （ .TEL 注册管理机构 ） 的 CEO Khashayar Mahdavi 提交了对 Tim Ruiz 意见的回应。他声称 ， 该提案不是对 .TEL 的性质进行基础性更改 ， 因为对全数字型字符串的限制与 .TEL 的性质无关 ， 而是一种现行措施 ， 旨在解决最初担心可能与 ENUM 发生冲突的问题。 他说 ， 根据《章程》中的描述 ， .TEL 的用途是为希望使用 TLD 在 DNS 中存储和发布联系信息的用户机构群体提供服务。
-
应 ICANN 的要求 ， .TEL 的政策制定机构 IPAG 在 2010 年 11 月 25 日提交的信函中提供了更多信息 ， 解释了执行 RSEP 请求所遵循的政策制定和批准流程。
-
IPAG 主席 Lawrence Conroy 是公认的 ENUM 专家 ， 他在这封信函中解释了该提案不会产生 ENUM 技术问题的原因。 Conroy 宣称 “ 在此提议中 ， 将会保留单位数字标签 （ 例如 1.tel 或 4.tel ）， 而不是继续申请一律禁止的全数字型标签 （ 例如 3663.tel ）； 这样做没有必要 ， 也没有用。 通过阻止所有单位数字标签 ， ENUM 树的根不能直接放置在 .tel 中。 ENUM 只是对多位数字的标签不起作用。 Telnic 过去没有且现在也不打算启动任何 ENUM 替代方案 ， 并与 ICANN 达成了关于 .tel 此项规定的长期有效协议。 ” （ 此信件包含在附录中 ） 。
-
应 ICANN 的要求 ， Telnic 在 2011 年 1 月 7 日提交的信函中解释了他们为何相信该提案不会在 .TEL 下的全数字型名称与可能被视为相应电话号码的数字之间引起混淆。 Telnic 指出以前并未发生此问题 ， 并且有适当的工具可以处理实际用户混淆和 / 或误解的情况 ， 此外 ， 其他 TLD 已提供了此类名称 ， 也未受到限制或发生问题。最后 ， Telnic 表示 ， 如果确实会发生用户混淆问题 ， 他们的 IPAG 也有足够的资质来解决可能发生的任何问题。
-
.TEL 是被禁止分配全数字型域名的两个 gTLD 之一。通过批准该提案 ， .TEL 将在与其他 gTLD 的市场竞争中处于更有利的地位 ， 这也会相应地为注册人提供更多选择。
对机构群体产生积极影响还是负面影响 ？
通过批准提议的修正案 ， 允许 .TEL 提供与其他 gTLD 类似的服务 ， 将使 gTLD 市场竞争更激烈 ， 且更重要的是 ， 注册人将有更多的注册选择权。
是否对 ICANN （ 战略计划、运营计划、预算 ） 、机构群体和 / 或公众产生财政影响 / 后果 ？
批准此修正案对战略计划、运营计划、预算、机构群体或公众没有可预见的财政影响 / 后果。
是否存在与 DNS 相关的任何安全性、稳定性或灵活性问题 ？
根据《注册管理机构服务评估政策》对与修正案相关的提议服务进行了初步的安全性与稳定性审查。 ICANN 没有发现任何安全性、稳定性或竞争问题 ： http://www.icann.org/en/registries/rsep/arias-to-shadrunov-14oct10-en.pdf [PDF, 53 KB] 。
-
-
CEO 的报告
理事会收到了由 CEO 提交的针对喀他赫纳会议后的进展情况的报告。 CEO 感谢理事会对工作人员在向理事会 /GAC 征询意见之前所做的准备工作的认可。 CEO 还提供了硅谷 / 旧金山会议计划的更新版 ， 包括增加适用于该会议的赞助机会 ， 这样不但能进一步完善该事件 ， 而且能使 ICANN 的预算金额保持不变。
主席感谢 CEO 和工作人员将理由纳入理事会文件的工作 ， 以及 GAC 的顾问工作。
Bruce Tonkin 指出 ， 有机构群体对跳跃赞助等级的问题表示担心 ， 并询问针对硅谷 / 旧金山会议而引入的等级对于未来的 ICANN 会议是否仍保持不变。
CEO 指出 ， 赞助机会为企业提供了自我推广和构建品牌的手段 ， 也是支付 ICANN 会议成本和 / 或使 ICANN 会议升级的方式。 CEO 引用了完全自筹资金开会的 IGF 模式 ， 同时也承认 ICANN 会议有史以来就需要进行一定程度的融资并提供技术支持 ， 一贯如此。为了使硅谷会议升级，同时又不增加预算，于是创建了更高的赞助类别。主席指出 ， 在决定未来会议的赞助等级之前 ， 应对计划进行审查 ， 重点关注增加资金以减轻预算问题 ， 以及通过对所有各方都公平透明的方式进行操作。
Bertrand de La Chapelle 对与 IGF 进行比较提出了质疑 ， 特别是已知 ICANN 会议周期为每年三次 ， 而 IGF 会议则是每年一次。 Bertrand 提出的问题是关于赞助等级与向 ICANN 机构群体提交材料和活动的能力之间的 关 系 ， 以及赞助会议的行为是否属于商业活动。
CEO 声明他没有将 ICANN 会议视为商业活动 － 它们不是商业活动。而是那些希望通过赞助提高知名度的各方将赞助会议的行为视为商业活动。
主席指出 ， 提醒那些未赞助 ICANN 会议的各方仍需参加 ICANN 会议 ， 这一点很重要。
Ram Mohan 询问了支持 IDN 变体管理项目的工作人员资源安排问题。
CEO 指出 ， 已任命 Naela Sarras 接替 Tina Dam 担任 IDN 主管。 Naela 以前在 IANA 职能部门工作。 CEO 还指出 ， 在 IDN 变体管理项目的许多工作中将使用外部顾问。
Sébastien Bachollet 指出赞助可以代表政治和商业活动 ， 还指出需要考虑没有资金的各方可能也有一些项目要与机构群体分享。
CEO 声称提供给赞助方的特权应只是商业上的特权 ； 与 ICANN 政策工作以及 ICANN 和机构群体的其他活动无关。 CEO 要求理事会告诉他某些不应与赞助特权有关而实际上与赞助特权绑定的任何问题。
George Sadowsky 的问题是关于在 ICANN 会议安排中包含一次面向顶级赞助商的 90 分钟会议 ， 以及该会议可能如何干扰会议周内预先安排的其他事件。
CEO 确认 George 提出的发言人时段安排问题是一个重要问题 ， 应在定义亚洲会议的赞助机会之前进行审查。
Mike Silber 指出 ， 几年前做出了一项决定 ， 即不应只通过地方赞助商提供的资金召开会议 ， 并且不应将会议视为零成本的活动。如果要更改该决定，理事会委员会应参与到此项工作中。
CEO 声称并不打算将召开会议视为零成本的活动 ； 增加赞助机会将进一步完善会议 ， 并且对硅谷会议的赞助将补偿 Gala 的成本 ， 因为这是 ICANN 的责任。召开会议的成本在理事会批准的预算范围内。
主席指出此番交谈的重要性，还指出公众参与委员会可以解决许多此类问题。
Rita Rodin Johnston 指出 ， 机构群体中对更改赞助等级存在某些困惑 ， 并要求工作人员在将更改提交给会议时有更加清晰透明的解释。
CEO 指出 ， 随着组织变得更加专业 ， 有人担心 ICANN 的工作可能是为了获取利润 ， 这是一种误解。管理层的工作是为了运行世界级的非盈利组织 ， 如有任何相反的理解 ， CEO 愿意与理事会就此问题展开讨论。
-
战略计划
Kurt Pritz 简要介绍了战略计划工作的状态，预定在硅谷 / 旧金山会议上批准该计划。 Kurt 指出 ， 已电话咨询了 ccNSO 、 GNSO 和 ALAC ， 并制定了处理公众意见的加红线的草案。此外 ， 理事会工作组还会见了工作人员 ， 一起讨论对计划的更改 ， 包括更好地确定 ICANN 能控制结果的领域 ， 以及 ICANN 只能施加影响的领域 － 例如签署根的 TLD 数。其他更改是为了在每个部分中提供更加可度量的目标。增加了一些特定目标以及对术语的更好定义。为了完成关于战略计划的工作 ， 将对最近结束的公众意见进行审查 ， 并在硅谷 / 旧金山会议之前提交新版本。
-
理由文档
总顾问和秘书长提供了演示文稿，说明理事会考虑根据问题复杂性创建三级理由文档的工作，具体内容如本会议文件中所述。第一级是长篇详细说明 ， 如同交叉所有权理由那样 ， 用于确定所有项目 ， 作为决策一部分进行处理和对待。 .TEL 理由陈述是第二级陈述的一个示例 ， 它较为简洁。第三级陈述是关于更多行政管理问题或更容易考虑的问题，以较为简洁的形式说明决策的基础。总顾问和秘书长要求理事会继续提供关于如何改进这些文档的反馈。
George Sadowsky 要求阐述理由文档的用途。它们是直接表示决策，还是表示继续改进此项工作并欢迎提供反馈。理事会讨论了理由和会议记要之间的差异，还讨论了理由文档的范围，以便提交考虑的问题、查看的材料以及拒绝或接受项目的理由。
Rita Rodin Johnston 表示 ， 她明白理由陈述不是会议记要 ， 后者是记录讨论和投票情况的。理由陈述提供了理事会决策所依据的理由 － 理事会考虑了哪些文件 ， 理事会进行了哪些听证 ， 执行决策有哪些利弊 ， 以及其他相关项目。理由陈述不是为了记录特定理事会成员的想法或异议。
主席指出，理事会似乎一致同意理由的用途，但理事会执行的某些特定决策可能需要更多详细信息，例如经济研究方面的工作。 George 和 Rita 的观点都正确 ； 并不需要完全汇总每个问题 ， 但有时可能需要在理由陈述中提供更高级别的详细信息。主席确认组织将继续优化这种做法。
总顾问和秘书长指出 ， 在讨论提议的理由陈述时 ， 如果理事会指出缺少任何信息 ， 则应提供相应的信息。这些文件阐述了理事会大多数成员的观点。
主席确认，从总体上说，机构群体希望看到以下概要信息：考虑的问题、审查的材料，以及拒绝或接受项目的理由。各位理事的立场将记录在会议记要中。
-
经济 研究 － 采纳理由
总顾问和秘书长展示了为构建理事会行动的详细理由在新 gTLD 计划的经济研究方面所做的工作。由于理事会成员在理事会会议之前已提供了一些意见，因此需要注意可对文件进行某些改进。
主席鼓励大家展开讨论。
Katim Touray 要求理事会的决议明确说明这是理事会的理由陈述 ， 不是工作人员的陈述。
Sébastien Bachollet 和 Thomas Narten 表示他们已建议进行编辑更改。
Rita Rodin Johnston 指出提议的陈述大体上符合理事会的立场。
主席恳请理事会在编辑建议方面与总顾问合作，并询问了理事会可能希望讨论的高级别问题。主席恳请理事会在会后尽快向总顾问提供编辑意见。
总顾问确认会将所有意见处理到新版本中，并提交给理事会考虑，包括要最终完成理由陈述，以便发布在理事会的会议记要中。会议记要的初步报告将会指出，理由陈述仍在编辑过程中。
随后 ， 主席将话题转向提议的决议上 ， 指出需要一段时间对理由文本进行润色 ， Rita Rodin Johnston 表示支持。
Bertrand de La Chapelle 指出他已提议更改决议文本 ， 并讨论了他提议插入的内容。
Heather Dryden 要求 ， 采用任何决议都不表示将在硅谷会议上最终完成或批准《申请人指南》 ， 因为这 并 不是 GAC 所期望 的。
主席和 Rita 谨慎地表示 ， 任何决议都应重点关注与理事会的经济研究决策相关的理由 的批准 ， 并且不应超出此问题的范围。
Rita 随后提出的问题是 ， 如果在会议上批准了该决议 ，那么 将如何考虑在新 gTLD 经济研究第 2 阶段收到的公众意见以及来自 GAC 的建议。
主席确认虽然 ICANN 不会开展进一步的研究 ， 但它会认真听取根据已完成的研究提出的所有建议。
CEO 指出 ， 重要的是听取机构群体的意见 ， 了解他们是否要根据迄今为止已进行的研究提出更深入的见解。
主席向总顾问确认 ， 决议指出已在考虑理由 ， 并正在处理 ， 且将包含在会议记要中。
理事会随后采取了以下行动：
2010 年 12 月 10 日 ， 理事会确认 ， 要求进行经济分析这一首要问题已通过全面的专家咨询和分析 （ 包括 CRA 国际、 Dennis Carlton 、 Michael Katz 和 Greg Rosston 提供的报告 ） 得以解决。 http://www.icann.org/zh/minutes/resolutions-10dec10-zh.htm#2 。
2010 年 12 月 10 日 ， 理事会确认 ， 对于进行经济分析的要求 ， ICANN 正在接收和审查公众意见 ， 理事会也将考虑公众意见 ， 包括 GAC 的建议 ， 并指示工作人员进行更改 http://www.icann.org/zh/minutes/resolutions-10dec10-zh.htm#2 。
所有经济研究都确认了继续开放域名空间的总体收益，包括支持创新、拓展选择和营造更健康的竞争环境。
在申请人指南草案后续版本中通过机构群体意见引入详细规则和防卫机制，是一种妥当的方法，它可以尽量减少与实施此政策相关的成本，还可以优化域名空间作为全球公共资源的使用。
为了避免进一步推迟引起的机会成本 ， 现在的工作重点应该是在 2 月召开的理事会 -GAC 会议期间以及在 3 月召开的硅谷会议上机构群体互动交流时 ， 最终确定这些机制。
CEO 应继续确保工作人员考虑关于新 gTLD 经济研究阶段 II 的公众意见 ， 以及 GAC 关于要求进行经济研究的建议 ， 并对最终的《申请人指南》进行适当修订。
CEO 将认真考察实施时机并履行《义务确认书》中规定的 ICANN 义务 ： 如果新 gTLD 运营一年 ， ICANN 将组织一次审查 ， 以评估引入或扩展 gTLD 对竞争、用户信任和用户选择的提升程度 ， 并检查 (a) 申请和评估流程的有效性 ， 以及 (b) 用于减轻此类引入或扩展所涉及问题的现有防卫机制的有效性。
理事会考虑了做出此决策的理由，目前正在对理由进行修订，如果获得批准，将在本会议的会议记要中发布这些理由。
第 2011.01.25.22 号决议 ： 理事会在决定是否启动新 gTLD 计划之前不会委托进行关于新 gTLD 的任何进一步经济研究 ， 因为理事会认为这样做并不能为决策提供更好的依据。
十五位理事会成员投票支持第 2011.01.25.22 号决议。 Rita Rodin Johnston 反对该决议。决议通过。
Rita 认为理由和决议都很妥当 ， 但从监管的角度来说 ， 对仓促讨论决议背景的过程表示担心。此外 ， Rita 还提出了一个问题 ， 如前面所述 ， 对此问题征询公众意见刚刚结束 ， 理事会就根据这些意见通过了决议。
第 2011.01.25.22 号决议的理由
根据理事会的决议 ， 提供了在会议期间讨论的理由： http://www.icann.org/zh/minutes/rationale-economic-studies-21mar11-zh.pdf [PDF, 213 KB]
-
交叉所有权 － 采纳理由
理事会指出，所有以前关于此主题宣称的利益冲突仍然存在，有冲突的成员和联络员只要不参与讨论，就不必退出关于讨论的会议。
主席恳请对理由中的高级别问题展开讨论，并讨论提议的陈述是否会引起对互持所有权的争论。
George Sadowsky 指出他事先并不知道有提供意见的机会 ， 他没有机会提供可消除其反对意见的建议措辞。 George 表示他将投票反对该决议。
Sébastien Bachollet 请求在理由陈述中包含一些交叉所有权问题的历史 ， 例如包含 .COM 和 .NET 注册管理机构协议中的条款。
总顾问确认可以插入历史信息。
主席指出会后将有一段较短时间来提供关于理由陈述的措辞建议，并与会议的初步报告一起发布。
Katim Touray 针对决议提交了一些建议的修正案 ， 供理事会考虑。
Ray Plzak 提出的问题是 ， 为何理事会必须对理由投票 ， 以及为何公布的理由不够充分。 Ray 表示他将因该问题而对此决议投反对票。
主席指出 Ray 的立场似乎表明没有必要对理由投票 ， 但 Ray 并未表示反对理由的实际文本。
随后 ， 主席提出以下决议 ， 并得到 Steve Crocker 的支持 ：
2010 年 11 月 5 日 ， 理事会通过了关于新 gTLD 计划中注册管理机构与注册服务商之间交叉所有权问题的决议。 http://www.icann.org/en/minutes/resolutions-05nov10-en.htm .
理事会已审查并考虑了说明理事会决策的提议理由。
第 2010.01.25.23 号决议 ： 理事会采纳提议的理由作为理事会关于新 gTLD 计划中注册管理机构与注册服务商之间交叉所有权决策的理由。
九位理事会成员投票支持第 2011.01.25.23 号决议。 Ray Plzak 、 George Sadowsky 、 Katim Touray 和 Kuo-Wei Wu 反对该决议。 Sébastien Bachollet 、 Bertrand de La Chapelle 和 Bruce Tonkin 对此决议投弃权票。决议已经通过。
第 2010.01.25.23 号决议的理由
此处提供了理事会批准的理由： http://www.icann.org/zh/minutes/rationale-cross-ownership-21mar11-zh.pdf [PDF, 256 KB]
-
-
理事会 /GAC 咨询
-
咨询流程
总顾问和秘书长介绍了迄今为止为了建立向 GAC 咨询的提议流程所做的工作 ， 即首先在喀他赫纳会议后起草提案 ， 然后纳入理事会成员的修订意见来创建单个流程文档 ， 并指出关于流程形式还有后续讨论。
主席阐明了已成立理事会工作组来处理咨询事务 ， 包括确定主题领导者 ， 以及计划通过一系列电话来阐述对问题的立场。主席指出目标是在硅谷会议上实现向 GAC 进行《章程》咨询。主席解释说 ， 因为召开硅谷会议前在布鲁塞尔进行的咨询时间太短 ， ICANN 无法在旧金山会议上最终完成指南。
Heather Dryden 担心的是 ， 理事会似乎正在朝通过最终流程的方向前进 ， 而 GAC 则期望能对该流程的具体形式进行审查、加以评论并达成一致意见。 Heather 期望 GAC 对材料中提供的流程加以评论 ， 它将是 GAC 要做出回应的有用草案。 Heather 要求理事会对此项目采取的任何行动都能使 GAC 有机会影响和更改流程。
主席确认 ， 理事会不会设立一个通用流程然后试图在硅谷会议上使用该流程 ； 而会向 GAC 咨询 ， 这样有助于为将来制定出通用流程。主席指出 ， 理事会不打算推迟确定理想的咨询流程 ， 以便继续进行即将开始的《章程》咨询 ， 这对于 .XXX 和新 gTLD 是十分必要的。主席同意将提交给理事会的文档称为草案以允许 GAC 提供意见 ， 并指出在实际咨询过程中可能需要对草案加以改进。
Heather 回应说 GAC 可能会对提议的流程提供意见 ， 并且在首次咨询后对流程给予进一步优化会非常有用。但 Heather 质疑理事会对提议的流程采取行动是否会发出流程已确定这样的错误消息。
Ray Plzak 询问理事会是否会确定通用流程并将其仅用于首次咨询 ， 而不是期望该流程用于所有未来的咨询。
Heather 建议反对做出在首次进行《章程》咨询时使用目前形式提议流程的决定 ， 因为缺少 GAC 对流程的意见。
主席建议此议程项目仅供讨论 ， 且 Ray 和 Heather 同意 ， 只要关于流程形式的沟通还在继续进行 ， 此时就不必做出决议。主席同意将提议的流程发送给 GAC 作为理想化的版本。
Ray 和 Steve Crocker 确认主席的建议符合理事会存在的意义。
CEO 表示支持 Ray 的意见 ， 并阐明了工作人员对此项目的立场。虽然工作人员更希望对流程有较严谨的定义 ， 但在 Heather 对 GAC 问题的反馈中 ， 该定义还是较宽松的。需要的流程必须符合《章程》要求，并且可通过简要定义的流程来实现。在多种情况下 ，已 向理事会重复提交提议的流程。 CEO 指出 ， 他关注的是在布鲁塞尔通过清晰的流程实现富有成效的会议 ， 因为 ICANN 花费了近 50 万美元来安排此项活动。
总顾问支持 CEO 的观点 ， 并指出工作人员已准备了较严谨的流程备用版本 ， 可与理事会分享 ， 供其考虑并决定将哪个版本发送给 GAC 讨论。
Rita Rodin Johnston 支持总顾问关于分享其他版本的意见 ， 并要求理事会成员在决定将哪个版本发送给 GAC 之前有机会向工作人员发送对任何一个版本的意见。
主席同意 Rita 的建议 ， 这样就可以确定理事会在选择流程方面的意义。主席要求工作人员提供备用的措辞，然后理事会将处理完所有增加的措辞或意见。
-
新 gTLD
主席随后将话题转向关于新 gTLD 的 布鲁塞尔会议的具体问题上 ， 以启动在旧金山举办的布《章程》咨询。
Heather Dryden 指出 ， 提交给理事会的关于新 gTLD 的 布鲁塞尔会议提议流程的材料未得到 GAC 的认可 ， 并且她尚未看过该文档。虽然该文档反映了她与理事会主席之间的许多谈话内容 ，但是 仍有一些项目需要通过 GAC 进一步反映和优化。 Heather 认为应较早提供信息 ， 而不是将信息包含在整套理事会材料中 ， 而且由于 GAC 尚无机会审查这些材料并提供意见 ， Heather 请求不要发布这些文档。文档中有些观点并未在理事会和 GAC 之间达成共识。 Heather 还为理事会关于此主题的决议提议了一些备用文本 ， 以明确表示不会在硅谷会议上最终完成和批准《申请人指南》 ， 这与 GAC 的期望不符。虽然 GAC 不想对所有问题重启对话 ， 但它对《申请人指南》仍保留一些自认为重要的实质性问题。
主席确认只要 Heather 对决议的修正案可启动《章程》咨询 ， 就可以考虑该修正案。
Gonzalo Navarro 要求此启动《章程》咨询的修正案应表达得非常清晰。
总顾问应理事会的要求提供了文本。
主席提出以下决议 ， 并得到 Mike Silber 的支持 ：
ICANN 理事会和 ICANN 政府咨询委员会 (GAC) 安排了于 2011 年 2 月 28 日至 3 月 1 日在比利时布鲁塞尔召开的会议 （“ 布鲁塞尔会议 ”）， 以讨论 GAC 提出的关于新 gTLD 计划的各种具体问题 ， 如下所述 （“ 主题 ”）：
- 包括需要政府支付费用在内的异议程序 ；
- 审查敏感字符串的程序 ；
- 根区域调整 ；
- 市场和经济影响 ；
- 注册管理机构与注册服务商分离 ；
- 对权利所有者和用户的保护问题 ；
- 与政府之间的授权后争议 ；
- 地理名称的使用和保护 ；
- 申请人的合法资源 ；
- 为包括发展中国家利益主体在内的所有利益主体提供机会 ；
- 旨在根据布鲁塞尔公报修正《注册服务商委任协议》的执法尽职调查建议 ； 以及
- 需要提前通知申请人提议的字符串是否可能引起争议或导致敏感问题 （ 包括地理名称 ） 。
该会议不是《 ICANN 章程》第 XI 条第 2 款第 1(j) 段规定进行的咨询。
理事会希望在预定于 2011 年 3 月 13-18 日召开的 ICANN 硅谷 / 旧金山 ("SV/SF") 会议期间，启动《章程》规定的咨询工作。
理事会希望在 SV/SF 会议期间进行《章程》规定的咨询工作仅限于布鲁塞尔会议期间讨论的主题。
第 2011.01.25.24 号决议 ： ICANN 理事会特此决定 ， 尽可能按照《提议的最终申请人指南》中规定的形式 ， 逐步启动新 gTLD 计划。
第 2011.01.25.25 号决议 ： 理事会特此决定 ， 对上述目前不符合 GAC 建议的主题采取行动。
第 2011.01.25.26 号决议： ICANN 理事会特此启动《 ICANN 章程》第 XI 条第 2 款第 1(j) 段规定的咨询工作，该工作应在 ICANN SV/SF 会议期间于 2011 年 3 月 17 日星期四开始。
第 2011.01.25.27 号决议：启动的上述《章程》规定的咨询工作应仅限于布鲁塞尔会议上讨论的以下主题：理事会在会议期间或结束后没有改变立场，这仍不符合 GAC 建议。
所有出席的理事会成员批准了第 2011.01.25.24 、 2011.01.25.25 、 2011.25.26 和 2011.25.27 号决议。
Heather Dryden 重申了她所担心的问题 ： 不应公布理事会书籍中包含的流程 ， 因为这些文件表示各方目前一致同意的说法并不完全准确。如果这些文件没有加入 GAC 的意见和评论 ， 就不应该发布。
主席确认他和 Heather 会继续就此主题展开对话。
Sébastien Bachollet 随后询问可否增加差旅补助 ， 以便 ICANN 赞助组织和咨询委员会主席能出席布鲁塞尔咨询会议。
主席认为虽然使 SO 和 AC 主席在线参加会议会有帮助 ， 但主席往往不是确定要讨论的任何特定主题方面的权威人士 ， 咨询工作应侧重于专家的参与。主席就此主题对理事会进行了非正式的民意调查，结果许多成员反对这种意见。
主席指出，虽然初看起来这似乎是个好主意，但无法保证他们的立场会对争论有所贡献；只让他们出席会议却不发表任何意见，这样做似乎成本过高，并且没有多少收获。
Steve Crocker 对任何确实想出席会议的主席进行询问 ， 这样 ICANN 就不会给人留下他们有义务参加会议的印象。会议规模已经很庞大了。但 Steve 指出 ， 如果主席确实需要出席会议 ， 却无力承担费用 ， 设法提供某些帮助可能较为妥当。
Sébastien 声称他知道至少有三个人即使 ICANN 不提供差旅补助也会设法出席会议。 Sébastien 担心的问题是 ， 向机构群体表明 ICANN 将仅支持一部分机构群体。
Bruce Tonkin 指出 ， 仅邀请主席可能导致的问题比要解决的问题更多 ， 因为其他人也希望出席会议。整个会议将会改版。在布鲁塞尔不会做出任何决策。一般而言 ， GAC 咨询并不是与机构群体之间的对话 ， 而是对所有人公开的理事会与 GAC 之间的对话。
主席同意 Bruce 的意见 ， 强调布鲁塞尔会议不是机构群体咨询的这一观点。主席指出，虽然看似不会根据提议提供额外的差旅补助，但可以针对此项目继续进行更多的在线交谈。
第 2011.01.25.24 － 2011.01.25.27 号决议的理由
理事会和 GAC 都认为需要针对与提议启动新 gTLD 计划相关的待决问题进行咨询。双方都同意这是进行此咨询的正确时间。理事会将考虑 GAC 建议 ， 审查为会议准备的所有文件 （ 包括支持材料和参考 ） 。此外 ， 理事会还在发布和修订每个《申请人指南》版本的整个流程中 ， 针对 GAC 确定的问题咨询了所有利益主体。可在 GAC 喀他赫纳公报中找到将在布鲁塞尔会议上解决的 GAC 提出的特定问题。 http://gac.icann.org/press-release/gac-2010-communique-39 。
在理事会与 GAC 之间召开布鲁塞尔会议并进行《章程》咨询应该会对机构群体产生积极影响。这样可向整个机构群体保证，理事会将认真对待意见征询流程及其《章程》要求，并希望尽可能达成一致意见。
布鲁塞尔会议将对 ICANN 的预算产生重大财政影响 ， 因为召开会议需要额外的差旅、住宿、会议空间资源和相关费用。这些费用包括某些 GAC 成员、理事会成员、工作人员和其他可能出席会议的代表的开销。对未获得资金支持出席此次会议而又选择亲自出席会议的 GAC 成员也会产生某些财政影响。召开布鲁塞尔会议或进行《章程》咨询不会引起与 DNS 相关的安全性、稳定性或灵活性问题。
-
ICM
总顾问和秘书长提出的一项决议明确采纳了理事会的立场 ， 即这些问题是关于向 GAC 就 ICM 进行《章程》咨询。
主席确认 ， 该决议会授权转送一封信 ， 其中包含关于理事会针对此主题确定 GAC 建议的所有材料。
CEO 提出以下决议 ， 并得到 Katim Touray 的支持 ：
在哥伦比亚卡塔赫纳会议期间 ， 理事会表示同意工作人员的评估结论 ， 即 ： 如果理事会继续决定与 ICM 注册管理机构就 .XXX sTLD 签订注册管理机构协议 ， 可能会与 GAC 建议发生冲突 ， 因此启动了 GAC 咨询流程。请参阅 http://www.icann.org/zh/minutes/resolutions-10dec10-zh.htm#4 。
在卡塔赫纳会议期间 ， GAC 力求理事会对其在 ICM 相关项目上的立场表示肯定与支持。
为了使将来向 GAC 咨询尽可能富有成效 ， 理事会在附加文档中明确阐述了对 GAC 建议的所有项目的立场。
第 2011.01.25.28 号决议 ： 理事会指导工作人员向 GAC 提供文档 ， 充分阐述理事会对 GAC 建议项目的立场。阐述的理事会立场对应于在理事会 2010 年 10 月 28 日会议上确定咨询的项目。
十位理事会成员批准了第 2011.01.25.28 号决议。 Cherine Chalaby 、 Rita Rodin Johnston 、 Erika Mann 、 Rajasekhar Ramaraj 和 Kuo-Wei Wu 未能对该决议投票。 Sébastien Bachollet 对该决议投弃权票。
Bruce Tonkin 随后询问是否定义了针对 ICM 问题进行《章程》咨询的实际日期 ， 因为决议中未阐述此问题。
主席指出 ， 虽然早前 GAC 和理事会表示如果有时间将尽量在布鲁塞尔完成此定义 ， 但并未设定确切日期。
Bruce 向 ICM 礼貌地指出应该有某些时间安排上的指示。
CEO 提议指定 3 月 17 日进行 ICM 《章程》咨询 ， 并指出工作人员已准备提前进行此项工作。但如果在布鲁塞尔没有时间进行 ICM 咨询 ， 在硅谷会议之前召开额外的会议成本会非常高 ， 除非可以召开电话会议。
Bruce 认为仅有的两种实际选择就是在布鲁塞尔还是在旧金山 ， 并且 GAC 主席表示布鲁塞尔的议程已被新 gTLD 问题占满。 Bruce 建议应在旧金山正式安排此会议。
主席认为 ， 如果不一致的意见较少 ， 则针对 ICM 问题向 GAC 咨询的时间可能很短。主席随后接受了要求不晚于 3 月 17 日完成咨询的提案。
Heather Dryden 确认 ， 3 月 17 日就 ICM 进行咨询的意见已提交给 GAC ， 但她未收到关于此意见的反馈。虽然可能安排时间在布鲁塞尔继续进行 ICM 咨询 ， 但 Heather 认为 ， 鉴于时间表已排满 ， 实际上不可能这么做。
Bruce Tonkin 随后提出了以下决议 ， 并得到 CEO 的支持 ：
第 2011.01.25.29 号决议 ： ICANN 理事会特此决定 ， 在卡塔赫纳启动的《 ICANN 章程》第 XI 条第 2 款第 1(j) 段中规定的关于 ICM 的咨询不应晚于 2011 年 3 月 17 日星期四。
十位理事会成员批准了第 2011.01.25.29 号决议。 Cherine Chalaby 、 Rita Rodin Johnston 、 Erika Mann 、 Rajasekhar Ramaraj 和 Kuo-Wei Wu 未能对该决议投票。 Sébastien Bachollet 对该决议投弃权票。
第 2011.01.25.28 – 2011.01.25.29 号决议的理由
理事会在继续讨论 ICM 于 2010 年 10 月 28 日提出的关于 .XXX sTLD 的申请期间，确定了在理事会与 ICM 签订提议的《注册管理机构协议》之前需要向 GAC 咨询的领域，因为某些 GAC 建议可能与理事会期望的行动不一致。理事会向 GAC 咨询的义务是在《 ICANN 章程》第 XI 条第 2.1(j)-(k) 款中规定的 ， 理事会在卡塔赫纳会议上正式启动了咨询流程。为了使咨询尽可能富有成效 ， 也为了解决 GAC 担心的问题 （ 获知理事会对是否与 ICM 签订《注册管理机构协议》的立场与 GAC 建议不一致 ）， 附件中提供了更多的详细信息和具体的引用材料来支持理事会对各条 GAC 建议的立场。
提供全面的理事会立场文档可能会对公众产生积极影响。由于会继续围绕 .XXX sTLD 《注册管理机构协议》的预期批准进行讨论 ， 立场文档提供的详细信息和解释说明将使整个 ICANN 机构群体受益。提交此文档不会对 ICANN 、机构群体或公众产生任何财政影响 ， 但为了方便理事会与 GAC 之间进行讨论 ， 可能会发生额外的成本和费用 ， 包括差旅和住宿费用。提供立场文档不会对 DNA 的安全性、稳定性或灵活性产生任何影响。
-
-
关于 AOC 审 查 的报告（包含 ATRT 建议） － 后续 措施
理事会召开了符合法定人数的电话会议，并估计有七位有投票权的成员仍然会出席。
Mike Silber 请求在理事会会议之外向工作人员更充分地介绍 ATRT 建议。 CEO 确认会安排一次会议。
Steve Crocker 随后提出以下决议 ， 并得到 Mike Silber 的支持 ：
《义务确认书》要求 ICANN 针对以下义务的执行情况组织一次审查 （ 最晚要在 2010 年 12 月 31 日完成 ）： 维护和改进关于公众意见、问责制和透明度的稳健机制 ， 以确保其制定决策的结果能反映公众利益并对所有利益主体负责 ；
根据《确认书》的要求 ， 问责制和透明度审查小组 (ATRT) 于 2010 年 12 月 31 日向理事会提交了最终报告 ， 并发布了该报告来征询公众意见 ， 意见征询期于 2011 年 2 月 14 日结束 ；
《确认书》声称，理事会将在收到报告后的六个月内对最终建议采取行动。
第 2011.01.25.30 号决议 ： 理事会肯定了 ICANN ATRT 成员的辛勤工作和全心投入 ， 并感谢这些志愿者在期限紧张的情况下参与密集的公共流程 ， 提出一套全面的 ICANN 改进建议。
第 2011.01.25.31 号决议 ： 理事会鼓励公众对 ATRT 建议提出意见 ， 并要求所有支持组织、咨询委员会和提名委员会在 2011 年 2 月 14 日之前向理事会提供关于报告的初步意见 ， 并要求政府咨询委员会和提名委员会与理事会合作 ， 考虑对与其组织相关的建议采取的行动 。
第 2011.01.25.32 号决议 ： 理事会要求 ICANN 工作人员在 2011 年 2 月 21 日之前考虑收到的所有意见 ， 向理事会提交一份关于理事会针对每条建议采取行动的提案 ， 并在可行的情况下提议关于建议的初步工作计划和预算 ， 以及针对所有建议相关工作的状态报告。
十位理事会成员批准了第 2011.01.25.30 、 2011.01.25.31 和 2011.01.25.32 号决议。 Cherine Chalaby 、 Rita Rodin Johnston 、 Erika Mann 、 Rajasekhar Ramaraj 和 Kuo-Wei Wu 未能对该决议投票。 Peter Dengate Thrush 对该决议投弃权票。
主席指出，他弃权是因为虽然他支持推进该决议，但他本人在为问责制和透明度审查小组提供服务。
第 2011.01.25.30 － 2011.01.25.32 号决议的理由
要遵守《义务确认书》 ， ICANN 就必须针对理事会对问责制和透明度审查小组 (ATRT) 最终报告中提出的每条建议采取的行动创建提案。虽然此工作已在进行中 ， 但 ICANN 对问责制和透明度的承诺会通过透明跟进该流程来进一步实现。
机构群体仍通过公开的公众意见征询流程提供对 ATRT 最终建议的回应。创建关于理事会行动的提案将对组织产生预算影响。大量工作人员将致力于创建提案，且提案本身也会确定实施建议时在预算方面的进一步考虑。可能需要重新分配组织的财务资源，以便有足够的工作人员提供支持来创建有意义的提案。
-
新 gTLD