Skip to main content
Resources

.COM、.NETおよび.JOBSのためのThick Whois移転ポリシー

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

すべての翻訳されたコンテンツおよび文書の英語版が公式版であり、英語以外の言語の翻訳版は情報提供のみを目的として作成されたものです。

ニュース

2019年11月7日、ICANN理事会は、契約遵守の強制を延期する議決を可決しました。ICANN 契約遵守チームは、以下がすべて起こるまで、Thick WHOIS移転ポリシーの執行を延期します。

  • gTLD登録データポリシー実装レビューチーム(IRT)が、検討を完了し、迅速なポリシー策定プロセス(EPDP)チームの勧告(2019年5月15日にICANN理事会により採択)の実装タイムライン見通しを確立する。
  • ICANN組織およびIRTが、既存のポリシーおよび手順(Thick WHOIS移転ポリシーを含む)に対するEPDPチームの勧告の影響に関して、必要な情報をGNSO評議会に提供する。
  • GNSO評議会が、Thick WHOIS移転ポリシーに影響を与える関連のポリシーおよび手順(追加のポリシー作業、ガイダンス、その他の決定されるアクションを含む可能性がある)の更新に対してアクションをとるかどうかを決定する。

本ドキュメントのキーワード「必要があります」、「禁止されています」、「必要になります」、「するものとします」、「するものではない」、「すべき」、「すべきではない」、「推奨」および「できます」は、 RFC 2119(http://www.ietf.org/rfc/rfc2119.txt)の規定どおりに解釈されます。

範囲:

このポリシーは、.COM、.NETおよび.JOBS gTLDのレジストリ運用者、.COM、.NETまたは.JOBS gTLDのドメイン名登録のスポンサーとなっているすべてのレジストラに適用されます。

定義:

    • Thin(登録):レジストリ運用者が技術情報(ネームサーバー、ステータス、作成日など)およびドメイン名に関連付けられたスポンサーのレジストラのみを維持して提供する保持するドメイン名。ドメイン名の連絡先情報は、スポンサーのレジストラによって維持されます。
    • Thick(登録):スポンサーのレジストラが関連する連絡先情報のコピーをレジストリ運用者に提供するドメイン名。レジストリ運用者が、技術情報(ネームサーバー、ステータス、作成日など)およびドメイン名に関連付けられたスポンサーのレジストラを維持して提供します。ドメイン名の連絡先情報は、スポンサーのレジストラによって管理されます。
    • 既存のドメイン名:2018年5月1日以前に作成された、または、ステータスがpendingCreateのドメイン名。
    • 移転の進捗の指標:少なくとも、レジストラが管理するドメインの総数、連絡先オブジェクトが添付されているドメイン数と割合など、ThinからThickへの移転の進捗状況を測定できるようにレジストラ運用者によって作成されレジストラとICANNに定期的に通知される指標。

ポリシーと有効期限:

3.1 すべての新しいドメイン名の登録は、遅くとも2018年5月1日からThickとして提出する必要があります。

3.2 2019年2月1日までに、既存のドメイン名のすべての関連登録データをThinからThickに移行する必要があります。

以下の要件はレジストリ運用者のみに適用されます。

4.1 レジストリ運用者は、既存のドメイン名の登録データを移転(つまり、ThinからThickへの移行)するレジストラ向けに、2017年8月1日までにEPPメカニズムと別の一括移転メカニズムを導入する必要があります。

4.2 2017年5月1日までに、レジストリ運用者は、セクション4.1の要件に対応するために必要なシステムの変更を反映した文書を、対象となるレジストラとICANNに提出する必要があります。

4.3 2017年5月1日までに、レジストリ運用者は、既存のドメイン名の登録データの移転をテストするレジストラ(つまり、ThinからThickへの移行)向けに、関連する運用テスト環境(OT&E)でEPPメカニズムと別の一括移転メカニズムを導入する必要があります。

4.4 2017年8月1日までに、レジストリ運用者は、この条項に記述されているように、RFC5733で指定されたすべてのコンタクトコマンドをサポートする必要があります。EPPコンタクトフィールドの<contact:id>、<contact:postalInfo type>、および<contact:authInfo>は、レジストリ運用者による指定が必須となります。レジストリ運用者は、2019年2月1日まで、その他のすべての登録データ要素を必須とする必要はありませんが、受け入れる必要があり、2014年1月9日に承認された「基本レジストリ契約」の仕様4のセクション1またはそれ以降の修正事項、およびレジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシーに記載されているWHOIS (ポート43から利用可能)およびWebベースのディレクトリサービス要件に準拠できるようにします。

4.5 2018年5月1日から、レジストリ運用者は、この条項に記載されているEPPドメインオブジェクトの<create>コマンドのThick登録データを必須にする必要があります。レジストリ運用者は、すべての登録データ要素を必須とする必要があり、2014年1月9日に承認された「基本レジストリ契約」の仕様4のセクション1またはそれ以降の修正事項、およびレジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシーに記載されているWHOIS (ポート43から利用可能)およびWebベースのディレクトリサービス要件に準拠できるようにします。

4.6 2017年8月1日から2019年2月1日までの間、レジストリ運用者は、翌月の最初の日の23:59 UTCまでに少なくとも毎月、レジストラに移転進捗状況指標を提供する必要があります。

4.7 2017年8月1日から2019年2月1日までの間、レジストリ運用者は、翌月の最初の日の23:59 UTCまでに少なくとも毎月、すべてのレジストラに関する移転進捗状況指標をICANNに提供する必要があります。

4.8 レジストリ運用者は、「2014年1月9日に承認された基本レジストリ契約」の仕様4のセクション1(「基本レジストリ契約書」)と2017年8月1日までのそれ以降の修正事項と併せて、レジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシー(「CL&Dポリシー」)の要件を履行できます。

4.9 レジストリ運用者は、新規の登録については2018年5月1日まで、また既存のドメイン名については2019年2月までに、2014年1月9日に承認された「基本レジストリ契約」の仕様4のセクション1またはそれ以降の修正事項、およびレジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシーに記載されているWHOIS (ポート43から利用可能)およびWebベースのディレクトリサービス要件に準拠する必要があります。

4.10 2017年8月1日から2019年2月1日まで、既存のドメイン名については、共有登録システム(SRS)にデータが存在しない以下のRDDS出力フィールドについて、レジストリ運用者は、以下のRDDSフィールドを「Advisory: Clarifications to the Registry Agreement and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications(レジストリ契約および2013年レジストラ認定契約(RAA)に適用される登録データディレクトリサービス(WHOIS)の仕様に関する説明)」で説明されているように、オプションとして扱うことができます。

    • レジストリのレジストラント/管理担当者/技術担当者 ID
    • レジストラント/管理担当者/技術担当者の名前
    • レジストラント/管理担当者/技術担当者の番地
    • レジストラント/管理担当者/技術担当者の都市
    • レジストラント/管理担当者/技術担当者の国
    • レジストラント/管理担当者/技術担当者の電話
    • レジストラント/管理担当者/技術担当者の電子メール

4.11 レジストリ契約で別段の定めがない限り、「請求」の連絡先はオプションです。レジストリポリシーで、連絡先を必須にするか、オプションにするか、サポートしないかを定義できます。サポートされる場合は、請求の連絡先情報は、「Advisory: Clarifications to the Registry Agreement and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications(レジストリ契約および2013年レジストラ認定契約(RAA)に適用される登録データディレクトリサービス(WHOIS)の仕様に関する説明)」で説明されているように表示される必要があります。

以下の要件はレジストラのみに適用されます。

5.1 2017年8月1日から2019年2月1日の間は、レジストラは、2019年2月1日まで、2014年1月9日に承認された「基本レジストリ契約」の仕様4のセクション1またはそれ以降の修正事項、およびレジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシーに記載されているWHOIS (ポート43から利用可能)およびWebベースのディレクトリサービス要件にレジストリ運用者が準拠できるように、レジストラデータベースで利用可能な既存のドメイン名のすべての必須フィールドを関連するすべてのレジストリ運用者に移行する必要があります。

5.2 レジストラは、2017年8月1日から新しいドメイン名登録を行う場合、2014年1月9日に承認された「基本レジストリ契約」の仕様4のセクション1またはそれ以降の修正事項、およびレジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシーに記載されているWHOIS (ポート43から利用可能)およびWebベースのディレクトリサービス要件に準拠できるように、レジストリ運用者へのThick登録データの提供を完了できます。

5.3 レジストラは、2018年5月1日から新しいドメイン名登録を行う場合、2014年1月9日に承認された「基本レジストリ契約」の仕様4のセクション1またはそれ以降の修正事項、およびレジストリ登録データディレクトリサービスの一貫性あるラベル付けと表示ポリシーに記載されているWHOIS (ポート43から利用可能)およびWebベースのディレクトリサービス要件に準拠できるように、レジストリ運用者へのThick登録データの提供を完了する必要があります。

実装に関する注記

各国のプライバシー法と本ポリシーに記載されている要件との間に競合がある場合、レジストリ運用者とレジストラは、 プライバシー法とWHOISの競合に関するICANNの手続きを利用できます。

背景

ICANN理事会は、GNSO評議会によって承認された後、2014年2月7日に、すべてのgTLDレジストリによるThick WHOISの使用に関するGNSO Thick WHOISワーキンググループのコンセンサス ポリシー勧告を採択しました。勧告1では、2013年の[Registrar Accreditation Agreement]の仕様3で示されたモデルに従い、一貫性のあるラベル付けおよび表示に関するThick WHOISサービスの条項は、現在および将来に対してすべてのgTLD レジストリの1つの要件になります」と記載されています。ICANN Board resolutions 2014.02.07.08 - 2014.02.07.09を参照してください( http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c)。

ICANNは、ポリシーの勧告を履行するためにコミュニティメンバーのチーム(実装審査チーム)と協力しています。ICANNは、実装の一環として、またその採用前に、提案されたポリシーの勧告よびこのポリシーに含まれる文言についてコミュニティからの意見を求めています。(https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-enを参照してください)。

Thick Whois Policy PDP WGの最終レポート[PDF, 1.23 MB]では、ThinからThick Whoisへの移行の実施のためのタイムラインおよび要件に関する「実施の検討」ガイダンスを第7.2項に含めました。特に次のように示しています。「WGでは、推奨の一部(例えば、既存のthin gTLDレジストリからのthickモデルへの移行)の実施は、推奨の別の部分(例えば、当該データの一貫性のあるラベル付けおよび表示)の実施を必ずしも遅らせるものではないことを強調しています。」。

そのため、ICANNは、Thin WhoisからThick Whoisへの登録の移行とWhoisデータの一貫性のあるラベリングと表示を同時進行で実装できるように、実装審査チームと協力してきました。その他の詳細情報についは、 https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-enを参照してください。

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."