Skip to main content
Resources

レジストリ - レジストラ契約 (RRA) の修正手順

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

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

2018 年 7 月 2 日更新

gTLD登録データの承認された一時的仕様を組み入れたレジストリ - レジストラ修正については、このページを参照してください。

RRA修正のメインページ

公開された修正案およびカバーノート（2021年8月～現在）

公開された修正案およびカバーノートの廃止（2009年7月～2021年7月） -
本メーリングリストの名称を手順に合わせて更新した後、廃止されました。

gTLD レジストリ - レジストラ契約の修正案に対する ICANN の検討手順

ICANN は、gTLD レジストリ - レジストラ契約 (以下、RRA) の修正案を検討するために、次のプロセスを策定しました。このプロセスでは、レジストリがその修正案に対して ICANN の承認を得る必要があります。このプロセスは、ICANN が RRA の修正を承認する前にレジストラの意見 (および、該当する場合はパブリックコメント) が確実に検討されるよう設計されています。

RRA の修正案に対する検討手順:

  1. RRA の修正を求めるレジストリは、すべての変更箇所を明記した修正案
    (レッドライン版) のコピーとカバーノートを ICANN に提出する必要があります。レジストリが提出するカバーノートには、提案される変更の目的を記載します。必須ではありませんが、RRA の修正案を提出する前に、ICANN に電話で相談されることをお勧めします。
  2. ICANN は、RRA の修正案のレッドライン版とカバーノートをレジストラステークホルダーグループへ転送して審査を仰ぐとともに、ICANN 内部でも
    修正案の審査を行います。レジストラの審査期間は、提案された変更の複雑度など、状況によって異なります。ただし、通常は 21 日以内に行われます。ICANNは、通常はICANNのWebサイトで修正案とカバーノートを公開し
    ます。
  3. 審査期間の終了時に何らかの懸念が表明された場合、懸念事項を解決するため、ICANN はレジストリおよびレジストラステークホルダーグループとの間で協議を行います。
  4. 協議の結果として修正案が変更される場合、ICANN は修正案をレジストラステークホルダーグループに提出し、追加の審査期間 (通常は 15 日以内) を設けます。この期間の終了時に、ICANN は、レジストラおよびレジストリとの協議を通じて、残りのすべての問題の解決を試みます。
  5. 上記の審査および協議のプロセスの後、ICANN は修正案を承認または拒否します。第三者への影響または DNS の安全性および安定性への影響が大きい可能性がある場合など、変更の内容によっては ICANN 理事会の承認が必要となることがあります。

RRA修正承認プロセスのフローチャート

RRA Amendment Approval Process Flowchart

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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