Skip to main content
Resources

実装に関する注記

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

更新日:2019 年 6月 17 日

数ヵ月にわたる議論の後、RySG RSEP 改善討議部会および ICANN 組織は、ポリシーを順守しながら、プロセス内の効率および予測性を可能にする一連の運用上の改善に同意しました。プロセスの変更は、2019年6月17日に公開された更新されたRSEP 実装に関する注記に反映されています。実装に関する注記のこのバージョンは、現在保存されています。


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

本書は、プロセスの概要について説明し、レジストリサービス評価ポリシー(以下「ポリシー」)の実装に関する概要を提供することを目的としています。

新しいレジストリサービスのプロセス

2005年11月8日、ICANN理事会は、新しいレジストリサービスの要求について検討するプロセスの実施を指示しました。このプロセスはレジストリサービスと機密性の定義を規定する.NETレジストリ契約の条項に準拠することにしました。

手順1

gTLDレジストリオペレータおよびスポンサー組織は、新しいレジストリサービスの要求をICANNに提出できます。このプロセスは、要求が提出される前に、ICANNとレジストリオペレータまたはレジストリスポンサー組織との間のコミュニケーションを促すように設計されています。要求が提出されると、ICANNは要求の受領を確認し、その完全性を審査します。

新しいレジストリサービス要求を送信するオンラインツール

安全なWebベースのアプリケーションを現在開発中です。これにより、gTLDレジストリオペレータおよびレジストリスポンサー組織が所定のポリシーの下で要求を直接ICANNに提出でき、ICANNがレジストリサービス評価ポリシーの推奨事項に従って、これらの要求をタイムリー、予測可能、かつ透過的な方法で審査できるようになります。提案された新しいレジストリサービスを評価するのに十分な情報をICANNに提供する目的で、このアプリケーションでは一連の質問にgTLDレジストリオペレータまたはレジストリスポンサー組織が回答するように求めます。これらの質問には以下が含まれます。

  1. 提案されたサービスに関する諮問情報。レジストリがスポンサー付きのTLDである場合、レジストリは、スポンサー付きのTLDコミュニティとの諮問について記載するよう奨励されます。
  2. 提案されたサービスの実施のタイムライン、提供方法およびテスト方法。
  3. 提案されたサービスによって影響を受ける契約条項の一覧と、提案されたサービスによって必要となる契約上の修正を記述します。
  4. 提案されたサービスの利点の説明。
  5. 提案されたサービスがレジストラによって提供される同様のサービスに影響するか、サービスがレジストラを異なる方法で扱うことになるか、ドメイン名のレジストラント間の競争を軽減するかどうかの説明。
  6. 提案されたサービスが登録データの保存と入力を変更するかどうかに関する議論。
  7. 提案されたサービスがインターネットサーバーまたはエンドシステムのスループット、応答時間、応答の一貫性や整合性にどのように影響するかの説明。
  8. 提案されたサービスによって発生する知的財産に関する懸念についての議論、または提案されたサービスにgTLDレジストリの排他的な知的財産が含まれるかどうかの議論。
  9. 提案されたサービスの評価に関連するその他の情報の記述。

このアプリケーションは2006年8月15日以前にテストするレジストリが利用できます。このアプリケーションは、ICANNのWebサイトに掲載され、そのリンクは後日公開されます。

手順2

ICANNは、オンラインツールから提出された要求が完了したと判断すると、要求しているレジストリオペレータまたはスポンサー組織に15日の審査プロセスが開始されたことを通知します。ICANNは、提案されたサービスが重大なセキュリティおよび安定性の問題や競争上の問題を発生させるかどうかの前審を15日以内に実施します。

