Skip to main content
Resources

コミュニティgTLD変更要求の手続き

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

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

はじめに

コミュニティgTLD変更要求の手続きは、レジストリステークホルダーグループとICANNコミュニティからの意見を取り入れながらコミュニティgTLD変更要求プロセスのワーキンググループ(以下「ワーキンググループ」)とICANN組織によって作成されました。この手続きの指針は、コミュニティgTLDレジストリオペレータが、コミュニティ登録ポリシーを削除することなく、レジストラントの資格や名前選択要件を過度に拡大または縮小したり、TLDコミュニティに重大な悪影響を及ぼすことなく、 仕様12を変更できるようにすることです。

ICANN組織は、2018年2月に公聴の手続きドラフトを公開しました。ICANN組織とワーキンググループは、コメントを検討した後、この手続きが既存のポリシーと矛盾していることを示すコメントがないと結論付け、この手続きの更新について議論しました。さらに、2018年4月26日、GNSO評議会[PDF、574 KB]は、「ICANN組織は、コミュニティgTLD変更要求のプロセスを今後、実際に導入する問題として扱う必要があること」に合意しました。この手続きの公開版は、2018年4月にワーキンググループとICANN組織によって合意されました。

手続き

バージョン: 2018年4月

コミュニティgTLD変更要求

コミュニティgTLD変更要求(以下「要求」)とは、コミュニティgTLDレジストリオペレータがレジストリ契約の仕様12に列挙されているコミュニティ登録ポリシーの変更についてICANNから承認を受けるための手続きです。コミュニティgTLDレジストリ契約の2.19項には、「レジストリオペレータは、TLDコミュニティがTLDのポリシーや慣行の開発や修正について討議をし、参加できる方法でTLDを運営するものとする」と定められています。コミュニティgTLDのレジストリオペレータは、コミュニティ登録ポリシーを削除することなく、レジストラントの資格や名前選択要件を過度に拡大または縮小したり、TLDコミュニティに重大な悪影響を及ぼすことなく、 変更できるようになります。

すべてのICANN手続きと同様に、ICANNは、関連するレジストリオペレータおよび部会からの意見を参考にしながら、定期的にこの手続きの有効性を検討します。

1.定義

1.1 コミュニティgTLDは、セクションタイトルが「コミュニティ登録ポリシー」または「TLDポリシー」になっている仕様12を含むICANNとのレジストリ契約を締結しているgTLDとして定義されます。

1.2 コミュニティgTLDの変更は、ICANNとのレジストリ契約の仕様12への変更と定義されます。

1.3 TLDコミュニティは、ICANNとのレジストリ契約の仕様12に記載されている資格要件によって定義されます。

1.4 レジストリオペレータは、コミュニティgTLDを管理するためのレジストリ契約を締結している団体として定義されます。

1.5 この手続きに関連する日付は、すべて暦日として定義されます。

2.コミュニティgTLD変更要求の手続き

2.1 レジストリオペレータが、コミュニティgTLD変更要求(「要求」)を提出します。

レジストリオペレータは、いつでも要求を提出できます。この要求は、完全なコミュニティgTLD変更要求アンケート(付録Aを参照)[PDF、38KB]を添付して、書面でICANNに提出する必要があります。また、TLDコミュニティ(該当する場合には、TLDコミュニティの拡張を提案している団体を含む)、および該当する場合には代表的な運営組織が変更を支持していることを示す文書を追加する必要があります。

2.2 ICANNによる要求の予備審査

ICANNは、要求を受け取ったら、その完全性を検証し、不備がある場合には5日以内に書面によりレジストリオペレータに通知します。レジストリオペレータは、修正された要求をいつでもICANNに再提出して、手続きを再開できます。アンケートに記載されているすべての項目が解決され、支持を示す文書が提供されている場合に、要求が完全であるとみなされます。

ICANNは、完全性を確認した後に、10日以内に、予備審査を実施し、コメント期間のための要求と修正案を準備します。

ICANNが予備審査で要求がこの手続きの対象にならないと判断した場合や要求を拒否する懸念が生じた場合、ICANNはこれらの懸念を明示して、コメント期間の前にレジストリオペレータと協議する場合があります。

2.3 変更要求のコメント期間

ICANNが要求を予備審査した後、ICANNは、30日のコメント期間のために、要求と修正案を掲載します。

2.4 レジストリオペレータの応答期間

コメント期間中に要求に関する疑問が提起された場合、ICANNはレジストリオペレータとの協議期間を開始し、ICANNが要請してから15日以内に、レジストリオペレータが受け取ったコメントについて回答するように要求します。この間、ICANNは、レジストリオペレータと協議し、要求の承認に悪影響を及ぼす可能性のあるコメントを明確にしたり、必要に応じて受け取ったコメントについて直接回答する場合があります。

3.ICANNによる審査と決定

3.1 ICANNによる審査

ICANNは、要求を承認または拒否するかどうかを分析します。この評価は以下を基準として行われます。

  1. TLDコミュニティの説明 – TLDの資格要件と変更要求によってどのように影響を受けるかについての明確な記述があるか?
  2. TLDコミュニティのアウトリーチおよび支持の証拠 – レジストリオペレータが「TLDコミュニティがTLDのポリシーや慣行の開発や修正について討議をし、参加できる方法でTLDを運営している」努力を示すTLDコミュニティへのアウトリーチの合理的な証拠があるか?変更要求についてTLDコミュニティが支援している合理的な証拠があるか?
  3. TLDコミュニティのメリット – 変更要求アンケートの1.3と1.4で提供された回答は、TLDコミュニティにとってどのような利益があるかを適切に説明しているか?変更を許可するとTLDコミュニティに損害を与えることがないか?
  4. コメント期間中に提起された懸念 – コメント期間中にTLDコミュニティやインターネットコミュニティに悪影響を及ぼす判断された重大な懸念があったか?レジストリオペレータは、これらの懸念に対して適切な対応を行ったか?適切な対応には、(1)コミュニティに評判を傷つけることがない、(2)コミュニティの中核の活動に干渉しない、(3)コミュニティに経済的な損害を与えることがないことを示すレジストリオペレータからの証拠が含まれる場合があります。

3.2 ICANNによる決定

3.2.1 承認

ICANNが要求を承認することを決定する場合、コメント期間の終了から、または、コメント期間中に提起された懸念に対するレジストリオペレータの対応から30日の目標期間内に、ICANNは、レジストリオペレータに要求の承認を通知します。遅延する場合、ICANNは、書面による説明と新しい期限を提示します。

承認に修正案が含まれる場合、ICANNは、修正案を提供し実施します。承認された要求を実施するために必要となる場合、ICANNは修正案を変更し、実施前にレジストリオペレータが検討できるように変更した内容を提出する場合があります。

3.2.2 拒否

ICANNが要求を拒否することを決定する場合、変更要求の拒否をレジストリオペレータに通知し、コメント期間の終了から、または、コメント期間中に提起された懸念に対するレジストリオペレータの対応から30日の目標期間内に、ICANNは、レジストリオペレータに要求を拒否した根拠を明確に通知します。遅延する場合、ICANNは、書面による説明と新しい期限を提示します。

付属書類 A: コミュニティgTLD変更要求のアンケート [PDF、38 KB]

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