Skip to main content
Resources

移転ポリシー

このページは以下の言語でもご覧いただけます。

  1. レジストラ間移転ポリシー

    1. 保有者-権限のある移転

      1. レジストラの要件

        登録名保有者は、新レジストラの移転プロセスが本ポリシーの最低基準を満たし、ICANNまたはレジストリポリシーによってそのような移転が禁止されていない場合、レジストラ間でドメイン名登録を移転できなければなりません。レジストラ間ドメイン名移転プロセスは、混乱を避けるために、明確かつ一貫性がなければなりません。さらに、レジストラは、レジストラで採用された特定の移転プロセスに関する公開された文書を登録名保有者に通知し、そのアクセスの提供について適切な努力を行う必要があります。

        1.1 移転権限

        現レジストラまたは該当レジストリ(利用可能な場合)に公的にアクセス可能なWhoisサービスに記載されている管理担当者および登録名保有者は、新レジストラの移転リクエストの承認または拒否の権限を持つ唯一の当事者です。紛争が発生した場合、登録名保有者の権限は管理担当者の権限に優先します。

        レジストラは、移転リクエストの正当性を検証する目的で、管理レジストラまたは関連レジストリのWhoisデータを使用することができます。またはコンセンサスポリシーによって決定される別のデータソースから取得することができます。

      2. 新レジストラの要件

        登録名保有者がドメイン名登録を別のレジストラに移転することを要求する各インスタンスについて、新レジストラは以下のことを行う必要があります。

        2.1 登録名保有者または管理担当者(以下、「移転担当者」といいます)の明示的な許可を取得します。移転の確認が移転担当者から新レジストラによって受信された場合にのみ、移転が進められます。

        2.1.1 許可は、有効な標準化された許可書式(FOA)を使用して行わなければなりません。ICANNのWebサイトには2種類のFOAがあります。新レジストラは、「レジストラ移転の初期認可」というラベルのFOA使用して、移転担当者からレジストラ移転の認可をリクエストする必要があります。管理レジストラは、「レジストラ移転リクエストの確認」というラベルのFOA使用して、移転担当者から移転の確認を要求する必要があります。

        FOAは英語で通知され、移転リクエストに関する紛争はすべて英語で行われるものとします。レジストラは、他の言語で移転担当者との通信を選択することがあります。ただし、そのような選択肢を行使することを選択したレジストラは、追加の非英語版FOAの翻訳の正確性および完全性について責任があります。

        2.1.2 新レジストラがこの承認を得るために物理的プロセスに依存している場合、移転担当者が署名されていたり、さらに問題のドメイン名の管理レジストラのWhois出力の物理的なコピーがある場合はFOAの書面で十分です。

        2.1.2.1 新レジストラが物理的な承認プロセスに依拠している場合、新レジストラは、移転担当者を識別できる信頼性の高い証拠を入手し、そのような証拠が得られたことを証明する適切な記録を保持する責任があります。さらに、新レジストラは、リクエストを行う団体が実際にそのような権限を与えられていることを保証する責任があります。物理的識別の認定可能な文書は次のとおりです。

        1. 公正証書
        2. 有効な運転免許証
        3. パスポート
        4. 会社定款
        5. 軍ID
        6. 州または政府発行ID
        7. 出生証明書

        2.1.3.1 新レジストラがこの承認を得るための電子プロセスに依存している場合、識別の認定可能な文書には次のものが含まれます。

        1. 新レジストラの所在地における国内法に準拠した電子署名(そのような法律が存在する場合)。
        2. 移転担当者の電子メール アドレスと一致する電子メール アドレスを有する個人または団体からの同意。

        2.1.3.2 管理レジストラは、上記の確認を新レジストラが受信していないと認識するため、移転リクエストを却下することはできません。

        2.1.3.3 新レジストラが確認を受信していない場合は、移転を進めることはできません。あらゆる場合の仮定は、新レジストラが移転担当者による移転リクエストを受信して認証したことになります。

        2.2 レジストラツールキットに指定されている「移転」コマンドの送信により、レジストリオペレーターデータベースを変更し新しいレジストラを反映するリクエスト。

        2.2.1 「移転」コマンドの送信は、必要な権限が権限のあるWhoisデータベースに記載された移転担当者から取得されている新レジストラ部分の表現から成ります。

        2.2.2 新レジストラは、レジストラ間でドメイン名を移転する登録名保有者のリクエストを検証する責任があります。ただし、管理レジストラは、本ポリシーのセクションI.A.3(「管理レジストラの責務」)に従って、ドメイン名を新レジストラに移転する登録名保有者の意向を引き続き個々に確認しなければなりません。

        2.2.3 、「レジストラ移転の初期認可」というラベルのFOAは、以下のような状況で期限切れになります。

        2.2.3.1 新レジストラがFOAの自動更新を許可し、登録名保有者が自動更新に明示的に選択していない限り、FOAが新レジストラによって発行されてから60日間が経過した;

        2.2.3.2 レジストラ間の移転が完了する前に、ドメイン名の有効期限が切れている;

        2.2.3.3 レジストラントの変更はセクションII.Cで完了する。

        2.2.3.4 レジストラ間の移転が完了する。

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

      3. 管理レジストラの責務

        3.1 管理レジストラは、登録名保有者に移転の通知をしてレジストリから移転保留通知を受け取ったときに、登録名保有者の意向を確認しなければなりません。管理レジストラは、本ポリシーに定められた基準に従った方法でこれを行う必要があります。

        3.2 管理レジストラに採用されているリクエストの形式が本質的また実質的に管理上有益であることを確実にするために、また移転担当者の意思を確認する目的で移転担当者に明確に提供するために、管理レジストラはFOAを使用する必要があります。

        3.3 FOAは英語で通知され、移転リクエストに関する紛争はすべて英語で行われるものとします。レジストラは、他の言語で移転担当者との通信を選択することがあります。ただし、そのような選択肢を行使することを選択したレジストラは、追加の非英語版FOAの翻訳の正確性および完全性において責任があります。さらに、このような非英語コミュニケーションは、本ポリシーに定められたプロセスと手順に従わなければなりません。これには、移転リクエストの場合、レジストラは移転担当者の同意を得るために使用されるFOAに追加情報を追加しないという要件が含まれますが、これに限定されません。

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

        この要件は、管理レジストラがレコードを別の通信を介して既存の顧客に販売することを排除するものではありません。

        3.4 FOAは、可能な限り直ちに管理レジストラから登録名保有者に送信されるべきですが、レジストリオペレーターから移転リクエストを受領してから24時間以内に送信されなければなりません。

        3.5 管理レジストラから、移転リクエストに関してレジストリからの通知に5暦日以内に応答することができない場合、移転に関する既定の「承認」が行われます。

        3.6 Whoisに記載されている移転担当者が管理レジストラと移転のリクエストを確認しておらず、管理レジストラが移転リクエストを明示的に否認していない場合、既定のアクションによって管理レジストラは移転を続行します。

        3.7 次のいずれかの理由により移転リクエストが拒否された場合、管理レジストラは、登録名保有者および潜在的な新レジストラに拒絶の理由を提供しなければなりません。管理レジストラは、次の特定の場合にのみ移転リクエストを拒否することができます。

        3.7.1 詐欺の証拠。

        3.7.2 登録名保有者または管理担当者の識別に関する

        3.7.3 ドメイン名が期限切れの場合、前の登録期間(クレジットカードのチャージバックを含む)の支払いはありません。またはドメイン名が有効期限を過ぎていない場合は、前の登録期間または現在の登録期間に対しての支払いはありません。ただし、そのような場合は、移転拒否に先立って、管理レジストラによりドメイン名を「レジストラホールド」ステータスにする必要があります。

        3.7.4 許可された移転担当者による移転への異議申し立て。異議申し立ては、特定の移転リクエストまたはレジストラが受領したすべての移転リクエストに対する一般的異議を一時的または無期限に拒否するために、権限のある移転担当者による特定の請求(書面または電子的手段による)の形式をとる必要があります。いかなる場合においても、異議申し立ては権限のある移転担当者の明示的かつ十分な情報に基づく同意により、選択的に行われなければなりません。権限のある移転担当者のリクエストにより、レジストラはロックを解除するか、または権限のある移転担当者がロックを解除するための合理的にアクセス可能な方法を5日暦日以内に提供する必要があります。

        3.7.5 移転は、ドメイン名のレジストリWhois記録に示されているように、作成日から60日以内にリクエストされました。

        3.7.6 ドメイン名は、移転後60日以内(またはより短い期間で決定)です(双方がレジストラが同意した場合および/または紛争解決プロセスの決定がある場合、元のレジストラに移転されることを除く)。「移転済み」とは、本ポリシーの手順に従ってレジストラ間の移転が行われたことを意味します。

        3.8 管理レジストラは、以下のような状況で移転リクエストを拒否することができます。

        3.8.1 レジストラに通知された係争中のUDRP。

        3.8.2 管轄裁判所による裁判所命令の受領。

        3.8.3 移転紛争処理ポリシーに基づく以前の移転に関連する係争中の紛争。

        3.8.4 レジストラは、本ポリシーの手順に従ったレジストラントの変更を受けて、60日間のレジストラ間の移転ロックを課した。

        3.8.5 レジストラは、レジストラントの変更を受けて、60日間のレジストラ間移転ロックを課しており、登録名保有者は、レジストラントの変更リクエストに先立って、60日間のレジストラ間移転ロックをオプトアウトしていませんでした。

        3.9 リクエストされたレジストラの変更が拒否されない場合のインスタンスには、以下のものが含まれますが、これらに限定されません。

        3.9.1 保留中または将来の登録期間について支払いがない。

        3.9.2 登録名保有者または管理担当者から支払いがない。

        3.9.3 移転リクエストに先だって登録名保有者に対してドメイン名のロックを解除するための合理的な機会および手段が提供されていない限り、ドメイン名がレジストラ ロックステータスにある。

        3.9.4 セクションII.C.2条に規定されている最初の登録後の最初の60日間、レジストラ移転後の最初の60日間、またはレジストラントの変更を伴う60日間のロック中以外のドメイン名登録期間の制約。

        3.9.5 当該ドメインの登録名保有者が登録料を支払った場合に、レジストラとビジネスパートナー/アフィリエイトとの間の一般支払いの不履行。

        3.10 管理レジストラには、移転プロセスから独立した登録名保有者からの支払いを回収するための別の仕組みがあります。したがって、支払いに関する紛争が発生した場合、管理レジストラは、登録名保有者からのサービスの支払いを確保するための仕組みとして、移転プロセスを採用してはなりません。この要件の例外は次のとおりです。

        3.10.1 有効期限が過ぎてから移転がリクエストされた場合に前の登録期間が未払いの場合、または

        3.10.2 有効期限の前に移転がリクエストされた場合に現在の登録期間が未払いの場合。

      4. レジストラ調整

        4.1 各レジストラは、紛争処理ポリシーに基づいて紛争の申し立てや、支援に必要となるFOAや移転担当者の応答などの文書のコピーを保持する責任があります。新レジストラは、契約書の標準的な文書保存ポリシーに従って、移転担当者から受け取ったFOAのコピーを保持する必要があります。識別できる信頼性の高い証拠のコピーは、FOAと一緒に保持する必要があります。

        4.2 新レジストラと管理レジストラの両方は、適用されるレジストラ間ドメイン名の取引中および取引後に移転に関する証拠を提供する必要があります。そのような情報は、移転取引の当事者である他のレジストラからリクエストされたときに提供しなければなりません。さらに、レジストリオペレーターであるICANN、本件に関する管轄権を有する裁判所または当局、または第三者の紛争解決パネルは、リクエスト後5日以内にそのような情報を要求することがあります。

        4.3 新レジストラは、FOAの書面または電子コピーを現レジストラのリクエストに従って保持し、作成する必要があります。管理レジストラがFOAの写しをリクエストした場合、新レジストラは管理レジストラのリクエスト(出席者の関連文書の提供を含む)を5暦日以内に履行する必要があります。指定された期間内に本文書を提出できないと、本ポリシーの要件に従って移転に関する苦情が提起された場合には、レジストリオペレーターまたは紛争解決パネルによる取り消しの理由となります。

        4.4 管理レジストラまたは新レジストラのいずれかが、本ポリシーの規定に従って移転リクエストが処理されたと認識しない場合、レジストラは本ポリシーのセクションI.Cに定められた紛争解決手続きを開始することができます。

        4.5 移転リクエストを容易にするために、レジストラは、他のレジストラとレジストリによってのみ使用される一意のプライベート電子メールアドレスを提供し、維持する必要があります。

        4.5.1 この電子メールアドレスは、移転リクエストに関連する問題や、本ポリシーに記載されている手順のみに適用されます。

        4.5.2 電子メールアドレスは、移転の問題に対応できる人がメッセージを受信できるように管理する必要があります。

        4.5.3 そのような電子メールアドレスで受信したメッセージは、7暦日を超えない商業上の合理的な期間内に対応する必要があります。

        4.6 移転時緊急連絡先

        4.6.1 レジストラは、移転に関連する緊急連絡のための移転時緊急連絡先(「TEAC」)を設立します。EACの目的は、緊急時にレジストラ間で(両当事者が理解できる言語で)リアルタイムの会話を迅速に確立することです。そして、既存の(または将来の)移転紛争の開始やプロセスの取り消しなどの決議に向けて、さらなる措置を講じることができます。

        4.6.2 TEACとの通信は、ICANN認定レジストラ、gTLDレジストリオペレーター、およびICANNスタッフによる使用のために予約されます。TEACの連絡先は、電話番号またはその他のリアルタイム通信チャネルとして指定することができ、ICANNレジストラポータルに記録され、保護されます。TEACへの通信は、ドメインの不正な消失の疑念があった後の合理的な期間内に適時に開始しなければなりません。

        4.6.3 TEAC通信チャネルを介して送信されるメッセージは、新レジストラの人間の代表者による非自動応答を生成する必要があります。応答した人物またはチームは、緊急の移転問題を調査し、対処する能力があり権限がなければなりません。インシデントの最終的な解決には時間がかかるかもしれませんが、最初のリクエストから4時間以内に回答が必要です。

        4.6.4 現レジストラは、ICANNコンプライアンスおよびレジストリオペレーターへのTEAC通信に応答できないと報告します。TEAC通信に応答できない場合、本ポリシーのセクションI.A.6.4に従って移転の取り消しが可能になり、ICANNによる非更新または認定の終了などのさらなる措置を講じることができます。

        4.6.5 両当事者は、書面または電子形式によるTEAC通信および応答の対応を保持し、リクエストに応じて、本文書のコピーをICANNおよびレジストリオペレーターと共有します。本文書は、レジストラ認定契約(RAA)のセクション3.4に従って保持されます。TEAC通信チャネルのユーザーは、応答がないレジストラをICANNに報告する必要があります。さらに、ICANNは、レジストラが実際にTEACメッセージに応答していることを確実にするために、状況に応じてレジストラTEAC通信チャネルの定期的なテストを行います。

      5. 「ClientTransferProhibited」ステータスと「AuthInfo」コードの要件

        レジストラは、登録名保有者による登録またはその後のリクエストの際に、ドメイン名の移転を禁止する条件を登録契約書(登録名義人の明示的同意)に記載するという条件で、「ClientTransferProhibited」ステータスでドメイン名を設定することができます。さらに、レジストラが「ClientTransferProhibited」ステータスを削除するための登録名保有者のための機能を提供していない場合、レジストラは登録名保有者の最初のリクエストから5暦日以内に「ClientTransferProhibited」ステータスを削除する必要があります。

        5.2 レジストラが独自の「AuthInfo」コードを生成して管理し、「ClientTransferProhibited」ステータスを削除するための登録名所有者の機能を提供しない場合は、レジストラは登録名所有者に一意の「AuthInfo」コードを提供し、登録名所有者の最初のリクエストから5暦日以内に「ClientTransferProhibited」を削除する必要があります。

        5.3 レジストラは、登録名保有者による「ClientTransferProhibited」ステータスの削除のリクエストに応えて、適用可能な「AuthInfo コード」を取得するために、登録名保有者の担当者またはネーム サーバー情報に関する変更に使用される仕組みよりも制限的なメカニズムを採用することはできません。

        5.4 管理レジストラは、登録名保有者とレジストラとの間で支払いに関する紛争が生じるために、「ClientTransferProhibited」ステータスの削除をしたり、「AuthInfoコード」を登録名保有者のみにリリースしてはなりません。

        5.5 レジストラが生成した「AuthInfo」コードは、ドメインごとに一意でなければなりません。

        5.6 「AuthInfo」コードは、登録名義者の識別にのみ使用する必要がありますが、本ポリシーのセクションI.A.2およびセクションI.A.4に記載されているように、移転リクエストの承認または確認にFOAを使用する必要があります。

      6. レジストリの要件

        6.1 新レジストラから「移転」コマンドを受信すると、レジストリオペレーターは双方のレジストラに電子的通知を送信します。電子メール通知を使用するレジストリの場合、移転を容易にするために各レジストラが設定した固有の電子メールアドレスに応答通知を送信することができます。

        6.2 レジストリオペレーターは、管理レジストラからNACKプロトコルコマンドを受け取った場合を除いて、リクエストされた移転を5暦日以内に完了しなければなりません。

        6.3 新レジストラへの変更を反映するためにレジストリのデータベースが更新された場合、レジストリオペレーターは、双方のレジストラに電子的通知を送信します。通知は、移転を容易にする目的で、各レジストラによって設定された固有の電子メールアドレスまたは当事者が合意した他の電子メールアドレスに送信することができます。

        6.4 レジストリオペレーターは、移転が発生した後、レジストリオペレーターが下記の通知のいずれかを受領した場合、移転を取り消さなくてはなりません。このような場合、移転は元に戻され、[管理レジストラ]フィールドは元の状態にリセットされます。レジストリオペレーターは、レジストリ紛争の決定の場合を除き、通知を受領してから5暦日以内に移転を取り消さなければなりません。この場合、レジストリオペレーターは訴訟を起こされない限り、14暦日以内に移転を取り消さなければなりません。必要な通知は、次のいずれかになります。

        6.4.1 移転が誤って行われたこと、または本ポリシーに従わずに行われたことを電子メール、郵便またはファックスで通知した管理レジストラと新レジストラの同意書;

        6.4.2 移転を管轄する紛争解決機関の最終決定; または

        6.4.3 移転を管轄する裁判所の命令;

        6.4.4 新レジストラがセクションI.A.4.6で指定された期間内にTEACを介してメッセージに応答しなかったことを移転する前に管理レジストラから提供された文書。

      7. 登録の記録

        各レジストラは、その顧客である登録名保有者に対し、最初のドメイン名の登録日を文書化して証明するために適切な記録を保持することを要求するものとします。

      8. 登録期間の効力

        レジストリオペレーターがセクションI.Aに基づく保有者-権限のある移転を完了した場合、登録期間の満了前の期間が10年を超えない限り、既存の登録を1年間延長するものとします。

    2. ICANN-承認の移転

      1. (i)別のレジストラによるレジストラまたはその資産の取得、または(ii)レジストラの認定の欠落またはレジストリオペレーターへの認可の欠落の結果として、あるレジストラがスポンサーとなるすべての登録のスポンサーシップの移転は 以下の手順に従って行うことができます。

        1.1 新レジストラは、レジストリTLDに対してICANNの認定を受けていなければならず、実際にレジストリTLDのレジストリオペレーターとレジストリ-レジストラ契約を結ばなければなりません。

        1.2 ICANNは、レジストラの現実的または差し迫った業務上の不履行によって脅かされる可能性のある安定性への関心など、移転が地域社会の利益を促進することを書面によりレジストリオペレーターに証明する必要があります。

      2. これらの2つの条件が満たされると、レジストリオペレーターは、50,000件以下の登録が必要な移転の場合、1回限り無料でレジストリデータベースに必要な変更を行います。移転に50,000件を超える登録がある場合、レジストリオペレーターは新レジストラに一回定額US$ 50,000米ドルを請求します。

    3. 移転紛争処理ポリシー

      レジストラ間移転に関する紛争の処理手順は、移転紛争処理ポリシーに記載されています。本ポリシーの手順には、該当レジストリオペレーターとICANN認定レジストラが従う必要があります。

  2. レジストラ間の移転(レジストラントの変更)

    1. 定義

      1. 本ポリシーは次の用語を使用します。

        1.1 「レジストラントの変更」は、次のいずれかへの重大な変更となります。

        1.1.1 前レジストラントの名前

        1.1.2 前レジストラントの組織

        1.1.3 前レジストラントの電子メールアドレス

        1.1.4 前レジストラントの電子メールアドレスがない場合は、管理担当者の電子メールアドレス

        1.2 「指定代理人」とは、前レジストラントまたは新レジストラントがレジストラントの変更を承認することを明示的に認めた個人または団体を意味します。

        1.3 「重大な変更」とは、誤植の修正以外の変更を意味します。以下は重大な変更と見なされます。

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

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

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

        1.4 「前レジストラント」とは、レジストラントの変更が開始された時点の登録名保有者を意味します。

        1.5 「新レジストラント」とは、前レジストラントがドメイン名登録を移転することを提案する団体または個人を意味します。

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

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

      2. レジストラは、以下の状況下でレジストラントの変更リクエストを拒否しなければなりません。

        2.1 ドメイン名の登録契約の期限が切れている場合、期限切れの登録リカバリーポリシーのセクション2.2.5に規定されているように、登録名保有者はドメイン名を別のレジストラに更新または移転する権利がない;

        2.2 レジストラントの変更は、前レジストラントまたは新レジストラントによって、以下のセクションII.Cに従って適切に承認されなかった;

        2.3 ドメイン名は、以下を含むがこれに限定されないドメイン名関連の紛争の対象となる。

        2.3.1 レジストラに通知された係争中のUDRP;

        2.3.2 レジストラに通知された係争中のURS;

        2.3.3 係争中のTDR;

        2.3.4 管轄裁判所の裁判所命令で、レジストラントの変更を禁止し、レジストラントに通知されている。

      3. 以下の状況では、登録名保有者の詳細は、レジストラまたはレジストリオペレーターによって変更される可能性があり、以下のセクションII.C項に記載されているレジストラントの変更プロセスは適用されません。

        3.1 登録契約の有効期限が切れた;1

        3.2 登録契約がレジストラによって終了された;

        3.3 レジストラまたはレジストリオペレーターは、裁判所命令に基づいて前レジストラントの情報を更新する;

        3.4レジストラはUDRP決定の実施において前レジストラントの情報を更新する;

        3.5 レジストラは期限切れドメイン名の削除ポリシーに従って前レジストラントの情報を更新する;

        3.6レジストラは不正の苦情に応じて前レジストラントの情報を更新する。

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

      1. レジストラントの変更を前レジストラントから新レジストラントに処理するには、レジストラは以下のすべてを行う必要があります。

        1.1 ドメイン名がセクションII.Bのレジストラントの変更に適格であることを確認します;

        1.2 新レジストラントまたは新レジストラントの指定代理人からのレジストラントの変更リクエストの確認を取得します。レジストラは、新レジストラントおよび/またはそれぞれの指定代理人が明示的にレジストラントの変更に同意したことを確認するための安全な仕組み2 を使用する必要があります。確認書を入手するにあたり、レジストラは、新レジストラントに、レジストラとの登録契約を締結しなければならないことを通知する必要があります(登録契約へのリンクが提供されます)。レジストラは、レジストラントの変更を承認または取り消す方法についての指示を含んでいなければならず、新レジストラントまたは指定代理人に、レジストラが定めた日数(60日を超えない)内に確認が行われない場合、リクエストが進まないことを通知する必要があります;

        1.3 前レジストラントまたはその指定代理人に、最終的な目的がドメイン名を別のレジストラに移転することであれば、前レジストラントは、セクションII.C.2に記載されている60日間のロックを引き起こさないようにレジストラントの変更前に、レジストラ間の移転をリクエストすることが推奨されることを通知します(レジストラが前レジストラントに60日間のロックを辞退するオプションを付与しており、前レジストラントが60日間のロックを辞退している場合を除く);

        1.4 上記のII.C.1.3に記載されているように前レジストラントに通知するか、または通知した後、前レジストラントまたは前レジストラントの指定代理人からのレジストラントの変更リクエストの確認を取得します。レジストラは、前レジストラントおよび/またはそれぞれの指定代理人が明示的にレジストラントの変更に同意したことを確認するための安全な仕組みを使用する必要があります。確認書を入手するにあたり、レジストラは、前レジストラントまたは指定代理人に、レジストラが定めた日数(60日を超えない)内に確認されない場合、レジストラントの変更リクエストが進まないことを通知する必要があります;3

        1.5 上記の確認を取得してから1日以内にレジストラントの変更を処理します;

        1.6 レジストラントの変更の完了前または1日以内に前レジストラントおよび新レジストラントに通知します。通知は次の条件を満たす必要があります。

        1.6.1 レジストラントの変更前または1日以内に新レジストラントと前レジストラントの両方に常に送付する;

        1.6.2 受け取ったリクエストを説明し、問題のドメインを列挙する;

        1.6.3. 質問の連絡先情報を含める。

        1.6.4. セクションII.C.2に記載されているように、60日間のレジストラ間移転ロックを前レジストラントおよび新レジストラントに通知するか、新レジストラントにセクションII.C.2に記載されているように、60日間のレジストラ間移転ロックを以前に辞退したことを通知する。

      2. レジストラは、レジストラントの変更リクエストに先立って、登録名保有者が60日間のレジストラ間移転ロックを辞退できることを条件として、レジストラントの変更に引き続き、60日間のレジストラ間の移転ロック4 を課する必要があります。

