本 ccTLD 赞助协议（“协议”） 由ICANN 和 TWNIC 输入并在本协议第 2 节中定义。
1 演奏会
1.1 ICANN 是一家非营利性公司，成立于 1998 年 9 月 30 日，旨在为公众利益为互联网提供技术协调功能。ICANN 的职责之一是监督互联网权威根服务器系统的运行。
1.2 1989 年 7 月 31 日，.tw 顶级域由南加州大学信息科学研究所建立，当时该研究所履行互联网号码分配机构 (IANA) 的职能。该地区早期的互联网与美国JvNcnet相连，由1990年7月成立的教育部TANet运营。在 1994 年之前，TANet 还负责将 .tw 域名注册为 .tw ccTLD 注册机构。1994年，TWNIC开始域名注册启动所有y 作为一个技术实验项目。从 1996 年 10 月起，TWNIC 自愿运行 .tw 域名服务，并为 TWNIC 的正式成立做准备。1998年，行政院国家信息基础设施（NII）工作组确定电信总局（DGT）将监督TWNIC的注册过程。1999 年 12 月 29 日，TWNIC 获得法人资格批准，并作为法人监督机构运营。由电信总局 (DGT) 决定。TWNIC 的证书及其英文译文见本协议附件 1。
1.3 自本协议签署之日起，由 ICANN 履行的职能互联网号码分配机构 (IANA) 承认 TWNIC 为赞助组织，Vincent WS Chen 为行政联系人，许乃文为技术联系人.tw 顶级域名。
1.4 2002 年 4 月 4 日，TWNIC 在与政府机构的通信中报告其打算与 ICANN 签署 ccTLD-ICANN 赞助协议。2002 年 4 月 4 日的信函为本协定的附件 2。
1.5 2002 年 5 月 14 日，在回复 2002 年 4 月 4 日的 TWNIC 信函时，政府机构以书面形式向 TWNIC 表示支持 .tw 顶级域，并承认 TWNIC 是运营 .tw ccTLD 的合适实体，其条款如下：如第 1.6 节所述，在其发送给 ICANN 的认可信中说明。该通信的副本作为附件 3 附于本协议。
1.6 2003 年 3 月 11 日，政府机构写信给 ICANN，支持 TWNIC 管理 .tw 顶级域，基于 TWNIC 是否适合为当地互联网社区的利益运营该域以及它与 TWNIC 的通信。政府当局的背书副本作为本协议的附件 4 附后。
1.7 根据 DGT 2003 年 3 月 11 日的信函，TWNIC 执行董事 Vincent WS Chen 于 2003 年 3 月 11 日致函 ICANN 总裁兼首席执行官 M. Stuart Lynn，要求签订一份赞助协议，承认TWNIC 作为 .tw 赞助实体。2003 年 3 月 11 日的信函为本协定的附件 5。
1.8 TWNIC 和 ICANN 希望政府机构负责监督 TWNIC 对 .tw 顶级域的管理，确保其服务于当地互联网社区的利益，同时 ICANN 继续发挥维护技术稳定性和运营的作用为全球互联网社区的利益而建立 DNS 和互联网。就.tw顶级域以及第 1.4、1.5、1.6 和1.7节
中描述的通信，确定政府机构、 TWNIC和 ICANN 各自的责任, TWNIC 和 ICANN 现在签订本协议，以形成他们对彼此的承诺。
2 定义
2.1 “Authoritative-Root Database”是指第 3.2 节中描述的数据库。
2.2 “权威根服务器系统”是指不时在文件 <ftp://ftp.internic.net/domain/named.root> 中指定的 DNS 根名称服务器群。
2.3 除非另有说明，“天”是指日历（而不是工作日）天。
2.4 “授权ccTLD”是指互联网域名系统的.tw顶级域。
2.5 “DNS”是指互联网域名系统。
2.6 “政府机构”是指交通和通信部 (MOTC) 电信总局 (DGT)，是 TWNIC 运营的监督政府机构。
2.7 “政府通讯”是指规范主办单位与政府机关之间关系的法律、法规、协议、文件、合同、谅解备忘录和其他书面文书。本协议开始时的政府通讯在第 1.5和1.6节中进行了描述。
2.8 “ICANN”是指互联网名称与数字地址分配机构（Internet Corporation for Assigned Names and Numbers），本协议的一方，其主要办事处位于美国加利福尼亚州玛丽娜德尔雷，或其受让人。
2.9 “主办单位”和“TWNIC”是指台湾网络信息中心，成立于 1999 年 12 月 29 日，是本协议的一方，其主要办公地点位于 4F-2 号。 9, Roosevelt Road, Section 2, Taipei, 100, Taiwan 或其受让人。
2.10 “本协议的期限”自本协议首次代表双方签署之日起开始，一直延续到本协议终止为止。
3 ICANN 职责
3.1 赞助实体的认可。
ICANN 特此承认 TWNIC 在本协议有效期内是授权 ccTLD 的管理者。
3.2 权威根数据库。ICANN应维护或促使维护权威根服务器系统中有关 TLD的
相关信息的稳定、安全和权威数据库（在本协议中称为“权威根数据库”）。对于委派的 ccTLD，权威根数据库都至少包含有关赞助实体、管理联系人、技术联系人和名称服务器的信息。
3.3 指定行政和技术联系人。在本协议期限开始时，授权 ccTLD 的管理和技术联系人均应
如附件 A中所述. 在本协议期限内，发起实体可以不时以书面形式通知 ICANN，请求更改行政或技术联系人的指定。行政和技术联系人在其被指定为政府当局的整个期间必须居住在政府当局的领土内。指定行政或技术联系人的请求必须由赞助实体提出，并附有根据第 4.4 节新指定联系人的完整和准确的联系信息。互联网名称与数字地址分配机构 (ICANN )在 ICANN 合理地认为请求是真实的并符合第 3.3 节的要求后 7 天内，实施更改授权 ccTLD 中授权 ccTLD 的管理或技术联系人的请求。
3.4 更新域名服务器信息。在本协议期限开始时，授权 ccTLD 的名称服务器的主机名和 IP 地址均应如附件 A中所述。在本协议期限内，发起实体可以不时通知 ICANN，请求更改授权 ccTLD 中反映的授权 ccTLD 的名称服务器的主机名或 IP 地址。此类请求的初始格式和技术要求载于附件 B. ICANN 可在三十天书面通知赞助实体后更改格式要求。只有在 ICANN 和发起实体（双方均不得无理拒绝）或以第 5 节中提供的方式相互书面同意的情况下，才能对技术要求进行更改。ICANN将在 ICANN 合理地认为请求是真实的并符合第 3.4 节的要求后 7 天内实施更改授权 ccTLD 中授权 ccTLD 的名称服务器数据的请求。
3.5 更新联系信息的实施。
ICANN应在 ICANN 合理地确信该请求是真实的并符合第 4.4 节的要求后 7 天内实施由发起实体根据第 4.4 节提交的请求，以修改权威根
数据库中
的联系信息。
3.6 发布根区 Whois 信息。
ICANN应全部发布或促使发布在权威根数据库中维护的有关授权 ccTLD 的数据。公布的数据至少包括主办单位、管理联系人和技术联系人的名称。发布的数据元素的规范、发布的方式和发布的更新频率都应在附件 C中提供。只有在 ICANN 和发起实体（双方均不同意所有
不合理的扣留）或以第 5 节规定的方式。
3.7 权威根域名服务器系统运行；权威根区文件的内容。ICANN 应尽合理的商业努力来协调权威根服务器系统，以确保其以稳定和安全的方式运行和维护。ICANN 在其协议和其他方面拥有权限的范围内，都应促使权威根服务器系统发布将授权 ccTLD 委托给权威根数据库中记录的名称服务器的 DNS 资源记录。
3.8 维护权威记录和审计追踪。ICANN应维护或促使维护有关ccTLD 授权的权威记录和审计跟踪以及与这些授权相关的记录。一旦 TWNIC 和政府机构在 30 天内提出要求，这些有关 .tw 的记录将全部提供给他们。
3.9 ICANN 联系信息变更通知。ICANN应在更改生效后的 7 天内将 ICANN 联系信息的任何更改通知发起实体。
3.10 ICANN 名称和徽标的使用。ICANN 特此在本协议期限内向赞助实体授予非排他性、全球性、免版税许可 (a) 声明其被 ICANN 认可为授权 ccTLD 的赞助实体，以及 (b) 使用ICANN 指定的标志以表示该认可。ICANN 名称或徽标的其他用途未在此获得许可。赞助实体不得转让或分许可此许可。赞助实体不会因本协议而获得对任何 ICANN 名称或徽标的任何权利、所有权或利益。
四、保荐机构义务
4.1 为授权的 ccTLD 提供名称服务。发起实体应尽合理和最佳的商业努力，以使授权的主要和次要域名服务器以稳定和安全的方式运行和维护，足以解析授权 ccTLD 内的名称，以及超过发起实体为整个 Internet 的用户保留管理权限。
4.2 ICANN 访问授权 ccTLD 的区域文件和注册数据。赞助实体SH一切确保区域文件，并准确和最新登记资料委托ccTLD是连续可用到ICANN，在ICANN可能不时合理指定的方式，用于验证和保证的目的仅授权 ccTLD 的运营稳定性。
4.3 ccTLD 注册数据托管。发起实体应确保注册数据库的安全性和完整性，包括为发起实体管理的注册数据建立数据托管或镜像站点策略。托管代理或镜像站点运营商均应获得发起实体和政府机构的批准，并且均不受发起实体的控制。托管或镜像站点数据将全部根据发起实体、上述托管代理或镜像站点运营商和 DGT 之间的协议（“托管协议”）持有，前提是 (1) 数据将由托管代理或镜像站点运营商维护根据政府当局 (DGT) 领域内普遍的商业惯例；(2) 托管代理或镜像站点运营商将按照双方合理约定的时间表和程序验证数据的完整性、一致性和格式正确；(3) 本协议终止后，数据将立即提供给委派 ccTLD 的继任经理；(4) 在此类规定的情况下，继任经理都有_ _ 使用授权 ccTLD 及其注册管理机构所必需的数据的权利。
4.4 联系信息的准确性和完整性。
发起实体应在更改生效后不迟于 7 天通知 ICANN 有关授权根数据库中授权 ccTLD 的联系信息的任何更改。委派 ccTLD 的管理和技术联系人在其被指定为政府机构的整个期间必须居住在政府机构的领土内。通知的格式均应符合 ICANN 不时制定的要求。附件 D中规定了初始格式要求. ICANN 可在三十天书面通知赞助实体后更改格式要求。
4.5 符合 ICANN 政策。发起实体应遵守根据第 5 节制定的ICANN 政策，其中涉及：
4.5.1 授权 ccTLD 与 DNS 和互联网的其他部分的互操作性；ccTLD运营商的技术运营能力和技术业绩；获取、维护和公开访问域名注册人的准确和最新的联系信息；和
4.5.2 其他主题，在授权 ccTLD 的注册政策鼓励或促进居住在政府机构境外的实体或个人注册的情况下，只要这些政策适用于授权 ccTLD，除非（a ) 赞助实体被法律禁止实施此类其他 ICANN 政策或 (b) 政府机构书面指示赞助实体不要实施此类其他 ICANN 政策，并提前三个月书面通知 ICANN 和 ICANN 政府咨询委员会。
4.6 对 ICANN 的财务贡献。在本协议的整个期限内，赞助实体均应根据 ICANN 的总资金需求（包括储备金），按照公平的比例为 ICANN 的运营成本做出贡献，该资金需求由 ICANN 在协商一致的基础上制定，如附件 F中所述. 应 ICANN 的要求，赞助实体将在定期计算该金额时向 ICANN 提供合理必要的信息，以计算赞助实体的捐款金额（例如，ccTLD 中注册名称的数量）。
5 规范和政策的制定
5.1 设立程序。附件 G中规定的规范和政策均适用于根据第 4.5.1 节
从
本协议期限开始开始的授权 ccTLD 的运营。在本协议有效期内，适用于发起实体的新的或修订的ICANN规范和政策均应根据符合 ICANN 章程和公司章程的程序制定。此外，新的或修订的d 在本协议期限内制定的 ICANN 规范和政策要求按照本协议第 5 节规定的方式
制定在可行的情况下 (a) 事先通知（通过网络发布、通过电子邮件或根据第 6.8 节）向赞助实体解释正在考虑采用哪些规范或政策以及原因；(b) 赞助实体在规范或政策发布之前以书面形式和在公共论坛上发表评论的合理机会已制定，以及 (c) 已制定的规范或政策及其制定原因的书面声明。
5.2合规所需时间。在收到通知后，发起实体应获得一段合理的时间（不超过四个月，除非根据第 5.1 节制定的规范或政策的性质合理地要求，经 ICANN 和发起实体同意，更长的时间）
考虑到所涉及的任何紧迫性，根据第 5.1 节建立规范或政策以遵守该规范或政策。
6 杂项
6.1 赞助实体终止。
发起实体可在六个月书面通知 ICANN 和政府机构 (DGT) 后终止本协议。
6.2 ICANN 终止。ICANN 可在下列任何情况下终止本协议：
6.2.1 在 ICANN 向发起实体发出违约的书面通知后，发起实体未能在 30 天内（或尽最大努力纠正此类违约可能需要的更长的合理期限）纠正任何重大违反本协议的行为，并且政府机关。
6.2.2 保荐实体的作为或不作为已根据第 6.5 条经仲裁认定
违反本协议，且保荐实体在一段时间内继续以被认定违反本协议的方式作为或不作为仲裁决定中规定的期限，如果没有规定期限，则为 30 天。
6.2.3 在发起实体收到有关决定的 7 天通知后，发起实体以 ICANN 合理确定危及 DNS 或互联网运营稳定性的方式行事或继续行事。
6.2.4 在政府机构通知 ICANN 赞助实体违反了政府通讯的条款，或政府机构指定赞助实体作为授权 ccTLD 经理的期限已届满后，ICANN 将通知其意图终止赞助实体。
6.2.5 保荐实体破产或资不抵债。
在上述第 6.2.1 至 6.2.3 节所述的情况下，本协议
仅可在向发起实体和政府机构发出三十天通知（“仲裁通知期”）后终止（在发起实体未能生效后发生）在规定的期限内获得补救），在仲裁通知期内，发起实体有机会根据第 6.5 条启动仲裁
确定根据本协议终止的适当性。如果发起实体就 ICANN 终止的适当性发起仲裁，发起实体可以同时请求仲裁小组暂停终止，直到做出仲裁决定，并且该请求应具有中止终止的效力，直到做出决定或仲裁小组批准 ICANN 解除中止的请求。如果发起实体以 ICANN 合理确定的方式行事危及 DNS 或互联网的运营稳定性，并且在收到通知后未立即实施补救措施，则 ICANN 可以暂停本协议五个日历日，等待 ICANN 根据以下规定申请更延长的禁令救济第 6.5 节。在第 6.2.4 和 6.2.5 节所述的情况下，本协议可在通知发起实体后立即终止。
6.3 终止的影响。本协议终止后，ICANN应与政府机构 DGT 协调，通知已将授权 ccTLD 管理权重新分配给其的继任者的发起实体。（继任者的选择方式或结果均不受主办单位的变更）。然后，各方应合作将委派 ccTLD 的运营转移给该继任者。特别是，发起实体应确保所有转让向继任者提供相关的 DNS 和注册数据，但仅限于继任者承诺以与发起实体先前公布的关于使用其个人数据的数据主体的承诺一致的方式使用数据。发起实体承认，在本协议终止后，它将不再是授权 ccTLD 的公认管理者。发起实体同意按照第 6.2 节所述的条件和方式重新分配授权 ccTLD ，
并应就任何和因根据该节终止本协议而引起的所有索赔、损害、责任、成本和开支，包括合理的法律费用和开支。
6.4 无金钱责任。任何违反本协议项下义务的行为均不会导致一方对另一方承担金钱责任，只要一方未能按照本协议的要求作出财务贡献均构成对本协议的重大违约。
6.5 争议的解决。因本协议引起的、与本协议有关的或与之相关的争议均应根据国际商会（“ICC”）的仲裁规则最终解决。仲裁均应以英语进行，且均应在双方约定的地点进行，或在没有约定的情况下，在美国纽约州纽约市进行。应有三名仲裁员：ICANN均应选择一名仲裁员，发起实体均应选择一名仲裁员，如果这两名仲裁员不同意第三名仲裁员，则第三名都是根据ICC规则选择的。ICANN 和发起实体均应平等分摊仲裁费用，但仲裁员有权按照 ICC 规则的规定在裁决中重新确定费用。当事人
应自行承担与仲裁有关的律师费，仲裁员不得将律师费连同其裁决一并追讨。仲裁员均应在仲裁庭审结束后九十日内作出裁决。为了协助仲裁和/或维护权利在仲裁未决期间，各方均有权向仲裁小组或位于美国加利福尼亚州洛杉矶的法院寻求中止或临时或初步禁令救济放弃本仲裁协议。在涉及 ICANN 与本协议有关的所有
诉讼中，此类诉讼的管辖权和专属地点均应在位于美国加利福尼亚州洛杉矶的法院进行；但是，当事方都有权在任何有管辖权的法院执行该法院的判决。
6.6 法律的选择。与解释本协议有关的法律问题均应通过(a) 由仲裁小组认为适用的法律冲突规则确定的法律规则和 (b) 国际法律规则作为解决仲裁小组认为适用；但政府机关及主办单位之行为之效力、解释及效力，均依台湾政府之法律判定，ICANN之效力、诠释、效力均依法律之判定。美国加利福尼亚州。
6.7 无第三方受益人。本协议不得解释为任何一方对本协议的任何非一方承担任何义务。
6.8 通知。除非另有特别说明，否则根据本协议向各方或政府当局发出的所有通知均应以书面形式按以下规定的地址发出，除非收件人已在写作。本协议要求的任何通知在当面送达、通过电子传真发送或安排通过所有公认的国际快递服务送达时均应被视为已正确发出。
