注：本文書は、下記のリンクに記載されている移転ポリシーに関連するレジストラ要件の概要を説明するものです。本書内の条項の要約は、このポリシーに記載されている条項よりも優先されたり、置き換えたりするものではありません。レジストラの要件を確認し理解するには、ポリシーの全文を参照してください。

ポリシーの全文は以下で参照できます。https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en

本セクションでは、以下について説明します。

レジストラントの変更（セクションII）

定義：

• レジストラントの変更 - 以下に対する大幅な変更：

• 単なる誤植の修正ではない登録名保有者の名前または組織への変更。

• 住所または電話番号の変更を伴う、登録名保有者の名前または組織に対する何らかの変更。

• 登録名保有者の電子メールアドレスへの変更。

レジストラントの変更の有効性：

- 一般的に、レジストラントは自分の登録/WHOISデータを更新し、他のレジストラントに自由に移転することが許可されなければなりません。

- 次の場合、レジストラは、レジストラントの変更リクエストを拒否する必要があります。

レジストラントの変更プロセス

(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）は、以下の状況には適用されません。

登録名保有者（セクションII.C）へのレジストラの通知

• 1.1.2および1.1.4 –

60日間のレジストラ間転送ロック（II C 2）

• レジストラは、レジストラントの変更後に60日間のレジストラ間移転を強制的にロックする必要があります。

• レジストラは、レジストラントの変更リクエストの前に、ロックを「辞退する」オプションを前レジストラントに提供できます。

• 「辞退する」オプションが提供されており、前レジストラントがロックを辞退している場合、レジストラはレジストラロックを強制する必要はありません。

レジストラ間移転（セクションI.A.1-4）

移転権限（移転担当者）

管理担当者および登録名保有者の両方が、レジストラ間移転リクエストを承認または拒否できます。しかし、紛争が発生した場合、登録名保有者の権限は管理担当者の権限に優先します。

新レジストラ

• 移転担当者からインバウンド移転リクエストを受け取った場合は、標準の英語版テンプレートのFOA「レジストラ移転の初期認可」を送信して、承認を取得する必要があり
  ます。

• レジストラは、移転を進める前に、移転担当者から確認を受ける必要があります。

• 新しいFOAは、次のいずれかの条件（セクションI A）までに終了します。

• FOAが、前述の状況のいずれかに基づいて期限切れになった場合、レジストリに「移転」リクエストを提出する前に、移転を進めるために、新レジストラは、新しいFOAで移転リクエストを再承認しなければなりません。

現レジストラ

• レジストリオペレータからのアウトバウンド移転リクエストを受け取った場合、24時間以内に、標準英語版のテンプレートFOA「レジストラ移転リクエストの確認」を送信する必要があります。

• RNHが移転を事前承認する場合、レジストラは、変更されたバージョンのFOAを送信して、移転の事前承認が開始されたことをRNHに通知できます。

• 現レジストラが移転担当者から確認を受けておらず、レジストラが移転リクエストを明示的に拒否していない場合は、5暦日後、既定のアクションによってレジストラは移転を続行します。これは、移転に関する既定の「承認」になります。

• 現レジストラは、以下の理由のいずれかに基づき移転リクエストを拒否（NACK）できます。（セクションI.A.3.7）

• 現レジストラは、以下の状況のいずれかの場合、移転リクエストを拒否（NACK）する必要があります。（セクションI.A.3.8）

移転時緊急連絡先

• レジストラは、移転に関連する緊急連絡のための移転時緊急連絡先（「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）

• レジストラは、以下の結果として、スポンサーとなる登録をすべて別のレジストラに移転できます。

• レジストラは、次の手続きを行うものとします。