ICANNは、15日間の前審期間中に、追加情報が必要な場合は、新しいサービスを要求しているレジストリオペレータまたはレジストリスポンサー組織とコミュニケーションを図ります。前審期間中にレジストリオペレータまたはレジストリスポンサー組織によって提供される情報は、「機密情報」として指定される場合ができますが、レジストリオペレータまたはレジストリスポンサー組織は、提案されたレジストリサービスの目的およびDNSユーザーに与える影響を説明するために必要な情報を「機密」と指定しないものとします。

ICANNは前審期間中に専門家(守秘義務契約を順守する法人または個人)からレジストリサービスの競合、提案されたレジストリサービスに関するセキュリティと安定性の影響について「前審」するための助言を求めることができます。このような専門家には、レジストリサービス技術評価パネルのメンバーが含まれる場合があります。

手順3

15暦日の終わりまでに、ICANNは提案されたレジストリサービスの前審の結果を、サービスを要求したレジストリオペレータに通知します。タイミングによっては、レジストリオペレータとの通知や討議のため、15日間の前審期間の終了時に2〜5日間を審議に利用できます。

手順4

前審は、1)要求の承認、2)技術評価パネルへの要求の付託、3)該当する政府の競合機関への要求の付託、4)技術評価パネルおよび該当する政府の競合機関両方への要求の付託、5)ICANN理事会への付託、または6)レジストリオペレータまたはレジストリスポンサー組織の要求の却下のいずれかの結果となります。

手順5

提案されたサービスを政府の競合機関または技術評価パネルに付託する決定がなされる場合、レジストリオペレータまたはレジストリスポンサー組織は、審査プロセスを継続するか、提案された新しいレジストリサービスの申請を撤回するかを確認する必要があります。

ICANNによって競合の問題やセキュリティと安定性に関する懸念が示されない場合、要求したレジストリオペレータまたはレジストリスポンサー組織は、要求されたサービスを展開し、実施計画をICANNに通知できます。承認された新しいレジストリサービスについては、ICANNのWebサイトに公開されます。提案された新しいレジストリサービスを実施するために、レジストリ契約の重大な変更が必要となる場合、前審はICANN理事会へ付託されます。

手順6

このプロセスでは、インターネットのセキュリティまたは安定性への潜在的な影響に関して、専門家による独立したチームが、提案された新規または修正されたレジストリサービスを評価します。2006年1月26日、Lyman Chapin氏が、レジストリサービス技術評価パネルの議長に指名されました。公聴期間の後、2006年3月31日にニュージーランドのウェリントンで開催されたICANN会議で、理事会はこの人事指名を承認しました。

3月31日以降、Lyman Chapin氏は技術評価パネルの技術的な専門家と顧問の役職の調整を行っています。技術評価パネルは、ICANNから付託された新規または修正されたレジストリサービスの要求のみを審査します。要求が技術評価パネルに付託されると、提案された各サービスを審査するために、セキュリティまたは安定性に関する問題についてICANN理事会に報告するまでに45日間が付与されます。

技術評価パネルのメンバーは個別に公表されます。

手順7

技術評価パネルが提案されたレジストリサービスの審査を終えると、審査報告書は一般意見を公聴するためにICANNのWebサイトに掲載され、ICANN理事会に提出されます。ICANN理事会には、決定を下すまでに30暦日が付与されます。ICANN理事会は、1)要求の承認、2)要求の却下、または3)詳細情報を要求するための延期を決定できます。

手順8

提案された新しいレジストリサービスの決定の影響を受ける組織や団体は、ICANN付属定款で指定される再審手続きを適用できる。

コンセンサスポリシーと審査プロセスを含むgTLD契約の契約条件との間の調整 - コミュニティにおける議論および質問に対応するために、これらのプロセスのバージョン間の違いがこの調整プロセスで説明されます。再審は、コンセンサスポリシーを実装した結果、コンセンサスポリシーや現行のgTLD契約の条項とプロセスが矛盾しないことの実証を目的としています。

レジストリサービスワークフロー - 本書では、レジストリサービス評価プロセスのワークフローをグラフィカルに説明します。

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