備考

概要と背景:IRTPパートCのポリシー開発プロセス(PDP)は、既存の移転ポリシーの改善領域に対処する一連の5つのPDPのうちの3番目です。

GNSO評議会は、2012年9月22日の会合で、以下の3つの問題に対処するためのPDPを立ち上げることを決議しました。

  1. 国コードネームスペースにgTLDスペースのベストプラクティスとして使用可能なモデルがあれば、この機能が現在どのように達成されているかの調査を含む「支配権移転」機能、および関連するセキュリティ上の懸念。正規の移転活動とセキュリティのバランスをとる目的で、拒否理由#8と#9で記載されているように、ロック手順の審議も含める必要があります。
  2. 不正な移転を避けるために、期限付き許可書式(FOR)の条項を実施すべきかどうか。たとえば、新レジストラが移転担当者からFOAを送り返しても、その名前がロックされている場合、レジストラはFOA保留の調整をドメイン名ステータスに保持することができ、その間にレジストラントまたはその他の登録情報が変更されている可能性があります。
  3. レジストリが独自のIDではなくレジストラにIANA IDを使用するという要件によって、プロセスを合理化できるかどうか。

IRTPパートCワーキンググループは、2012年6月4日にパブリックコメントフォーラム(詳細はセクション6を参照)の開設と同時に、2012年10月9日の最終レポート [PDF, 1.23 MB] に続いて初回レポート [PDF, 624 KB] を公開しました。ICANN理事会は、2012年12月20日付でIRTPパートCワーキンググループの勧告を採択しました。ICANNのスタッフと連携した実施審査チームは、協調して移転ポリシーのドラフトを開発しました。ドラフトポリシーはパブリックコメント期間の対象となりました。

