注：本文書は、下記のリンクに記載されている移転ポリシーに関連するレジストラ要件の概要を説明するものです。本書内の条項の要約は、このポリシーに記載されている条項よりも優先されたり、置き換えたりするものではありません。レジストラの要件を確認し理解するには、ポリシーの全文を参照してください。
ポリシーの全文は以下で参照できます。https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en
本セクションでは、以下について説明します。
レジストラントの変更（セクションII）
定義：
- レジストラントの変更 - 以下に対する大幅な変更：
- 以前のレジストラントの名前、または
- 以前のレジストラントの組織、または
- 以前のレジストラントの電子メールアドレス、または
- 前レジストラントの電子メールアドレスがない場合、管理連絡先の電子メール
アドレス
- 単なる誤植の修正ではない登録名保有者の名前または組織への変更。
- 住所または電話番号の変更を伴う、登録名保有者の名前または組織に対する何らかの変更。
- 登録名保有者の電子メールアドレスへの変更。
- 以前のレジストラント – 変更が開始されるときの、登録名所有者（RNH）
- 新レジストラント – 前レジストラントがドメイン名登録を移転することを提案する団体または個人
- 重大な変更 – 誤植ではない修正：
レジストラントの変更の有効性：
- 一般的に、レジストラントは自分の登録/WHOISデータを更新し、他のレジストラントに自由に移転することが許可されなければなりません。
- 次の場合、レジストラは、レジストラントの変更リクエストを拒否する必要があります。
- 登録契約の期限が切れている場合で、期限切れの登録リカバリーポリシー（ERRP）に規定されているように、レジストラントがドメイン名を別のレジストラに更新または移転する権利がない場合
- レジストラントの変更は、前レジストラントおよび新レジストラントによって、
従って適切に承認されていなかった場合 - 紛争中のドメイン名（例、URS、UDRP、TDRP、裁判所命令）
レジストラントの変更プロセス
(1) ドメイン名がレジストラントの変更の対象となる資格があることを確認します
(2) 安全な仕組みを通じて、新レジストラント（またはその指定代理人）が明確にレジストラントの変更を承諾していることを確認します
(3) 前レジストラント（またはその指定代理人）に、最終的な目的がドメイン名を別のレジストラに移転することであれば、II.C.2に記載されている60日間のロックを引き起こさないようにレジストラントの変更前に、レジストラ間の移転をリクエストすることが推奨されることを通知します（レジストラが前レジストラントに60日間のロックを辞退するオプションを付与しており、前レジストラントがそのロックを辞退している場合を除く）
(4) 安全な仕組みを通じて、前レジストラント（またはその指定代理人）が明確にレジストラントの変更を承諾していることを確認します
(5) 確認してから1日以内にレジストラントの変更を処理します
(6) II.C.1.1.6に従って前および新レジストラントに通知します
(7) II.C.2に従って名前をロックします（該当する場合）
レジストラントのプロセスの変更（セクションII.C.1.1）は、以下の状況には適用されません。
- 登録契約の有効期限が切れた
- 登録契約がレジストラによって終了された
- レジストラまたはレジストリが、裁判所命令に基づいて前レジストラントの情報を更新した
- UDRP決定の実装に伴う更新
- 有効期限が切れたドメイン名の削除ポリシーに伴う更新
- 悪用に関する苦情に対応した更新
登録名保有者（セクションII.C）へのレジストラの通知
- 1.1.2および1.1.4 –
- 新レジストラントに、レジストラとの登録契約を締結しなければならないことを通知します。
- 変更を承認または取り消す方法についての指示を含んでいなければならず、前レジストラントおよび新レジストラントに、レジストラが定めた日数（60日を超えない）内に確認が行われない場合、リクエストが進まないことを通知する必要があります。
- 1.1.6 -
- 1.1.6.1 – レジストラントの変更前または1日以内に新レジストラントと前レジストラントの両方に常に送付します。
- 1.1.6.2 - 受け取ったリクエストを説明し、問題のドメインを列挙します。
- 1.1.6.3 - 質問の連絡先情報を含めます。
- 1.1.6.4 – 60日間のロック（該当する場合）を新および前レジストラントに通知します。または、以前に60日間のロックを解除したことを前レジストラントに通知します
60日間のレジストラ間転送ロック（II C 2）
- レジストラは、レジストラントの変更後に60日間のレジストラ間移転を強制的にロックする必要があります。
- レジストラは、レジストラントの変更リクエストの前に、ロックを「辞退する」オプションを前レジストラントに提供できます。
- 「辞退する」オプションが提供されており、前レジストラントがロックを辞退している場合、レジストラはレジストラロックを強制する必要はありません。
レジストラ間移転（セクションI.A.1-4）
移転権限（移転担当者）
管理担当者および登録名保有者の両方が、レジストラ間移転リクエストを承認または拒否できます。しかし、紛争が発生した場合、登録名保有者の権限は管理担当者の権限に優先します。
新レジストラ
- 移転担当者からインバウンド移転リクエストを受け取った場合は、標準の英語版テンプレートのFOA「レジストラ移転の初期認可」を送信して、承認を取得する必要があり
ます。
- レジストラは、FOAで追加の言語で利用してコミュニケーションを図ることができます。ただし、レジストラは、翻訳の正確性および完全性について責任を負う必要があります。
- レジストラは、移転を進める前に、移転担当者から確認を受ける必要があります。
- 新しいFOAは、次のいずれかの条件（セクションI A）までに終了します。
- 2.2.3.1 新レジストラがFOAの自動更新を許可し、登録名保有者が自動更新に明示的に選択していない限り、FOAが新レジストラによって発行されてから60日間が経過した。
- 2.2.3.2 レジストラ間の移転が完了する前に、ドメイン名の有効期限が切れている。
- 2.2.3.3 レジストラントの変更はセクションII.Cで完了した。
- 2.2.3.4 レジストラ間の移転が完了した。
- FOAが、前述の状況のいずれかに基づいて期限切れになった場合、レジストリに「移転」リクエストを提出する前に、移転を進めるために、新レジストラは、新しいFOAで移転リクエストを再承認しなければなりません。
現レジストラ
- レジストリオペレータからのアウトバウンド移転リクエストを受け取った場合、24時間以内に、標準英語版のテンプレートFOA「レジストラ移転リクエストの確認」を送信する必要があります。
- レジストラは、FOAで追加の言語で利用してコミュニケーションを図ることができます。ただし、レジストラは、翻訳の正確性および完全性について責任を負う必要があります。
- RNHが移転を事前承認する場合、レジストラは、変更されたバージョンのFOAを送信して、移転の事前承認が開始されたことをRNHに通知できます。
- 現レジストラが移転担当者から確認を受けておらず、レジストラが移転リクエストを明示的に拒否していない場合は、5暦日後、既定のアクションによってレジストラは移転を続行します。これは、移転に関する既定の「承認」になります。
- 現レジストラは、以下の理由のいずれかに基づき移転リクエストを拒否（NACK）できます。（セクションI.A.3.7）
- 3.7.1 詐欺の証拠。
- 3.7.2 RNHまたは管理担当者の識別情報に関して合理的な紛争が存在する場合。
- 3.7.3 ドメイン名が期限切れの場合、前の登録期間（クレジットカードのチャージバックを含む）の支払いはありません。またはドメイン名が有効期限を過ぎていない場合は、前の登録期間または現在の登録期間に対しての支払いはありません。ただし、そのような場合は、移転拒否に先立って、管理レジストラによりドメイン名を「レジストラホールド」ステータスにする必要があります。
- 3.7.4 許可された移転担当者による移転への異議申し立て。
- 3.7.5 移転がドメイン名のレジストリWHOIS記録に示されているように、作成日から60日以内にリクエストされた場合。
- 3.7.6 ドメイン名が、現レジストラに移転されてから60日以内である場合。
- 現レジストラは、以下の状況のいずれかの場合、移転リクエストを拒否（NACK）する必要があります。（セクションI.A.3.8）
- 3.8.1 レジストラに通知された係争中のUDRP。
- 3.8.2 管轄裁判所による裁判所命令の受領。
- 3.8.3 移転紛争処理ポリシーに基づく以前の移転に関連する係争中の紛争。
- 3.8.4 レジストラに通知されたURSの手続きまたはURSの凍結。
- 3.8.5 レジストラは、レジストラントの変更を受けて、60日間のレジストラ間移転ロックを課しており、RNHは、レジストラントの変更リクエストに先立って、60日間のレジストラ間移転ロックをオプトアウトしていませんでした。
移転時緊急連絡先
- レジストラは、移転に関連する緊急連絡のための移転時緊急連絡先（「TEAC」）を設立します。EACの目的は、緊急時にレジストラ間で（両当事者が理解できる言語で）リアルタイムの会話を迅速に確立することです。そして、既存の（または将来の）移転紛争の開始やプロセスの取り消しなどの決議に向けて、さらなる措置を講じることができ
ます。 - TEACとの通信は、ICANN認定レジストラ、gTLDレジストリオペレータ、およびICANNスタッフによる使用のために予約されます。TEACの連絡先は、電話番号またはその他のリアルタイム通信チャネルとして指定することができます。TEACへの通信は、ドメインの不正な消失の疑念があった後の合理的な期間内に適時に開始しなければなり
ません。 - TEAC通信チャネルを介して送信されるメッセージは、新レジストラの人間の代表者による非自動応答を生成する必要があります。インシデントの最終的な解決には時間がかかるかもしれませんが、最初のリクエストから4時間以内に回答が必要です。
- TEAC通信に応答できない場合、本ポリシーのセクションI.A.6.4に従って移転の取り消しが可能になり、ICANNはさらなる措置を講じる場合があります。
- 両当事者は、書面または電子形式によるTEAC通信および応答の対応を保持し、リクエストに応じて、本文書のコピーをICANNおよびレジストリオペレータと共有します。
「ClientTransferProhibited」ステータスと「AuthInfo」コードの要件（セクションI.A.5）
- レジストラは、RNHによる登録またはその後のリクエストの際に、「ClientTransferProhibited」ステータスを強制する条件を登録契約書に記載し、登録名保有者からの同意を得る場合、「ClientTransferProhibited」ステータスでドメイン名を強制することができます。
- レジストラは、登録名保有者の最初のリクエストから5暦日以内に、「ClientTransferProhibited」ステータスを削除し、独自の「AuthInfo」コードを登録名保有者に提供する必要があります（レジストラが独自の「AuthInfo」コードを生成し、「ClientTransferProhibited」ステータスを削除するための登録名所有者の機能を提供しない場合）。
- レジストラは、「ClientTransferProhibited」ステータスを削除するRNHの要求、またはRNHの連絡先またはネームサーバー情報の変更に使用されるメカニズムよりも制限の
厳しい「AuthInfoコード」を取得するためのメカニズムを採用することはできません。 - レジストラが生成した「AuthInfo」コードは、ドメインごとに一意でなければなり
ません。 - 「AuthInfo」コードは、RNHの識別にのみ使用する必要があります。
- レジストラは、支払いに関する紛争があることを唯一の理由として、「ClientTransferProhibited」ステータスの削除をしたり、「AuthInfoコード」をリリースしたりすることを拒否することはできません。
ICANNが承認する移転（セクションI.B）
- レジストラは、以下の結果として、スポンサーとなる登録をすべて別のレジストラに移転できます。
(i) このレジストラまたはその資産を別のレジストラが取得した場合、または
(ii) レジストラのICANNとのRAA またはレジストリとのRRAが終了したとき
- レジストラは、次の手続きを行うものとします。
- 新レジストラは、レジストリTLDに対してICANNの認定を受けていなければならず、実際にレジストリTLDのレジストリオペレータとレジストリ-レジストラ契約を結ばなければなりません。
- ICANNは、レジストラの現実的または差し迫った業務上の不履行によって脅かされる可能性のある安定性への関心など、移転が地域社会の利益を促進することを書面によりレジストリオペレータに証明する必要があります。
- これらの2つの条件が満たされる場合：
- レジストリオペレータは、50,000件以下の登録が必要な移転の場合、1回限り無料でレジストリデータベースに必要な変更を行います。
- 移転に50,000件を超える登録がある場合、レジストリオペレータは新レジストラに一回定額50,000米ドルを請求します。
