本レジストリ契約（以下、「本契約」といいます）は、 日（以下、「発効日」といいます）時点で、カリフォルニア州の非営利公益法人、Internet Corporation for Assigned Names and Numbers（以下、「ICANN」といいます）と 、 （以下、「レジストリオペレータ」といいます）との間で締結されます。
レジストリ契約
本レジストリ契約（以下、「本契約」といいます）は、 日（以下、「発効日」といいます）時点で、カリフォルニア州の非営利公益法人、Internet Corporation for Assigned Names and Numbers（以下、「ICANN」といいます）と 、 （以下、「レジストリオペレータ」といいます）との間で締結されます。
第1条。
トップレベルドメインの委任とオペレーション、表明と保証
1.1 ドメインと指定。 本契約が適用されるトップレベルドメインとは、
（以下、「TLD」といいます）です。 発効日および契約満了日前（4.1項に定義されるように）まで、または第4条に従って本契約の終了の際に、TLDの委任とルートゾーンへのエントリーのための要件を満たし、必要な承認を得ることを条件として、ICANNはレジストリオペレータをTLDのレジストリオペレータとして指定します。
1.2 文字列の技術的実行可能性。ICANNはインターネット全体に渡るすべてのトップレベルドメインの文字列の一般的受容を推奨しており、これ以降も推奨し続けてゆきますが、特定のトップレベルドメインの文字列は、ISPとウェブホスターによる受け入れやウェブアプリケーションによる検証において障害に遭遇する場合があります。レジストリオペレータは、本契約を締結する前にTLDの文字列の技術的実行可能性を確保する責任を負うものとします。
1.3 表明と保証。
(a) レジストリオペレータは、次の通りにICANNへ表明し、保証します：
(i) レジストリTLDアプリケーションで提供されるすべての重要な情報と提示される声明、および本契約の交渉期間中に書面にて提示される声明は、レジストリオペレータによりICANNへ事前に書面にて開示されていない限り、すべての重要な点において、それがなされた時点でxxかつ正確であり、そしてそのような情報や声明は、すべての重要な点において、その発効日時点で依然xxであり、正確です。
(ii) レジストリオペレータはこの序文に規定される法域の法律の下で、適法に設立され、正当に存続し、信用状態が良く、そしてレジストリオペレータは本契約を締結し、適法に執行し、履行するために必須条件となるすべての法的能力と権限を持ち、必要な承認を得ています。そして、
(iii) レジストリオペレータはICANNに本契約を終了または満了した場合にはTLDのレジストリ機能を実行するために必要な資金を保証する適法に執行された証書（以下、「継続運営証書」といいます）を提出して
おり、そのような証書はその契約条件に従って双方の当事者に法的拘束力がおよぶ義務であり、双方の当事者への強制力があります。
(b) ICANNは、レジストリオペレータへICANNがアメリカ合衆国カリフォルニア州の法律の下で、適法に設立され、正当に存続し、信用状態が良い非営利公益法人であることを表明し、保証します。 ICANNは、本契約を締結し、適法に執行し、履行するために必須条件となるすべての法的能力と権限を持ち、必要な法人としての承認を得ています。
第2条。
レジストリオペレータの誓約
レジストリオペレータは、次の通りにICANNに誓約し、同意します：
2.1 承認されたサービス、追加サービス。 レジストリオペレータはここに添付される仕様書6（以下、「仕様書6」といいます）、第2.1項第一段落の(a)および(b)に記載されるレジストリサービス、および別紙Aに規定されるその他のレジストリサービス（以下、集合的に「承認されたサービス」といいます）を提供する資格を有するものとします。 レジストリオペレータが承認されたサービスではないか、あるいは承認されたサービスへ重大な変更がなされた任意のレジストリサービス（それぞれ「追加サービス」）の提供を希望する場合、かかるポリシーはコンセンサスポリシー（以下、「RSEP」といいます）に該当するICANNの付属定款に従って随時改定される（随時改定される
「ICANNの付属定款」の通りに）場合があるので、レジストリオペレータは xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxx/xxxx.xxxx に記載されるレジストリサービス評価ポリシーに従い、そのような追加サービスの承認リクエストを提出するものとします。レジストリオペレータは、書面によりICANNの承認を得た追加サービスのみ提供することができ、そのような承認に際して、そのような追加サービスは本契約の下でレジストリサービスとしてみなされるものとします。 その合理的な裁量において、ICANNはRSEPに従って承認された任意の追加サービスの規定を反映し、本契約への改定を求めることができ、そしてその改定は双方の当事者へ合理的に受容される形式であるものとします。
2.2 コンセンサスポリシーおよびテンポラリポリシーの遵守。 レジストリオ ペレータは本契約の発効日時点、およびICANNの付属定款に従い将来において開発され、採用され、<xxxx://xxx.xxxxx.xxx/xxxxxxx/xxxxxxxxx-xxxxxxxx.xxx> に記載されるすべてのコンセンサスポリシーとテンポラリポリシーを遵守し、実践するものとします。但し、そのような将来のコンセンサスポリシーとテンポラリポリシーは、ここに添付される仕様書1（以下、「仕様書1」といいます）に規定される手続きに従い、それらの制限に関連して、それらの制限の対象となる場合に限ります。
2.3 データエスクロー。 レジストリオペレータは委任後14日以内に、ここに添付される仕様書2（以下、「仕様書2」といいます）に規定されるレジストリデータエスクロー手続きに従うものとします。
2.4 マンスリーレポート。TLDがルートゾーンで委任された最初の暦月が開始する、各暦月の月末後20日以内に、レジストリオペレータはここに添付される仕様書3
（以下、「仕様書3」といいます）に規定される形式でICANNへレポートを提出するものとします。但し、その暦月の15日以降にルートゾーンで委任された場合に限り、レジストリオペレータはその最初の暦月のレポート提出を延期し、その代わりに、その月のレポートをレジストリオペレータが翌暦月のレポート提出が求められている期日までに、 ICANNへ提出することができます。 レジストリオペレータは、委任時点で削除されていない委任前テスト中に作成されたすべてのドメイン名を各レジストラトランザクションレポートに含める必要があります（特に、レジストラID 9995および/または9996により登録されたドメインですが、それだけに限りません）。
2.5 登録データの公表。 レジストリオペレータは、ここに添付される仕様書4
（以下、「仕様書4」といいます）に従い、登録データへのパブリックアクセスを提供するものとします。
2.6 予約名。 ICANNが書面にて明白に許可した範囲を除き、レジストリオペレータはここに添付される仕様書5（以下、「仕様書5」といいます）に規定される要件を遵守するものとします。レジストリオペレータは、レジストリオペレータの予約能力（すなわち、第三者、代理人、用途に対して登録したり、DNSでアクティベートしたり、さもなくば利用できるようにすること）に関するポリシーを随時設定したり、修正したり、あるいはTLD内の追加文字列を自由裁量で制限したりすることができます。 仕様書5で指定される場合を除き、レジストリオペレータがレジストリTLDの任意のドメイン名のレジストラントである場合、そのような登録はICANN認定レジストラを通して行う必要があり、6.1項に従ってレジストリオペレータによりICANNへ支払われるレジストリレベル手数料計算におけるトランザクション（6.1項に定義されるように）としてみなされます。
2.7 レジストリの相互運用性と継続性。 レジストリオペレータは、ここに添付される仕様書6（以下、「仕様書6」といいます）に規定されるレジストリ相互運用性と継続性仕様に準拠するものとします。
2.8 第三者の法的権利の保護。 レジストリオペレータは、ここに添付される仕様書7（以下、「仕様書7」といいます）に規定されるTLDの立ち上げと初期登録に関連した継続的な第三者の法的権利の保護のためのプロセスと手順を指定し、遵守する必要があります。 レジストリオペレータは、その選択により、第三者の法的権利の追加保護を実施することができます。 契約の発効日以降の仕様書7により求められるプロセスと手順への任意の変更や修正は、事前に書面によりICANNの承認を得る必要があります。該当する手順に規定される救済策へ異議を申し立てるレジストリオペレータの権利を承認することを条件として、レジストリオペレータは仕様書7の2項に従ってICANNにより課される、かかるすべての救済策を遵守する必要があります。レジストリオペレータは、 TLDの使用に関連し、法執行機関や政府および準政府機関からの違法行為の任意の報告を調査し、そしてそれに対応するために合理的な措置を取るものとします。 かかる報告
に対応するに当たり、レジストリオペレータは適用法に違反する措置を講じる必要はありません。
2.9 レジストラ。
(a) TLDで登録されるすべてのドメイン名は、ICANNが認定したレジストラを通して登録される必要があります。但し、レジストリオペレータは2.6項に従った委任や利用の際にその名称を公表しないために、自身の名称を登録する場合には、レジストラを利用する必要がありません。 仕様書11の要件に従い、レジストリオペレータはTLDのレジストリ-レジストラ契約を締結し、それを遵守しているICANNが認定するすべてのレジストラにレジストリサービスへの差別のないアクセスを提供する必要があります。但し、レジストリオペレータは適切なTLD機能に関連して合理的なTLDでの名称登録資格のために、差別のない基準を設定することができます。 レジストリオペレータは、TLDでの名称登録の権限を持つすべてのレジストラと統一された差別のない契約を利用する必要があります
（以下、「レジストリ-レジストラ契約」）。 レジストリオペレータは、随時レジストリ-レジストラ契約を改正する場合があります。但し、ここで何らかの重大な改定には、その改定が効力を持ち、任意のレジストラに拘束力がおよぶ前に、ICANNによる承認を受ける必要があります。 レジストリオペレータは、何らかの改定が効力を持ち、任意のレジストラに拘束力がおよぶ前に、レジストリ-レジストラ契約に対する改定に関し、書面による通知を少なくとも15日前までに、ICANNとTLDで名称登録の権限を持つすべてのレジストラへ提供します。 このような期間中、ICANNはその提案された改定が、本質的にあまり重要ではないか、将来的に重要であるか、あるいは重要であるかを判断します。ICANNがレジストリオペレータにその判断の通知を15日以内に提出していない場合には、ICANNがその提案された改定が本質的にあまり重要ではないと判断しているとみなされるものとします。 ICANNがその改定をあまり重要ではないと判断し、あるいはこの2.9(a)項の下でそのように判断しているとみなされる場合には、レジストリオペレータはその改定を採用し、実施することができます。 ICANNがその改定を重要であると判断し、あるいは将来的に重要であると判断する場合には、ICANNはそれ以降、< xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx-xxxxxxxxx-xxxxxxxxx >でレジスト リ-レジストラ契約への変更の再検討および承認に関する手続きに従い、ICANNにより承認されるまでその改定を採用したり、実施したりすることはできません。 この2.9(a)項に先行する規定にも拘らず、レジストリオペレータによりTLDでのドメイン名登録に課金される手数料へ独占的に関連するレジストリ-レジストラ契約への任意の変更は、この 2.9(a)項に指定される通知と承認プロセスに従いませんが、以下の2.10項の要件に従います。
(b) レジストリオペレータは、(i) ICANN認定レジストラのアフィリエイトや再販業者になるか、または、(ii) ICANN認定レジストラ、レジストラ再販業者、あるいはそれぞれのアフィリエイトのいずれかへの任意のレジストリサービス提供を請負契約し、さらに上記の(i)または(ii)のいずれかの場合、レジストリオペレータはそのようなアフィリエーション、再販業者の関係や請負契約の結果としてもたらされる契約、取引、あるいはその他の合意を該当する場合には、ICANNにより要求されたこれに関連する任
意の契約のコピーを含め、ICANNへ直ちに通知します。但し、部外秘として適切に印が付けられた（7.15項に求められる通り）そのような契約や関連文書をICANNは、7.15項に従ってレジストリオペレータの機密情報として取り扱います（ICANNが関連する競争当局へそのような契約と関連する文書を開示する場合を除く）。 ICANNはそのような契約、関連する文書、取引、あるいはその他の合意が、適用する法律の下で重大な競合問題を引き起こす判断する場合に、ICANNは関連する競争当局へそのような任意の契約、関連する文書、取引、あるいはその他の合意を照会する権利を留保しますが、その義務を留保しません。 状況が実現可能で適切な場合に、ICANNはレジストリオペレータへそのような競争当局へ任意の照会を行う前に、レジストリオペレータへ事前に通知します。
(c) 本契約の目的のために： (i) 「アフィリエイト」とは、1人以上の仲介者を介して、または1人以上のその他の個人や組織と共に直接的、あるいは間接的に指定された個人や組織によって管理され、あるいはそれらによる共通の管理下にある個人や組織を指し、(ii) 「管理」（「によって管理され」および「と共通の管理下にある」という文言を含みます）とは、株式の保有を通して受託者や執行者として、従業員として、あるいは理事会や同等の管理組織のメンバーとして働くことにより、契約により、信用協定やその他により、ある個人や組織の経営上の指導やポリシーを指示したり、生み出したりする権限を直接的、あるいは間接的に持つことを意味します。
2.10 レジストリサービスの料金設定。
(a) 最初のドメイン名登録に関して、レジストリオペレータはTLDのレジストリ-レジストラ契約を執行しているICANN認定の各レジストラへ30日以上前に書面による任意の料金値上げ（任意の返金、リベート、割引、製品試供、あるいはレジストラへ課金する料金を減額する効果があるその他のプログラムが、提供時にレジストラへ明確に、はっきりと開示された期間限定である場合を除き、返金、リベート、割引、製品試供、あるいはその他のプログラムの排除した結果を含む）通知を提出するものとします。 レジストリオペレータは、レジストラへレジストラの自由裁量により1年から10年までで10年を超えない期間に、最初のドメイン名登録を取得する選択肢を提供するものとします。
(b) ドメイン名登録の更新に関して、レジストリオペレータはTLDのレジストリ-レジストラ契約を執行しているICANN認定の各レジストラへ180日以上前に書面による任意の料金値上げ（任意の返金、リベート、割引、製品試供、的確なマーケティングプログラム、あるいはレジストラへ課金する料金を減額する効果があるその他のプログラムを排除した結果を含む）通知を提出するものとします。 先行する文章にも拘らず、ドメイン名登録の更新に関しては、 (i) 結果としてもたらされる料金が、(a) 発効日に始まり、発効日の後12カ月間で終わる期間、TLDでの登録に対して課金される最初の料金に等しいか、それ以下である場合、あるいは(b) それに続く期間、提案された料金値上げの発効日の前の12カ月間に、この2.10(b)項の最初の文章に従って、レジストリオペレータが通知を提出した料金に等しいか、それ以下である場合、レジストリオペレータは任意の料金値上げの通知を30日前までに提出する必要があります。そして、(ii) レジストリオペレータは6.3項に規定されている変動レジストリレベル手数料の賦課による任意の料金値上げ通知を
提出する必要はありません。 レジストリオペレータは、レジストラへレジストラの自由裁量により1年から10年までで10年を超えない期間に、現行料金（すなわち、任意の料金値上げ通知以前に設定されている料金）でドメイン名登録更新を取得する選択肢を提供するものとします。
(c) また、レジストリオペレータは、ドメイン名登録の更新のために、均一料金設定（以下、「更新料」といいます）を備えている必要があります。 更新料を決定する目的のために、各ドメイン登録の更新料は、そのような更新時に適用されているその他すべてのドメイン名登録更新の料金と同一である必要があり、そのような料金は更新時に適用されている任意の返金、リベート、割引、製品試供やその他のプログラムのあらゆる状況に適用するように考慮する必要があります。 この2.10(c)項の先行す る要件は、(i)該当するレジストラントへそのような更新料と(ii)認定マーケティングプログラムに従って割引更新料を明白にはっきりと分かるように開示した後、最初のドメイン名登録時に、レジストラとの間でより高い更新料となる登録契約に同意していることを説明する文書をレジストラがレジストリオペレータへ提供している場合、更新料を判断する目的で適用してはならないものとします。 双方の当事者は、この2.10(c)項の目 的が、ドメイン初期登録時に該当するレジストラントの書面による同意なく、レジストリオペレータにより課される乱用的および/または差別的更新料設定慣行の禁止である と認め、そしてこの2.10(c)項はそのような慣行を禁止するために広く解釈されます。 この2.10(c)項の目的のために、「認定マーケティングプログラム」とは、レジストリオペレータが提供する割引された更新料設定に従ったマーケティングプログラムです。但し、次の各基準を満たすものとします： (i) プログラムおよび関連する割引は、180暦日を超えない期間限定（プログラムの暦日数を判定する目的で、連続した本質的に類似のプログラムを総計します）で提供され、(ii)すべてのICANN認定レジストラはそのような割引された更新料設定を利用できる同一の機会が提供され、そして(iii)プログラムの意図や効果は、いずれか特定の登録等級（例えば、大企業によって維持される登録）を排除したり、いずれか特定の登録等級の更新料を値上げしたりすることではありません。 この 2.10(c) 項は、2.10(b) に従うレジストリオペレータの義務を何ら制限するものではありません。
(d) レジストリオペレータは自らの費用負担でTLDのためにパブリッククエリーに基づくDNS検索サービス（それはレジストリTLDゾーンサーバーを操作します）を提供するものとします。
2.10 契約と運用のコンプライアンス監査。
(a) ICANNは随時（暦年あたり2回を超えない）、本契約の第1条に含まれる表明および保証と本契約の第2条に含まれるその契約により、レジストリオペレータによるコンプライアンスの状況を調査するために契約のコンプライアンス監査を実施し、あるいは第三者にそれを実施させることができます。そのような監査はコンプライアンス調査の目的を達成するために状況に合わせて調整されるものとし、ICANNは(a)そのような任意の監査の合理的な事前通告を与え、そしてその通告には文書、データ、そして
ICANNにより要求トされるその他の情報のカテゴリーを合理的で詳細な説明の中で指定するものとし、(b)そのような監査を通常の営業時間中に、レジストリオペレータの運営を正当な理由なく混乱させないような方法で実施できるように商業的に合理的な努力を払うものとします。 かかる監査の一環として、ICANN からの要請に応じて、レジスト リオペレータは、自身が本契約を遵守していることを証明するために必要となるすべての回答文書、データおよびその他の情報を適時に提出するものとします。 10日以上前 の通知（「レジストラ」による別段の同意がある場合を除きます）により、ICANN は、任意の契約のコンプライアンス監査の一環として、通常の営業時間中に現地視察を実施し、本契約の第1条に含まれる表明および保証、本契約の第2条に含まれるその条項によって、レジストリオペレータのコンプライアンス状況を調査することができます。 ICANNは、7.15項に従い、レジストリオペレータの機密情報として適切に部外秘として印が付けられた（7.15項で求められるように）、このような監査に関連して取得したすべての情報を取り扱います。
(b) 2.11(a)に従って実施される任意の監査は、(i) レジストリオペレータが (A)任意のICANN認定レジストラ、レジストラ再販業者、またはそれぞれのアフィリエイトを管理し、それらにより管理され、それらの共通の管理下にある、あるいはそれらに関連するか、または(B)レジストリサービスの提供をICANN認定レジストラ、レジストラ再販業者、またはそれぞれのアフィリエイトと請負契約していない限り、ICANNの費用負担によるものとし、そして先の(A)または(B)のいずれかのケースで、その監査が2.14項によるレジストリオペレータのコンプライアンスに関連している場合、レジストリオペレータは2.14項のレジストリオペレータのコンプライアンスに関連する部分に関するすべての合理的なコストと費用をICANNへ払い戻すものとし、あるいは (ii) レジストリオペレータにより支払われた手数料の相違が、その四半期のICANNの損失の5%を超えることに、その監査が関連している場合、レジストリオペレータはそのような監査全体に関連するすべての合理的なコストと費用をICANNへ払い戻すものとします。先の(i)または(ii) のいずれかの場合、そのような払い戻しはかかる監査の費用明細書が転送された日以降、次のレジストリレベル手数料支払い満期日に一緒に支払われます。
(c) (a)項の規定にも拘らず、レジストリオペレータが2.11項に従い実施された2回の連続した監査で、本契約の第1条に含まれる表明および保証、本契約の第2条に含まれる条項を遵守していないことが発覚した場合、ICANNはそのような監査の回数を四半期毎に1回に増やすことができます。
(d) レジストリオペレータは4.3(d)項で言及される任意の訴訟手続きの開始、または4.3(f)項に指定される任意の事象の発生に関するレジストリオペレータの見解を即時通告としてICANNへ与えます。
2.12 継続運営証書。 レジストリオペレータは、ここに添付される仕様書8（以下、「仕様書8」といいます）に規定される継続運営証書に関連した契約条件を遵守するものとします。
2.13 緊急時の移行。 レジストリオペレータは、仕様書10の第6項に規定されるレジストリ機能の任意の緊急時基準に達した場合に、ICANNのレジストリ移行プロセス
（<xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxxxx-xxxxxxxxx>にて入手できます）（随時改定される「レジストリ移行プロセス」と同様に）に従って、レジストリオペレータがそのような障害を再発させることなく、TLDのそのレジストリの運営を再開できることをICANNが合理的に納得できる証明がなされる時まで、ICANNがTLDの緊急時暫定レジストリオペレータを指定できることに同意します。 そのような証明の後、レジストリオペレータはレジストリ移行プロセスに規定される手順に従い、TLDのそのレジストリの運営に復帰することができます。但し、レジストリオペレータは (i) 緊急時オペレータの指名の結果として、そして(ii) TLDのそのレジストリの運営に関連して緊急時オペレータにより発生したすべての合理的なコストを支払うものとし、そしてそのコストはレジストリオペレータが利用できるようにされたレコードに合理的で詳細な説明として文書化されるものとします。 2.13項とレジストリ移行プロセスに従い、ICANNが緊急時オペレータを指名する場合、レジストリオペレータはICANNやかかる任意の緊急時オペレータが合理的に要求できるオペレーションとレジストリ機能を維持するために必要なTLDのレジストリのオペレーションに関するすべてのデータ（2.3項に従ってエスクローがデポジットされたデータを含む）をICANNやかかる任意の緊急時オペレータへ提供するものとします。 レジストリオペレータは、この第2.13項に従い緊急時オペレータが指定される場合に、TLDに関するDNSおよびWHOISレコードに対し、IANAデータベースへ必要と思われる任意の変更をICANNが加えることに同意します。 さらに、かかる障害が発生した場合、ICANNは継続運営証書の下でその権利を保持し、その権利を行使することができます。
2.14 レジストリの行動規範。 TLDのレジストリのオペレーションに関連して、レジストリオペレータはここに添付される仕様書9（以下、「仕様書9」といいます）に規定されるレジストリの行動規範を遵守するものとします。
2.15 経済的調査への協力。 ICANNが、インターネット、DNS、あるいは関連す る事柄における新しいジェネリックトップレベルドメインの影響や機能に関する経済的 調査を開始し、あるいは委任する場合、レジストリオペレータはICANNやその被指名人 により要求されるそのような調査の目的で合理的に必要となるTLDのオペレーションに 関連するすべてのデータの調査を実施するICANNやその被指名人へ提供することを含み、かかる調査へ合理的に協力するものとします。但し、そのレジストリオペレータは (a) か かるデータに関してレジストリオペレータによって準備された任意の内部分析や評価、 および(b) 適用する法律に違反するかかるデータの提出に至るまでの範囲で任意のデー タを差し控えることができます。 本2.15項に従って適切に部外秘として印がつけられ
（7.15項で求められるように）、ICANNやその被指名人に提供される任意のデータは、 7.15項に従ってレジストリオペレータの機密情報として取り扱われるものとます。但し、 ICANNがそのようなデータを集積し、匿名にする場合、ICANNやその被指名人はかかるデータを任意の第三者へ開示できます。レジストリオペレータがデータを提供している経済的調査の完了後、ICANNは集積されていない、匿名にされていないレジストリオペレータによって提供されたすべてのデータを破棄します。
2.16 レジストリ性能仕様。TLDのオペレーションのためのレジストリ性能仕様は、ここに添付される仕様書10（以下、「仕様書10」といいます）に規定される通りです。 レジストリオペレータは、このような性能仕様を遵守するものとし、契約期間の各暦年にそのような仕様を遵守していることを証明するのに十分な技術および運用記録を少なくとも1年間保管するものとします。
2.17 その他公益のための誓約。 レジストリオペレータは、ここに添付される仕様書11（以下、「仕様書11」といいます）に規定される公益のための誓約を遵守するものとします。
2.18 個人データ。 レジストリオペレータは、(i) そのようなレジストラによって、レジストリオペレータへ提供された任意の特定された、または特定可能な自然人（以下、「個人データ」といいます）のデータの目的が、本契約の下で収集され、利用されること、さもなくばその個人データの対象となる受領者（または受領者のカテゴリー）をTLDのレジストリ-レジストラ契約の一方の当事者である各ICANN認定レジストラへ通知し、そして、(ii) そのようなレジストラにその個人データの収集と利用のために、TLDの各レジストラントの同意を得るように求めるものとします。 レジストリオペレータは、そのようなレジストラから収集された個人データを損失、誤用、不正な開示、改変または破壊から保護するために、合理的な措置を講ずるものとします。 レジストリオペレータは、レジストラへ提出した通知内容と相
容れない方法で個人データを使用したり、使用する権限を与えたりしてはならないものとします。
2.19 [注： コミュニティーベースのTLDに対してのみ] TLDコミュニティへのレジストリオペレータの義務。 レジストリオペレータは、以下のためにTLDに関して提出された申請と一致した登録ポリシーを確立するものとします： (i) TLD内の命名規則、(ii) TLDコミュニティのメンバーによる登録の要件、そして (iii) コミュニティベースのTLDの明記された目的と一致する登録ドメイン名の利用 レジストリオペレータは、TLDコミュニティがTLDのポリシーや慣行の開発や修正について討議をし、参加できる方法で TLDを運営するものとします。 レジストリオペレータは、TLDの登録ポリシーの施行、およびTLDの登録ポリシーへのコンプライアンスに関する紛争を解決するための手順を確立し、そのような登録ポリシーを施行するものとします。 レジストリオペレータは、本2.19項に従い提起される紛争に関して、 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx に規定されるレジストリの制限に 関する紛争解決手続きを実践し、それに拘束されることに同意します。 レジストリオペ
レータは、ここに添付される仕様書12に規定されるコミュニティ登録ポリシーを実践し、遵守するものとします。
第3条。
ICANNの誓約
ICANNは、次の通りにレジストリオペレータに誓約し、同意します：
3.1 オープンかつ透明。ICANNが表明したミッションや本質的価値と一致して、 ICANNはオープンで透明性のある方法で運営するものとします。
3.2 xxな取扱い。ICANNは実質的かつ合理的な理由によって正当化されない限り、基準、ポリシー、手順、または行動規範の恣意的、不当、あるいは不xxな適用をしたり、当該レジストリオペレータのみに異なる対応を選択したりしてはなりません。
3.3 TLDネームサーバー。 ICANNはレジストリオペレータによってICANNへ提出されたTLDネームサーバー指定への任意の変更（xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/でICANNによって指定される形式と技術的要素による）が7暦日以内に実施されるか、技術的検証後可能な限り速やかに実施されるように商業的に合理的な努力を払います。
3.4 ルートゾーン情報の公開。 ICANNによるTLDルートゾーンの連絡先情報の公開範囲には、レジストリオペレータとその管理および技術担当の連絡先が含まれます。レジストリオペレータの連絡先情報を変更する任意のリクエストは、 xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx/ で随時ICANNによって指定される形式で行う必要
があります。
3.5 権威ルートデータベース。 ICANNが、権威ルートサーバシステム（以下、
「権威ルートサーバシステム」といいます）に関してポリシーを設定できる点において、 ICANNは(a) その権威ルートがTLDのレジストリオペレータによって指定されたトップレベルドメインへ向けられ、(b) ICANNの公開ポリシーと手順に従って、TLDについての関連情報データベースを安定して、安全に、そして権威を公に利用できるように維持し、
(c) 権威ルートデータベースが安定して、安全な方法で運営され、維持されるように調整するため商業的に合理的な努力を払うものとします。但し、ICANNは本契約に違反してはならず、ICANNは任意の第三者（任意の政府組織やインターネットサービスプロバイダを含む）が任意の法域のTLDへのアクセスをブロックしたり、制限したりする場合にも一切責任を負わないものとします。
第4条。
契約期間および終了
4.1 契約期間。 本契約の契約期間は発効日から10年間とします（かかる契約期間は、4.2項「契約期間」に従って延長することができます）。
4.2 更 新 。
(a) 本契約は4.1項に規定される最初の契約期間の満了にあたり、後続期間10年として更新されます。但し、それぞれの後続期間が次のような場合を除きます：
(i) 本契約の第2条に規定されるレジストリオペレータの誓約に関する基本的かつ重大な違反、あるいは本契約の第6条の下での支払い義
務の違反をICANNがレジストリオペレータへ通知した後、そしてその通知には主張される違反の詳細な説明が特定されているものとし、かかる違反がかかる通知の30暦日以内に改善されていない場合、(A) 調停者または管轄裁判所は最終的にそのレジストリオペレータがそのような誓約の基本的で重大な違反状態、またはその支払い義務の違反であると判断し、(B) レジストリオペレータがそのような判断に従わず、10暦日または調停者や管轄裁判所により決定されたその他の期間以内にそのような違反が改善されていない場合、または
(ii) 当時最新の期間に、レジストリオペレータは調停者または管轄裁判所により、(A) 本契約の第2条に規定されるレジストリオペレータの誓約に対する基本的で重大な違反、または (B) 本契約の第6条の下でのその支払い義務に違反している、少なくとも3件の個別の事態が認識さられているものとします。
(b) 4.2(a) (i)項または(ii)項に規定される事態が発生した際には、本契約は当時最新の期間の満了をもって終了するものとします。
4.3 ICANNによる契約終了
(a) 次の場合には、ICANNはレジストリオペレータへ通知することにより、本契約を終了することができます： (i) レジストリオペレータは(A) 本契約の第１条に 規定されるレジストリオペレータの表明および保証、または第2条に規定される誓約に対する任意の基本的で重大な違反、または (B) 本契約の第6条に規定されるレジストリオペレータの支払い義務に対する任意の違反をその主張される違反の詳細な説明を特定したうえで、ICANNがレジストリオペレータへかかる違反を通知した後、30暦日以内に改善していない場合、(ii) 調停者または管轄裁判所が、レジストリオペレータがかかる誓 約に対し基本的で重大な違反、またはその支払い義務に違反していると最終的に判断し、
(iii) レジストリオペレータが、10暦日以内または調停者や管轄裁判所により決定されたその他の期間以内に、かかる判断に従わず、かかる違反が改善されない場合。
(b) レジストリオペレータがTLDをルートゾーンへ委任するためのすべてのテストと手順（この日に先立ち、レジストリオペレータへ書面にて、ICANNによって特定される）を契約の発効日から12カ月間以内に完了しない場合には、ICANNは通知によって本契約を終了することができます。レジストリオペレータがTLDの委任のために必要となる手順を無事に完了させるために、熱心かつ誠実に作業を進めていることをICANNへ合理的に満足のゆく証明ができる場合には、レジストリオペレータは最大12カ月間まで委任をさらに延期するようにリクエストできます。そのような契約終了日以前に、レジストリオペレータがICANNへ支払った任意の手数料は、ICANNが全額保持するものとします。
(c) (i) レジストリオペレータが本契約の2.12項に規定されるレジストリオペレータの義務に対する重大な違反をICANNがそのような違反の通知を提出した日から30暦日以内に改善しない場合、または継続運営証書が契約発効日の後任意の時点で連続60暦
日間以上有効ではない場合、(ii) 調停者または管轄裁判所がレジストリオペレータはかかる誓約に対して重大な違反状態にあると最終的に判断している場合、かつ (iii) レジストリオペレータがかかる違反を10暦日以内、または調停者または管轄裁判所により決定されたその他の期間以内に改善していない場合。
(d) ICANNは (i) レジストリオペレータが債権者に利益を譲渡したり、同様の行為をしたりする場合、(ii) レジストリオペレータに対して担保権の設定、債権差し押さえ通告、あるいは同様の訴訟手続きが開始され、その訴訟手続きがレジストリオペレータのTLDでの登録運営能力への重大な脅威となり、その開始日から60暦日以内に却下されない場合、(iii) レジストリオペレータの代理として受託者、管財人、清算人、あるいはそれに相当する者が指名された場合、あるいはレジストリオペレータの任意の財産管理権を維持する場合、(iv) レジストリオペレータの任意の重要な財産に差し押さえ処分が執行され、差し押さえられるとレジストリオペレータのTLDでの登録運営能力へ重大な悪影響を与えることが合理的に予想される場合、(v) 任意の破産、支払不能、更生、あるいは債務者の救済に関するその他の法律の下でレジストリオペレータにより、またはレジストリオペレータに対して訴訟手続きが開始され、その訴訟手続きが、その開始日から60暦日以内に却下されない場合（その訴訟手続きが、レジストリオペレータまたはその関係者により開始された場合には）、あるいはその開始日から180暦日以内に却下されない場合（その訴訟手続きが、レジストリオペレータに対して、第三者により開始された場合には）、あるいは、(vi) レジストリオペレータがアメリカ合衆国連邦破産法（合衆国法律集第11編101条以下参照）の下での保護、または海外の同等の法律、清算、解散、あるいはさもなくば、その運営やTLDの運用の廃止を提訴した場合、レジストリオペレータへの通知により、本契約を終結することができます。
(e) ここに記載されるような適用する手順に規定されるレジストリオペレータの契約終結に異議を申し立てる権利を条件として、仕様書7の2項の下での任意の PDDRPパネルやRRDRPパネルによる判断に従い、または仕様書11の2項、3項、またはその他すべての当該条項の下での任意のPICDRPパネルによる判断に従い、ICANNはレジ
ストリオペレータへ30暦日前に通知することにより、本契約を終結することができます。
(f) 金融活動に関係する軽罪、もしくは何らかの重罪で有罪判決を受けた者であること、詐欺もしくは受託者の義務違反を犯したとの判決を管轄裁判所から受けた者であること、または上記のいずれかと実質的に同等であるとICANNが合理的に判断する判決を受けた者であることを知りながら、レジストリオペレータが、その者を役員として雇用している場合で、レジストリオペレータが上記の事実を知った時から30暦日以内に、かかる役員が解雇されなかったとき、またはレジストリオペレータの理事会またはこれに類する統治機関のメンバーが、金融活動に関係する軽罪でもしくは何らかの重罪で有罪判決を受け、詐欺もしくは受託者の義務違反を犯したとの判決を管轄裁判所から受け、または上記のいずれかと実質的に同等であると ICANNが合理的に判断する判決を受けた場合で、レジストリオペレータが上記の事実を知った時から30暦日以内に、かかるメンバーがレジストリオペレータの取締役会またはこれに類する統治機関から解任されないとき。
(g) ICANNは7.5項に指定される通りに、レジストリオペレータに対して 30暦日前に通知することにより、本契約を終了することができます。
(h) [政府間組織や政府機関にのみ適用。] ICANNは、7.16項に従い本契約を終了することができます。
4.4 レジストリオペレータによる契約終了。
(a) (i) 第3条に規定されるICANNの誓約に対する任意の基本的で重大な違反をレジストリオペレータがICANNへその主張される違反の詳細な説明を特定したうえで、かかる通知をICANNへ提出した後30暦日以内にICANNが改善しない場合、(ii) 調停者または管轄裁判所がICANNはそのような誓約に対して基本的で重大な違反状態にあると最終的に判断しており、そして(iii) ICANNが10暦日以内、あるいは調停者または管轄裁判所により決定されたその他の期間以内にかかる判断に従わず、かかる違反を改善しない場合、レジストリオペレータはICANNへ通知することにより、本契約を終了することができます。
(b) レジストリオペレータはICANNへ180暦日前に通知することにより、いかなる理由によっても本契約を終了することができます。
4.5 契約終了時のレジストリの移行。 第4.1項または第4.2項に従う契約期間満了、または第4.3項または第4.4項に従う契約終了により、レジストリオペレータは、ICANNまたはこの第4.5項に従ってICANNがTLDに指定できる後継レジストリオペレータに、 ICANNまたはかかる後継レジストリオペレータが合理的に要求する可能性があるオペレーションおよびレジストリ機能を維持するために必要なTLDのレジストリの運用に関するすべてのデータ（第2.3項に従ってエスクローされたデータを含む）を提供します。 レジストリオペレータとの相談の後、ICANNはその自由裁量により、レジストリ移行プロセスに従って、TLDの運営を後継のレジストリオペレータへ移行するか、否かを判断するものとします。但し、(i) ICANNは、後継レジストリオペレータへTLDの運営を移行させるか、否かを判断するうえで、レジストリオペレータの任意の知的財産権（レジストリオペレータによりICANNへ伝達された通りに）を考慮するものとし、(ii) レジストリオペレータがICANNへ(A) TLDのすべてのドメイン名登録がレジストリオペレータまたはそのアフィリエイトによる独占的な利用のために、それらに対して登録され、それらによって維持され、(B) レジストリオペレータがTLDの任意の登録の管理や使用権をレジストリオペレータのアフィリエイトではない任意の第三者へ販売、配布、移譲しない、そして (C) TLDのオペレーションの移行が公共の利益のために必ずしも必要とは限らない場合、ICANNは本契約の満了や終了にあたって、レジストリオペレータの同意なく、TLDの運営を後継レジストリオペレータへ移行してはならないものとします（そして正当な理由なく、差し控えたり、条件を付けたり、遅延させたりしないものとします）。 誤解避けるため、先行する文章は、第三者の権利を保護するために、かかる申請プロセスに関連してICANNが制定したプロセスや異議申立手続きを条件として、ICANNがトップレベルドメインの委任の今後の申請プロセスに従って、TLDの委任を禁止しているものではありません。 レジストリオペレータは、この第4.5項に従うTLDの移転の際に、TLDに関するDNSおよびWHOISの記録のために、ICANNが必要と考えられる変更をIANAデータベースに加えることに同意します。 さらに、ICANNまたはその代理人は、契約の終了
または満了の理由にかかわらず、TLDの維持および運用のために、継続運営証書に基づく権利を保持するものとし、またかかる権利を行使できます。
[政府間組織、政府機関、またはその他特別な状況の 4.5 項契約終了時のレジストリの移行 の代替テキスト：「契約終了時のレジストリの移行。 本契約の4.1項または4.2項に従う契約期間満了に際し、あるいは本契約の4.3項または4.4項に従う任意の終了に際し、TLDの後継レジストリオペレータをCANNが指定することに関連して、レジストリオペレータとICANNは本4.5項に従ってTLDの移行を促進し、実施するために互いに相談し、協力することに同意します。 レジストリオペレータとの相談の後、ICANNはTLDのオペレーションを後継レジストリオペレータへ移行するか、否かをその自由裁量により、そしてレジストリ移行プロセスに従って判断するものとします。ICANNが後継レジストリオペレータにTLDのオペレーションを移行することを決定する場合、レジストリオペレータの同意によって、レジストリオペレータは、ICANNまたはかかるTLDの後継レジストリオペレータへオペレーションとレジストリ機能を維持するために必要なTLDの運営に関して、この2.3項に従ってエスクローがデポジットされたデータに加えて、ICANNやそのような後継レジストリオペレータから合理的に要求されるデータを提供するものとします。 レジストリオペレータがかかるデータの提供に同意しない場合には、TLDに関する任意のレジストリデータは双方の当事者の同意がない限り、レジストリオペレータへ返却されるものとします。 レジストリオペレータは、この第4.5項に従うTLDの移行の際に、TLDに関するDNSおよびWHOISの記録のために、ICANNが必要と考えられる変更をIANAデータベースに加えることに同意します。 さらに、ICANNまたはその代理人は、本契約の終了または満了の理由にかかわらず、TLDの維持および運用のために、継続運営証書に基づく権利を保持するものとし、またかかる権利を行使できます。」］
4.6 契約終了の影響。 本契約期間の満了、または本契約の終了に際し、双方の当事者の義務と権利はここに停止するものとします。但し、本契約期間の満了、または本契約の終了は、第6条の下で生ずるすべての支払い義務を含みますが、それだけに限らず、そのような満了や終了以前に生じている本契約の任意の義務や違反から双方の当事者を解放しないものとします。 さらに、第5条、第7条、2.12項、4.5項、およびこの4.6項は、本契約の満了または終了後も存続するものとします。 誤解を避けるために、TLDのレジストリを運営するレジストリオペレータの権利は、本契約の任意の契約期間の満了や終了に際して、直ちに停止するものとします。
第5条。紛争の解決
5.1 調停。 本契約の下で、あるいはそれに関連して生ずる任意の紛争の場合に
は、いずれかの当事者が以下の5.2項に従う調停を開始する前に、ICANNとレジストリオペレータは次の契約条件に従う調停により、その紛争の解決を試みる必要があります：
(a) 一方の当事者は他方の当事者へ調停すべき紛争の書面による通知を提出するものとします。調停は、双方の当事者が選定した1名の調停人により行われる
ものとします。第5.1項に従い、調停通知の受領後15暦日以内に当事者が調停人について合意に達することができない場合、当事者は、速やかに、互いに許容可能な調停機関を選定するものとします。かかる機関は、その選定後において可能な限り速やかに、調停人を指名するものとします。かかる調停人は、資格を有する弁護士であって、当該特定の紛争の調停に必要な範囲で契約法に関する全般的な知識を有しており、かつドメイン名システムに関する全般的な知識を有している必要があります。調停人は、当人がICANNまたは該当レジストリオペレータの従業員、パートナー、執行役員、取締役または証券保有者ではなく、また調停期間中にこれらの地位に就かないことについて、書面で確認しなければなりません。 指名された調停人がかかる確認書を提出しない場合は、5.1(a)項に従い代替の調停人を指名するものとします。
(b) 調停人は、当事者との協議のうえで決定した規則および手続きに従い、調停を実施するものとします。 当事者は、紛争に関し誠実に協議するとともに、調停人の助力を受けながら紛争の友好的な解決を目指すものとします。この調停は和解交渉として扱われ、それゆえ部外秘とするものとし、5.2項に従う任意の仲裁を含み、その紛争に関するいずれかの当事者へのその後の訴訟手続きにおいて利用することはできません。調停者は、その紛争に関わるその後の任意の訴訟手続きにおいて、いずれかの当事者のために証言することはできません。
(c) 各当事者は、調停における自身の費用を負担するものとします。 当事者は、調停人の報酬および経費を等しい割合で負担するものとします。 各当事者は他方の当事者から受領した情報を、7.15項に従い他方の当事者の機密情報と同じように適切に部外秘として印を付けて（7.15項により求められるように）、仲裁に従い取り扱うものとします。
(d) 双方の当事者がその仲裁に誠意をもって参加する努力を払うが、任意の理由によってその紛争が解決されない場合には、いずれかの当事者、または調停者は随時その調停を終了することができ、そしてさらに、その紛争を以下の5.2項に従う仲裁に進めることができます。 双方の当事者が任意の理由により、5.1(a)項に従い提供された通知日以降、90暦日以内にその紛争を解決できない場合、調停者は自動的に終了（双方の当事者の合意により延長されない限り）させるものとし、その紛争を以下の5.2項に従う仲裁に進めることができます。
5.2 仲裁。特定の性能の要求などを含め5.1項に従って解決されない、本契約の下で、あるいは本契約に関連して生ずる紛争は、国際商業会議所（以下、「ICC」といいます）の国際仲裁裁判所の規則に従って実施される拘束力を持つ仲裁により解決されます。 仲裁は、米国カリフォルニア州ロサンゼルス郡において英語で実施されるものとします。 (i) ICANNが刑罰的、懲罰的損害賠償または運営上の制裁を求める場合、(ii) 双方の当事者が書面にて多人数の仲裁者の設置に同意する場合、あるいは(iii) 7.6項または7.7項の下で紛争が生じた場合を除き、すべての仲裁は単独の仲裁者の下で実施されます。 前文の(i)、(ii)または(iii) 項の場合、仲裁は各当事者がICCにより承認される1名の仲裁者を指名し、その2名の仲裁者がICCにより承認される3人目の仲裁者を指名し、合計3名の仲裁者の下で実施されま
す。 唯一の仲裁者の下で実施される仲裁のために、レジストリオペレータとICANNは相互の合意により、ICCにより承認される唯一の仲裁者を指名することができます。 双方の当事者が唯一の仲裁者を指名できない場合、3名の仲裁者の下での仲裁の際に、いずれかの当事者が1名の仲裁者を指名できない場合には、ある当事者の仲裁請求が他方の当事者に受け入れられた日から30暦日以内、またはICCの裁判所事務局により認められる延長期間内に、仲裁者がICCにより指名されるものとします。 任意の指名された仲裁者がICCにより承認されない場合、その仲裁者を指名した当事者または個人は、ICCにより承認される代わりの仲裁者を速やかに指名するものとします。 仲裁を促進し、そのコストを制限するために、仲裁者は仲裁に関連した当事者の訴状のページ数制限を設定するものとし、仲裁者が、公聴会が必要であると判断した場合には、公聴会は1日に制限されるものとします。但し、ICANNが刑罰的、懲罰的損害賠償あるいは運営上の制裁を求めている任意の仲裁において、双方の当事者による合意、仲裁者の独自の判断やこの当事者の一方の合理的な要請に基づいた仲裁者による命令がある場合には、公聴会を1日延長することができます。 仲裁における勝訴当事者には、仲裁者が裁定に含めるそのコストと合理的な弁護士費用を回収する権利があります。レジストリオペレータが本契約の2条、6条または5.4項に規定されるその義務に対し、繰り返し、故意に、xx的で重大な違反をしていると仲裁者が判断する場合には、ICANNは仲裁者に刑罰的、懲罰的損害賠償、あるいは運営上の制裁（レジストリオペレータが新規登録を販売する権利の一時的な制限を含みますが、これに限りません）を課す裁定を要求することができます。各当事者は他方の当事者から受領した情報を、7.15項に従い他方の当事者の機密情報と同じように適切に部外秘として印を付けて（7.15項により求められるように）、仲裁に従い取り扱うものとします。本契約に関してICANNが関係する任意の訴訟は、すべて米国カリフォルニア州ロサンゼルス郡の裁判所を専属管轄および裁判地とします。但し、各当事者は、そのような裁判所の判決を任意の管轄裁判所において執行する権利も有します。
[政府間組織、政府機関、またはその他特別な状況の 5.2項仲裁の代替テキスト：
「仲裁。 特定の性能の要求などを含め5.1項に従って解決されない、本契約の下で、あるいは 本契約に関連して生ずる紛争は、国際商業会議所（以下、「ICC」といいます）の国際仲裁裁判所の規則に従って実施される拘束力を持つ仲裁により解決されます。 仲裁は英語で行われ、別の場所がレジストリオペレータとICANNにより相互に合意される場合を除き、スイスのジュネーブで実施されます。 (i) ICANN が刑罰的、懲罰的損害賠償または運営上の制裁を求める場合、(ii) 双方の当事者が書面にて多人数の仲裁者の設置に同意する場合、 あるいは(iii) 7.6項または7.7項の下で紛争が生じた場合を除き、すべての仲裁は単独の仲裁者の下で実施されます。 前文の(i)、(ii) または (iii) 項の場合、仲裁は各当事者がICCにより承認される1名の仲裁者を指名し、その2名の仲裁者がICCにより承認される3人目の仲裁者を指名し、合計3名の仲裁者の下で実施されます。 唯一の仲裁者の下で実施される仲裁のために、レジストリオペレータとICANNは相互の合意により、ICCにより承認される唯一
の仲裁者を指名することができます。双方の当事者が唯一の仲裁者を指名できない場合、 3名の仲裁者の下での仲裁の際に、いずれかの当事者が1名の仲裁者を指名できない場合 には、ある当事者の仲裁請求が他方の当事者に受け入れられた日から30暦日以内、また
はICCの裁判所事務局により認められる延長期間内に、仲裁者がICCにより指名されるものとします。 任意の指名された仲裁者がICCにより承認されない場合、その仲裁者を指名した当事者または個人は、ICCにより承認される代わりの仲裁者を速やかに指名するものとします。 仲裁を促進し、そのコストを制限するために、仲裁者は仲裁に関連した当事者の訴状のページ数制限を設定するものとし、仲裁者が、公聴会が必要であると判断した場合には、公聴会は1日に制限されるものとします。但し、ICANNが刑罰的、懲罰的損害賠償あるいは運営上の制裁を求めている任意の仲裁において、双方の当事者による合意、仲裁者の独自の判断やこの当事者の一方の合理的な要請に基づいた仲裁者による命令がある場合には、公聴会を1日延長することができます。 仲裁における勝訴当事者には、仲裁者が裁定に含めるそのコストと合理的な弁護士費用を回収する権利があります。 レジストリオペレータが本契約の2条、6条または5.4項に規定されるその義務に対し、繰り返し、故意に、xx的で重大な違反をしていると仲裁者が判断する場合には、 ICANNは仲裁者に刑罰的、懲罰的損害賠償、あるいは運営上の制裁（レジストリオペレータが新規登録を販売する権利の一時的な制限を含みますが、これに限りません）を課す裁定を要求することができます。各当事者は他方の当事者から受領した情報を、7.15項に従い他方の当事者の機密情報と同じように適切に部外秘として印を付けて（7.15 項により求められるように）、仲裁に従い取り扱うものとします。 本契約に関してICANNが関係する任意の訴訟は、レジストリオペレータとICANNにより他の場所が相互に合意される場合を除き、スイス、ジュネーブの裁判所を専属管轄および裁判地とします。但し、各当事者は、そのような裁判所の判決を任意の管轄裁判所において執行する権利も有します。」]
5.3 責任の制限。 ICANNの本契約への違反に対する賠償責任総額は、本契約に従う直前の12カ月間にレジストリオペレータがICANNへ支払ったレジストリレベル手数料に等しい金額を超えることはありません（もしあれば、6.3項に規定される変動レジストリレベル手数料を除く）。 レジストリオペレータの本契約への違反に対するICANNへの賠償総額は、もしあれば、7.1項と7.2項に従うレジストリオペレータの損害賠償責任に関するものを除き、5.2項に従って裁定される、直前の12カ月間（もしあれば、6.3項に規定される変動レジストリレベル手数料を除く）にICANNへ支払った金額と刑罰的、懲罰的損害賠償に制限されます。 いかなる場合においても、5.2項に規定される場合を除き、いずれかの当事者は本契約から、または本契約に関連して生ずる、あるいは本契約に取り入れられた義務の履行や不履行から、あるいはそれらに関連して生ずる特別な刑罰的、懲罰的、あるいは間接的損害賠償責任を負うことはないものとします。 本契約に特に規定さる場合を除き、いずれの当事者も当事者自身、その使用人、または代理人により提供されるサービスに関して、あるいはそれらの仕事から得られる結果に関して、特定の用途に対する任意の暗示的な市場性、非侵害や適合性を含みますが、それにだけに限らず、一切の明示的あるいは黙示的保証をしないものとします。
5.4 特定の性能。 レジストリオペレータおよびICANNは、本契約の任意の規定が、その特定の条項に従って実施されなかった場合に、回復不能な損害が発生することに同意します。 したがって、双方の当事者は、そのそれぞれが仲裁者や管轄裁判所に本契約の特定の条項の実施を求める権利を有するものとします（それぞれの当事者が権利を有するその他いずれかの救済に加えて）。
第6条。手数料
6.1 レジストリレベル手数料。
(a) レジストリオペレータはICANNへ (i) 四半期ごとに6,250米ドルの固定登録手数料、および (ii) レジストリレベルトランザクション手数料に相当するレジストリレベル手数料を支払うものとします（以下、集合的に「レジストリレベル手数料」といいます）。 レジストリレベルトランザクション手数料は、該当する四半期のドメイン名の初期または更新登録（１つ以上のレベルで、あるICANN認定レジストラから別の認定レジストラへの移行に関連する更新を含み、以下、それぞれを「トランザクション」といいます）の年間増分数に0.25米ドルを乗算した金額に相当します。但し、レジストリレベルトランザクション手数料は、任意の四半期に、あるいは次の任意の4四半期の総計でTLDに50,000以上のトランザクションが発生（以下、「トランザクションの基準」といいます）するまで、あるいは発生しない限り、適用されないものとし、各四半期に発生したそのトランザクションの基準を満たす各トランザクションに適用しますが、そのトランザクションの基準を満たしていない各四半期には適用しないものとします。四半期ごとのレジストリレベル固定手数料を支払うレジストリオペレータの義務は、TLDがDNS内でレジストリオペレータへ委任される日に始まります。レジストリレベル固定手数料の最初の四半期の支払いは、委任日とその委任日が含まれる四半期末との間の暦日数に基づいて日割り計算されます。
(b) 6.1(a)項に従い、レジストリオペレータはレジストリレベル手数料を四半期ベースでICANNによって指定されたアカウントへICANNにより請求書が提供された日以降30暦日以内に支払うものとします。
6.2 RSTEPのためのコスト回収。 2.1項に従い追加サービスの承認を得るためのレジストリオペレータからのリクエストは、xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/ でのプロセスに従い、ICANNによりレジストリサービス技術評価パネル(RSTEP) へ照会されます。 そのようなリクエストがRSTEPへ照会される場合、ICANNが絶対的な裁量権により、かかる請求書に記載されたRSTEPのレビュー費用の全額または一部を支払うことを決断しない限り、レジストリオペレータは請求書に記載されたRSTEPレビューの費用を ICANNからRSTEPの請求書のコピーを受け取った日から14暦日以内にICANNへ送金するものとします。
6.3 変動レジストリレベル手数料。
(a) ICANN認定レジストラが（総数では、すべてのレジストラ-レベル手数料の2/3の支払いを占める（または、当時最新のレジストラ認定契約の下で変動認定手数料を承認する必要があるICANN認定レジストラの割合））ICANNとのレジストラ認定契約の条件に従い、 ICANNの任意の会計年度のICANN理事会により設定された変動認定手数料を承認しない場合、 ICANNからの通知の提出により、レジストリオペレータは変動レジストリ-レベル手数料を支払
い、そしてそれは四半期ベースで支払われ、そのICANNの会計年度第1四半期の開始時に発生するものとします（以下、「変動レジストリ-レベル手数料」といいます）。 手数料はICANNにより四半期ベースで計算され、請求書が送られ、ICANNの会計年度の第1四半期に関しては、ICANNから金額を示した請求書を受領してから60暦日以内に、残りの四半期に関しては20暦日以内に、レジストリオペレータにより支払われるものとします。 レジストリオペレータは、レジストリオペレータとのレジストリ-レジストラ契約（本契約はこの6.3項に従ってレジストリオペレータによって支払われる変動レジストリ-レベル手数料の償還のために特別に提供することができます）の一方の当事者であるレジストラからの変動レジストリ-レベル手数料の請求書を提出し、徴収することができます。但し、いずれかへ請求書が提出される場合には、この手数料についてすべてのICANN認定レジストラへ請求書が提出されるものとします。 ICANNによって徴収できる場合には、変動レジストリ-レベル手数料は、レジストリオペレータの義務とし、レジストリオペレータがレジストラからそのような手数料の償還を求め、取得する能力に拘わらず、この6.3項に規定されるように当然支払うべきものであり、支払い義務が生じるものとします。 レジストリオペレータがICANNに支払っている変動レジストリ-レベル手数料をICANNが後で徴収する場合、ICANNにより合理的に判断されるように、ICANNはレジストリオペレータへ変動レジストリ-レベル手数料の適切な金額を償還するものとします。 ICANN認定レジストラ（グループとして）が、ICANNとのレジストラ認定契約の条項に従い、ある会計年度のICANN理事会によって設定された変動認定手数料を承認する場合、その会計年度中にそのICANN認定レジストラが ICANNへの支払い義務を遵守しているか否かに拘わらず、この取り決めに従ってICANNはその会計年度の変動レベル手数料を受け取る権利を有しないものとします。
(b) 変動レジストリレベル手数料金額は、各レジストラに対して指定され、レジストラのコンポーネントとトランザクションのコンポーネント双方を含みます。変動レジストリレベル手数料の各-レジストラのコンポーネントは、ICANNの各会計年度にICANN理事会によって採用された予算に従って、ICANNにより指定されるものとします。 変動レジストリレベル手数料のトランザクションのコンポーネントは、ICANNの各会計年度にICANN理事会によって採用された予算に従って、ICANNにより指定されるものとしますが、ドメイン名登録（認定レジストラから別の認定レジストラへの移行に関する更新を含む）1件当たり年間0.25米ドルを超えないものとします。
6.4 転嫁される手数料。 レジストリオペレータはICANNへ (i) 仕様書7に記載され るようにTrademark Clearinghouseへのアクセスと利用に対して1回限りの手数料5,000米ドル相当を支払い（以下、「RPMアクセス手数料」といいます）、(ii) サンライズ登録およびクレーム登録（仕様書7に従いこのような用語自体はTrademark Clearinghouse RPM で使用される用語 がここに取り入れられています）ごとに0.25米ドルを支払うものとします（以下、「RPM登録手数料」といいます）。 RPMのアクセス料は、本契約の発効日の時点で請求され、レジストリオペレータは、請求書の日付以降30暦日以内にICANNにより指定されたアカウントへその手数料を支払うものとします。 ICANNは、レジストリオペレータに対して RPM登録手数料を四半期ごとに請求し、そしてそれは6.1項に指定される請求書発行と支払い手続きに従い満期となるものとします。
6.5 手数料の調整。 本第6条に規定される任意の手数料の制限にも拘らず、本契約の初年度とそれ以降契約期間の各年度の満了時に始まる、6.1項と6.3項に規定される当時最新の手数料は、ICANNの裁量により、もしあれば (i) アメリカ合衆国労働省労働統計局発表の都市部全消費者物価指数(1982-1984年＝100）、または該当する年度開始前の１カ月前の月の任意の後継指標（以下、「CPI」といいます）、または(ii) 直前の年度開始前の１カ月前の月の公開されたCPIにおける変化の割合に等しい割合で調整することができます。 かかる任意の値上げの場合には、ICANNはレジストリオペレータへそのような調整金額を指定した通知を提供するものとします。 本6.5項の下での任意の手数料の調整は、ICANNがレジストリオペレータへかかる手数料調整通知を提出した後、少なくとも30暦日後の最初の四半期の初日時点で有効であるものとします。
6.6 延滞料。 本契約の下で任意の支払いが30暦日以上遅延している場合、レジストリオペレータは1月あたり1.5%または少なくとも適用する法律で許される最大の利息で延滞料を支払うものとします。
6.7 手数料減額免除。 ICANNの独自の裁量により、ICANNはこの取り決めによって、レジストリオペレータが支払うべきレジストリ手数料の金額を任意の期間減額することができます（以下、「手数料減額免除」といいます）。 ICANNの独自の裁量で判断されるように、任意の手数料減額免除は、そのような権利の放棄に規定される契約条件をレジストリオペレータが受け入れることにより(a) 期間限定、そして (b) 条件付きとすることができます。 手数料減額免除は、7.6(i)項で検討されるように、ICANNにより書面にて執行する場合を除き、効力を持たないものとします。 ICANNは7.9項に従いレジストリオペレータへ任意の手数料減額免除を通知します。
第7条。 その他の事項
7.1 ICANNの免責。
(a) レジストリオペレータは、ICANNとその取締役、幹部職員、従業員および代理人（以下、「集合的に「被補償者」といいます）を、TLDに関する知的所有権、レジストリオペレータへのTLDの委任、レジストリオペレータのTLDの運営、またはレジストリオペレータのレジストリサービスの提供から生じる、またはそれらに関連する合理的な弁護士費用と経費を含む、一切の第三者の請求、損害、法的責任、費用および経費から補償し、免責を与えるものとします。但し、レジストリオペレータは次の理由により生じた任意の請求、損害、法的責任、費用および経費の範囲まで、任意の被補償者を補償し、免責を与える義務を負わないものとします： (i) レジストリTLD申請プロセスの期間に関連して生ずるICANN、その請負業者、パネリストまたは評価者の作為、あるいは不作為による（レジストリオペレータにより、あるいはそのために要求された作為、あるいは不作為を除く）、または、(ii) 本契約に含まれる任意の義務をICANNが違反する、またはICANNにより故意に任意の不正が行われたことによる。 本項はレジスト
リオペレータに本契約の交渉や執行に関連したコスト、あるいは双方の当事者のそれぞれの義務の監視や管理に関連したコストをこの記載に従って、ICANNへ返金または補填するように求めているとはみなされないものとします。 さらに、本項は第5条に支配されるか、管轄裁判所や調停者により裁定されるべき当事者間の任意の訴訟や仲裁に関連した、任意の弁護士費用の請求には適用されないものとします。
[政府間組織や政府機関のための7.1(a) 項の代替テキスト：「レジストリオペレータは、ICANNがTLDに関する知的所有権、レジストリオペレータへのTLDの委任、レジストリオペレータのTLDの運営、またはレジストリオペレータのレジストリサービスの提供から生じる、またはそれらに関連する合理的な弁護士費用と経費を含む、任意の請求、損害、法的責任、費用や経費に関連したコストを負わないことを保証するために最大の努力を払うものとします。但し、レジストリオペレータは本契約に含まれる任意の義務をICANNが違反したり、ICANNが故意に不正を行ったりしたことを理由として生じた任意の請求、損害、法的責任、費用および経費の範囲まで、そのような協力を提供する義務を負わないものとします。本項はレジストリオペレータに本契約の交渉や執行に関連したコスト、あるいは双方の当事者のそれぞれの義務の監視や管理に関連したコストをこの記載に従って、ICANNへ返金または補填するように求めているとはみなされないものとします。 さらに、本項は第5条に支配されるか、管轄裁判所や調停者により裁定されるべき当事者間の任意の訴訟や仲裁に関連した、任意の弁護士費用の請求には適用されないものとします。」] (b) 複数のレジストリオペレータ（当該レジストリオペレータを含む）が請求の対象となる同じ作為や不作為に関わっていることによる免責のための ICANNからの任意の請求に対し、かかる請求に関して当該レジストリオペレータがICANNを免責する賠償総額は、TLD内部の当該レジストリオペレータの下で登録されているドメイン名総数
（登録されているドメイン名数は、任意の該当する四半期に第6条とこれに関して一貫性を保って計算されるものとします）をその複数のレジストリオペレータがかかる請求が起こされている同じ作為や不作為に関わるすべてのトップレベルドメイン内部で登録されているドメイン名総数で除算して計算される、あるICANNの請求総額の割合に限定されるものとします。 本7.1(b)
項に従い7.1(a)項の下で当該レジストリオペレータの賠償責任を軽減する目的のために、当該レジストリオペレータはその請求が起こされている同じ作為または不作為に関わる その他のレジストリオペレータの賠償責任を負担し、その他のレジストリオペレータの そのような作為や不作為に対する過失責任をICANNの合理的な納得が得られるまで証明 するものとします。 誤解を避けるために、あるレジストリオペレータが、請求が起こさ れている同じ作為や不作為に関わっている場合であっても、かかるレジストリオペレー タは上記の7.1(a)項に規定されるように、ICANNへ同じあるいは同様の賠償責任を負うこ とはありませんが、そのようなレジストリオペレータにより管理されるドメイン数は、 それにも拘わらず、前述の文の計算の中に含まれるものとします。[注： 本7.1 (b)項は、 政府間組織や政府機関に適用できません。]
7.2 補償手続き。 任意の第三者の請求が上記の7.1項の下で賠償開始される場合、ICANNはできる限り速やかにレジストリオペレータへその通知を提供するものとします。 レジストリオペレータは、そのように選択する場合には、ICANNへ速やかに通知を提供することにより、そのような請求からの弁護および調査の主導権を握り、レジス
トリオペレータ単独の費用と経費負担により、ICANNが合理的に許容できる弁護士を雇用して契約し、同様に対応して弁護する権利を有するものとします。但し、どのような場合にも、ICANNは単独の費用と経費負担により、ICANNのポリシー、付属定款または行為の正当性や解釈に関する問題の訴訟を主導する権利を有します。ICANNはレジストリオペレータの費用と経費負担により、そのような請求とそれから生ずる任意の上告の調査、裁判、および弁護の中でレジストリオペレータとその弁護士にあらゆる合理的な観点で協力するものとし、そしてその単独の費用と経費負担により、その弁護士やその他により、そのような請求とそれから生ずる任意の上告の調査、裁判、および弁護に参加することができます。レジストリオペレータによって免責される金額で金銭が支払われる以外に、ICANNへ影響を与える救済策に関連する請求の和解は、ICANNの同意なく締結されることはありません。 レジストリオペレータが、本7.2項に従うそのような弁護の対象となる弁護の完全な主導権を想定していない場合、ICANNはレジストリオペレータの費用と経費負担により、適切であるとみなせるような方法でその請求を弁護する権利を有し、そしてレジストリオペレータはかかる弁護に協力するものとします。 [注：本7.2項は、政府間組織や政府機関に適用できません。]
7.3 定義された用語。 本契約の目的のために、次の定義がかかるコンセンサスポリシーに規定されるように完全に改定され、再提示されたとみなされるように、かかる定義が今後コンセンサスポリシーに従って改定されない限り、安全性と安定性は次の通りに定義されるものとします：
(a) 本契約の目的のために、提案されたレジストリサービスによる「安全性」への影響とは、（1） レジストリデータの無許可の開示、変換、挿入、または破壊、または（2） 該当するすべての標準規格に基づき運営されているシステムによるインターネット上の、情報やリソースへの不正なアクセスやそれらの開示を意味します。
(b) 本契約の目的のために、「安定性」への影響とは、（1） レジストリサービスが、IETFによる標準化過程やベストカレントプラクティスRFCのような、広く認知されている権威のある標準規格の推進団体により公表された、権威のある適切かつ妥当な基準を遵守していない、あるいは（2） 標準化過程やベストカレントプラクティスRFCのような広く認知されている権威のある標準規格の推進団体により公表された権威のある適切かつ妥当な基準に従い運営され、レジストリオペレータが委任された情報や提供されるサービスを信頼しているインターネットサーバーまたはエンドシステムのスループット、応答時間、一貫性や整合性を低下または悪化させる状況を、レジストリサービスが生成することです。
7.4 相殺禁止。 本契約の下で当然支払われるべきすべての支払いは、契約期間全体を通して、レジストリオペレータとICANNとの間の任意の紛争（金銭またはその他）が未決であっても、タイムリーに行われます。
7.5 管理の変更、譲渡および請負契約。 本7.5項に規定される場合を除き、いずれの当事者も他方の当事者の事前の書面による承認なくして、本契約の下でのその権
利と義務を譲渡することはできず、そしてその承認を正当な理由なく、差し控えることはできません。 本7.5項の目的のために、レジストリオペレータまたはTLDの任意の重大な機能（仕様書10の6項に特定されるように）に関する任意の請負契約協定（以下、
「重大な請負契約協定」といいます）の直接または間接の管理の変更は、譲渡とみなされるものとします。
(a) レジストリオペレータは30暦日以上前にICANNへ任意の譲渡、または重大な請負契約協定の事前通知を提供する必要があり、TLD運営（重大な請負契約であるか否かに拘わらず）の任意の部分の任意の譲渡契約や請負契約は、この記載に従って、レジストリオペレータによるすべての誓約、義務および合意を遵守することが必須の義務として課され、そしてレジストリオペレータはかかる誓約、義務、および合意によって法的に拘束され続けるものとします。 レジストリオペレータはまた、結果としてレジストリオペレータの直接または間接の管理の変更につながることが想定される任意のトランザクションの完了に先立ち、ICANNへ30暦日前までに事前通知を提供する必要があります。
(b) 7.5(a)項に従うかかる通知の日から30暦日以内に、ICANNはレジストリオペレータから (i) 本契約へのコンプライアンスの確立状況、および (ii) 当事者が取得している経営権や締結している譲渡や請負契約協定（以下、いずれの場合にも「契約当事者」といいます）、そして最終的な契約当事者の元受け組織が、ICANNが採用しているその時点で有効なレジストリオペレータの基準に関する仕様やポリシー（財務リソース、運営および技術的能力に関するものを含む）を満たしているかについて、追加情報を要求することができ、その場合にはレジストリオペレータは要求された情報を15暦日以内に提供する必要があります。
(c) レジストリオペレータは、任意の譲渡、管理または重大な請負契約協定の変更へのICANNの同意が、任意の提案された契約当事者（および、かかる契約当事者のアフィリエイト）の背景確認の対象となることに同意します。
(d) ICANNがそのようなトランザクションの通知をレジストリオペレータから受領した日から30暦日以内に（または、上記のようにICANNがレジストリオペレータから追加情報を要求する場合、そのようなトランザクションに関して書面により要求したすべての情報を受領した日から30暦日以内）、任意の譲渡、直接または間接のレジストリオペレータの管理の変更、あるいは任意の重大な請負契約協定への明白な同意を提供しない、あるいはそれを差し控える場合には、ICANNはそのようなトランザクションに同意したとみなされるものとします。
(e) 任意の譲渡、管理の変更、重大な請負契約協定に関連して、レジストリオペレータはレジストリトランザクションプロセスを遵守するものとします。
(f) 先行する記述にも拘らず、(i) 任意の完了した管理の変更はICANNによって無効にできないものとします。但し、ICANNがそのようなトランザクションへ同意を与えないことを合理的に決定する場合には、ICANNは4.3(g)項に従って本契約を終結できます。(ii) ICANNは本契約の契約条件をかかる譲受人が明白に引き継ぐ際に、ICANNの再編、再構成、再
編入と同時に、ICANN理事会の承認により、レジストリオペレータの同意なく、本契約を譲渡することができます。(iii) レジストリオペレータはその契約条件がこの以下に定義されるように、本契約の契約条件をかかる関連する譲受人が明白に書面にて引き継ぐ際に、ICANNによる同意なく、関連する譲受人へ直接本契約を譲渡することができます。(iv) この7.5項に従ってかかる通知をICANNが受領した日から10暦日以内に、ICANNがレジストリオペレータへかかるトランザクションへの異議を書面にて提出しない限り、ICANNはその契約の当事者と ICANNとの間でのレジストリ契約に従って（但し、そのような契約の当事者がその時点で、そのレジストリ契約の契約条件を全ての重要な点において遵守している場合に限ります）、任意の譲渡、重大な請負契約協定、あるいは契約の当事者がジェネリックトップレベルドメイン
（Generic Top Level Domain）の既存の運営者であるトランザクションの管理の変更に同意しているとみなすものとします。 7.5(a)項にも拘らず、この7.5(f)項の(ii)または(iii)に従って、譲渡が実施された場合には、譲渡する側の当事者は他方の当事者へそのような任意の譲渡の後に速やかに通知します。 この7.5(f)項のために、(A) 「関連する譲受人」とは1名以上の仲介者により、直接的または間接的に、指定された個人や団体を管理する、あるいはそれらに管理される、あるいはそれらと共通の管理下にある個人あるいは団体を指し、そして、(B) 「管理」（以下、「管理される」および「共通の管理下にある」という言葉を含む）とは本契約の2.9(c)項に指定されるものと同じ意味を持つものとします。
7.6 修正および免除。
(a) 本契約（本契約で言及された仕様を含みます。但し、かかる仕様の修正が明示的に禁止されている場合を除きます）およびICANNと該当レジストリオペレータとの間のその他すべての契約（以下、「該当レジストリオペレータ契約」といいます）に対する修正（以下、各々を「特別修正事項」といいます）を行うことが望ましいとICANN理事会が決定した場合、ICANNは、本7.6項に規定された要件および手続きに従い、特別修正事項を採択することができます。但し、特別修正事項は、制限的修正事項であってはなりません。
(b) レジストリオペレータの承認を受けるために特別修正事項を提出する場合、ICANNは、事前にかつ最初に、かかる特別修正事項の形式および内容について、ワーキンググループと誠実に協議するものとします。 かかる協議の期間は、特別修正事項の内容に基づき、ICANNが合理的に決定するものとします。 かかる協議の後、ICANNは、かかる修正をICANNのウェブサイトにおいて30暦日以上の期間（以下、「公示期間」といいます）にわたって掲載するとともに、かかる修正予定を7.9項に従って該当レジストリオペレータに通知することにより、特別修正事項の採択を提案することができるものとします。 ICANNは、特別修正事項に関して公示期間中に提出されたパブリックコメント（該当レジストリオペレータから提出されたコメントを含みます）を検討するものとします。
(c) 公示期間の満了後180暦日（以下、「承認期間」といいます）以内にICANN理事会が特別修正事項を承認した場合（かかる特別修正事項は、ワーキンググループおよびパブリックコメントによる意見を反映させ、および/またはこれらに対応したことにより、パブリックコメントの募集時に提出されたものとは形式が異なる場合がありますが、パブリックコメントのために公示された特別修正事項の主題に対応するも
のである必要があります）、ICANNは、該当レジストリオペレータの諾否を諮るため、かかる特別修正事項の通知および提出を行うものとします。ICANNが該当レジストリオペレータへ上記通知を行った日後60暦日の期間内にかかる特別修正事項についてレジストリオペレータによる承認を受領する場合、かかる特別修正事項は、該当レジストリオペレータによる承認を受けたものとみなされ（以下、「承認済み修正事項」といいます）、ICANNがかかる承認済み修正事項の承認の通知をレジストリオペレータに対し行った日から60暦日後（以下、「修正発効日」といいます）に効力を生じ、本契約への修正がなされたものとみなされます。特別修正事項についてレジストリオペレータによる承認を受領しなかった場合、かかる特別修正事項は、該当レジストリオペレータによる承認を受けなかったものとみなされます（以下、「却下済み修正事項」といいます）。 却下済み修正事項は、以下に規定するものを除き、本契約の条件に影響を及ぼさないものとします。
(d) ICANN理事会は、却下済み修正事項がコンセンサスポリシーおよびテンポラリポリシーに関する仕様の1.2項に定められた主題カテゴリに該当すると合理的に判断した場合には、かかる却下済み修正事項の内容に関する分野別トップレベルドメイン名支持組織（以下、「GNSO」といいます）による課題レポート（ICANNの付属定款における定義語です）を要求する旨の決議案を採択できるものとします（かかる決議案の採択日は、以下、本契約において「決議案採択日」といいます）。 かかる要求のあった課題レポートに従いGNSOが担当するポリシー策定プロセスは、本契約において
「PDP」といいます。 かかるPDPの結果として、(i) 却下済み修正事項をコンセンサスポリシーとして採択することを勧告するかまたは(ii) 却下済み修正事項をコンセンサスポリシーとして採択しないことを勧告する最終報告書がGNSO圧倒的多数（ICANNの付属定款に定義）によって支持された場合で、上記のうち (i) の場合にかかるコンセンサスポリシーを理事会が採択したときは、レジストリオペレータは、本契約の2.2項に基づく自身の義務を遵守するものとします。いずれの場合も、ICANN は却下済み修正事項を破棄するものとし、かかる却下済み修正事項は、本契約の条件に対し何らの効力も有しないものとします。 上記7.6(d)項にもかかわらず、7.6(c)項に基づくレジストリオペレータ承認を得るための却下済み修正事項の提出前12か月の期間内における何らかの時点で、かかる却下済み修正事項の主題が終結済みまたはその他破棄済みもしくは終了済みのPDPの対象となっており、それがGNSO圧倒的多数による勧告に至らなかった場合、ICANN理事会は、かかる却下済み修正事項について、PDPの開始を義務付けられないものとします。
(e) (a)却下済み修正事項がコンセンサスポリシーおよびテンポラリポリシーに関する仕様の1.2項に定められた主題カテゴリに該当しない場合、(b) 7.6項に基づくレジストリオペレータ承認を得るための却下済み修正事項の提出前12か月の期間内における何らかの時点で、かかる却下済み修正事項の主題が終結済みまたは破棄済みもしくは終了済みのPDPの対象となっており、それがGNSOの圧倒的多数による勧告に至らなかった場合、または(c) PDPの結果として、(A) 却下済み修正事項をコンセンサスポリシーとして採択することを勧告するかまたは(B) 却下済み修正事項をコンセンサスポリシーとして採択しないことを勧告する最終報告書が、GNSO圧倒的多数による支持を受
けるに至らなかった場合（またはかかるPDPが何らかの理由で破棄されもしくは終了した場合）はいずれも、かかる却下済み修正事項は、依然として採択することが可能なものとし、以下の方法によって有効になるものとします。 却下済み修正事項が採択されるためには、以下の要件を満たす必要があります。
(i) 却下済み修正事項の主題が、ICANNのミッションの範囲内にあり、かつその本質的価値（ICANNの付属定款に定義）のxxな適用と矛盾しないものであること。
(ii) 却下済み修正事項が、根拠あるやむを得ない公益的理由によって正当化されるものであって、却下済み修正事項により影響を受ける可能性のある公的または私的な対立利益を考慮に入れたとしても、かかる公益を促進する可能性があり、かつかかる根拠あるやむを得ない公益的理由に対処するために合理的に必要な範囲を超えないように厳密に調整されたものであること。
(iii) 却下済み修正事項により、行為もしくは活動が禁止されもしくは義務付けられ、該当レジストリオペレータに重大な負担を課され、および/またはドメイン名サービスへのパブリックアクセスが大きく減少することとなる範囲において、却下済み修正事項が、公共の利益上の根拠あるやむを得ない理由に対処するために合理的に利用可能な方法のうち、最も制限的でないものであること。
(iv) ICANN理事会が、30暦日以上の期間にわたるパブリックコメントの募集のため、上記サブクローズ(i) ～ (iii) に定められた要件に却下済み修正事項が合致しているとの当理事会の判断に関する理由付けを説明する書面を添えて、却下済み修正事項を提出すること。
(v) かかるパブリックコメント募集期間の後に、ICANN理事会が、
（i) ワーキンググループ、主題に関する専門家、GNSOのメンバー、関連の諮問機関およびその他の利害関係者との間で、かかる却下済み修正事項について、60暦日以上の期間にわたり、協議を行い（またはかかる協議を行うことをICANNの管理者に指示し）、かつ(ii) かかる協議の後に、却下済み修正事項（かかる却下済み修正事項は、ワーキンググループおよびパブリックコメントによる意見を反映させ、および/またはこれらに対応したことにより、レジストリオペレータ承認を得るために提出されたものとは形式が異なる場合がありますが、却下済み修正事項の主題に対応するものである必要があります）を、当該事項について投票権を有するICANN理事会メンバーの3分の2以上の賛成投票により、再承認した場合（以下、「理事会修正事項」といいます）。なお、かかる投票権の有無は、ICANNの利益相反に関するポリシーなど、かかる投票権に影響を及ぼすICANNの一切のポリシーを考慮に入れたうえで判断されるものとします。
かかる理事会修正事項は、7.6(f)項を条件として、承認済み修正事項とみなされるとともに、ICANNがかかる理事会修正事項の承認の通知をレジストリオペレータに対し行った日から60暦日後に効力を生じ、本契約への修正がなされたものとみなされます（かかる効力の発生日は、本契約において、修正事項発効日とみなされるものとします）。 上記にかかわらず、理事会修正事項によって、本契約に基づきICANNによって請求されるレジストリ手数料、または本7.6項を修正することはできないものとします。
(f) 7.6(e)項の規定にかかわらず、理事会修正事項のICANN理事会による承認後30暦日以内に、ワーキンググループが、該当レジストリオペレータのために、以下のすべての要件を満たす理事会修正事項の代替案（以下、「代替的修正事項」といいます）をICANN理事会へ提出した場合には、理事会修正事項が、承認済み修正事項とみなされることはないものとします。
(i) 理事会修正事項に代えて、本契約の修正としてワーキンググループが提案する明確な文言が記載されていること。
(ii) 理事会修正事項を正当化するものとしてICANN理事会が明らかにした公共の利益上の根拠あるやむを得ない理由に対処するものであること。
(iii) 理事会修正事項との比較において、次の要件を満たしていること。 (a) かかる公共の利益上の根拠あるやむを得ない理由に対処するため、より厳密に調整されたものであり、かつ(b) 代替的修正事項により、行為もしくは活動が禁止されもしくは義務付けられ、影響を受けるレジストリオペレータに重大な負担を課され、またはドメイン名サービスへのアクセスが大きく減少することとなる範囲において、公益の利益上の根拠あるやむを得ない理由に対処するための方法のうち、より制限的でないものであること。
直前のセンテンスのサブセクション(i)から(iii)の要件に合致していない修正案は、本契約における代替的修正事項とみなされることはありません。そのため、かかる修正案によって、理事会修正事項の効力が劣後し、または理事会修正事項の効力が遅延することはないものとします。 代替的修正事項がICANN理事会へ提出された後に、代替的修正事項がレジストリオペレータ承認を受けた場合、かかる代替的修正事項は、理事会修正事項に優先し、本契約に基づく承認済み修正事項とみなされます（その効力はICANNがかかる代替的修正事項の承認の通知をレジストリオペレータに対し行った日から60暦日後に生じ、本契約への修正がなされたものとみなされます（かかる効力の発生日は、本契約において、修正事項発効日とみなされるものとします）。但し、ワーキンググループがICANN理事会へかかる代替的修正事項のレジストリオペレータ承認を通知した日から60暦日（かかる期間中、ICANNは代替的修正事項についてワーキンググループと協働するものとします）の期間内に、ICANN理事会が、当該事項について投票権を有する ICANN理事会メンバーの3分の2以上の賛成投票により、かかる代替的修正事項を否決し
た場合は、この限りではありません。なお、かかる投票権の有無は、ICANNの利益相反に関するポリシーなど、かかる投票権に影響を及ぼすICANNの一切のポリシーを考慮に入れたうえで判断されるものとします。(A) 該当レジストリオペレータへの代替的修正事項の提出後30暦日以内に、かかる代替的修正事項がレジストリオペレータ承認を受けることができなかった場合（この場合、ワーキンググループは、かかる提出日をICANNに通知するものとします）、または(B) ICANN理事会が上述の3分の2以上の賛成投票により代替的修正事項を否決した場合には、理事会修正事項（代替的修正事項ではないもの）は、ICANNからレジストリオペレータへの通知から60暦日後（以下、「修正発効日」といいます）に効力を生じ、本契約への修正がなされたものとみなされます（かかる効力の発生日は、本契約において、修正事項発効日とみなされるものとします）。 ICANN理事会が代替的修正事項を否決した場合、当該理事会は、7.6(f)(i)項から7.6(f)(iii)項に定められた基準に関する分析を記載した理由書を公表するものとします。本契約に基づき代替的修正事項を否決するICANN理事会の権能によっても、理事会修正事項を7.6(e)(i)項から7.6(e)(v)項に定められた基準に合致させることについての理事会の義務が免除されることはありません。
(g) 承認済み修正事項が本7.6項に定められた実体的要件に合致していないとレジストリオペレータが判断する場合、または承認済み修正事項が本7.6項に定められた手続規定のいずれかに違反して採択されたとレジストリオペレータが判断する場合、レジストリオペレータは、第5条に定められた紛争解決条項に従い、かかる特別修正事項の採択に異議を申し立てることができるものとします。但し、この場合の仲裁は、 3名で構成される仲裁パネルによって行われるものとします。かかる異議申し立ては、 ICANNがレジストリオペレータへ承認済み修正事項の通知を行った日から60暦日以内に提起する必要があります。ICANNは、複数のレジストラ（レジストリオペレータを含みます）によって提起されたすべての異議申し立てを、単一の手続きに併合することができるものとします。 かかる紛争解決手続の係属中は、承認済み修正事項により本契約が修正されたとみなされることはないものとします。
(h) レジストリオペレータは、ICANNがレジストリオペレータへかかる承認済み修正事項の通知を行った日から30暦日の期間内に、ICANNに対し、かかる承認済み修正事項の適用除外を求める申請を、書面により行うことができます（レジストリオペレータにより提出されたかかる申請は、以下、本契約において「適用除外申請」といいます）。 各適用除外申請には、かかる申請の根拠を記載するとともに、承認済み修正事項の適用除外に関する裏付けを詳細に記載するものとします。 また、適用除外申請には、かかるレジストリオペレータが提案する承認済み修正事項の代替案または修正版に関する詳細な説明および裏付けを記載することもできます。適用除外申請が認められるのは、承認済み修正事項を遵守することにより、適用法への抵触が生じるか、またはレジストリオペレータの長期の財務状況もしくは経営成績に重大な悪影響を及ぼすおそれがあることについて、明白かつ確信を抱くに足る証明がレジストリオペレータによってなされた場合に限られるものとします。 かかる適用除外申請を認めることにより、レジストラントに重大な害が生じるおそれがあるか、またはレジストラントの直接便益が否定されることになるとICANNがその合理的な裁量によって判断した場合には、適用除
外申請は認められないものとします。適用除外申請のICANNによる受領後90暦日以内に、 ICANNは、かかる適用除外申請についての承認（かかる承認は、承認済み修正事項の代 替案もしくは修正版を条件としてなされるか、またはかかる代替案もしくは修正版を構 成要素としてなされることがあります）または非承認を、書面により行うものとします。 かかる期間内においては、かかる承認済み修正事項によって本契約が修正されることは ないものとします。 適用除外申請がICANNにより承認された場合、承認済み修正事項に より本契約が修正されることはありません。但し、かかる承認済み修正事項について ICANNが必要と判断した条件、代替案または修正版は、その効力を生じるものとし、そ の適用のある範囲において、修正事項発効日付で本契約が修正されるものとします。 か かる適用除外申請がICANNにより非承認とされた場合、承認済み修正事項により、修正 事項発効日付で、本契約が修正されるものとします（または、かかる修正事項発効日が 既に経過しているときは、かかる承認済み修正事項は上記の非承認がなされた日に、即 時に効力を生じるものとします）。但し、レジストリオペレータは、ICANNの決定を受 領した後30暦日間、第5条に定められた紛争解決条項に従い、ICANNによる適用除外の
非承認決定に異議を申し立てることができるものとします。かかる紛争解決手続の係属中は、承認済み修正事項により本契約が修正されたとみなされることはないものとします。誤解を避けるために記載すると、レジストリオペレータが提出した適用除外申請が、 5.1項に従う仲裁の後、あるいは5.2項に従う仲裁の裁定を通じて、ICANNの承認を受けた場合にのみ、それによりレジストリオペレータが承認済み修正事項についての適用除外を受けることができます。他の該当レジストリオペレータについて（ICANNによりまたは仲裁を通じて）認められた適用除外申請により、本契約の下で何らかの効果が生じたり、レジストリオペレータについて承認済み修正事項の適用が除外されたりすることはありません。
(i) 本7.6項または7.7項に規定されている場合ならびに本契約およびその仕様に別段の規定がある場合を除き、本契約またはその条項の修正、補足、変更は、両当事者が署名した書面によるものでない限り、法的拘束力を有しません。本7.6項および7.7項は、いずれもICANNおよびレジストリオペレータが両当事者間に限った交渉により本契約の双方的な修正および変更に合意することを、制限するものではありません。本契約の条項の免除は、当該条項の遵守を免除する当事者が署名した書面によって確証されない限り、法的拘束力を有しません。本契約のいずれの条項の免除または不行使も、本契約のその他の条項の免除と解釈してはならず、また、明示的な別段の規定がない限り、かかる免除は継続的免除を構成するものではありません。 誤解を避けるために記載すると、本7.6項または7.7項は、2.2項を遵守すべきレジストリオペレータの義務を限定するものとみなされるものではありません。
(j) 以下の用語は7.6項で使用されるときに、次のような意味となります。
(i) 「該当レジストリオペレータ」とは、レジストリオペレータを含む、本7.6項に含まれるレジストリ契約のトップレベルドメインの当事者であるレジストリオペレータを集合的に意味します。
(ii) 「レジストリオペレータの承認」とは次のそれぞれの受容を意味します： (A) 当該レジストリ契約に従って直前の暦年の間に、すべての該当レジストリオペレータによりICANNへ支払われたICANNへの支払い手数料総額（該当する場合、ICANNによりその計算がなされる日のウオールストリートジャーナル米国版に記載されている前日に公開された優勢な為替レートで米国ドルに変換）の2/3を占める当該ブランドレジストリオペレータの肯定的承認、そして、(B) そのような承認が得られた時点での該当レジストリオペレータの多数による肯定的承認。 条項 (B) に関して誤解を避けるために、各レジストリオペレータは当該ブランドレジストリ契約に従い、そのようなレジストリオペレータにより運用される各トップレベルドメインに対して1票を持つものとします。
(iii) 「制限付き改定」とは次のことを意味します： (A) 仕様書1の改定、(B) 2.10項でこれに関して触れられる範囲までを除く、ドメイン名登録のためにレジストリオペレータからレジストラへ課金される料金を指定する改定、(C) 仕様書6の2.1項の前文に規定されるようなレジストリサービスの定義への改定、または(D) 契約期間の長さについての改定。
(iv) 「公共の利益上の本質的でやむを得ない理由」とは、ICANNのミッションに含まれる、ICANNの付属定款に定義されるICANNの本質的価値のバランスの取れた適用と一貫性があり、重要、具体的かつ明瞭な公益目標により正当化される理由を指します。
(v) 「ワーキンググループ」とは、該当レジストリオペレータの代表者およびコミュニティのその他のメンバーであって、該当レジストリオペレータ契約の修正（7.6(i)項に従う二者間の修正を除きます）に関する協議を行うワーキンググループとして機能するためにレジストリステークホルダーグループが随時指名する者を意味します。
(k) 本7.6項と異なる定めがある場合であっても、(i) 承認済み修正事項によりレジストリサービスの提供費用が著しく増加するおそれがあることの証拠を、レジストリオペレータがICANNにおいて合理的に納得できる形で提出したときは、ICANNは、レジストリオペレータについて、かかる承認済み修正事項の発効を、180暦日を上限として猶予するものとし、また (ii) レジストリオペレータが4.4(b)項に従い取消不能の契約終了通知を行ったときは、7.6項に従い採択された承認済み修正事項は効力を生じないものとします。
7.7 交渉プロセス。
(a) ICANNの最高経営責任者（以下、「CEO」といいます）またはレジストリステークホルダーグループの長（以下「座長」といいます）のいずれかが本契約の改定に関する協議を希望する場合、該当のCEOまたは座長は、他方の者に対し、本契約の改定案についての合理的な詳細を記載した通知（以下、「協議通知」といいます）を行うものとします。 上記にか
かわらず、CEOおよび座長のいずれも、次の事項を行うことはできないものとします。
(i) その時点で存するコンセンサスポリシーの修正をすることとなる本契約の改定内容 を提案すること、(ii) 2014年6月30日以前に本7.7項に従って本契約の改定を提案すること、または (iii) 2014年7月1日に開始する任意の12か月間において複数回、改定を提案し、または協議通知を提出すること。
(b) CEOまたは座長のいずれかが協議通知を受領した後、ICANNおよびワーキンググループは、本契約の改定案の形式および内容について、誠実に協議するものとします。かかる協議は、本契約の改定案（以下、「改定提案」といいます）の形式をもって、少なくとも90暦日間（早期に決議に達した場合を除きます）、改定提案に関して互いに受け入れることのできる合意内容に達することを目指して行われるものとします（以下、「協議期間」といいます）。
(c) 協議期間の終了後に改定提案について合意に達した場合、ICANNは、パブリックコメントを募集するため、30暦日以上の期間（以下、「公示期間」といいます）にわたり、合意済みの改定提案をICANNのウェブサイトに公示するとともに、かかる改定内容を7.9項に従いすべての該当レジストリオペレータに通知するものとします。 ICANNおよびワーキンググループは、改定提案に関して公示期間中に提出されたパブリックコメント（該当レジストリオペレータから提出されたコメントを含みます）を検討するものとします。 公示期間の終了後、改定提案は、レジストリオペレータの承認（7.6項に定義されるように）およびICANN理事会の承認を受けるために提出されるものとします。 かかる承認を受けた場合、改定提案は、該当レジストリオペレータおよびICANNにより承認済み修正事項（7.6項に定義されるように）とみなされるとともに、ICANNからレジストリオペレータへの通知から60暦日後に発効し、本契約の修正とみなされるものとします。
(d) 協議期間の終了後にICANNとワーキンググループの間で改定提案について合意に達しなかった場合、CEOまたは座長は、他方の者に対し、下記の条件に従いxxな自主交渉援助型調停（判断を下さない形式）を通じてかかる改定提案に関する意見の不一致の解消を目指すことを各当事者に求める書面による通知（以下、「調停通知」といいます）を行うことができます。 調停通知が行われた場合、ICANNおよびワーキンググループは、その15暦日以内に、それぞれが希望する改定提案の文言およびそれに関する声明書をICANNのウェブサイト上で両者同時に公示するものとします。
(i) 調停は、当事者が選定した1名の調停人により行われるものとします。 CEOまたは座長のうちいずれか該当する方による調停通知の受領後15暦日以内に当事者が調停人について合意に達することができない場合、当事者は、速やかに、互いに許容可能な調停機関を選定するものとします。かかる機関は、その選定後において可能な限り速やかに、調停人を指名するものとします。かかる調停人は、資格を有する弁護士であって、当該特定の紛争の調停に必要な範囲で契約法に関する全般的な知識を有しており、かつドメイン名システムに関する全般的な知識を有している必要
があります。調停人は、当人がICANNまたは該当レジストリオペレータの従業員、パートナー、執行役員、取締役または証券保有者ではなく、また調停期間中にこれらの地位に就かないことについて、書面で確認しなければなりません。 指名された調停人がかかる確認書を提出しない場合は、 7.4.4.1項に従い代替の調停人を指名するものとします。
(ii) 調停人は、当事者との協議のうえで決定した自主交渉援助型に関する規則および手続きに従い、調停を実施するものとします。 当事者は、紛争に関し誠実に協議するとともに、調停人の助力を受けながら紛争の友好的な解決を目指すものとします。
(iii) 各当事者は、調停における自身の費用を負担するものとします。 当事者は、調停人の報酬および経費を等しい割合で負担するものとします。
(iv) 調停中に何らかの合意に達した場合、ICANNは、公示期間にわたり、合意済みの改定提案をICANNのウェブサイトに公示するとともに、 7.9項に従いすべての該当レジストリオペレータに通知するものとします。 ICANN およびワーキンググループは、合意済みの改定提案に関して公示期間中に提出されたパブリックコメント（該当レジストリオペレータから提出されたコメントを含みます）を検討するものとします。 公示期間の終了後、改定提案は、レジストリオペレータの承認およびICANN理事会の承認を受けるために提出されるものとします。 かかる承認を受けた場合、改定提案は、該当レジストリオペレータおよびICANNにより承認済み修正事項
（7.6項に定義されるように）とみなされるとともに、ICANNからレジストリオペレータへの通知から60暦日後に発効し、本契約の修正とみなされるものとします。
(v) CEOまたは座長（いずれか該当する者）が調停通知を受領した後90暦日までに当事者がその理由にかかわらず紛争を解決できなかった場合、調停は自動的に終了するものとします（但し、当事者が延長に同意した場合は、この限りではありません）。 調停人は、将来に仲裁が開始された場合にその仲裁において考慮できるよう、争点を定義したものを当事者に送付するものとします。 かかる争点は、下記7.4.5.2項に定められた制限の対象となるものとします。
(e) 調停の後に、ICANNおよびワーキング グループが改定提案について合意に達しなかった場合、CEOまたは座長は、本7.7(e)項における要件および制限を条件として、他方の者に対し、5.2項の仲裁条項に従い法的拘束力のある仲裁を通じて紛争を解決するようICANNおよび該当レジストリオペレータに要求する書面による通知（以下、
「仲裁通知」といいます）を送付することができるものとします。
(i) 仲裁通知が送付された場合、パブリックコメントを募集するため、調停人による争点の定義、および改定提案（ICANN、レジストリオペレータまたはその両方によるもの）を、ICANN のウェブサイトに30暦日以上掲載するものとします。 ICANNおよびワーキンググループは、改定提案に関して公示期間中に提出されたパブリックコメント（該当レジストリオペレータから提出されたコメントを含みます）を検討するものとします。かかるコメントおよび検討に関する情報は、3名の仲裁人パネルへ提出するものとします。 各当事者は、公示期間の前後を問わず、自身の改定提案を変更することができるものとします。 仲裁手続は、かかるパブリックコメント期間の終了以前には、開始できないものとします。ICANNは、複数のレジストリオペレータ（単独のレジストリオペレータを含みます）によって提起されたすべての異議申し立てを、単一の手続きに併合することができるものとします。 本7.7項に規定されている場合を除き、仲裁は、5.2項に従って行われるものとします。
(ii) 改定提案に関するいかなる紛争も、改定提案の主題が次のいずれかに該当する限りにおいて、仲裁に付すことができないものとします。
(i) コンセンサスポリシーに関係するもの、(ii) コンセンサスポリシーおよびテンポラリポリシーに関する仕様の1.2項に定められた主題カテゴリに該当するもの、または(iii) 本契約の次の条項または仕様のいずれかの修正を求めるもの。 第1条、第3条、第6条、2.1項、2.2項、2.5項、2.7項、2.9項、2.10項、2.16項、2.17項、2.19項、4.1項、4.2項、7.3項、7.6項、7.7項、 7.8項、7.10項、7.11項、7.12項、7.13項、7.14項、7.16項、2.8項および仕様書7（そのような提案された改定が2.8項および仕様書7で熟慮されていない、RMP実施を目指す範囲までのみ）、別紙A、および仕様書1、4、6、10、および11。
(iii) 調停人は、改定提案に関するICANNおよびワーキンググループの各々の提案内容について、仲裁人パネルに対し概要説明を行うものとします。
(iv) 改定提案に関係する本契約の修正は、ワーキンググループの場合はその修正案がレジストリオペレータ承認を受けない限り、ICANNの場合はその修正案がICANN理事会の承認を受けない限り、仲裁に付すことはできないものとします。
(v) 仲裁人パネルは、改定提案に関する修正案のうち、ICANNによるものまたはワーキンググループによるもののいずれかを承認するためには、かかる修正案がICANNの本質的価値（ICANNの付属定款に定義）のxxな適用と矛盾しないものであって、該当レジストリオペレータおよび ICANN（該当する場合）の事業上の利益における費用と便益の調和という観点で合理的なものであり、かつかかる修正に記載されている改定提案に
より達成しようとする公益の観点でも合理的なものであるとの結論に達している必要があります。仲裁人パネルが、改定提案に関する修正案のうち、 ICANNによるものまたはワーキンググループによるもののいずれかが上記の基準に合致しているとの結論に達した場合、かかる修正案は、ICANNからレジストリオペレータへの通知から60暦日後に発効して、本契約の修正とみなされ、かつ本契約の下での承認済み修正事項とみなされるものとします。
(f) ICANNによって提案された修正に関する承認済み修正事項については、レジストリオペレータは、7.6項の定めに従い、書面により、かかる修正の適用除外をICANNに申請することができるものとします。
(g) 本7.7項にこれと異なる定めがある場合であっても、(a) 承認済み修正事項によりレジストリサービスの提供費用が著しく増加するおそれがあることの証拠を、レジストリオペレータがICANNにおいて合理的に納得できる形で提出したときは、 ICANNは、レジストリオペレータについて、かかる承認済み修正事項の発効を、180暦日を上限として猶予するものとし、また (b) レジストリオペレータが4.4(b)項に従い取消不能の契約終了通知を行ったときは、7.7項に従い採択された承認済み修正事項は効力を生じないものとします。
7.8 第三者の受益者の不在。 本契約は、ICANNまたはレジストリオペレータのいずれによっても、本契約書の当事者以外の者（レジストラまたは登録名保有者を含みます）に対して、何らかの義務を創出するものと解釈されないものとします。
7.9 一般的な注意事項。 7.6項および7.7項に従う通知を除き、当事者が本契約 に規定されるように、郵便住所、電子メールアドレス、あるいはファックス番号の変更 を通知しない限り、本契約の下に与えられるすべての通知は、(i) 以下に規定される適切 な当事者の住所へ書面にて、あるいは (ii) 以下に規定される通りにファックスまたは電 子メールにて与えられます。 7.6項および7.7項の下でのすべての通知は、ICANNのウェ ブサイト上への該当する情報の掲示、および電子メールによるレジストリオペレータへ の送信の双方の方法で与えられるものとします。以下の通知の連絡先に変更がある場合 は、変更後30日以内に当事者により報告されます。 7.6項または7.7項の下での通知を除 き、本契約により求められる任意の通知は、(i) 書面の場合は手交された時点または受領 確認を伴う宅配便によって配達された時点、または(ii) ファックスや電子メールの場合 は受信者側のファックスマシンや電子メールサーバーによって受信が確認された時点で、適切に送達されたものとみなされます。但し、ファックスや電子メールを介した通知の 後、3暦日以内に通常の郵便サービスによるコピーの送達が伴うことを条件とします。 7.6項または7.7項で求められる任意の通知は、ICANNのウェブサイト上に電子的に掲示さ れ、電子メールサーバーによって受信確認された時点で与えられたものとしてみなされ ます。 セキュアなウェブサイトを介した通知など、その他の通知の手段が現実的に実行 可能になる場合には、双方の当事者は本契約の下でそのような通知手段を協力して実装 します。
ICANNに対する場合の宛先は次の通りとします。 Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300
Los Angeles, CA 00000-0000 USA
電話番号： x0-000-000-0000
ファックス番号： x0-000-000-0000
宛先： 理事xxCEO
必要なコピー送付先： 法律顧問
電子メール： （随時指定される通り。）
レジストリオペレータ向けの場合の宛先：
[ ]
[ ]
[ ]
電話番号：
必要なコピー送付先：
電子メール： （随時指定される通り。）
7.10 完全合意。 本契約（参照のために組み入れられるそれらの仕様書、文書から、その一部分を形成するURLの場所に至るまでを含む）はTLDの運営に関してここに双方の当事者の完全合意を構成し、口頭によるか書面によるかに拘わらず、その主題に関する当事者間での従前のすべての契約、合意、交渉および相談に取って代わるものとします。
7.11 英語の優先。 本契約および/または仕様書の任意の翻訳されたバージョンがレジストリオペレータへ提供できるにも拘わらず、本契約と参照されるすべての仕様書の英語バージョンが、双方の当事者をここに法的に拘束する公式なバージョンです。本契約の任意の翻訳バージョンと英語バージョン間の任意の矛盾や不一致がある場合には、英語バージョンが優先されます。 本契約の下で作成される通知、通知、決定、仕様はすべて英語によるものとします。
7.12 所有権。 本契約には、(a) TLD、文字、ワード、シンボル、あるいはTLD文字列を構成するその他のキャラクターにおけるレジストリオペレータへの任意の知的財産権やレジストリオペレータの利益を設定し、あるいは認めているとして解釈され、または(b) レジストリオペレータの任意の既存の知的財産や所有権に影響を与えると解釈されるものは含まれていません。
7.13 分離/可分性、法の抵触。 本契約は、分離可能であるとみなされるものとし、本契約の任意の条項や規定の無効性や実施不能性は、これによって本契約のバランスや任意のその他の条項の有効性や執行可能性に影響を与えず、完全に効力を有するも
のとします。任意の規定がこれによって、無効または実施不能であると判断される場合、双方の当事者は誠意をもって、その元来の意図にできる限り近い効力を持つように本契約を修正するものとします。 ICANNおよびワーキンググループは、適用する法律と本契約の非WHOIS関連規定との間の主張される矛盾をICANNがレビューし検討するため、 ICANNの手順の開発に相互に協力します。 このような手順がICANNによって開発され、実装されるまで、WHOISとプライバシー法との矛盾に対処するICANNの手順と同様の方法で、ICANNは適用する法律と本契約の非WHOIS関連規定との間の主張される矛盾をレビューし検討します。
7.14 裁判所命令。 ICANNは政府の同意や異議がないことがTLDの委任の要件である任意の法域からの任意の命令を含む、管轄裁判所からの任意の命令を尊重します。本契約のその他任意の規定にも拘わらず、そのような任意の命令をICANNが実施することは、本契約に違反するものではありません。
7.15 機密保持
(a) 7.15(c)項に従い、契約期間およびその後3年間、各当事者は、各当事者自身の、そしてその関係者の幹部職員、取締役、従業員および代理人に機密情報を保持させ、直接または間接的に、開示する当事者が、本契約の条項によりそのような開示が認められる範囲を除き、「機密取引情報」、「機密商業情報」、「機密財務情報」
（以下、集合的に「機密情報」といいます）として印がつけられた、あるいは受容する当事者として書面にて指定している任意の情報を任意の第三者へ公開や開示せず、そして公開や開示させないものとします。
(b) 7.15(a)項の下での機密保持義務は、(i) 公な利用、公開、一般的知識などによって、本契約の違反に受信側当事者の過失がなくとも、パブリックドメインの一部であるか、今後パブリックドメインの一部となる、あるいは (ii) かかる情報に関する任意の機密保持義務なく、開示側当事者による開示以前に、受信側当事者が所有していた文書やその他の有力な証拠により証明され、(iii) その後、かかる情報に関して任意の機密保持義務によって法的な拘束を受けない第三者から受信側当事者によって受信され、(iv) 第三者によって公開されている、あるいは受信側当事者の過失なく、パブリックドメインに含まれ、あるいは(v) 開示側当事者の機密情報に言及することなく、受信側当事者により、あるいは受信側当事者のために独自に開発されている文書やその他の有力な証拠によって証明される任意の機密情報へは適用しないものとします。
(c) 各当事者はそのような開示が、(i) 管轄裁判所の正当な命令に応じてなされ、受信側当事者の法律顧問の合理的意見として、そのような開示が、さもなければ適用する法律によって求められる場合、但し、受信側当事者がそのような命令や適用する法律の下で、そのような通知を提供することが認められていない場合を除き、受信側当事者は最初に開示側当事者へ通知を与えており、開示側当事者へそのような命令を取り消し、またはそのような命令や適用する法律の対象となる機密情報が、そのような裁判所やその他第三者の受信者により機密性が保持されることを求めている保護命令や
機密情報取り扱い命令を得る合理的機会を与えており、あるいは (ii) 本契約の下での活動の成果に必要であるか、あるいはそれに関連して有用であることを理由として、受信側当事者または任意のその関係者により、その弁護士、会計士、顧問、コンサルタント、契約者あるいはその他の第三者へその個人や組織で利用するためになされる範囲までの機密情報を開示する権利を有するものとします。但し、そのような第三者が少なくとも書面による合意、または職業上の責任基準の中で規定されるものと同等の厳しい機密保持義務によって法的な拘束を受ける場合に限ります。
[注： 次の項は政府間組織や政府機関にのみ適用されます。] 7.16 政府間組織や政府 機関に関連する特別規定。(a) ICANNはレジストリオペレータが、レジストリオペレータに適用する国際条約を含む国際公法の対象となる組織であることを認めます（そのような国際公法と条約を、これ以降集合的に「適用法」と呼びます）。 本契約およびその関連する仕様において、レジストリオペレータに適用する法律に違反することを求める、あるいはそれをもってコンプライアンスを妨げると解釈されるものは一切ないものとします。 双方の当事者は、レジストリオペレータの適用法へのコンプライアンスが、本契約への違反を構成しないことに同意します。(b) レジストリオペレータが本契約およびその関連する仕様の任意の規定、テンポラリポリシーとコンセンサスポリシー（そのような規定、仕様およびポリシーをこれ以降、集合的に「ICANNの要件」と呼びます）を含みますが、それだけに限らず、本契約に言及されるICANNの任意の決定またはポリシーが適用法に抵触しているか、あるいは違反している（これ以降「潜在的抵触」と呼びます）かを合理的に判断する場合、レジストリオペレータはできる限り速やかにICANNへかかる潜在的抵触を詳細に説明した通知（以下、「通知」といいます）を提供するものとし、提案されたコンセンサスポリシーの場合には、提案されたコンセンサスポリシ
ーの任意のパブリックコメント期間の終了前までにかかる通知を提供するものとします。レジストリオペレータが、提案された適用法と任意のICANNの要件との間に潜在的抵触 があると判断する場合には、レジストリオペレータはできる限り速やかに、かかる潜在 的抵触を詳細に説明した通知をICANNへ提供するものとし、提案されたコンセンサスポ リシーの場合には、提案されたコンセンサスポリシーの任意のパブリックコメント期間 の終了前までにかかる通知を提供するものとします。 (c) かかるレビューの後できる 限り速やかに、双方の当事者は5.1項に規定される手順に従う調停により、潜在的抵触を 解決するよう試みるものとします。 さらに、レジストリオペレータは適用法と任意の ICANNの要件との間のかかる潜在的抵触から生じる任意の影響を取り除き、あるいは最 小限に抑えるよう最善の努力を払うものとします。 かかる調停の後、レジストリオペレ ータが潜在的抵触は一方の任意のICANNの要件と他方の適用法との間で実際に抵触して いると判断する場合、レジストリオペレータがかかるICANNの要件を遵守していないこ とが、レジストリサービス、インターネットやDNSの安全性と安定性への脅威を構成す るとICANNが合理的かつ客観的に判断（以下、「ICANNの判断」といいます）しない限 り、ICANNはかかるICANNの要件を遵守することを放棄するものとします（但し、双方 の当事者はICANNへのかかる不遵守の影響を軽減し、あるいは取り除くために、これ以 降継続的に誠意をもって交渉するものとします）。 かかるICANNの判断に関する通知を レジストリオペレータが受領した後、レジストリオペレータは適用法とのかかる抵触を
解決するために90暦日の期間を与えられるものとします。 適用法との抵触が、かかる 期間中にICANNの完全な満足が得られるように解決されていない場合、レジストリオペレータはその後10暦日以内に、その事案を以下のサブセクションに定義されるように法的拘束力のある仲裁に付託する選択肢を持つものとします。 かかる期間中に、レジストリオペレータがその事案を以下のサブセクション(d)に従って仲裁に付託しない場合に は、ICANNはレジストリオペレータへの通知によって、即時の効力により本契約を終了することができます。(d) レジストリオペレータがICANNの判断に同意しない場合には、レジストリオペレータは5.2項の規定に従って、この事案を法的拘束力のある仲裁へ付託することができます。但し、判断のために仲裁者へ提示される唯一の問題が、ICANNが合理的かつ客観的にICANNの判断に到達できるか、否かというものである場合を除きます。 そのような仲裁の目的のために、ICANNはICANNの判断を支持する仲裁人へ証拠を提示するものとします。 仲裁者がICANNは合理的かつ客観的にICANNの判断に到達していないと判断する場合、ICANNは対象となるICANNの要件をレジストリオペレータが遵守することを放棄するものとします。 仲裁者や該当する場合には仲裁前裁定人が、 ICANNは合理的かつ客観的にICANNの判断に到達したと判断する場合、ICANNはレジス
トリオペレータへの通知によって、即時の効力により本契約を終了することができます。
(e) レジストリオペレータは、本契約の執行日時点で知りうる範囲で、任意の適用法と抵触する、あるいはそれに違反する既存のICANNの要件が存在しないことを、この記
載によって表明し、保証します。 (f) 本7.16項のその他任意の規定にも拘らず、 ICANNの判断の後、上記の7.16(d)項に従う仲裁者による認定に先立ち、ICANNはレジストリオペレータとの事前の相談を条件として、レジストリサービス、インターネットおよびDNSの安全性と安定性を確保するため必要と考えられるかかる合理的な技術的措置を取ることができます。 これらの合理的な技術的措置は、上記の7.16(d)項に言及される仲裁手続きの終結日、または適用法との抵触が完全に解決される日の前まで、暫定的にICANNによって取られるものとします。 レジストリオペレータがICANNによって取られるそのような技術的措置に同意しない場合には、レジストリオペレータは上記の5.2項の規定に従い、その案件を、法的拘束力を持つ仲裁へ付託することができ、そしてそのプロセスの期間、ICANNはそのような技術的措置を継続して取ることができます。 ICANNがそのような措置をとる場合には、レジストリオペレータはかかる措置を取った結果として、ICANNによって発生したすべての費用を支払うものとします。 さらに、 ICANNがかかる措置を取る場合に、ICANNは適用できる範囲で、継続運営証書と代替証書の下での権利を保持し、執行できるものとします。** * * *
上記の証として、双方の当事者は適法に権限を持つ代表者による署名をもって、ここに本契約を執行させるために締結しました。
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS
署名：
[ ] 理 事 x x CEO 日 付 ：
[レジストリオペレータ]
署名：
[ ] [ ]
日付：
別紙A
承認されたサービス
ICANN gTLD 申請者ガイドブック(xxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxx/xxx) および RSEPでは、提案されたレジストリサービスの検討プロセスを指定しています。 レジストリオペレータは、本契約の条項により求められる任意のサービスを提供することができます。 さらに、次のようなサービスは（もし、あれば）契約の発効日以前にICANNにより認められているものとして特に識別され、レジストリオペレータはこのようなサービスを提供することができます：
1. DNSサービス–TLDゾーンコンテンツ
本契約のその他すべてにも拘わらず、gTLD 申請者ガイドブックの 2.2.3.3 項に示されるように、TLDのDNSサービスに許容されるコンテンツは、
1.1. 「インターネット」(IN) クラス向け：
1.1.1. Apex SOAレコード
1.1.2. Apex NSレコードとTLDのDNSサーバーの下位グルーレコード
1.1.3. NSレコードとTLDの登録名のDNSサーバーの下位グルーレコード
1.1.4. TLDの登録名のDSレコード
1.1.5. TLDゾーンの署名に関連付けられているレコード（例えば、RRSIG、DNSKEY、 NSEC、NSEC3PARAMおよびNSEC3）
1.1.6. ゾーンのバージョン管理が目的のApex TXTレコード
1.1.7. 自動dnssecシグナリング署名のためのApex TYPE65534レコード
1.2 「カオス」(CH) クラス向け：
1.2.1. サーバーバージョン/識別子（例えば、「version.bind」、「id.server」、
「authors.bind」および/または「hostname.bind」のTXTレコード） のTXTレコード
（注: 上記の言語には、特に、TLDゾーンでドットレスのドメイン名が有効となるDNSリソースレコード（例えば、apex A、AAAA、MXレコード）を含めることを許容できません。
レジストリオペレータが、そのTLD DNSゾーン（前記の1.1項または1.2項に記載されるもの以外）へ任意のDNSリソースレコードタイプやクラスを配置したい場合、その提案に詳細に説明して、レジストリサービス評価プロセス (RSEP) にリクエストを提出する必要があります。 これは、サービスがDNSのセキュリティや安定性に重大な悪影響を与えるリスクを作り出すか否かを判断するために、RSEPごとに評価されます。 レジストリオペレータは、TLDゾーンのあまり一般的ではないDNSリソースレコードおよび/またはクラスの使用に基づいたサービスは、例え許可されたとしても、ソフトウェアサポートの不足により、すべてのユーザを対象としては機能しない場合があることを認識し、認めています。
仕様書1
コンセンサスポリシーおよびテンポラリポリシーに関する仕様
1. コンセンサスポリシー。
1.1. 「コンセンサスポリシー」とは、(1) ICANNの付属定款に定められた手続きおよび適正手続きに従い、かつ(2) 本仕様書の1.2項に列記されたトピックを対象として確立されたポリシーです。ICANNの付属定款に定められたコンセンサスポリシーの策定プロセスおよび手続きは、当該付属定款に定められた手順に従い、随時改定されることがあります。
1.2. コンセンサスポリシーおよびこれによって定められた手続きは、可能な限り、gTLDのオペレータを含むインターネットステークホルダーにおけるコンセンサスを生み出すように立案されるものとします。コンセンサスポリシーは、少なくとも以下のいずれかに関係するものである必要があります。
1.2.1 インターネットまたはドメインネームシステム（以下、「DNS」といいます）の相互運用性、安全性、安定性を促進するために、統一されたまたは協調的な解決策が合理的に必要となる問題
1.2.2 レジストリサービスの提供に関する機能上および性能上の仕様
1.2.3 TLD のレジストリデータベースの安全性と安定性
1.2.4 レジストリ運営またはレジストラに関連するコンセンサスポリシーを履行するために合理的に必要となるレジストリポリシー
1.2.5 ドメイン名の登録に関する紛争の解決（かかるドメイン名の使用に対立するものとして）、または、
1.2.6 レジストリオペレータとレジストラまたはレジストラ再販業者との共同所有に関する制限、ならびにレジストリオペレータとレジストラまたはレジストラ再販業者に関係がある場合、レジストリ運営、レジストリとレジストラのデータ利用に関する規制と制限。
1.3. 本仕様書の1.2項に言及される問題のかかるカテゴリーには、次のものを含みますが、それだけに限りません：
1.3.1 TLDにおける登録名の割り当てに関する原則（先着順、適時更新、有効期間満了後の猶予期間など）
1.3.2 レジストリまたはレジストラによるドメイン名の投機目的保有の禁止
1.3.3 当初から登録できないか、または (i) ユーザを混乱させたり誤解を与えたりすることの回避、(ii) 知的財産権、(iii) DNSまたはインターネットの技
術的管理（名前の登録保留設定など）に合理的に関連付けられる理由のために更新できない可能性のあるTLDにおける登録名の保留、および、
1.3.4 レジストリオペレータまたはレジストラによる運用の凍結または停止によるドメイン名登録の途絶を回避するための手順。これには、かかる凍結または停止によって影響を受けるTLDで登録ドメイン名を提供する責任を割り当てる手順が含まれます。
1.4. コンセンサスポリシーに対するその他の制限事項に加え、コンセンサスポリシーは、以下に該当するものであってはなりません：
1.4.1 レジストリサービスの価格を規定し、またはこれを制限すること
1.4.2 レジストリ契約の更新または終了のための条項または条件を変更すること
1.4.3 テンポラリポリシー（以下に定義）またはコンセンサスポリシーに対する制限事項を修正すること
1.4.4 レジストリオペレータによりICANNへ支払われた手数料に関するレジストリ契約の規定を修正すること、または、
1.4.5 オープンかつ透明性のある方法でレジストリオペレータと行動のxxな取扱いを確保するICANNの義務を変更すること。
2. テンポラリポリシー。 レジストリオペレータは、ICANN理事会（以下、「理事会」といいます）が臨時的に確立したすべての仕様およびポリシーを遵守し、これらを履行するものとします。但し、この義務は、かかる修正または改定の正当化が可能であり、かつレジストリサービス、またはDNSの安定性または安全性を維持するためにはその主題に関する仕様またはポリシーを即時かつ臨時に確立する必要があると理事会が判断する限りにおいて、理事会がそのメンバーの3分の2以上の賛成によって確立した場合に限られるものとします（以下、「テンポラリ ポリシー」といいます)。
2.1. かかる仕様またはポリシーの案は、その目的の達成するために可能な限り厳密に調整されたものである必要があります。テンポラリポリシーの確立にあたっては、理事会は、テンポラリポリシーが採択される期間を言明するとともに、ICANNの付属定款に定められたコンセンサスポリシーの策定プロセスを直ちに実行するものとします。
2.1.1 また、ICANNは、テンポラリポリシーの採択理由、およびかかるテンポラリポリシーがインターネットステークホルダーの一致した支持を受ける必要があると理事会が判断する理由に関する詳細な説明を含む助言的声明を発するものとします。
2.1.2 テンポラリポリシーの採択期間が90暦日を超えた場合、理事会は、それがコンセンサスポリシーとなる時点まで当該テンポラリポリシーの有効性を維持するために、合計で1年を超えない期間において、90暦日ごとに一時的な採択を再確認するものとします。 1年の期間が満了した場合、またはかかる1年の期間内にテンポラリポリシーがコンセンサスポリシーとならず理事会による再確認もなされなかった場合、レジストリオペレータは、かかるテンポラリポリシーの遵守および実行の義務から解放されます。
3. 通知および抵触。コンセンサスポリシーまたはテンポラリポリシーの確立の通知後、レジストリオペレータには、かかるポリシーまたは仕様を遵守するための妥当な猶予期間が与えられるものとします。かかる猶予期間の付与は、任意の関連する緊急事態を考慮したうえでなされるものとします。レジストリサービスとコンセンサスポリシーまたはテンポラリポリシーとの間に抵触が生じた場合、その抵触の存する主題に限り、コンセンサスポリシーまたはテンポラリポリシーが優先するものとします。
仕様書2
データエスクロー要件
レジストリオペレータは、レジストリ契約に関連してデータエスクローサービスを提供するために、独立した組織をデータエスクローエージェント(「エスクローエージェン ト」)としての役割を担わせるために契約します。パートAに記載された以下の技術仕様、およびパートBに記載された法的要件は、レジストリオペレータとエスクローエージェント間の任意のデータエスクロー契約に含まれ、その下ではICANNは第三者の受益者として指定される必要があります。 次の要件に加えて、データエスクロー契約には以下に規定される必要な条項と矛盾したり、打ち消したりすることを意図したものではないその他の規定を含めることができます。
パートA-技術仕様
1. デポジット。 デポジットには2つのタイプがあります： 全額デポジットと差額デポジット。 双方のタイプに対して、データエスクローのために考慮すべきレジストリオブジェクトのユニバースは、承認されたレジストリサービスのすべてを提供するために必要なこれらのオブジェクトです。
1.1. 「全額デポジット」とは、そのような全額デポジットがエスクローエージェントへ提出された当日の00:00:00 UTC（協定世界時）時点のレジストリの状態を反映するデータから構成されます。
1.2. 「差額デポジット」とは、場合によっては、直近の全額デポジットまたは差額デポジットに反映されていないすべてのトランザクションを反映したデータを指します。 直近のデポジットは日曜日以外の各日00時00分00秒 UTC（協定世界時）時点で終了しているので、各差額デポジットはすべてのデータベーストランザクションを含んでいます。 差額デポジットには、最近の全額デポジットや差額デポジット以来含まれていない、または変更されていない以下に指定されるような、完全なエスクローレコードを含む必要があります（すなわち、データの完全追加、修正または削除）。
2. デポジットのスケジュール。 レジストリオペレータは、次の通りに日常的に1セットのエスクローファイルを提出します：
2.1. 各日曜日は23:59 UTCまでに、全額デポジットがエスクローエージェントへ提出される必要があります。
2.2. 週のその他の6日は23:59 UTCまでに、全額デポジットまたは対応する差額デポジットがエスクローエージェントへ提出される必要があります。
3. エスクローフォーマット仕様。
3.1. デポジットのフォーマット。 ドメイン、連絡先、ネームサーバー、レジストラなどのレジストリオブジェクトは、
draft-arias-noguchi-registry-data-escrow で記述されるように構成された１つのファイルへコンパイルされます。本仕様書のパートA、9項参考資料1を参照。draft-arias-noguchi-dnrd-objects-mapping については、本仕様書のパートA、9項参考資料2を参照（以下、集合的に「DNDE仕様」といいます）。 DNDE仕様では、オプションとしてのいくつかの要素について説明しています。レジストリオペレータは利用できる場合に、デポジットにそれらの要素を含めます。 既にRFCではない場合は、レジストリオペレータは発効
日時点で利用できるDNDE仕様の最新のドラフトバージョンを使用します。レジストリオペレータは選択により、発行日以降にDNDE仕様のより新し
いバージョンを使用することができます。 DNDE仕様がRFCとして公開されると、その後180暦日以内にレジストリオペレータはDNDE仕様のそのバージョンを実装します。 UTF-8文字コードが使用されます。
3.2. 拡張。 レジストリオペレータが、追加データの提出を要求する追加レジストリサービスを提供している場合は、そのデータを表示するために上記に含まれていない追加「拡張スキーマ」がケースバイケースで定義されるものとします。 これらの「拡張スキーマ」は本仕様書のパートA、9項、参考資料2に記載されるように指定されます。 「拡張スキーマ」に関連したデータは、本仕様書のパートA、3.1項に記載されるようにデポジットファイルに含まれます。 ICANNとそれぞれのレジストリオペレータは、かかる新しいオブジェクトデータエスクロー仕様に関して合意を得るために協力するものとします。
4. デポジットファイルの処理。 圧縮の利用は、電子データの転送時間とストレージ容量の要件を低減させるために推奨されます。 データの暗号化は、レジストリエスクローデータのプライバシーを確保するために使用されます。圧縮と暗号化のために処理されたファイルは、OpenPGPメッセージフォーマット-RFC 4880に従って、バイナリOpenPGP形式となります。この仕様書のパートA、9項、参考資料3を参照してください。 公開鍵暗号化、共通鍵暗号化、ハッシュおよび圧縮に許容できるアルゴリズムは、RFC 4880に列挙され、OpenPGP IANAレジストリで廃止予定として印がつけられていないものです。本仕様書のパートA、9項、参考資料 4を参照してください。それはまたロイヤルティフリーです。 オリジナルのテキスト形式のデータファイルのために従うべきプロセスは、次の通りです：
(1) 本仕様書のパートA、9項、参考資料1に記載されるようにデポジットのXMLファイルは、5項に指定されるような格納ファイルとして、拡張子xmlが付いた名前である必要があります。
(2) データファイルは(1)と同じですが、拡張子tarが付いた名前の1つのtarballファイルにまとめられます。
(3) 圧縮および暗号化されたOpenPGPメッセージは唯一の入力として、tarballファイルを使用して作成されます。圧縮のために提案されるアルゴリズムは、RFC 4880に従ってZIPとなります。 圧縮されたデータは、エスクローエージェントの公開鍵を使って暗号化されます。公開鍵暗号化のために提案されるアルゴリズムは、RFC 4880に従ってElgamalとRSAとなります。共通鍵暗号化のために提案されたアルゴリズムは、RFC 4880に従って TripleDES、AES128およびCAST5となります。
(4) 圧縮および暗号化した後、エスクローエージェントと合意したファイルサイズよりも大きい場合に、必要であればファイルを分割することができます。 この項では分割されたファイルの各部分、または分割されていない場合には、ファイル全体を処理されたファイルと呼びます。
(5) デジタル署名ファイルが、レジストリオペレータの秘密鍵を用いて、すべ ての処理されたファイルに対して生成されます。デジタル署名ファイルは、 RFC 4880の9項、参考資料3に従いバイナリOpenPGP形式となり、圧縮また は暗号化されません。 デジタル署名のために提案されるアルゴリズムは、 RFC 4880に従ってDSAとRSAとなります。 デジタル署名でのハッシュのた めに提案されるアルゴリズムはSHA256です。
(6) 処理されたファイルとデジタル署名ファイルは、それから、エスクローエージェントとレジストリオペレータ間で合意された通りに、SFTP、SCP、 HTTPSファイルアップロードなどのセキュアな電子的メカニズムによりエスクローエージェントへ転送されます。ICANNによって許可される場合には、CD-ROM、DVD-ROM、またはUSBストレージデバイスなどの物理媒体を介した、非電子的な提供方法を使用することができます。
(7) エスクローエージェントは、それから、本仕様書のパートA、8項に記載される手順を用いて、すべての転送された（処理された）データファイルを承認します。
5. ファイルの命名規則。 ファイルは次の命名規則に従って命名されます：
{gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} ここで、
5.1. {gTLD}はgTLD名に置き換えられます。IDN-TLDの場合には、ASCII互換形式
（Aラベル）を使用する必要があります。
5.2. {YYYY-MM-DD}はトランザクションのタイムラインウォーターマークとして使用されるその時に対応する日付によって置き換えられます。すなわち、 2009-08-02T00:00Zに対応する全額デポジットには、使用される文字列は
「2009-08-02」となります。
5.3. {type}は次によって置き換えられます：
(1) データが全額デポジットを示す場合には、「full」
(2) データが差額デポジットを示す場合には、「diff」
(3) データが仕様書4の3項に指定されるように、一括登録データアクセスファイルを示す場合には、「thin」
(4) データが仕様書4の3.2項に定義されるように、特定のレジストラからの分厚い登録データの場合には、「thick-{gurid}」。{gurid}要素は、データと関連したIANAレジストラIDと置き換える必要があります。
5.4. {#}は一連のファイルの中での「1」から始まる、そのファイルの位置によって置き換わられます。単独のファイルの場合には、これは「1」によって置き換えられる必要があります。
5.5. {rev}は「0」から始まるこのファイルの版数によって置き換えられます：
5.6. 見かけ上同名ファイルのデジタル署名ファイルである場合には、{ext}は
「sig」によって置き換えられます。 それ以外の場合は、「ryde」によって置き換えられます。
6. 公開鍵の配布。 それぞれのレジストリオペレータとエスクローエージェントは、指定された電子メールアドレスへ電子メールにより、他方の当事者（場合によって、レジストリオペレータ、またはエスクローエージェント）へ自身の秘密鍵を配布します。 各当事者は電子メールの返信により、他方の当事者の秘密鍵の受領を確認し、配布側の当事者はそれに続いて、対面や電話などのオフラインの方法によって、送信された鍵が本物であることを再確認します。このようにして、配布側の当事者により運営される電子メールサーバーによってユーザが電子メールの送受信ができるまで、公開鍵の転送が本物であることを確認されます。 エスクローエージェント、レジストリオペレータおよびICANNは、同様の手順で、公開鍵を交換します。
7. デポジットの通知。 各デポジットの提供と合わせて、レジストリオペレータはエスクローエージェントとICANNへ（draft-lozano-icann-registry-interfaces に記載されるAPIを用いて、本仕様書（以下、「インタフェース仕様書」といいます）のパートA、9項、参考資料5を参照してください）デポジット作成時に生成されたレポートを含み、そのデポジットがレジストリオペレータによって検査され、完全で正確であることを明記したレジストリオペレータからの書面による仕様書
（認証された電子メールによって）を提供します。 この仕様書の準備と提出は、レジストリオペレータまたはその被指名人により実施される必要があります。但し、そのような被指名人はエスクローエージェントやエスクローエージェントの関係者であってはならないものとします。 レジストリオペレータは、その仕様書
の中にデポジットの「id」と「resend」属性を含めます。 この属性は、この仕様書のパートA、9項、参考文献1で説明されています。
そうでない場合は、既にRFCレジストリオペレータは発効日時点で最新のドラフトバージョンのインタフェース仕様を利用します。レジストリオペレータは自己の選択として、発行日以降により新しいバージョンのインタフェース仕様を利用することができます。 インタフェース仕様がRFCとして公開されると、レジストリオペレータはその公開から180暦日以内にそのバージョンのインタフェース仕様を実装します。
8. 検証プロシージャ
(1) それぞれの処理されたファイルの署名ファイルが検証されます。
(2) 処理されたファイルが大きなファイルの断片である場合、後者は一緒に置かれます。
(3) 前の手順で取得した各ファイルは、その後復号化され、展開されます。
(4) 前の手順に含まれる各データファイルは、その後、この仕様書の参考資料1の9項、パートAに定義される形式に対して検証されます。
(5) データエスクローエージェントは、この仕様書Aのパート2、参考文献2並びに、その参考文献に含まれるその他すべてのデータエスクロー検証プロセスに定義されるように、検証プロセスを拡張しました。
手順のいずれかで食い違いがある場合、そのデポジットは不完全であるとみなされます。
9. 参 考 資 料 。
(1) ドメイン名データエスクロー使用（作業中）、
xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxxxxxx-xxxx-xxxxxx
(2) ドメイン名登録データ(DNRD) オブジェクトマッピング、
xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxx-xxxxxxx-xxxx-xxxxxxx-xxxxxxx
(3) OpenPGPメッセージフォーマット、 xxxx://xxx.xxx-xxxxxx.xxx/xxx/xxx0000.xxx
(4) OpenPGPパラメータ、
xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxx-xxxxxxxxxx/xxx-xxxxxxxxxx.xxxxx
(5) レジストリとデータエスクローエージェント用ICANNインタフェース、
xxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxxx-xxxxx-xxxxxxxx-xxxxxxxxxx
パートB-法的要件
1. エスクローエージェント。 エスクロー契約を締結する前に、レジストリオペレータはエスクローエージェントの身元に関して、ICANNへ通知を提出し、ICANNへ連絡先情報と関連するエスクロー契約のコピー、それに加えてそのすべての修正条項を提出する必要があります。 さらに、エスクロー契約を締結する前に、レジストリオペレータは(a) 指定したエスクローエージェントを利用し、(b) 提供されたエスクロー契約用紙に記入して、ICANNの同意を得る必要があります。 ICANNはエスクロー契約の第三者の受益者として明示的に指定される必要があります。 ICANNは完全な自由裁量により、任意のエスクローエージェント、エスクロー契約、それに加えて任意の修正条項に対し、同意することを差し控える権利を留保します。
2. 手数料。レジストリオペレータはエスクローエージェントへ直接手数料を支払い、あるいは自身の代わりに支払わせている必要があります。レジストリオペレータが支払期限までに任意の手数料を支払わない場合には、エスクローエージェントはそのような未払いの書面による通知をICANNへ与え、ICANNはエスクローエージェントからの書面による通知を受領した後、15暦日以内に延滞料を支払うことができます。 ICANNによる延滞料金の支払いの際に、ICANNはレジストリオペレータに対して、そのような金額を請求し、そしてレジストリオペレータはレジストリ契約の下で当然支払うべき次回の支払いと合わせて、ICANNへ送金する必要があるものとします。
3. 所有権。 レジストリ契約の有効期間中のデポジットの所有権は、常にレジストリオペレータにあるものとします。 それ以降、レジストリオペレータはそのようなデポジットにあるそのような任意の所有権（場合によっては、知的財産権を含む）をICANNへ譲渡するものとします。レジストリ契約の期間中に任意のデポジットがエスクローからICANNへリリースされる場合、そのデポジットにレジストリオペレータにより保持される任意の知的財産権は、TLDの運営、メンテナンス、または移行に関する任意の用途で、非独占的、永久、取り消し不能、ロイヤルティフリー、支払い済みを原則として、自動的にICANN、またはICANNにより書面にて指定される当事者へライセンス供与されます。
4. 完全性と機密性。 エスクローエージェントは、(i) エスクローエージェントの許可された代表者のみアクセスできる、セキュアで、ロックされた、環境的に安全な設備にデポジットを保管し、維持し、(ii) 商業的に合理的な手段を用いて、デポジットの完全性と機密性を保護し、(iii) 各デポジットを1年間保持、防護することが求められます。 ICANNとレジストリオペレータは、合理的な事前の通知により、通常の営業時間中にエスクローエージェントの該当するレコードを検査する権利を提供されます。 レジストリオペレータとICANNには、随時、第三者の監査人を指定し、本仕様書2の技術仕様とメンテナンス要件をエスクローエージェントが遵守しているかを監査する権利が提供されます。
エスクローエージェントが召喚令状、裁判所やその他の司法機関から、デポジットの開示やリリースに関連したその他任意の命令を受領する場合、法律により禁止されていない限り、エスクローエージェントはレジストリオペレータとICANNへ速やかに通知します。 レジストリオペレータおよびICANNに通知した後、エスクローエージェントはレジストリオペレータまたはICANNにレジストリオペレータまたはICANNの責任において、そのような命令に異議申し立てする十分な時間を与えるものとします。但し、エスクローエージェントは任意のそのような命令に関して、その立場を示す権利を放棄しません。 エスクローエージェントは、任意の召喚令状を取り消し、あるいは制限する努力を支援するために、そのような当事者の経費負担により、レジストリオペレータまたはICANNと協力します。 追加支援を求める任意の当事者は、エスクローエージェントの標準料金または、詳細な要求を提出して得られる見積額を支払うものとします。
5. コピー。 エスクローエージェントは、エスクロー契約の条項と規定を遵守するために、任意のデポジットの複製を許可される場合があります。
6. デポジットのリリース。 エスクローエージェントがレジストリオペレータから ICANNへの提出物の効力を行使するリクエストを受け取る場合、あるいは、以下のいずれか１つを書面に明記したICANNからの通知を受け取る場合、エスクローエージェントは、レジストリオペレータの費用負担により24時間以内に、ICANNやその被指名人が、エスクローエージェントが保有するすべてのデポジットを電子的にダウンロードできるようにします。
6.1. レジストリ契約が更新されずに、契約期間が満了している、または終了されている、または
6.2. ICANNはデポジットのスケジュール上の提供日の後5暦日以内にエスクローエージェントから、本仕様書のパートB、7.1項および7.2項に記載されるような通知を受け取っておらず、(a) ICANNはエスクローエージェントおよびレジストリオペレータへその障害の通知を与え、そして(b) ICANNはそのような通知の後7暦日以内にエスクローエージェントから、その通知を受領したという通知を受け取っていません。または、
6.3. ICANNは本仕様書のパートB、7.1項および7.2項に記載されるように、エスクローエージェントから特定の日付の最新のエスクローデポジットの認証失敗についての通知、デポジット不足の通知、または日曜日に入金されるべきデポジット（すなわち、全額デポジット）の通知を受領しています。
(a) ICANNはそれを受領した通知をレジストリオペレータへ与えました。そして(b) ICANNはそのような通知を受領した後7暦日以内に、本仕様書のパートB、7.1項および7.2項に記載されるように、エスクローエージェントから、そのような全額デポジットの修正バージョンの確認通知を受領していません。または、
6.4. ICANNは過去30暦日以内にエスクローエージェントから、月曜日から土曜日までに入金されているはずだったエスクローデポジット（すなわち、差額デポジット）の不足やエスクローデポジットの失敗を知らせている5つの通知を受領しています。そして(x) ICANNはそのような通知を受領したことをレジストリオペレータへ通知を提供しました。そして(y) ICANNはそのような通知をレジストリオペレータへ送付した後7暦日以内に、エスクローエージェントから、そのような差額デポジットの修正バージョンの確認通知を受領していません。または、
6.5. レジストリオペレータは、 (i) 通常の過程で事業を行うことを中止し、または (ii) 破産を申請し、支払い不能となり、あるいは世界中の任意の場所の任意の法域における法律の下で前述のいずれかに類似したいずれかの状態にある。または、
6.6. レジストリオペレータは重大なレジストリ機能の障害を経験しており、
ICANNが本契約の2.13項に従う権利を主張している。または、
6.7. 管轄裁判所、仲裁機関、立法機関、あるいは政府機関がデポジットをICANNへリリースするように命じている。または
6.8. 本契約の2.11項の下で指定されるように、契約上および運営上のコンプライアンス監査に従う。
エスクローエージェントが以前にレジストリオペレータのデポジットをICANNまたはその被指定人へリリースしていない限り、レジストリ契約またはエスクロー契約の契約期間満了や終了の際には、エスクローエージェントはすべてのデポジットをICANNへ提供します。
7. デポジットの確認。
7.1. 各デポジットを受領したり、デポジットを修正したりした後24時間以内に、エスクローエージェントは各デポジットの形式と完全性を検証し、各デポジットに対して生成された通知をICANNへ送付する必要があります。レポートは、draft-lozano-icann-registry-interfaces に記載されるAPIを利用して、電子的に送信されます。本仕様書のパートA、9項、参考資料5を参照してください。
7.2. エスクローエージェントが任意のデポジットの検証手順の失敗を発見した場合、またはエスクローエージェントが任意のスケージュールされたデポジットを受領していない場合には、エスクローエージェントは電子メール、ファックスあるいは電話により、そのような不一致や受領していない旨をレジストリオペレータへそのような一致しないデポジットを受領した後、あるいはそのようなデポジットの期限の後24時間以内にICANN
（draft-lozano-icann-registry-interfaces に記載されるAPIを利用して、本仕様書のパートA、9項、参考資料5を参照してください）へ通知する必要があります。 そのような確認や配信失敗の通知時に、レジストリオペレータは、デポジットが提供され、検証手順を通過し、できる限り速やかにエスクローエージェントへ提供できるような修正のために必要な、変更、更新、訂正およびその他の修正の開発を開始する必要があります。
8. 改定。 エスクローエージェントおよびレジストリオペレータは、この仕様書2の任意の修正または変更から10暦日以内に、エスクロー契約の条項をこの仕様2に準拠するように改正するものとします。 本仕様書2とエスクロー契約との間に矛盾がある場合には、本仕様書2が優先されるものとします。
9. 免責事項。 エスクローエージェントは、レジストリオペレータとICANN、およびそれらの各取締役、幹部職員、代理人、従業員、メンバーおよび関係者（以下、
「被補償者」といいます）を完全かつ永遠に、エスクローエージェント、その取締役、幹部職員、代理人、従業員および契約者の虚偽、過失あるいは不正に関連し、任意の被補償者に対して、第三者により主張される、合理的な弁護士費用と経費を含む一切の請求、法的措置、損害、訴訟、法的責任、義務、コスト、費用、料金およびその他任意のあらゆる経費から補償し、免責するものとします。
仕様書3
レジストリオペレータマンスリーレポートの形式と内容
レジストリオペレータは、draft–lozano-icann-registry-interfaces で説明されるAPIを使用して、gTLDごとに1セットのマンスリーレポートを提供するものとします。次のコンテンツと共に、仕様書2、パートA、9項、参考資料5を参照してください。
ICANNは将来的にそのレポートをその他の手段で、その他の形式を用いて提供するようにリクエストすることができます。ICANNはそのレポートが関連する月末の後3カ月間、報告された情報の機密を保持するために合理的な商業上の努力を払います。 本仕様書3に規定されない限り、特定の時間に対する任意の言及は、協定世界時(UTC) を指します。マンスリーレポートは、月末時点(UTC) でのレジストリの状態を反映したデータから構成されるものとします。
1. レジストラごとのトランザクションレポート。 このレポートは、RFC 4180で指定されるようにCSV形式のファイルにコンパイルされるものとします。 このファイルは「gTLD-activity-yyyymm.csv」と名前が付けられ、ここで「gTLD」はgTLD名であり、IDN-TLDの場合にはAラベルが使用されるものとし、「yyyymm」は報告される年・月とします。 このファイルには、レジストラごとに次のフィールドを含むものとします：
フィールド番 号 | フィールド名 | 説明 |
01 | registrar-name | IANAに登録されたレジストラの正式法人名 |
02 | iana-id | レジストリオペレータがレジストラとして行動する場合には、登録タイプ（仕様書5に記載されるように）によって9998または9999を利用するか、さもなくば、xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxx に指定されるようにスポンサーレジストラのIANA idを使用する必要があります。 |
03 | total-domains | 任意のEPPステータスですが、パージされていないpendingCreateのスポンサーの下でのドメイン名総数 |
04 | total-nameservers | 任意のEPPステータスですが、パージされていないpendingCreateのTLDに関連したネームサーバー総数（ドメイン名の属性としては、ホストオブ ジェクトまたはネームサーバーホストのいずれ |
か） | ||
05 | net-adds-1-yr | 最初の契約期間を1年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
06 | net-adds-2-yr | 最初の契約期間を2年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
07 | net-adds-3-yr | 最初の契約期間を3年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
08 | net-adds-4-yr | 最初の契約期間を4年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
09 | net-adds-5-yr | 最初の契約期間を5年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
10 | net-adds-6-yr | 最初の契約期間を6年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
11 | net-adds-7-yr | 最初の契約期間を7年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
12 | net-adds-8-yr | 最初の契約期間を8年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すな わち、EPP pendingCreateステータスではない） |
ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 | ||
13 | net-adds-9-yr | 最初の契約期間を9年間（かつ登録猶予期間内に 削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
14 | net-adds-10-yr | 最初の契約期間を10年間（かつ登録猶予期間内に削除されていない）として登録が成功した（すなわち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、登録猶予期間が終了する当月に報告する必要があります。 |
15 | net-renews-1-yr | 新規更新期間を1年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
16 | net-renews-2-yr | 新規更新期間を2年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
17 | net-renews-3-yr | 新規更新期間を3年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
18 | net-renews-4-yr | 新規更新期間を4年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更 新猶予期間が終了する当月に報告する必要があ |
ります。 | ||
19 | net-renews-5-yr | 新規更新期間を5年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
20 | net-renews-6-yr | 新規更新期間を6年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
21 | net-renews-7-yr | 新規更新期間を7年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
22 | net-renews-8-yr | 新規更新期間を8年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
23 | net-renews-9-yr | 新規更新期間を9年間（かつ更新または自動更新 猶予期間内に削除されていない）として、自動的にまたはコマンドにより更新が成功した（すなわち、EPP pendingCreateステータスではない）ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 |
24 | net-renews-10-yr | 新規更新期間を10年間（かつ更新または自動更新猶予期間内に削除されていない）として、自動 的にまたはコマンドにより更新が成功した（すな |
わち、EPP pendingCreateステータスではない） ドメイン数トランザクションは、更新または自動更新猶予期間が終了する当月に報告する必要があります。 | ||
25 | transfer-gaining-successful | 正常に完了し（明示的または自動的に承認）、転送猶予期間内に削除されていない、このレジストラによって開始されたドメインの転送数トランザクションは、転送猶予期間が終了する当月に報告する必要があります。 |
26 | transfer-gaining-nacked | 他のレジストラによって拒否され、このレジストラによって開始されたドメインの転送数（例えば、EPP transfer op="reject"） |
27 | transfer-losing-successful1 | 正常に完了し（明示的または自動的に承認）、別のレジストラによって開始されたドメインの転送数 |
28 | transfer-losing-nacked | このレジストラが拒否し（例えば、EPP transfer op="reject"）、別のレジストラによって開始されたドメイン転送数 |
29 | transfer-disputed-won | このレジストラが勝った転送に関する紛争の数 （判断が下った当月に報告） |
30 | transfer-disputed-lost | このレジストラが負けた転送に関する紛争の数 （判断が下った当月に報告） |
31 | transfer-disputed-nodecision | 分割または未定のこのレジストラに関連する転 送に関する紛争の数（判断が下った当月に報告） |
32 | deleted-domains-grace | 登録猶予期間内に削除されたドメイン（EPP pendingCreateステータスの削除された名前を含まない）削除はその名前がパージされた当月に報告する必要があります。 |
33 | deleted-domains-nograce | 登録猶予期間外に削除されたドメイン（EPP pendingCreateステータスの削除された名前を含まない）削除はその名前がパージされた当月に報告する必要があります。 |
34 | restored-domains | レポート期間中に復元されたドメイン名 |
35 | restored-noreport | レジストリによりレポートの復元を求められているが、レジストラがそれを提出していない復元 |
1 誤字を訂正するように変更されました。「transfer-losing-successfully」あるいは
「transfer-losing-successful」のいずれかがフィールド名として許容できます。
された名前の総数 | ||
36 | agp-exemption-requests | AGP（登録猶予期間）免除リクエストの総数 |
37 | agp-exemptions-granted | 許可されたAGP（登録猶予期間）免除リクエストの総数 |
38 | agp-exempted-domains | 許可されたAGP（登録猶予期間）免除リクエストにより、影響を受ける名前の総数 |
39 | attempted-adds | ドメイン名作成コマンドの試行数（成功、失敗双方とも） |
最初の行には、上記の表に説明されるものと全く同じように、RFC 4180の2項に記述される「header line」と同じフィールド名を含めるものとします。 各レポートの最終ラインには、全レジストラの各列の総数を含めるものとします。このラインの最初の欄には
「総数」と書かれ、その列の2番目の欄は空欄のままとします。 上記以外の他の行を含まないものとします。 改行はRFC 4180に記載されるように、<U+000D, U+000A> とするものとします。
2. レジストリ機能の活動レポート このレポートは、RFC 4180で指定されるように CSV形式のファイルにコンパイルされるものとします。 このファイルは
「gTLD-activity-yyyymm.csv」と名前が付けられ、ここで「gTLD」はgTLD名であり、IDN-TLDの場合にはAラベルが使用されるものとし、「yyyymm」は報告される年・月とします。 このファイルには、次のフィールドを含むものとします。
フィー ルド番号 | フィールド名 | 説明 |
01 | operational-registrars | レポート期間の終了時に生産システム内で運用しているレジストラの数 |
02 | zfa-passwords | レポート期間の終了時点のアクティブゾーンファイルアクセスパスワードの数。集中ゾーンデータサービス(CZDS) が利用される場合には、エンドユーザへゾーンファイルを提供するため に、「CZDS」をアクティブゾーンファイルアクセスパスワードの数の代わりに利用することができます。 |
03 | whois-43-queries | レポート期間に応答されたWHOIS（ポート 43） クエリの数 |
04 | web-whois-queries | 検索可能なWhoisを含まない、レポート期間に応答されたウェブベースのWhoisクエリの数 |
05 | searchable-whois-queries | 提供される場合には、レポート期間に応答され |
フィールド番 号 | フィールド名 | 説明 |
た検索可能なWhoisクエリの数 | ||
06 | dns-udp-queries-received | レポート期間にUDPトランスポートにより受信したDNSクエリの数 |
07 | dns-udp-queries-responded | レポート期間に応答されたUDPトランスポートにより受信したDNSクエリの数 |
08 | dns-tcp-queries-received | レポート期間にTCPトランスポートにより受信したDNSクエリの数 |
09 | dns-tcp-queries-responded | レポート期間に応答されたTCPトランスポートにより受信したDNSクエリの数 |
10 | srs-dom-check | レポート期間に応答されたSRS(EPPと他のインタフェース)ドメイン名「check」リクエスト数 |
11 | srs-dom-create | レポート期間に応答されたSRS(EPPと他のインタフェース)ドメイン名「create」リクエスト数 |
12 | srs-dom-delete | レポート期間に応答されたSRS(EPPと他のインタフェース)ドメイン名「delete」リクエスト数 |
13 | srs-dom-info | レポート期間に応答されたSRS(EPPと他のインタフェース)ドメイン名「info」リクエスト数 |
14 | srs-dom-renew | レポート期間に応答されたSRS(EPPと他のインタフェース)ドメイン名「renew」リクエスト数 |
15 | srs-dom-rgp-restore-report | レポート期間に応答された復元レポートを提出するSRS(EPPと他のインタフェース)ドメイン名RGP「restore」リクエスト数 |
16 | srs-dom-rgp-restore-reques t | レポート期間に応答されたSRS(EPPと他のイン タフェース)ドメイン名RGP「restore」リクエスト数 |
17 | srs-dom-transfer-approve | レポート期間に応答された転送許可のための SRS(EPPと他のインタフェース)ドメイン名 「transfer」リクエスト数 |
18 | srs-dom-transfer-cancel | レポート期間に応答された転送キャンセルのためのSRS(EPPと他のインタフェース)ドメイン名 「transfer」リクエスト数 |
19 | srs-dom-transfer-query | レポート期間に応答された転送についてのクエリのためのSRS(EPPと他のインタフェース)ドメイン名「transfer」リクエスト数 |
フィールド番 号 | フィールド名 | 説明 |
20 | srs-dom-transfer-reject | レポート期間に応答された転送拒否のための SRS(EPPと他のインタフェース)ドメイン名 「transfer」リクエスト数 |
21 | srs-dom-transfer-request | レポート期間に応答された転送要求のための SRS(EPPと他のインタフェース)ドメイン名 「transfer」リクエスト数 |
22 | srs-dom-update | レポート期間に応答されたSRS(EPPと他のインタフェース)ドメイン名「update」要求（RGP復元要求を含まない）の数 |
23 | srs-host-check | レポート期間に応答されたSRS(EPPと他のインタフェース)ホスト「check」リクエスト数 |
24 | srs-host-create | レポート期間に応答されたSRS(EPPと他のインタフェース)ホスト「create」リクエスト数 |
25 | srs-host-delete | レポート期間に応答されたSRS(EPPと他のインタフェース)ホスト「delete」リクエスト数 |
26 | srs-host-info | レポート期間に応答されたSRS(EPPと他のインタフェース)ホスト「info」リクエスト数 |
27 | srs-host-update | レポート期間に応答されたSRS(EPPと他のインタフェース)ホスト「update」リクエスト数 |
28 | srs-cont-check | レポート期間に応答されたSRS(EPPと他のインタフェース)コンタクト「check」リクエスト数 |
29 | srs-cont-create | レポート期間に応答されたSRS(EPPと他のインタフェース)コンタクト「create」リクエスト数 |
30 | srs-cont-delete | レポート期間に応答されたSRS(EPPと他のインタフェース)コンタクト「delete」リクエスト数 |
31 | srs-cont-info | レポート期間に応答されたSRS(EPPと他のインタフェース)コンタクト「info」リクエスト数 |
32 | srs-cont-transfer-approve | レポート期間に応答された転送許可のための SRS(EPPと他のインタフェース)コンタクト 「transfer」リクエスト数 |
33 | srs-cont-transfer-cancel | レポート期間に応答された転送キャンセルのためのSRS(EPPと他のインタフェース)コンタクト 「transfer」リクエスト数 |
34 | srs-cont-transfer-query | レポート期間に応答された転送についてのクエ |
フィールド番 号 | フィールド名 | 説明 |
リのためのSRS(EPPと他のインタフェース)コンタクト「transfer」リクエスト数 | ||
35 | srs-cont-transfer-reject | レポート期間に応答された転送拒否のための SRS(EPPと他のインタフェース)コンタクト 「transfer」リクエスト数 |
36 | srs-cont-transfer-request | レポート期間に応答された転送要求のための SRS(EPPと他のインタフェース)コンタクト 「transfer」リクエスト数 |
37 | srs-cont-update | レポート期間に応答されたSRS(EPPと他のイン タフェース)コンタクト「update」リクエスト数 |
最初の行には、上記の表に説明されるものと全く同じように、RFC 4180の2項に記述される「header line」と同じフィールド名を含めるものとします。 上記以外の他の行を含まないものとします。 改行はRFC 4180に記載されるように、<U+000D, U+000A> とするものとします。
シングルインスタンス共有レジストリシステムの一部であるgTLDには、レジストリ機能の活動レポートには、システム内のすべてのTLDのコンタクトまたはホストトランザクション総数を含めることができます。
仕様書 4
登録データ公開サービス
1. 登録データディレクトリサービス。 ICANN が異なるプロトコルを要求するまでの間、レジストリオペレータは、RFC 3912 に従いポート 43 を通じて利用可能な WHOIS サービスを運用するとともに、以下の形式で少なくとも以下の要素に対する無料の公開クエリベースのアクセスを提供する<whois.nic.TLD> でのweb ベースのディレクトリサービスを運用するものとします。 ICANN は、代替的な形式およびプロトコルを指定する権利を留保します。かかる指定に際し、レジストリオペレータは、合理的に可能な限り速やかに、かかる代替的な指定を履行するものとします。
以下の場合、レジストリオペレータは、ICANN による要求後 135 日以内に、ドメイン名登録データへのアクセス（SAC 051）をサポートする新たな標準を実装するものとします。1) IETF が標準を作成した（すなわち、少なくともRFC 2026 で規定される提案標準RFC として公開された）場合、および 2) その実装が、レジストリの全体的運用に関連して商業上合理的である場合。
1.1. 応答のフォーマットは、以下に概略する半自由式テキスト フォーマットに沿ったものであり、その後ろには、空白行と、レジストリオペレータの権利およびデータベースへのクエリを実行するユーザの権利を明示した法的免責事項とが続くものとします。
1.2. 各データオブジェクトは、キー / 数値のペアのセットで表現されるものであり、行の最初がキーで始まり、その後ろに区切りのためのコロンとスペースが置かれ、その後ろに値が続きます。
1.3. 複数の値が存在するフィールドについては、同じキーを持つ複数のキー/値のペアとすることができます（例えば、複数のネームサーバーを列記する場合など）。 空白行の後の最初のキー/ 値のペアは、新たな記録の先頭であるとみなされるとともに、かかる記録を同定するものとみなされ、データを合わせてグループ化（ホスト名とIPアドレス、またはドメイン名とレジストラント情報）するのに用いられます。
1.4. 以下に指定されるフィールドは最低限の出力要求事項を規定しています。レジストリオペレータは、ICANN の承認を受けることを条件として、以下に指定されるものに追加してデータフィールドを出力することができ、その承認は、不当に留保されないものとします。
1.5. ドメイン名データ：
1.5.1 クエリフォーマット： whois EXAMPLE.TLD
1.5.2 応答のフォーマット：
ドメイン名：EXAMPLE.TLDドメインID：D1234567-TLD
WHOISサーバ： whois.example.tld参照URL： xxxx://xxx.xxxxxxx.xxxxxx：2009-05-29T20:13:00Z
作成日：2000-10-08T00:45:00Z
レジストリの有効期限：2010-10-08T00:44:59Z
スポンサーレジストラ：EXAMPLE REGISTRAR LLC
スポンサーレジストラIANA ID：5555555
ドメインステータス： clientDeleteProhibited ドメインステータス： clientRenewProhibitedドメインステータス： clientTransferProhibitedドメインステータス： serverUpdateProhibitedレジストラントID：5372808-ERL
レジストラント名：EXAMPLE REGISTRANT
レジストラントの組織名：EXAMPLE ORGANIZATION
レジストラントの番地：123 EXAMPLE STREET
レジストラントの都市名：ANYTOWNレジストラントの州名：AP
レジストラントの郵便番号：A1A1A1レジストラントの国名：EX
レジストラントの電話：+1.5555551212レジストラントの内線電話：1234
レジストラントのファックス：+1.5555551213レジストラントの内線ファックス：4321
レジストラントの電子メール：EMAIL@EXAMPLE.TLD管理担当者ID：5372809-ERL
管理担当者の氏名：EXAMPLE REGISTRANT ADMINISTRATIVE
管理担当者の組織名：EXAMPLE REGISTRANT ORGANIZATION
管理担当者の番地：123 EXAMPLE STREET
管理担当者の都市名：ANYTOWN管理担当者の州名：AP
管理担当者の郵便番号：A1A1A1管理担当者の国名：EX
管理担当者の電話：+1.5555551212管理担当者の内線電話：1234
管理担当者のファックス：+1.5555551213管理担当者の内線ファックス：
技術担当者ID：5372811-ERL
技術担当者の氏名：EXAMPLE REGISTRAR TECHNICAL
技術担当者の組織名：EXAMPLE REGISTRAR LLC
技術担当者の番地：123 EXAMPLE STREET
技術担当者の都市名：ANYTOWN技術担当者の州名：AP
技術担当者の郵便番号：A1A1A1技術担当者の国名：EX
技術担当者の電話：+1.1235551234技術担当者の内線電話：1234
技術担当者のファックス：+1.5555551213技術担当者の内線ファックス：93
技術担当者の電子メール：EMAIL@EXAMPLE.TLDネームサーバー：NS01.EXAMPLEREGISTRAR.TLDネームサーバー：NS02.EXAMPLEREGISTRAR.TLD
DNSSEC： signedDelegation DNSSEC： unsigned
>>> WHOISデータベースの最終更新：2009-05-29T20:15:00Z <<<
1.6. レジストラデータ：
1.6.1 クエリフォーマット： whois “registrar Example Registrar, Inc. ”
1.6.2 応答のフォーマット：
レジストラ名: Example Registrar, Inc.
番地：1234 Admiralty Way
都市名：Marina del Rey
州名：CA
郵便番号：90292国名：米国
電話番号：+1.3105551212
ファックス番号：+1.3105551213 電子メール： xxxxxxxxx@xxxxxxx.xxx
WHOISサーバ： whois.example-registrar.tld参照URL： xxxx://xxx.xxxxxxx-xxxxxxxxx.xxxxxxxxxxxx：Xxx Registrar
電話番号：+1.3105551213
ファックス番号：+1.3105551213
電子メール： xxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
管理担当者の連絡先：Xxxx Registrar
電話番号：+1.3105551214
ファックス番号：+1.3105551213
電子メール： xxxxxxxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
技術担当の連絡先：Xxxx Xxxx
電話番号：+1.3105551215
ファックス番号：+1.3105551216
電子メール： xxxxxxxx@xxxxxxx-xxxxxxxxx.xxx
>>> WHOISデータベースの最終更新：2009-05-29T20:15:00Z <<<
1.7. ネームサーバーデータ：
1.7.1 クエリフォーマット： whois「nameserver（ネームサーバー名）」、またはwhois「nameserver（IPアドレス）」。例：whois「nameserver NS1.EXAMPLE.TLD」
1.7.2 応答のフォーマット：
サーバー名：NS1.EXAMPLE.TLD IPアドレス：192.0.2.123
IPアドレス：2001:0DB8::1
レジストラ：Example Registrar, Inc.
WHOISサーバ： whois.example-registrar.tld
参照URL： xxxx://xxx.xxxxxxx-xxxxxxxxx.xxx
>>> WHOISデータベースの最終更新：2009-05-29T20:15:00Z <<<
1.8. 次の情報（またはWHOIS 応答における返却値）の表示の統一的な処理および把握を可能にするため、データフィールドのフォーマット （ドメインステータス、個人名および組織名、住所、番地、都市名、州名、郵便番号、国名、電話およびファックスの番号（上述のように、内線は別個のフィールドとして提供されます）、電子メールアドレス、日付および時間）が EPP RFC 5730-5734 に定められたマッピングに合致している必要があります。
1.9. ICANN の共通WHOIS インタフェース（InterNIC）に適合するために、WHOIS出力は、上記のフォーマットであるものとします。
1.10. 検索機能。 ディレクトリサービスにおける検索機能の提供はオプションですが、レジストリオペレータが提供する場合、本項に記載される仕様に準拠するものとします。
1.10.1 レジストリオペレータはweb ベースのディレクトリサービスにおける検索機能を提供します。
1.10.2 レジストリオペレータは少なくとも次のフィールドに関して、部分一致機能を提供します： ドメイン名、連絡先およびレジストラント
名、並びに連絡先およびレジストラントの郵便宛先（EPP に記載されるすべてのサブフィールド（例えば、番地、都市名、州名など）を含みます）。
1.10.3 レジストリオペレータは少なくとも次のフィールドに関して、完全一致機能を提供します： レジストラID、ネームサーバー名およびネームサーバーのIPアドレス(レジストリ、すなわち、グルーレコードが格納されたIPアドレスにのみ適用されます)。
1.10.4 レジストリオペレータは、検索基準のセットを結合する次の論理演算子： AND、OR、NOT を少なくともサポートするブール検索機能を提供します。
1.10.5 検索結果には、検索基準と一致するドメイン名が含まれます。
1.10.6 レジストリオペレータは、 1) この機能の悪用を避けるための適切な対策を実施し（例えば、正当な権限を有するユーザのみにアクセスを許可し）、2) この機能が、適用されるプライバシー法またはポリシーに従うことを確保します。
1.11. レジストリオペレータは、TLD のプライマリウェブサイト（すなわち、 ICANN ウェブサイトで公開するためにICANN に提供されるウェブサイト）で、WHOIS ポリシーと教育用資料を含むICANN が指定したウェブページへのリンクを提供するものとします。
2. ゾーンファイルアクセス
2.1. 第三者のアクセス
2.1.1 ゾーンファイルアクセス契約。レジストリオペレータはインターネットユーザと契約を締結し、これにより、そのようなユーザは、レジストリオペレータが指定したインターネットホストサーバーへアクセスし、ゾーンファイルデータをダウンロードすることが可能になります。 本契約は、ICANN またはICANN の被指名人であり得る Centralized Zone Data Access プロバイダ（以下、「CZDA プロバイダ」といいます）により標準化され、推進され、管理されます。 レジストリオペレータ（任意に、CZDA プロバイダによる）は、この仕様書の 2.1.3 項に従い、ゾーンファイルデータへのアクセスを提供し、この仕様書の 2.1.4 項に記載されるファイルフォーマットを利用し て、これを行います。 先行する記述にも拘らず、(a) CZDA プロバ イダは、以下の 2.1.2 項の認証情報の要件を満たさないユーザのア クセス要求を拒否することができ、(b) レジストリオペレータは、 以下の 2.1.2 項に基づく正しいまたは正当な認証情報を提供しない
ユーザについて、またはレジストリオペレータが以下の 2.1.5 項の規定に違反すると合理的に考える場合、ユーザのアクセス要求を拒否することができ、そして、(c) レジストリオペレータにユーザが以
下の 2.1.5 項の規定に違反したことを裏付ける証拠がある場合には、レジストリオペレータはユーザのアクセスを取り消すことができま す。
2.1.2 認証情報の要件。レジストリオペレータは、CZDA プロバイダの推進により、ユーザを正確に識別し特定するための十分な情報を提供することを各ユーザに要求します。 そのようなユーザ情報には、会社名、連絡先名、住所、電話番号、ファックス番号、電子メールアドレスおよびIPアドレスが含まれますが、これらに限りません。
2.1.3 アクセス許可。 各レジストリオペレータ（任意に、CZDA プロバイダによる）は、レジストリのゾーンデータアーカイブへアクセスするユーザのために、ICANN が指定し、管理するURL（特に、
<TLD>.xxx.xxxxx.xxx、ここで <TLD> はそのレジストリが責任を負う TLD です）へゾーンファイルSFTP（またはその他のサポートされたレジストリ）サービスを提供します。 レジストリオペレータはユーザに、レジストリオペレータの（任意に、CZDA プロバイダの）ゾーンファイルホスティングサーバーへアクセスし、トップレベルドメインゾーンファイル、そしてSFTP あるいはICANN により規定されるその他のデータ転送およびアクセスプロトコルを利用して 24
時間に 1 回以下の任意の関連する暗号法チェックサムファイルのコピーを転送する非独占的、譲渡不能の限定的権利を許可します。 すべてのゾーンファイルアクセスサーバーに対して、ゾーンファイルは<zone>.zone.gz と呼ばれるトップレベルディレクトリにあり、
<zone>.zone.gz.md5 と<zone>.zone.gz.sig でダウンロードを検証します。 レジストリオペレータ（またはCZDA プロバイダ）が履歴データも提供する場合、命名パターン<zone>-yyyymmdd.zone.gz が利用されます。
2.1.4 ファイルフォーマット標準。レジストリオペレータ（任意で、CZDAプロバイダによる）は、5 項RFC 1035 に元来定義されるような標準のマスターファイルフォーマットのサブフォーマットを利用して、パブリックDNS で使用される実際のゾーンに存在するすべてのレコードを含め、ゾーンファイルを提供します。 サブフォーマットは次の通りです。
1. 各レコードは、次の通りに 1 行にすべてのフィールドを含める必要があります。 <domain-name> <TTL> <class> <type>
<RDATA>.
2. Class とType は標準のニーモニックを使用し、小文字である必要があります。
3. TTL は、10 進数の整数である必要があります。
4. ドメイン名内で¥X と¥DDD の使用が認められます。
5. すべてのドメイン名は、小文字である必要があります。
6. レコード内のフィールドの区切り記号として 1 つのタブを使用する必要があります。
7. すべてのドメイン名は、完全に修飾される必要があります。
8. $ORIGIN ディレクティブはありません。
9. カレントオリジンを示す「@」を使用しません。
10. 前のレコードのドメイン名を継続して使用するために、レコードの初めに「blank domain names」を使用しません。
11. $INCLUDE ディレクティブはありません。
12. $TTL ディレクティブはありません。
13. 例えば、レコードのフィールドのリストを行の境界を越えて続けるために、括弧を使用しません。
14. コメントを使用しません。
15. 空白行がありません。
16. SOA レコードは、ゾーンファイルのトップと（複製して）エンドにある必要があります。
17. SOA レコードを除いて、ファイル内のすべてのレコードがアルファベット順である必要があります。
18. 1 ファイルあたり 1 つのゾーン。TLD のDNS データを複数のゾーンに分ける場合、各ゾーンは上記の通りに名前が付けられた別個のファイルに移動し、すべてのファイルはtar を用いて、<tld>.zone.tar と呼ばれるファイルに結合されます。
2.1.5 ユーザによるデータ利用。 レジストリオペレータは、合法的な目的のためにユーザがゾーンファイルを使用することを許可します。但
し、(a) ユーザは不正アクセス、不正使用、およびデータの開示から保護するためにあらゆる合理的な措置を取り、(b) いかなる状況下でも、レジストリオペレータはユーザがデータを使用できるようにすることを要求されず、あるいは認められず、(i) 利用される媒体（そのような媒体には、大量迷惑メール、商用広告、あるいは団体への勧誘の電子メール、電話、ファックス、郵便、SMS および無線アラートを含みますが、それだけに限りません）に拘わらず、ユーザの既存の顧客以外の団体への任意のマーケティング活動を許可し、それを可能とし、あるいはサポートし、(ii) レジストリオペレータや任意のICANN認定レジストラのシステムへクエリやデータを送信 する高ボリューム、自動化された、電子的処理を可能とし、または、
(iii) 任意のレジストラントの通常のビジネス活動を中断、混乱、あるいは妨害しない場合に限ります。
2.1.6 利用期間。 レジストリオペレータは、CZDA プロバイダを通じて、各ユーザに 3 カ月以上の期間にわたってゾーンファイルへのアクセスを提供します。 レジストリオペレータは、ユーザがアクセス許可を更新することを許可します。
2.1.7 無料のアクセス。 ゾーンファイルへのアクセスは、ユーザに対し、無料で、レジストリオペレータにより提供され、CZDA プロバイダにより推進されます。
2.2. 協 力
2.2.1 支援。 レジストリオペレータは、本付属文書で意図される許可され たユーザによるゾーンファイルデータの効率的なアクセスを推進し、維持するために、協力して ICANN およびCZDA プロバイダに合理的 な支援を提供します。
2.3. ICANN のアクセス。 レジストリオペレータはICANN またはその被指名人に、TLD のゾーンファイルへのバルクアクセスを、ICANN が随時合理的に指定し得る方法で継続的に提供するものとします。アクセスは少なくとも 1 日に 1 回提供されます。ゾーンファイルには、00時00分00秒 UTC に可能な限り近い時点でコミットされたSRS データが含まれます。
2.4. 緊急オペレータのアクセス。 レジストリオペレータはICANN が指定した緊急オペレータに、TLD のゾーンファイルへのバルクアクセスを、ICANNが随時合理的に指定し得る方法で継続的に提供するものとします。
3. ICANN への登録データのバルクアクセス
3.1. Thin 登録データへの定期的なアクセス。 レジストリサービスの運用上の安定性を検証および確保し、並びに、認定レジストラへのコンプライアンスチェックを推進するために、レジストリオペレータはICANN に、毎週
（ICANN が指定した曜日に）以下に指定されるような最新の登録データを提供します。 データには、ICANN が指定した取得日の前日の 00時00分00秒UTC 時点でコミットされたデータが含まれます。
3.1.1 コンテンツ。 レジストリオペレータは、すべての登録されたドメイン名に対し、少なくとも次のデータを提供します。 ドメイン名、ドメイン名リポジトリオブジェクトid (roid)、レジストラID (IANA ID)、ステータス、最終更新日、作成日、有効期限、およびネームサーバー名。 スポンサーレジストラに対しては、少なくとも次のものを提供します： レジストラ名、レジストラid (IANA ID)、レジストラWhoisサーバのホスト名、およびレジストラのURL。
3.1.2 フォーマット。 データは、データエスクローに関する仕様書 2 に指定されるフォーマット（暗号化、署名などを含みます）で提供されますが、前項に記載されるフィールドのみを含みます。すなわち、ファイルには、上記のフィールドを持つドメインおよびレジストラオブジェクトのみが含まれます。 仕様書 2 に指定されるように、レジストリオペレータには、完全デポジットファイルを代わりに提供するオプションがあります。
3.1.3 アクセス。レジストリオペレータは、ICANN が指定した取得日の 00時00分00秒 UTC 時点でファイルをダウンロードできるよう準備します。 ファイルは、SFTP によってダウンロードできるようにしますが、ICANN は将来、その他の手段を要求できます。
3.2. Thick 登録データへの特別なアクセス。 レジストラの不履行、認定解除、裁判所命令などにより、そのドメイン名が別のレジストラへ一時的または最終的に移転される場合には、ICANN の要求に応じ、レジストリオペレータは、現レジストラのドメイン名の最新データを ICANN に提供します。データは、データエスクローに関する仕様書 2 に指定されるフォーマットで提供されます。 ファイルには、現レジストラのドメイン名に関連するデータのみが含まれます。 レジストリオペレータは、商業上実施可能な限り速やかに、但し、ICANN のリクエスト後 5 日以内に、データを提供します。レジストリオペレータおよびICANN による別段の合意がない限り、ファイルは、この仕様書の 3.1 項に指定されるデータと同じ方法で、ICANN がダウンロードできるようにします。
仕様書 5
予約名の一覧
ICANN の書面による明示的な別段の許可がある場合を除き、この仕様書の条件に従い、レジストリオペレータは次のラベルのTLD 内での初回（すなわち、更新以外の）登録を留保するものとします。 自己割り当てを使用する場合、レジストリオペレータはRDDSで登録を表示する必要があります。IDN 名（以下に示される通り）の場合、IDN バリアントは、該当する場合、レジストリオペレータ IDN 登録ポリシーに従って特定されます。
1. 例示。ASCII ラベル「EXAMPLE」は、レジストリオペレータが登録を提供する TLD内のセカンドレベルおよびその他すべてのレベル（そのようなセカンドレベルおよびその他すべてのレベルを、ここでは集合的に「すべてのレベル」と呼びます）で、登録から差し控えるか、あるいはレジストリオペレータに割り当てるものとします。 このようなラベルはDNS でアクティベートできず、レジストリオペレータ以外のいかなる個人や団体へも登録のためにリリースできません。TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、そのように差し控えられたり、割り当てられたりしたラベルは、ICANN により指定された通りに譲渡されるものとします。レジストリオペレータは、ICANN 認定レジストラを利用することなく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。
2. 2 文字のラベル。すべての 2 文字の ASCII ラベルは、TLD 内のセカンドレベルで、登録から差し控えるか、あるいはレジストリオペレータに割り当てるものとします。 このようなラベルはDNS でアクティベートできず、レジストリオペレータ以外のいかなる個人や団体へも登録のためにリリースできません。但し、レジストリオペレータが、ISO 3166-1 alpha-2規格で規定される文字列に関連する政府および国コードの管理者と合意に達している限りにおいて、このような 2 文字のラベル文字列をリリースできます。 レジストリオペレータは、ICANN の承認を受けることを条件として、対応する国コードとの混乱を避けるための対策の実施に基づき、これらの予約のリリースを提案することもできます。 TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、そのような依然として登録が差し控えられたり、あるいはレジストリオペレータに割り当てられたりしているすべてのラベルは、ICANN により指定された通りに譲渡されるものとします。 レジストリオペレータは、ICANN 認定レジストラを利用すること なく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。
3. レジストリ運用の予約
3.1. 次の ASCII ラベルはTLD のレジストリ運用と関連してすべてのレベルで 使用するために、登録から差し控えるか、あるいはレジストリオペレータに割り当てる必要があります： WWW、RDDS およびWHOIS。 次のASCIIラベルはTLD のレジストリ運用と関連してすべてのレベルで使用するために、ルートゾーンへの委任に際し、レジストリオペレータに割り当てる必要があります： NIC。 レジストリオペレータはDNS の WWW、RDDS およびWHOIS をアクティベートできますが、TLD（別紙A の規定に従い、 ASCII ラベルNIC はNS リソースレコードを用いたゾーンカットとして、 DNS に規定される必要があります）の運用に必要であれば、DNS のNIC をアクティベートする必要があります。WWW、RDDS、WHOIS またはNIC のいずれも任意の個人（レジストリオペレータ以外）や第三者へリリースしたり、登録したりしてはいけません。 TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、すべてのそのように差し控えられたり、割り当てられたりした名前は、ICANN により指定された通りに譲渡されるものとします。 レジストリオペレータは、ICANN 認定レジストラを利用することなく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。 このようなドメインは、レジストラ ID 9999 により識別されるものとします。
3.1.1 本契約の別紙A で特に、レジストリオペレータが IDN の登録を提供できると規定している場合、レジストリオペレータは用語「NIC」の言語固有の翻訳または音訳やDNS の用語「Network Information Center」の翻訳のための省略形をレジストリオペレータのIDNテー
ブルとIDN 登録規則に従って、アクティベートすることもできます。このような翻訳、音訳や省略形はレジストリオペレータによって予 約され、任意の求められるレジストリ機能を提供するために、ラベルNIC に追加して使用することができます。 誤解を避けるために、レジストリオペレータはこの仕様書 3 の 3.1 項に従って、ASCII ラベルNIC をアクティベートする必要があります。
3.2. レジストリオペレータはすべてのレベルで、TLD の運用や推進に必要な、最大 100 の名前（該当する場合には、それに加えて、その IDN バリアント）までDNS でアクティベートすることができます。 レジストリオペレータは、当時最新の ICANN レジストラ認定契約(RAA) に定義される用語のような名前の登録名保有者として行動する必要があります。これらのアクティベーションは、本契約の 6.1 項の目的でのトランザクションとみなされます。レジストリオペレータは、(i) ICANN 認定レジストラによりそのような名前を登録するか、あるいは、(ii) そのような名前を自らに割り当て、そ れらの名前に関して、当時最新の RAA （または、レジストラと登録名保有者間での登録契約条件を規定するその他いずれかの条項の代用）の 3.7.7.1項から 3.7.7.12 項までのサブセクションに規定されるICANN コンセンサ
スポリシーとその義務を遵守するためにICANN に従い、責任を負います。レジストリオペレータが上記のオプション (ii) を選択する場合、レジストラID 9998 を用いて、これらのトランザクションを識別するものとします。レジストリオペレータの自由裁量により、そして仕様書 7 に規定される RPM を含み、本契約のその他すべての条項に従い、そのような名前は別の個人や団体へ登録のためにリリースできます。
3.3. レジストリオペレータは本契約の 2.6 項に従い、すべてのレベルでレジストリオペレータ名（該当する場合、そのIDN バリアントを含みます）の登録を差し控えたり、それを割り当てたりすることができます。 このような名前はDNS でアクティベートできませんが、仕様書 7 に規定される当該 RPM を含み、本契約のすべての条項遵守の対象となる、レジストリオペレータへの登録やレジストリオペレータの自由裁量によって、別の個人や団体への登録のためにリリースすることができます。TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、そのような依然として登録が差し控えられたり、あるいはレジストリオペレータに割り当てられたりしているすべての名前は、ICANN により指定された通りに譲渡されるものとします。 ICANN のリクエストにより、レジストリオペレータは本契約の 2.6 項に従い、レジストリオペレータへ差し控えたり、あるいは割り当てられたりしているすべての名前のリストを提供するものとします。レジストリオペレータは、ICANN 認定レジストラを利用することなく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。
3.4. 仕様書 6 の 6.1 項に指定される非アクティベーション期間の終結に際して有効なレジストリオペレータは、ドメイン名「icann-sla-monitoring.<tld>」をICANN テストレジストラ（仕様書 10 の 8.2 項に記載されるレジストラなど）へ割り当てるものとします。 そのようなドメイン名がTLD の登録に利用できない場合、あるいは TLD の登録ポリシーと矛盾している場合に
は、レジストリオペレータは異なるドメイン名を ICANN と相談したうえで、
ICANN のテストレジストラへ割り当てることができます。 そのような任意の代替ドメイン名の割り当ては、そのような相談を受けて ICANN へ通知されます。 ICANN テストレジストラへのドメイン名
「icann-sla-monitoring.<tld>」の割り当ては、(i) 本契約の 6.1 項の目的でのトランザクションとはみなされず、(ii) この仕様書 5 の 3.2 項の下でレジス
トリオペレータに利用可能な 100 のドメイン名に加算されず、あるいは、
(iii) ここに（該当する場合）仕様書 13（BRAND TLD 規定）に従い、レジストリオペレータのBRAND TLD としての資格に悪影響を与えません。
4. 国名および地域名。国際的に認知される次のリストに含まれる国名および地域名
（該当する場合、そのIDN バリアントを含みます）は、すべてのレベルで、登録から差し控えるか、あるいはレジストリオペレータに割り当てるものとします。
4.1. ISO 3166-1 リストに含まれるすべての国名および地域名の省略形（英語）
（このリストは随時更新されます。ISO 3166-1 リストには、例外的に欧州
連合も定められています。また、その範囲は 1999 年 8 月に拡張され、欧州連合の名称を提示する必要のあるすべての用途が含まれるようになりました）
<xxxx://xxx.xxx.xxx/xxx/xxxxxxx/xxxxxxx_xxxxx/xxx_0000_xxxx_xxxxx/xxx-0 166-1_decoding_table.htm>。
4.2. 地理学的名称に関する国連専門家グループによる「Technical Reference Manual for the Standardization of Geographical Names（地理学的名称の標準化に関するテクニカルリファレンスマニュアル）」、第 3 部世界の国名。および、
4.3. 国連地名標準化会議の国名ワーキンググループが作成した国連公用 6 言語による国連加盟国リスト。
但し、レジストリオペレータが該当する政府機関と合意に達している限りにおいて、特定の国名および地域名（該当する場合、レジストリオペレータIDN 登録ポリシーに従うそのIDN バリアントを含みます）の予約をリリースできます。 レジストリオペレータはこのような名前をDNS でアクティベートすることはできません。但し、レジストリオペレータは、ICANN の政府諮問委員会の審査および ICANN の承認を受けることを条件として、これらの予約のリリースを提案することができます。TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、そのような依然として登録が差し控えられたり、あるいはレジストリオペレータに割り当てられたりしているすべての名前は、ICANN により指定された通りに譲渡されるものとします。レジストリオペレータは、ICANN 認定レジストラを利用することなく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。
5. 国際オリンピック委員会、国際赤十字・赤新月運動。 ICANN が随時指示する通り、xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx に記載される国際オリンピック委員会、国際赤十字・赤新月運動に関する名前（該当する場合、その IDNバリアントを含みます）は、TLD 内のセカンドレベルで、登録から差し控えるか、あるいはレジストリオペレータに割り当てるものとします。追加の国際オリンピック委員会、国際赤十字・赤新月運動の名前（その IDN バリアントを含みます）は、ICANN からレジストリオペレータへ 10 日前に通知することにより、リストに追加することができます。 このような名前はDNS でアクティベートできず、レジストリオペレータ以外のいかなる個人や団体へも登録のためにリリースできません。TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、そのような登録が差し控えられたり、あるいはレジストリオペレータに割り当てられたりしているすべての名前は、ICANN により指定された通りに
譲渡されるものとします。 レジストリオペレータは、ICANN 認定レジストラを利用することなく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。
6. 政府間組織。 ICANN が随時指示する通り、レジストリオペレータは、政府間組織のための識別子の保護に関するICANN 理事会により決定された保護メカニズムを実施するものとします。 この 6 項に関する予約名のリストは、 xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxxxx で参照できます。 追加の名前（そのIDN バリアントを含みます）は、ICANN からレジストリオペレータへ 10 日前に通知することにより、リストに追加することができます。 政府間組織のためのそのような任意の保護された識別子はDNS でアクティベートできず、レジストリオペレータ以外のいかなる個人や団体へも登録のためにリリースできません。TLD のレジストリのオペレータとしてのレジストリオペレータの指定が終結する際、すべてのそのような保護された識別子は、ICANN により指定された通りに譲渡されるものとします。 レジストリオペレータは、ICANN 認定レジストラを利用することなく、そのような名前を自らに割り当て、更新することができ、そしてそれは本契約の 6.1 項の目的でのトランザクションとはみなされません。
仕様書 6
レジストリの相互運用性と継続性の仕様
1. 準 拠 規 格
1.1. DNS。 レジストリオペレータは、関連する既存の RFC、および RFC 1034、 1035、1123、1982、2181、2182、3226、3596、3597、4343、5966 および 6891 を含みますが、それだけに限らず、DNS とネームサーバー運用に関するすべての後継規格、修正あるいはそれに対する追加を含めて、インターネット技術タスクフォース（IETF）によって将来公開されるものを遵守するものとします。 DNS ラベルはその ASCII コーディング（例：
“xn--ndk061n”）で有効な IDN（先に指定されるように）を示す場合に、第 3 番目および第 4 番目の位置にのみハイフンを含めることができます。
1.2. EPP。 レジストリオペレータは、関連する既存の RFC、および RFC 5910、 5710、5731、5732（ホスト オブジェクトを利用する場合）、5733 と 5734と一致するExtensible Provisioning Protocol (EPP) を用いたドメイン名の プロビジョニングと管理に関するすべての後継規格、修正あるいはそれに対する追加を含めて、インターネット技術タスクフォース（IETF）によって将来公開されるそれらを遵守するものとします。レジストリオペレータが、レジストリ猶予期間 (RGP) を実装している場合は、RFC 3915 およびその後継規格を遵守します。 レジストリオペレータが、基本のEPP RFC 以外の機能を使用する必要がある場合には、レジストリオペレータはRFC 3735 に記載されるガイドラインに従い、Internet-Draft フォーマットで
EPP extensions を文書化する必要があります。 レジストリオペレータは、展開する前にICANN へサポートされたすべてのEPP オブジェクトと Extensions の関連する文書を提供し、更新します。
1.3. DNSSEC。 レジストリオペレータは、Domain Name System Security Extensions（以下、「DNSSEC」といいます）を実装する TLD ゾーンファイルに署名するものとします。 誤解を避けるために、レジストリオペレータは<TLD> のゾーンファイルとTLD のDNS サーバーの下位グルーレコードに使用されるゾーンファイルに署名するものとします。 期間中、レジストリオペレータはRFC 4033、4034、4035、4509 およびその後継規格を遵守するものとし、RFC 6781 とその後継規格に記載されるベストプラクティスに従うものとします。 レジストリオペレータが、DNS セキュリティ拡張におけるハッシュ化された認証による存在否定を実装している場合は、RFC 5155 とその後継規格に従うものとします。 レジストリオペレータは、業界のベストプラクティスに従って、セキュリティで保護された方法で子ドメイン名から公開鍵材料を受け取るものとします。レジストリはまたそのウェブサイトの中で、鍵材料を保管するための重大なセキュリティ管理と
手順、その鍵自体とレジストラントの公開鍵材料を、安全を確保して受け取るためのアクセスと利用法を記述するDNSSEC プラクティスステートメント(DPS) を公開するものとします。 レジストリオペレータは、RFC 6841に記載される次の形式に従い、その DPS を公開するものとします。DNS 応答により取得されたデータを利用したレジストリオペレータのレジストリサービスのためのトラストアンカーとして、DNSSEC 検証がアクティブであり、IANA DNS ルート鍵署名鍵セット（xxxxx://xxx.xxxx.xxx/xxxxxx/xxxxxで入手できます）を使用する必要があります。
1.4. IDN。 レジストリオペレータが国際化ドメイン名（以下、「IDN」といいます）を提供する場合、RFC 5890、5891、5892、5893 およびそれらの後継規格に従うものとします。 ICANN IDN は随時改定、修正、あるいは取って代わられるので、レジストリオペレータは、
<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxx/xxxxxxxxxxxxxx-xxxxxxxxxx.xxx> でのICANN IDN ガイドラインを遵守するものとします。 レジストリオペレータはIDN プラクティスのIANA レポジトリ内のそのIDN テーブルとIDN登録規則を公開し、絶えず更新するものとします。
1.5. IPv6。 レジストリオペレータは、そのレジストリシステム内のグルーレ コードとして、IPv6 アドレスを受け入れ、それらを DNS で公開できるものとします。 レジストリオペレータは、IANA に登録されている対応する IPv6 アドレスを持つルートゾーンに記載されている少なくとも 2 つのレ ジストリのネームサーバーにパブリックIPv6 トランスポートを提供する ものとします。 レジストリオペレータは、BCP 91 に記載される「DNS IPv6トランスポート運用ガイドライン」とRFC 4472 に記載される推奨事項と考慮すべき事項に従う必要があります。 レジストリオペレータは、本契約の仕様書 4 に定義されるように、その登録データ公開サービスのために、パブリックIPv6 トランスポートを提供するものとします。例えば、Whois (RFC 3912)、ウェブベースの Whois です。 レジストリオペレータは、IPv6によりSRS で運用することを望むgTLD 認定レジストラから、書面による最初のリクエストを受け取った後、6 カ月以内に任意のレジストラに対し、その共有登録システム(SRS) のために、パブリック IPv6 トランスポートを提供するものとします。
1.6. IANA ルートゾーンデータベース。TLD に関する信頼できる情報公開を確実に維持するために、レジストリオペレータは、IANA 関数演算子への変更リクエストを提出し、TLD の任意の古くなった、または不正確なDNS や WHOIS レコードを更新するものとします。 レジストリオペレータは、そのような任意のDNS やWHOIS レコードが古くなった、または不正確になった日以降 7 日以内にそのような任意の変更リクエストを提出するように商業上合理的な努力を払うものとします。 レジストリオペレータは、
xxxx://xxx.xxxx.xxx/xxxxxxx/xxxx で規定される手続きに従い、すべての変更リクエストを提出する必要があります。
1.7. ネットワークイングレスフィルタリング。 レジストリオペレータは、 ICANN が実施するBCP 38 とBCP 84 に記載されるように、そのレジストリサービスのために、ネットワークイングレスフィルタリングチェックを実施するものとします。
2. レジストリサービス
2.1. レジストリサービス。「レジストリサービス」とは、本契約において、次のように定義されます。 (a) 以下のタスクにおいて重要なレジストリの業務であるサービス： ドメイン名およびネームサーバーの登録に関係するレジストラからのデータ受信、TLD のゾーンサーバーに関するステータス情報のレジストラへの提供、TLD ゾーンファイルの公開、レジストリ DNS サーバーの運用、および本契約により求められる、TLD でのドメイン名サーバ登録に関係する連絡先およびその他の情報の公開、(b) 仕様書 1 に定義されるコンセンサスポリシーの策定によりレジストリオペレータが提供を要求されるその他の製品またはサービス、(c) レジストリオペレータとして指定を受けているためにレジストリオペレータのみが提供することができるその他の製品またはサービス、並びに(d) 上記の(a)、(b) または(c)の範囲内でのレジストリサービスへの重大な変更。
2.2. ワイルドカードの禁止。未登録であるか、またはレジストラントが DNS ゾーンファイルに記載されるNS レコードなどの有効なレコードを提供していないか、またはそのステータスがそれらを DNS で公開することを許可しないドメイン名については、レジストリによる RFC 1034 および 4592 に記載されるDNS ワイルドカードリソースレコードまたはDNS リソースレコードを統合するためのその他の方法もしくは技術の使用、または DNS 内でのリダイレクトの使用が禁止されます。これらのドメイン名のクエリを実行する場合は、RFC 1035 および関連するRFC の記載に従って、権威ネームサーバーがRCODE 3 の「Name Error」の応答（別名「NXDOMAIN」）を返す必要があります。 この規定は、レジストリオペレータ（または登録サービスの提供に携わる関係者）がデータを管理したり、管理を手配したり、管理することで収益を得たりする、DNS ツリー内のすべてのレベルのすべてのDNS ゾーンファイルに適用されます。
3. レジストリの継続性
3.1. 高い可用性。 レジストリオペレータは、（xxなまたは局所的な）技術的障害、またはレジストリオペレータが制御できない特別な出来事もしくは状況の場合の継続運営を確保するために、ネットワークおよび地理的に分散した冗長サーバー（該当する場合、ネットワークレベルの冗長性、エン
ドノードレベルの冗長性、および負荷分散スキームの実装を含みます）を 使用してその運用を実施します。レジストリオペレータの緊急運用部門は、常に特別な出来事に応答できるようにするものとします。
3.2. 特別な事象。 レジストリオペレータは、レジストリオペレータが制御でき ない特別な事象の終了後 24 時間以内にレジストリの最重要機能を回復し、そのような事象の後最大で 48 時間以内に完全なシステム機能を回復する
ように、関与する最重要機能のタイプに応じて、商業上合理的な努力を払うものとします。 そのような事象による休止は、サービスの可用性の欠如とはみなされません。
3.3. ビジネス継続性。レジストリオペレータはビジネス継続性の計画を維持するものとし、これは、レジストリオペレータが制御できない特別な事象またはレジストリオペレータのビジネスの失敗の場合にレジストリサービスを維持することを可能にするものであり、レジストリサービス継続性プロバイダの指定を含めることができます。そのような計画にレジストリサービス継続性プロバイダの指定が含まれる場合、レジストリオペレータはそのようなレジストリサービス継続性プロバイダの名前および連絡先情報を ICANN に提供するものとします。 レジストリオペレータが制御できない特別な事象において、レジストリオペレータが連絡を受けられない場合、レジストリオペレータはICANN が（存在する場合）指定されたレジストリサービス継続性プロバイダに連絡できることに同意します。レジストリオペレータは、少なくとも年に 1 回、レジストリサービス継続性テストを実施するものとします。
4. 悪 用 の 緩 和
4.1. 悪用対応連絡先。 レジストリオペレータは、有効な電子メールアドレスおよび郵便宛先を含む正確な連絡先の詳細、並びに TLD での悪意のある行動に関連する問い合わせに対応するための一次連絡先をICANN に提供し、ウェブサイトで公開するものとし、そのような連絡先の詳細に変更があればICANN へ速やかに通知します。
4.2. オーファングルーレコードの悪意のある利用。 レジストリオペレータは、そのようなレコードが悪意のある行動と関連して存在することを示す書面形式の証拠を提供された場合、オーファングルーレコード
（xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxxx/xxxxxxxx/xxx000.xxx で定義される通り）を削除するためのアクションを取るものとします。
5. サポートされる初回および更新登録期間
5.1. 初回登録期間。 登録名の初回登録は、レジストリで 1 年単位で最長 10 年間まで行うことができます。誤解を避けるために、登録名の初回登録は 10年を超えることはできません。
5.2. 更新期間。 登録名の更新は、1 年単位で最長 10 年間まで行うことができます。 誤解を避けるために、登録名の更新は、更新時から 10 年を超えてその登録期間を延長することはできません。
6. 名前衝突の管理
6.1. 非アクティベーション期間。レジストリオペレータは、本契約の発効日の少なくとも 120 日後までは、レジストリTLD のDNS ゾーンで名前をアクティベートしないものとします（「NIC」は除く）。レジストリオペレータがレジストラントへ非アクティベーション期間が終了するまで名前をアクティベートできないことを明確に通知する場合に限って、レジストリオペレータは、この期間中に（以下のサブセクション 6.2 項に従い）名前を割り当てることができます。
6.2. 名前衝突発生審査
6.2.1 レジストリオペレータは、レジストリTLD に関してICANN が提供する名前衝突発生審査に従う場合を除き、レジストリTLD のDNSゾーンで名前をアクティベートしないものとします。レジストリオペレータは、(A) セカンドレベルドメイン名をアクティベートする前に、その名前衝突発生審査に記載される緩和対策を実施するか、あるいは、(B) 名前衝突発生審査に記載される緩和対策が実施されていないセカンドレベルドメイン名をブロックし、審査に記載されていない名前のアクティベーションを進めます。
6.2.2 サブセクション 6.2.1 項にも拘らず、以下の場合に限って、レジス トリオペレータは、6.2.1 項に規定される対策を実施することなく、
DNS ゾーンでの名前のアクティベーションを進めることができます。
(A) レジストリTLD がこの名前のアクティベーションの代替手段に適格であるとICANN が判断した場合、および (B) レジストリオペレータが、ICANN により特定され、
<xxxx://xxxxxxxx.xxxxx.xxx/xx/xxxxxxxxxxxxx-xxx-xxxxx/xxxxxxx ement-2-17nov13-en> で規定されるすべてのセカンドレベルドメイン名をブロックした場合（このようなリストは、随時ICANN により改定される場合があります）。 レジストリオペレータはこのサブセクションに従って名前をアクティベートし、その後、サブセクション 6.2.1項に従って名前をアクティベートすることができます。
6.2.3 6.2.1 項および 6.2.2 項に従って緩和またはブロックの対象となる名前のセットは、DNS Operations, Analysis and Research Center
（DNS-OARC）が管理する「Day in the Life of the Internet」データ
<xxxxx://xxx.xxx-xxxx.xxx/xxxx/xxxx/xxxx> を含むDNS 情報の
ICANN による分析に基づきます。
6.2.4 レジストリオペレータは、ICANN コミュニティによる、これらのブロックされた名前をリリースできるか否か、およびその方法を判断するためのプロセスの策定に参加できます。
6.2.5 TLD が名前のアクティベーションの代替手段に不適格であると ICANN が判断した場合、ICANN は、TLD の最終名前衝突発生審査の完了、およびレジストリオペレータによるすべての必要な緩和対策の完了まで、TLD を委任しないことを選択できます。レジストリオペレータは、TLD のDNS ゾーンでの名前のアクティベーションの条件としてICANN が求める緩和対策には、
<xxxx://xxx.xxxxx.xxx/xx/xxxxxx/xxxxx/xxxxxxxxx/xxxxxxxxxxx-x ew-gtld-annex-1-07oct13-en.pdf> に掲載されている 2013 年 10 月 7日にICANN 理事会の新 gTLD プログラム委員会（NGPC）によって 承認された新 gTLD 名前衝突管理計画の 3.2 項に記載されるものな どの緩和対策が含まれ得るが、これらに限らないことを理解します。
6.3. 名前衝突報告処理
6.3.1 TLD の委任後の最初の 2 年間は、レジストリオペレータの緊急運用部門は、ICANN から中継される、権威 DNS 外の名前の重複使用による衝突の明らかに重大な危害を主張するレポートを受け取ることができるようにするものとします。
6.3.2 レジストリオペレータは、サブセクション 6.3.1 項に従って受け取ったレポートに迅速に対応するための内部プロセスを策定するものとします。これに基づいて、レジストリオペレータは、必要かつ適切な限りにおいて、影響を受ける当事者がそのシステムに変更を加えることを許可するために、最大 2 年間TLD ゾーンから最近アクティベートされた名前を削除することができます。
仕様書 7
権利保護メカニズムの最低要件
1. 権利保護メカニズム レジストリオペレータは、この仕様書に指定される権利保護 メカニズム（以下、「RPM」といいます）を実装し、それを確実に実行するもの とします。 そのようなRPM に加えて、レジストリオペレータは別の当事者の法 的権利を侵害、あるいは乱用することになるドメイン名の登録を断念させたり、 防いだりする、追加のRPM を開発し、実装することができます。 レジストリオ ペレータは、この仕様書 7 により求められるすべてのRPM とTLD の名前を登録 する権限を持つICANN認定レジストラにより締結されたレジストリ- レジストラ 契約の中でレジストリオペレータが開発し、実装した任意の追加 RPM を含めます。レジストリオペレータは、随時、ICANN によりあまり重大ではない観点で改定さ れる場合がある、この日付時点で xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxx-xxxxxxxxxxxx (「Trademark Clearinghouse 要件」)に掲示される、Trademark Clearinghouse に規定される必須のRPM のそれぞれに規定される要件に従い実装するものとします。 レジストリ オペレータは、当該知的財産権の任意の所有者に、ICANN 指定Trademark Clearinghouse に追加した、あるいはその代わりに、その他任意のトレードマーク 情報集合、通知、あるいは検証サービスを利用するように命じてはならないもの とします。 本契約とTrademark Clearinghouse 要件の諸条件との間に矛盾がある 場合、本契約の条件が支配するものとします。 レジストリオペレータは、拘束力 があり、強制力のあるレジストリ- レジストラ契約を少なくとも 1 つのICANN認 定レジストラと締結する必要があり、そのようなレジストラは次の通りに TLD で ドメイン名を登録する権限を持ちます。
a. レジストリオペレータが、条件付き開始プログラムを実施し、あるいは ICANN により承認済み開始プログラム（それらの用語はTrademark Clearinghouse 要件に定義される通り）を実施する許可を受ける際、レジストリオペレータは該当する場合、そのような条件付き開始プログラムまたは承認済み開始プログラムに従って、任意のドメイン名を割り当てる前に、少なくとも 1 つのICANN認定レジストラと拘束力があり、強制力のあるレジストリ- レジストラ契約を締結する必要があります。
b. レジストリオペレータが、条件付き開始プログラムを実施せず、あるいは ICANN により承認済み開始プログラムを実施する許可を受けない場合、レジストリオペレータはTLD のサンライズ期間（Trademark Clearinghouse要件に定義される通り）の有効期限の少なくとも 30 日前までに、少なくとも 1 つのICANN認定レジストラと拘束力があり、強制力のあるレジストリ- レジストラ契約を締結する必要があります。または、
c. 本契約が仕様書 13 を含む場合、レジストリオペレータはクレーム開始日
（仕様書 13 に定義される通り）より前に、少なくとも 1 つのICANN認定レジストラと拘束力があり、強制力のあるレジストリ- レジストラ契約を締結する必要があります。
この仕様書 7 は、2.9(a) および仕様書 9 を含むレジストリオペレータに適用する本契約のその他任意の義務や要件を制限したり、免除したりするものではありません。
2. 紛争解決メカニズム。 レジストリオペレータは、以下の紛争解決メカニズムを遵守するものとします。これは、随時改訂される場合があります。
a. ICANN によって採用された商標の委任後の紛争解決手続き（PDDRP）および登録制限に関する紛争解決手続き（RRDRP）（それぞれ xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx および xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxx に掲示）。 レジストリオペレータは、任意のPDDRP または RRDRP パネルによる判断に従い、 ICANN が課す救済（任意の合理的な救済を含むことができ、誤解を避けるために、本契約の 4.3(e) 項に従う本レジストリ契約の終了を含みます）を履行および遵守し、そのような判断に拘束されることに同意します。および、
b. ICANN によって採用された統一早期凍結システム（以下、「URS」といいます）（xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxx に掲示）（URS監査法人が出した裁定の実施を含みます）。
仕様書 8
継続運営証書
1. 継続運営証書は、(a) 発効日の 5 年後の応当日以前の本契約の終了後 3 年間、または発効日の 5 年後の応当日後、但し発効日の 6 年後の応当日以前の本契約の終了後 1 年間、本契約の仕様書 10 の 6 項に規定されるTLD に関連する最重要のレジストリ機能の継続運営を確保するための財務的に十分なリソースを提供し、そして、(b) (i) 取消不能のスタンバイ信用状、または (ii) 取消不能のキャッシュエスクロー預託のいずれかの形式であり、それぞれ、この日付より前に ICANN が公開し、補完したgTLD 申請者ガイドブックのモジュール 2 の付属書類– 評価の質問および基準– の項目 50(b)（これは、参照によりこの仕様書 8 に組み込まれます）に規定される要件を満たすものとします。 レジストリオペレータは、継続運営証書の効力を発効日から 6 年間維持し、ICANN をその受益者である第三者として維持するのに必要なまたは望ましいすべてのアクションを取るように、最善の努力をするものとします。レジストリオペレータが取消不能のスタンバイ信用状を取得することを選択したものの、上記で求められる期間が得られない場合、レジストリオペレータは、信用状がこの日付より前にICANN が公開し、補完したgTLD申請者ガイドブックのモジュール 2 の付属書類– 評価の質問および基準– の項目 50(b) に規定される要件をその他の点で満たす場合には、1年の期間で「エバーグリーン条項」付きの信用状を取得することができ、発行銀行がその最終期限満了をICANN へ通知するまで、またはICANN が書面にて証明されるように当該信用状をリリースするまで、無期限の追加期間にわたって改定なしに毎年延長することが可能です。但し、発行銀行が発効日の 6 年後の応当日前にそのような信用状の期限満了をICANN へ通知する場合、そのような信用状には、ICANN がそのような期限満了前に当該信用状を担保に資金を引き出す権利を有することを規定する必要があります。 信用状では、発行銀行がそのような期限満了または非更新の少なくとも 30 日前にICANN へ通知することを求める必要があります。信用状が発効日の 6 年後の応当日前の任意の時点で期限満了または終了となった場合、レジストリオペレータは代わりの継続運営証書を取得する必要があります。代わりの継続運営証書が元の信用状の期限満了前に用意されない場合、ICANN は元の信用状に基づいて資金を引き出すことができます。レジストリオペレータは継続運営証書に関連するすべての最終文書のコピーをICANN へ提出するものとし、継続運営証書に関連する重大な進展をICANN へ逐次合理的に通知するものとします。レジストリオペレータは、ICANN の書面による事前の同意なしに（そのような同意は、不当に留保されないものとします）、継続運営証書またはそれに関連するその他の文書の改定またはそれに基づく権利放棄に同意し、またはそれを許可しないものとします。
2. レジストリオペレータが前パラグラフに基づく義務を履行するように最善の努力をしたにも拘らず、継続運営証書の全部または一部が、何らかの理由により、発効日の 6 年後の応当日前に期限満了したか、またはその別の当事者により終了さ
れた場合、レジストリオペレータは、速やかに (i) そのような期限満了または終了およびその理由をICANN へ通知し、そして、(ii) 発効日の 5 年後の応当日以前の本契約の終了後 3 年間、または発効日の 5 年後の応当日後、但し発効日の 6 年後
の応当日以前の本契約の終了後 1 年間、本契約の仕様書 10 の 6 項に規定される TLD に関連する最重要のレジストリ機能の継続運営を確保するための財務的に 十分なリソースを提供する、代替手段（以下、「代替手段」といいます）を手配するものとします。 そのような任意の代替手段は、ICANN にとって継続運営証書に劣らず有利な条件であるものとし、さもなくば、ICANN が合理的に受け入れ可能な形式および内容であるものとします。
3. この仕様書 8 にこれと異なる定めがあっても、レジストリオペレータはいつでも、継続運営証書を、(i) 発効日の 5 年後の応当日以前の本契約の終了後 3 年間、または発効日の 5 年後の応当日後、但し発効日の 6 年後の応当日以前の本契約の終了後 1 年間、本契約の仕様書 10 の 6 項に規定されるTLD に関連する最重要のレジストリ機能の継続運営を確保するための財務的に十分なリソースを提供し、そして、(ii) ICANN にとって継続運営証書に劣らず有利な条件を含み、さもなくば、 ICANN が合理的に受け入れ可能な形式および内容である、代替手段に置き換えることができます。 パラグラフ 2 または本パラグラフ 3 のいずれかに従って、レジストリオペレータが継続運営証書を置き換える場合には、この仕様書 8 の条項は、元の継続運営証書に関して適用されなくなるものとしますが、それ以降、そのような代替手段に関して適用されるものとし、そのような手段はそれ以降、本契約において、継続運営証書とみなされるものとします。
仕様書 9
レジストリオペレータ行動規範
1. TLD のレジストリの運用に関連して、レジストリオペレータは、以下のことを行わず、親会社、子会社、関係者、下請業者またはその他の関連団体が以下のことを行うことを、そのような当事者が TLD に関するレジストリサービスの提供に携わる（以下、それぞれ「レジストリ関連当事者」といいます）限りにおいて、許可しません。
a. レジストリシステムおよび関連するレジストリサービスへの運用アクセスについて、特定のレジストラを直接的または間接的に優遇したり、特別な配慮を与えたりすること。但し、そのような優遇または配慮を受ける資格を得るための相当の機会が、実質的に同様の条件で、実質的に同様の状況において、すべてのレジストラに提供される場合は、この限りではありません。
b. ICANN認定レジストラを通して登録される名前を除き、自身の権利でドメイン名を登録すること。但し、レジストリオペレータは、(a) 本契約の 2.6項に従って、名前の登録を留保することができ、(b) 仕様書 5 の 3.2 項に従って、最大 100 の名前まで登録から差し控えるか、あるいはレジストリオペレータに割り当てることができます。
c. 未登録のドメイン名についての消費者による検索または解決要求に関する情報への独自のアクセスに基づいて、TLD またはTLD のサブドメインで名前を登録すること（一般的に「フロントランニング」と呼ばれています）。または、
d. TLD の管理および運用に合理的に必要な場合を除き、加盟レジストラがレジストラントに関する個人データをレジストリオペレータまたはレジストリ関連当事者に開示することを許可すること。但し、すべての無関係な第三者（その他のレジストリオペレータを含みます）が、実質的に同様の条件で、実質的に同様の状況において、そのようなユーザデータへの等しいアクセスを与えられる場合は、この限りではありません。
2. レジストリオペレータまたはレジストリ関連当事者が、レジストラまたはレジストラと再販サービスのプロバイダとしても運営する場合、レジストリオペレータは、そのようなサービスがレジストリオペレータとは別個の法人を通じて提供されることを確保し、またはそのようなレジストリ関連当事者に確保させ、そのレジストラまたはレジストラと再販運営に関して別個の帳簿を保持します。
3. レジストリオペレータまたはレジストリ関連当事者が、レジストラまたはレジストラと再販サービスのプロバイダとしても運営する場合、レジストリオペレータ
は、少なくとも年 1 回の内部審査を実施して、この行動規範の遵守を確保します。
レジストリオペレータは、各暦年の終了後 20 暦日以内に、内部審査の結果とともに、レジストリオペレータによるこの行動規範の遵守について証明する、レジストリオペレータの執行役員が署名した証明書を、ICANN から提供されるアドレスに電子メールで提供します。 （ICANNは将来、そのようなレポートの形式と内容を指定したり、レポートが他の合理的な手段によって提出されたりするよう指定できます。）レジストリオペレータは ICANN がそのような結果および証明書を公表できることに同意します。但し、ICANN は、本契約の 7.15 項に従う場合を除き、そのような結果に含まれる機密情報を開示しないものとします。
4. 本仕様書のいかなる規定も、 (i) ICANN がレジストリオペレータによるこの行動規範の不遵守の主張に関する調査を実施することを制限したり、(ii) レジストリオペレータが、レジストリオペレータによるこの行動規範の不遵守の主張に関するICANN の調査への協力を拒否する理由を与えたりするものではありません。
5. 本仕様書のいかなる規定も、レジストリオペレータまたはレジストリ関連当事者が、あらゆる点で TLD に無関係な製品およびサービスに関して、レジストラまたは再販業者との通常のビジネスの過程で、アームズレングストランザクションを締結する能力を制限するものではありません。
6. レジストリオペレータはこの行動規範の免除を要求することができ、そのような免除は、レジストリオペレータが、(i) TLD でのすべてのドメイン名登録が、レジストリオペレータまたはその関係者の排他的使用のために、レジストリオペレータへ登録され、レジストリオペレータにより管理されていること、(ii) レジストリオペレータがTLD での登録の制御または使用をレジストリオペレータの関係者ではない第三者へ売却、配布または移転しないこと、および (iii) 公共の利益を保護するためにTLD へのこの行動規範の適用が必要でないことを、ICANN が合理的に満足できるように証明した場合、ICANN によりICANN の合理的な裁量で認められます。
仕様書 10 レジストリのパフォーマンス仕様 | ||
1. | 定義 | |
1.1. | DNS。 RFC 1034、1035 および関連するRFC で規定されるドメインネーム | |
システムを指します。 | ||
1.2. | DNSSEC の適切な解決。 ルートトラストアンカーから特定のドメイン名、例えば、TLD、TLD の下に登録されるドメイン名などまでの、有効な DNSSEC | |
信頼チェーンが存在します。 | ||
1.3. | EPP。 RFC 5730 および関連するRFC で規定されるExtensible Provisioning Protocol を指します。 | |
1.4. | IPアドレス。IPv4 アドレスまたはIPv6 アドレスを指すもので、これら 2 つを何ら区別しない場合に用います。区別が必要な場合は、IPv4 またはIPv6 | |
という用語を用います。 | ||
1.5. | プローブ。 （DNS、EPPなどの）テスト（下記を参照してください）の実 | |
施に用いられる、世界中の様々な場所に所在するネットワークホスト。 | ||
1.6. | RDDS。 登録データディレクトリサービスは、本契約の仕様書 4 に定義されるように、WHOIS およびWeb ベースのWHOIS サービスの総称です。 | |
1.7. | RTT。 ラウンドトリップタイムまたはRTT は、リクエストを必要とする | |
パケットのシーケンスにおける最初のパケットの最初のビットの送信から、 | ||
応答の受領を必要とするシーケンスの最後のパケットの最後のビットの受 | ||
信までを計測した時間を指します。クライアントが応答受信済みとみなす | ||
必要のあるパケットのシーケンスの全部を受信できなかった場合、かかる | ||
リクエストは未回答とみなされます。 | ||
1.8. | SLR。 サービスレベル要件は、サービスレベル契約（SLA）において測定 | |
される一定のパラメータについて求められるサービスの水準です。 | ||
2. サービスレベル合意の表
パラメータ | SLR （月次） | |
DNS | DNS サービスの可用性 | 0 分のダウンタイム= 100% の可用性 |
DNS ネームサーバーの可用性 | ≤ 432 分以下のダウンタイム( 99%) | |
TCP DNS 解決RTT | ≤ 1500 ms 以下、クエリの少なくとも 95% に ついて |
UDP DNS 解決RTT | ≤ 500 ms 以下、クエリの少なくとも 95% に ついて | |
DNS 更新時間 | ≤ 60 分以下、プローブの少なくとも 95% に ついて | |
RDDS | RDDS の可用性 | ≤ 864 分以下のダウンタイム( 98%) |
RDDS クエリRTT | ≤ 2000 ms 以下、クエリの少なくとも 95% に ついて | |
RDDS 更新時間 | ≤ 60 分以下、プローブの少なくとも 95% に ついて | |
EPP | EPP サービスの可用性 | ≤ 864 分以下のダウンタイム( 98%) |
EPP セッション- コマンド RTT | ≤ 4000 ms 以下、コマンドの少なくとも 90% について | |
EPP クエリ- コマンドRTT | ≤ 2000 ms 以下、コマンドの少なくとも 90% について | |
EPP 変換- コマンドRTT | ≤ 4000 ms 以下、コマンドの少なくとも 90% について |
レジストリオペレータにおいては、種々のサービスについて、サービスごとに統計的にトラフィックが低い日時にメンテナンスを実施することが推奨されます。 但し、計画休止または同様のサービス利用不能もしくは遅延期間に関する規定はないことに留意してください。いずれのダウンタイムも、保守のためのものであれシステム障害によるものであれ、単にダウンタイムとして記録され、SLA の目的において算入されます。
3. DNS
3.1. DNS サービスの可用性。 DNS プローブからのDNS クエリに回答する、特定のドメイン名（例えば、TLD）の権威として列記されたネームサーバーのグループの能力のことを指します。サービスが特定の時点で利用可能とみなされるには、DNS で登録された少なくとも 2 つの委任されたネームサーバーが、ネームサーバーが解決されるそのパブリック DNS 登録済み「IPアドレス」のそれぞれについての「DNS テスト」から好結果を得る必要があります。 51% 以上のDNS テストプローブにおいて、サービスが所定の時間内に利用不能であった場合に、DNS サービスは利用不能とみなされます。
3.2. DNS ネームサーバーの可用性。 インターネットユーザからのDNS クエリに回答する、ドメイン名に対する権威として列記された特定のネームサーバーのパブリックDNS 登録済み「IPアドレス」の能力のことを指します。監視対象のドメイン名のすべてのネームサーバーにおけるすべてのパブリックDNS 登録済み「IPアドレス」が、個別にテストされるものとします。 51% 以上のDNS テストプローブにおいて、所定の時間内にネームサーバー「IPアドレス」についての「DNS テスト」から未定義/ 未回答という結
果が得られた場合に、ネームサーバー「IPアドレス」は利用不能とみなされます。
3.3. UDP DNS 解決 RTT。 UDP DNS クエリおよび対応するUDP DNS 応答の、2つのパケットのシーケンスのRTTのことを指します。RTT が関連する SLRで規定される時間よりも 5 倍大きい場合、RTT は、未定義とみなされます。
3.4. TCP DNS 解決 RTT。 TCP コネクションの開始から終了（単一のDNS クエリに対するDNS 応答の受信を含みます）までのパケットのシーケンスの RTT のことを指します。 RTT が関連する SLR で規定される時間よりも 5倍大きい場合、RTT は、未定義とみなされます。
3.5. DNS 解決RTT。 「UDP DNS 解決RTT」または「TCP DNS 解決 RTT」のいずれかを指します。
3.6. DNS 更新時間。 ドメイン名における変換コマンドのEPP 確認の受信から、親ドメイン名のネームサーバーが「DNS クエリ」に対して変更と一致するデータをもって回答するまでを計測した時間のことを指します。 これは DNS 情報への変更のみに適用されます。
3.7. DNS テスト。 特定の「IPアドレス」へ送信された 1 件の非再帰DNS クエリ（UDP またはTCPによる）を意味します。 DNSSEC がクエリされたDNSゾーンで提供される場合、クエリが回答されたとみなされるには、署名が、親ゾーンで公開された該当のDS レコードに対して、または親が署名されていない場合には、静的に構成されたトラストアンカーに対して、明確に検証される必要があります。 クエリへの回答は、レジストリシステムからのこれに対応する情報を含んでいなければなりません。そうでない場合、クエリは未回答とみなされます。「DNS 解決RTT」が該当の SLR よりも 5倍高いクエリは、未回答とみなされます。 DNS テストによりもたらされ得る結果は、 「DNS 解決RTT」に対応するミリ秒の数値または未定義/ 未回答です。
3.8. DNS パラメータの測定。 1 分ごとに、すべてのDNS プローブが、監視対象のドメイン名のネームサーバーにおけるパブリックDNS 登録済み「IPアドレス」のそれぞれについて UDP またはTCP「DNS テスト」を実施します。
「DNS テスト」の結果が未定義 / 未回答であった場合、テストされた IPは、新たなテストが実施されるまでの間、かかるプローブから利用不能とみなされます。
3.9. DNS プローブからの結果の収集。 測定が有効とみなされるためのアクティブなテストプローブの最低数は、いずれの測定期間においても 20 とします。そうでない場合には、測定は破棄されて不確定とみなされます。こ
の状況の継続中は、障害について SLR に対するフラグが立てられることはありません。
3.10. UDP およびTCP クエリの分布。 DNS プローブは、これらのクエリの分布を見積もり、UDP またはTCP「DNS テスト」を送信します。
3.11. DNS プローブの配置。 DNS パラメータを測定するためのプローブは、異なる地域にわたる大部分のユーザについて、ネットワーク上の DNS リゾルバの可能な限り近くに配置されます。衛星リンクなど、伝播遅延が大きいリンクの背後にプローブを展開しないよう注意する必要があります。
4. RDDS
4.1. RDDS の可用性。 インターネットユーザからのクエリに対して該当のレジストリシステムにおける適切なデータをもって応答する、TLD におけるすべてのRDDS サービスの能力のことを指します。51% 以上のRDDS テストプローブにおいて、何らかのRDDS サービスが所定の時間内に利用不能であった場合に、RDDS は利用不能とみなされます。
4.2. WHOIS クエリRTT。 TCP コネクションの開始から終了（WHOIS 応答の受信を含みます）までのパケットのシーケンスの RTT のことを指します。 RTT が該当のSLR の 5 倍以上である場合、RTT は、未定義とみなされます。
4.3. Web ベースの WHOIS クエリRTT。TCP コネクションの開始から終了（単 一のHTTP リクエストに対するHTTP 応答の受信を含みます）までのパケ ットのシーケンスの RTT のことを指します。 かかる情報を得るためにレ ジストリオペレータが多段階の手順を実行する場合は、最後の段階のみを 測定するものとします。RTT が該当のSLR の 5 倍以上である場合、RTT は、未定義とみなされます。
4.4. RDDS クエリRTT。「WHOIS クエリRTT」および「Web ベースの WHOIS
クエリRTT」の総称です。
4.5. RDDS 更新時間。 ドメイン名、ホストまたはコンタクトにおける変換コマンドのEPP 確認の受信から、RDDS サービスのサーバーが変更を反映した時点までを計測した時間のことを指します。
4.6. RDDS テスト。 RDDS サービスの 1 つにおけるサーバーの 1 つにおける特定の「IPアドレス」へ送信された 1 件のクエリを意味します。 クエリは、レジストリシステムにおける既存のオブジェクトに関するものである必要があり、応答は、これに対応する情報を含んでいなければなりません。そうでない場合、クエリは未回答とみなされます。 RTT が該当のSLR よりも 5 倍高いクエリは、未回答とみなされます。 RDDS テストによりもたら
され得る結果は、 「RTT」に対応するミリ秒の数値または未定義 / 未回答です。
4.7. RDDS パラメータの測定。 5 分ごとに、RDDS プローブが、監視対象の TLDの各RDDS サービスのサーバーにおけるすべてのパブリックDNS 登録済み「IPアドレス」から 1 つのIPアドレスを選び出し、それぞれについて
「RDDS テスト」を実施します。 「RDDS テスト」の結果が未定義/ 未回答であった場合、該当のRDDS サービスは、新たなテストが実施されるまでの間、かかるプローブから利用不能とみなされます。
4.8. RDDS プローブからの結果の収集。測定が有効とみなされるためのアクティブなテストプローブの最低数は、いずれの測定期間においても 10 とします。そうでない場合には、測定は破棄されて不確定とみなされます。この状況の継続中は、障害について SLR に対するフラグが立てられることはありません。
4.9. RDDS プローブの配置。 RDDS パラメータを測定するためのプローブは、異なる地域にわたる大部分のユーザについて、ネットワーク内に配置されます。衛星リンクなど、伝播遅延が大きいリンクの背後にプローブを展開しないよう注意する必要があります。
5. EPP
5.1. EPP サービスの可用性。サーバーへの認証情報を既に持っているレジストリ認定レジストラからのコマンドに応答する、グループとしてのTLD EPPサーバーの能力のことを指します。 応答には、レジストリシステムにおける適切なデータを含めるものとします。 「EPP コマンド RTT」が該当のSLR よりも 5 倍高いEPP コマンドは、未回答とみなされます。 51% 以上のEPP テストプローブにおいて、EPP サービスが所定の時間内に利用不能であった場合に、EPP サービスは利用不能とみなされます。
5.2. EPP セッション - コマンド RTT。 セッションコマンドの送信に加えて、単一のEPP セッションコマンドに対するEPP 応答の受信を含むパケットのシーケンスの RTT のことを指します。 ログインコマンドに関しては、これには、TCP セッションの開始に必要なパケットが含まれます。 ログアウトコマンドに関しては、これには、TCP セッションの終了に必要なパケットが含まれます。 EPP セッションコマンドは、EPP RFC 5730 の 2.9.1 項に記載されるものです。RTT が該当のSLR の 5 倍以上である場合、RTT は、未定義とみなされます。
5.3. EPP クエリ- コマンドRTT。 クエリコマンドの送信に加えて、単一の EPPクエリコマンドに対するEPP 応答の受信を含むパケットのシーケンスの RTT のことを指します。 これには、EPP またはTCP セッションのいずれ
かの開始または終了に必要なパケットは含まれません。EPP クエリコマンドは、EPP RFC 5730 の 2.9.2 項に記載されるものです。 RTT が該当のSLRの 5 倍以上である場合、RTT は、未定義とみなされます。
5.4. EPP 変換- コマンドRTT。 変換コマンドの送信に加えて、単一のEPP 変換コマンドに対するEPP 応答の受信を含むパケットのシーケンスの RTT のことを指します。 これには、EPP またはTCP セッションのいずれかの 開始または終了に必要なパケットは含まれません。 EPP 変換コマンドは、 EPP RFC 5730 の 2.9.3 項に記載されるものです。 RTT が該当のSLR の 5 倍以上である場合、RTT は、未定義とみなされます。
5.5. EPP コマンドRTT。 「EPP セッション - コマンド RTT」、「EPP クエリ -
コマンドRTT」または「EPP 変換 - コマンドRTT」を指します。
5.6. EPP テスト。 EPP サーバーの 1 つにおける特定の「IPアドレス」へ送信された 1 つのEPP コマンドを意味します。 「create」を除く、クエリおよび変換コマンドは、レジストリシステムにおける既存のオブジェクトに関するものである必要があります。 応答には、レジストリシステムにおける適切なデータを含めるものとします。EPP テストによりもたらされ得る結果は、 「EPP コマンドRTT」に対応するミリ秒の数値または未定義/ 未回答です。
5.7. EPP パラメータの測定。 5 分ごとに、EPP プローブが、監視対象の TLD の EPP サーバーにおける 1 つの「IPアドレス」を選び出し、「EPP テスト」を実施します。これらはそのつど、3 つの異なる種類のコマンドおよび各カテゴリ内のコマンドを交互に実施する必要があります。 「EPP テスト」の結果が未定義/ 未回答であった場合、EPP サービスは、新たなテストが実施されるまでの間、かかるプローブから利用不能とみなされます。
5.8. EPP プローブからの結果の収集。 測定が有効とみなされるためのアクティブなテストプローブの最低数は、いずれの測定期間においても 5 とします。そうでない場合には、測定は破棄されて不確定とみなされます。この状況の継続中は、障害について SLR に対するフラグが立てられることはありません。
5.9. EPP プローブの配置。 EPP パラメータを測定するためのプローブは、異なる地域にわたる、レジストラのインターネットへのアクセスポイント内またはその近くに配置されます。衛星リンクなど、伝播遅延が大きいリンクの背後にプローブを展開しないよう注意する必要があります。
6. 緊 急 時 の 基 準
以下の表は緊急時の基準を示しており、TLD に関する上記のサービスのいずれかがこの条件に到達した場合、本契約の 2.13 項に定めるTLD のレジストリの緊急移行が行われます。
最重要機能 | 緊急時の基準 |
DNS サービス | ダウンタイムの合計が 4 時間/ 週 |
DNSSEC の適切な解決 | ダウンタイムの合計が 4 時間/ 週 |
EPP | ダウンタイムの合計が 24 時間/ 週 |
RDDS | ダウンタイムの合計が 24 時間/ 週 |
データエスクロー | 仕様書 2 パートB 6.2 項から 6.6 項までに記載されるデポジットの任意のリリース基準に到達しています。 |
7. 緊 急 時 の 上 申
上申は、厳密に、監視対象のサービスに関する起こり得るまたは潜在的な問題を通知し、調査することを目的とします。 上申およびその後の共同調査の開始は、それ自体が、監視対象のサービスによるそのパフォーマンス要件の不履行を示唆するものではありません。
上申は、ICANN とレジストリオペレータとの間、レジストラとレジストリオペレータとの間、およびレジストラとICANN との間で行われるものとします。 レジストリオペレータおよびICANN は、前記の緊急運用部門を提供する必要があります。 現在の連絡先をICANN とレジストリオペレータとの間で維持し、すべての関連当事者による緊急時の上申の処理の前にレジストラに公開し（上申におけるその役割に関連する場合）、常に最新の状態に保つ必要があります。
7.1. ICANN により開始される緊急時の上申
この仕様書の 6 項に記載される緊急時の基準の 10% に到達したら、ICANN の緊急運用は、関連するレジストリオペレータとの間で緊急時の上申を開始します。 緊急時の上申は、次の最小要素から成ります： 監視障害の証拠を含む上申される問題に関係する詳細情報をレジストリオペレータの緊急運用部門へ電子的（すなわち、電子メールまたは SMS）および/または音声連絡により通知すること、ICANN のスタッフとレジストリオペレータとの監視障害の共同トラブルシューティング、および監視サービスまたは監視中のサービスのいずれかに関する問題を是正するプロセスを開始するという誓約。
7.2. レジストラにより開始される緊急時の上申
レジストリオペレータは、レジストラからの緊急の要求に対応する用意のある緊急運用部門を維持します。 レジストラがレジストリサービスの障害のためにTLD のレジストリとのEPP トランザクションを実施できず、レジストリオペレータに（ICANN が命じた
連絡方法によって）連絡できないか、またはレジストリオペレータに障害に対処する能力または意思がない場合、レジストラは ICANN の緊急運用部門への緊急時の上申を開始することができます。 その場合、ICANN は、上記で説明したように、レジストリオペレータとの間で緊急時の上申を開始することがあります。
7.3. 休止および保守の通知
レジストリオペレータが保守を計画する場合、その保守の少なくとも 24 時間前に ICANN 緊急運用部門へ通知するものとします。 ICANN の緊急運用部門は、計画保守の時間に留意し、予期される保守休止期間の間は、監視対象のサービスに関する緊急時の上申サービスを凍結します。
レジストリオペレータは、サービスレベル合意およびパフォーマンス要件に基づくサービスに関するICANN との契約上の義務に従って休止を宣言する場合、ICANN 緊急運用部門へ通知します。 その宣言された休止の間は、ICANN の緊急運用部門は、関与する監視対象のサービスに関する緊急時の上申サービスに留意し、それを凍結します。
8. 性能測定に関する約束
8.1. 干渉の禁止。 レジストリオペレータは、測定プローブに干渉を加えてはなりません。これには、監視対象のサービス リクエストについて何らかの有利な取り扱いを行うことが含まれます。 レジストリオペレータは、（DNSおよびRDDS に関し）インターネット ユーザからのまたは（EPP に関し）レジストラからのその他の要求に応答するのと同様に、この仕様書に定められている測定テストに応答するものとします。
8.2. ICANN テストレジストラ。レジストリオペレータは、ICANN が上記の SLRを測定する目的で利用されるテストレジストラを持つことに同意します。レジストリオペレータは、トランザクションに課金されないこと以外にテストレジストラに何ら差別化された取り扱いを提供しないことに同意します。 ICANN は、本契約に記載される条件を契約上遵守していることを検 証する目的を除き、自身または他者のドメイン名（または、その他のレジストリオブジェクト）登録のためにレジストラを利用しないものとします。レジストリオペレータは、レジストラID 9997 を使用して、これらのトランザクションを識別するものとします。
仕様書 11
公益のための誓約
1. レジストリオペレータは、ドメイン名の登録において、2013年6月27日に ICANN 理事会によって承認されたレジストラ認定契約の当事者であるICANN認定レジストラのみを使用します。そのようなレジストラのリストは、ICANNのウェブサイトでICANN が管理するものとします。
2. レジストリオペレータは、以下のレジストリオペレータによるICANN への TLD の申請の項に記載されるすべての誓約、意思表明およびビジネス計画に従ってTLD のレジストリを運用します。それらの誓約、意思表明およびビジネス計画は、参照により本契約に組み込まれます。 本パラグラフに従うレジストリオペレータの義務は、ICANN が、随時、ICANN によりあまり重大ではない観点で改定される場合がある、ICANN により設定された公共の利益の約束に関する紛争処理プロセス
（xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxx に掲示）（以下、
「PICDRP」といいます）により強制できるものとします。 レジストリオペレータはPICDRP を遵守するものとします。レジストリオペレータは、任意の PICDRP パネルによる判断に従い、ICANN が課す救済（任意の合理的な救済を含むことができ、誤解を避けるために、本契約の 4.3(e) 項に従う本レジストリ契約の終了を含みます）を履行および遵守し、そのような判断に拘束されることに同意します。
［該当する場合、レジストリオペレータはここに特定の申請の項を挿入］
3. レジストリオペレータは次の特定の公共の利益上のための誓約を実行することに同意し、この誓約は、ICANN が、随時、ICANN によりあまり重大ではない観点で改定される場合がある、ICANN により設定された公益のための誓約に関する紛争処理プロセス
（xxxx://xxx.xxxxx.xxx/xx/xxxxxxxxx/xxxxxxxxxx/xxxxxx に掲示）（「PICDRP」）により強制できるものとします。2 レジストリオペレータはPICDRP を遵守するものとします。レジストリオペレータは、任意の PICDRP パネルによる判断に従い、ICANN が課す救済（任意の合理的な救済を含むことができ、誤解を避けるために、本契約の 4.3(e) 項に従う本レジストリ契約の終了を含みます）を履行および遵守し、そのような判断に拘束されることに同意します。
a. レジストリオペレータはレジストリ- レジストラ契約において、レジストラが登録名保有者によるマルウェア、不正に動作するボットネットの
2 この定義は上記の 2 項からの繰り返しです。レジストリオペレータがその申請に関する誓約を提供しない場合に備え、この文言は重複しています。 申請に関する誓約が提供されない場合、2 項は本レジストリ契約の最終版に含められません。
配布、フィッシング、海賊行為、商標もしくは著作権の侵害、不正もしくは欺瞞的行為、偽造、またはその他の適用法に反する活動への従事を禁止し、（適用法および任意の関連手続きに合致して）そのような活動に対してドメイン名の凍結を含む結果をもたらす規定を登録契約に含めることを要求する規定を含めるものとします。
b. レジストリオペレータは定期的に技術分析を実施してTLD のドメインがファーミング、フィッシング、マルウェアおよびボットネットなどのセキュリティ脅威の行使に使用されていないかについて評価します。レジストリオペレータは、判明したセキュリティ脅威の数と、定期的なセキュリティチェックの結果として実施したアクションに関する統計レポートを維持します。レジストリオペレータは、法律でより短い期間保持するように求められている場合やICANNから承認されている場合以外には、本契約期間中はこれらのレポートを維持し、要求があれば ICANNに提供するものとします。
c. レジストリオペレータは、明確な登録ポリシーの確立、公開、遵守による、公開と非差別の原則に合致する透明性のある方法でTLD を運用するものとします。
d. 「一般文字列」TLD のレジストリオペレータは、単一の個人もしくは 団体および/またはその個人もしくは団体の「関係者」（本レジストリ契約の 2.9(c) 項に定義される通り）だけに登録を制限するTLD での名称登録の資格基準を課すことはできません。「一般文字列」とは、財、サービス、グループ、組織、または物の一般分類を表示または説明する
（他者による財、サービス、グループ、組織、または物から特定ブランドを区別するのとは対照的）単語や用語から成る文字列を意味します。
仕様書 12
コミュニティ登録ポリシー
レジストリオペレータは、下記のおよび/またはこの仕様書 12 に添付されるすべてのコミュニティ登録ポリシーを履行および遵守するものとします。
［登録ポリシーを挿入］