すべてのICANN認定レジストラは、2016年11月1日までにポリシーを遵守する必要があります。

重大な変更:セクションII.A.1.3は、重大な変更は、誤植の修正以外の変更を意味すると定義しています。レジストラには、誤植の修正を判断できる柔軟性があります。誤植の修正例としては、以下のようなものがあります。

  1. レジストラントの名前フィールドを、oJhn SmithからJohn Smithに変更する。
  2. レジストラントの名前フィールドを、Jane KganからJane Kangに変更する。
  3. レジストラントの組織を、Example, IcnからExample, Incに変更する。
  4. レジストラントの組織を、ExampleCorp.からExample Corpに変更する。

念のために明記すると、レジストラが、レジストラントの名前またはレジストラントの組織の変更を重大な変更として扱うことを妨げるものはありません。

安全な仕組み:GNSOのポリシー勧告は、レジストラによるレジストラントの変更の処理方法にある程度の柔軟性が必要であることを認識しています。たとえば、レジストラがレジストラアカウント内で知り得た情報またはWhoisなどの一般公開されているリソースに基づいて、「帯域外」認証を検討する場合などがあります。次のような例がありますが、これらに限定されるものではありません。

  1. ツールベースの認証方法を使用して確認応答を要求する電子メールを送信し、たとえば、一意のコードを提供して、レジストラが指定した方法でそれを返信させるようにする。または、
  2. 登録名保有者の電話番号への通話またはSMSの送信のいずれかの手段を使い、レジストラによって指定された方法で一意のコードを答える。または、
  3. 登録名保有者の電話番号に電話して、Web、電子メール、または郵便で登録名保有者に送信された一意のコードを伝えるように要求する。

レジストラントの変更を受けたレジストラ間移転ロック:レジストラは、セクションII.C.2で説明した60日間のレジストラ間転送ロックについて特定のEPPステータスコードを適用する必要はありません。しかし、レジストラがclientTransferProhibitedのEPPステータスコードを適用することを選択した場合は、セクションI.A.5.1に定めるように、登録名保有者がロックを解除できないように、名前をロックする必要があります。


1 登録契約の条件に従ってドメイン名の有効期限が切れた後、登録およびWhoisの詳細が変更された場合、期限切れの登録リカバリーポリシーの保護は依然として適用されます。

2 安全な仕組みの例は、本ポリシーの本文に続く実施上の注記に記載されています。

3 レジストラは、前レジストラントからの確認を得る際に追加の連絡先情報を使用することができ、一般にアクセス可能なWhoisに限定されるものではありません。

4 レジストラは、セクションII.C.2で記載されているロックの解除に制限を課すことができますが、必須ではありません。たとえば、レジストラは、5営業日後にのみロックを解除します。ロック解除は、前レジストラントの電子メールでの確認応答などによって許可されなければなりません。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."