Skip to main content
Resources

RSEP 実装に関する注記

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

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

有効日:2019 年 6月 17 日

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

ここをクリックすると RSEP プロセスのウェブサイトに戻ります。

はじめに

2005年11月8日、ICANN 理事会は、新しいレジストリサービスに対する要求検討に関する GNSO の推奨手順がレジストリサービスの定義に関する .NET レジストリ契約の条項に従っているように指示しています。これらの実装に関する
注記は、レジストリサービス評価ポリシー (RSEP) プロセスの概要であり、ICANN 組織によるポリシーの実装に関するハイレベル情報を提供することを目的としています。ICANN 組織は、関連するレジストリオペレータおよび機関からの意見を参考に、定期的にこの実装の効果の検討を行うことができます。

2019年、レジストリステークホルダーグループ (RySG) 討議グループは、ICANN 組織との協力により、ポリシー自体を変更することなく、実装に関する注記を更新しました。これらの改定実装に関する注記は、RSEP プロセスが理解しやすく、予測性を確立しやすくし、および基本となるポリシーによる、継続中の調整を保証することを目的としています。

gTLD レジストリオペレータは、RSEP 要求を ICANN 組織に提出し提案されるレジストリサービスを追加、現行のレジストリサービスを修正、あるいはレジストリサービスを削除することができます。ICANN 組織が RSEP 要求中の提案されたサービスがレジストリ契約で定義のレジストリサービスの資格を満たしていないと判断した場合、ICANN 組織は、当該のレジストリオペレータに通知の上、同要求を閉じます。レジストリオペレータは、どの時点でもその要求を撤回することができます。

RSEP コンセンサスポリシーと特定レガシー gTLD レジストリ契約との間の契約上の用語に差異に対して、ICANN 組織はコンセンサスポリシーと評価プロセスを含む gTLD 契約中の契約上の用語との間で調整を行います。再審は、コンセンサスポリシーを実装した結果、コンセンサスポリシーや現行のgTLD契約の条項とプロセスが矛盾しないことの実証を目的としています。ICANN 組織は、これらの差異について、レジストリ契約に対する RSEP 要求に関する調整を考慮します。

日付の基準はすべて、特記事項がないかぎり、暦日とします。

手順 1 - 提出

レジストリオペレータは、下記の基準にしたがって、適切な要求フォームを使用して RSEP 要求を ICANN 組織に提出することができます。

  1. 標準RSEP 要求フォーム: RSEP 要求が提案されたレジストリサービスを追加する、現行のレジストリサービスを削除する、あるいは現行のレジストリサービスを大幅に修正するには、レジストリオペレータは ICANN 組織に、その要求を評価するの十分な情報を提供することを目的として、標準の質問群に答えなければなりません。レジストリオペレータは RSEP 要求に提出した情報を「機密扱い」として指定することができます。ただし、提案されたレジストリサービスの目的および DNS のユーザーへの効果を説明するのに必要な情報は除きます。

    ポリシータイムラインに従い、レジストオペレータにより多くの予測性を提供するには、ポリシーおよび ICANN 組織は、レジストリオペレータに対して、標準 RSEP 要求フォームの提出前に、ICANN 組織に相談するよう勧めます。このステップは、レジストリオペレータに対する負荷を増やすのではなく、RSEP 要求の検討に当たり、先行して必要な情報を組み立てる支援を行うことを目的としています。これは、要求がポリシーにおいて適性を有するかについて討議する、同要求の正式な検討に際して発生する可能性がある懸念事項に注意を向け明確にする、および適切な認証言語にできるかぎり早急に同意する機会でもあります。

  2. 簡易RSEP 要求フォーム: 特定の既知 サービス (セキュリティと安定のため ICANN 組織が繰り返し検討を行い、セキュリティあるいは安定性について大きな問題が提示されなかった、一時利用可能な修正テンプレートを発行したサービス) については、レジストリオペレータは簡易要求フォームに記入し、修正なしで標準テンプレート修正の使用を確認します。このステップにより、既知のサービス RSEP 要求の提出から認証までの期間が短縮されます。

手順 2 - ICANNによる完全性の審査

完全性の審査期間で、RSEP 要求は未発行のままとなり、RSEP 要求に関する ICANN 組織とレジストリオペレータとの間のインタラクションはすべて、機密扱いのままとなります。要求が提出されたら、ICANN 組織は完全性について検討を実施しますが、これには15日程度要します。要求は、手順 3 - ICANN 検討に移行するには、以下の基準を満たして
いなければなりません。

  1. 十分な情報:要求には ICANN 組織が ICANN 検討期間中に情報に基づく仮裁定ができるように、十分な情報が含まれていなければなりません。標準 RSEP 要求の完全提出には、提案されたサービスの全説明を含む、関連する質問すべてへの実質的回答、外部ユーザーへの影響の評価、新しいサービス(該当する場合)が影響を及ぼす契約条項のリストおよび説明、提案された修正言語(修正が必要な場合)、外部関係者およびコミュニティ(取得している場合)からのフィードバック、および仮裁定に役立つその他補助文書が含まれます。
  2. 承認書:手順 2 の終了までに、ICANN 織およびレジストリオペレータは、ICANN 検討に移行する前に、承認書のタイプ、レジストリ契約 (RA) 修正、修正言語に同意する必要があります。ICANN 組織が承認書への同意に移行できない理由には、提案されたサービスが ICANN コンセンサスポリシーまたは ICANN 理事会による指示と相反する場合が含まれます。

    承認書のタイプと基準:

    • RA 修正:提案されたサービスが (i) RA の現行条項と矛盾して、(ii) RA で検討されていない、すなわち、RA の付属書類 A に、および/または適切な補遺/付録に追加されている必要がある場合に使用されます。
    • 無料配布書類:提案されたサービスが RA ですでに検討され、契約条項と矛盾していない場合に使用されます。

ICANN 組織は、追加情報が ICANN 組織が評価できるように、および発行された要求に含まれるように、RSEP 要求に必要であるかを確定できます。この状況で、ICANN 組織はレジストリオペレータと相談する、および/またはレジストリオペレータにその要求を追加情報とあわせて再提出させることができ、これにより、手順 2 - 完全性の審査を延長する場合があります。ICANN 組織は、このプロセスでは、信義誠実に則り、レジストリオペレータに協力します。

2A - 続行要求

関係者が手順 2 の基準1が完全であることに同意しても、レジストリオペレータと ICANN 組織が承認書のタイプおよび/または修正言語に同意しなかった場合、レジストリオペレータは、承認書の最終確認前に手順 3 - ICANN 検討に続行の要求を提出することができます。ICANN 組織はすべての続行要求をタイムリーに検討し、交渉の進捗を審議誠実に則り評価します。

ICANN 組織は、続行要求が提出された場合、以下の行動のうちいずれかを行うことができます。

  • 交渉がほとんど終了した場合、ICANN 組織は続行要求を許可し、RSEP 要求は手順 3 - ICANN 検討に移行します。ここでRSEP 要求が発行されます。両関係者は手順 3 の間、ICANN 検討の終了までに同意することを目的として、交渉を継続します。
  • 交渉が終了に近づかない場合、ICANN 組織は、ICANN 組織経営部にエスカレーション(進言)の上、追加交渉を要求することができます。このエスカレーションはRSEP 要求を手順 3 に移行する前に行います。ICANN 組織がエスカレーションの後で続行要求を許可した場合、ICANN 組織は、提案されたレジストリサービスが新しい先行案を設定した、あるいは ICANN、第3者、あるいはドメインネームシステム(DNS)への実質的な効果を設定した場合に官報公告向けに提案された承認書を発行できます。官報公告は、手順 3 - ICANN 検討の後に行われます。
  • ICANN 組織が、レジストリオペレータが信義誠実に則り交渉していないと判断した場合、ICANN は続行要求を拒否することができます。

手順 3 - ICANN 検討

ICANN 組織が要求が完了したことを確認した、あるいはステップ 2 で続行要求を許可した場合、ICANN 組織は、15日間の審査プロセスを開始し、提案されたレジスリサービスを発行します。

ICANN 検討中、提案されたレジストリサービスで重大なセキュリティ、安定性あるいは競争上の問題が発生しているかどうかについて仮裁定が行われます。ICANN 組織は競争上の問題に関する仮裁定の発行済ガイドラインに従い、提案されたレジストリサービスのセキュリティ、安定性あるいは競争上の意味に関する機密契約の対象となる団体あるいは個人による専門的なアドバイスを求めることができます。上記の専門家にレジストリサービス技術評価パネル (RSTEP) の会員を含めることができます。この検討はポリシーの規定により、15日を超えないことになっています。

手順 3 - ICANN 検討の終了時、ICANN 組織は、要求したレジストリオペレータに提案されたレジストリサービスに関する仮裁定を通知します。

手順 4 - 承認または照会

手順 3 の仮裁定により、以下の結果のうち1つが確定します。

  1. RSEP 要求の承認
  2. レジストリサービス技術評価パネル (RSTEP) への照会
  3. 関係する政府の競争当局への照会、あるいは
  4. RSTEP および関係する政府の競争当局の両方への照会

仮裁定で2~4の結果が出た場合、レジストリオペレータが通知を受け、検討プロセスを続行するか、RSEP 要求を取り下げるかを確認しなければなりません。必要な場合、レジストリオペレータは、結果について ICANN 組織に相談することができます。

結果

裁定

次のステップ

(1) 承認

明らかに重大なセキュリティ、安定性あるいは競争上の問題がない

要求が完了と判断され、手順 6 - 認証に移行します。

(2) RSTEP への照会

重大なセキュリティまたは安定性問題を提起できる

レジストリオペレータが先へと続行する希望を確認した場合、提案されたサービスは RSTEP の評価を受けます (RSTEP 会員のリストは こちらで発行)。要求が RSTEP に照会されたら、パネルが45日間で提案されたサービスの検討を行い、セキュリティまたは安定性問題に関するレポートを作成します。RSTEP の最終レポートの未修正バージョンがレジストリオペレータに提供されます。手順 5 - 官報公告および ICANN による検討が必要です。

(3) 関係する政府の競争当局への照会

重大な競争上の問題を提起できる

レジストリオペレータが先へと続行する希望を確認した場合、ICANN 組織は、レジストリオペレータの移行確認から5営業日以内に、同案件に関する適切な政府の競争関連管轄当局に当該の問題を照会します。手順 5 - 官報公告および ICANN による検討が必要です。

(4) RSTEP および関係する政府の競争当局の両方に照会

重大なセキュリティと安定性問題
および競争上の問題を提起できる

レジストリオペレータが先へと続行する希望を確認したら、ICANN 組織は結果 2 と 3 の手順に従います。

手順 5 - 官報公告および ICANN による検討(該当する場合)

RSEP 要求による提案された承認書に関する官報公告期間は提案されたレジストリサービスが手順 4 において、あるいは 2A – 続行要求で記載の条件により、RSTEP または競争当局に紹介された場合に、必要となります。

  • RSTEP への照会: 提案されたレジストリサービスおよび承認書起案は官報にて公告され、同時にRSTEP が検討を行います。RSTEP 評価レポートが終了したら、掲載中の官報公告期間に追加されます。官報公告期間の終了後、レジストリオペレータは公告に対して回答、および承認書起案を更新することができます。
  • 競争当局への照会: 提案されたレジストリサービスおよび提案された承認書は、関係する政府の競争当局への45日間の照会中、官報公告されます。
    • 競争当局が45日間の期間に照会窓口に問題を提起した場合、レジストリオペレータはICANN 組織と協力して、その問題に対応し、承認書起案を更新することができます。
    • 競争当局が45日間の期間に照会窓口に問題を提起しなかった場合、あるいは要求が早期に解決された場合、ICANN は、官報公告の分析時において、この検討を行います。
    • 官報公告期間の終了後、レジストリオペレータは、公告に回答、および認証起案を更新することができます。

官報公告期間に続き、RSEP 要求は ICANN 組織により検討されるか、ICANN 理事会に照会されます。

ICANN 理事会に照会された場合、ICANN 理事会は、官報公告概要および分析レポートの最終確定から30日以内に
決定を下すことを目指します。ICANN 理事会は 1) RSEP 要求の承認、2) RSEP 要求の却下、または3) 詳細確認のため RSEP 要求の遅延を決定できます。

ICANN 組織または ICANN 理事会が RSEP 要求を承認した場合、レジストリオペレータと ICANN 組織は手順 6 - 認証に移行します。ICANN 理事会が要求を拒絶した場合、同要求は先へと続行しません。

手順 6 - 認証

以前の ICANN によるポリシーの実行にしたがって、RSEP 要求が承認され、ICANN 組織およびレジストリオペレータが承認書に同意した場合、ICANN 組織は認証プロセスを開始します。これらの条件を満たしてから5日以内に、ICANN 組織は以下のいずれかを行います。

  1. レジストリオペレータに対して無料配布書類を発行 (手順 2 での同意により) ‐この時点でレジストリオペレータはサビースを展開できる、あるいは
  2. 官報公告に続き、更新がなされた場合、手順 2 または手順 5 の RA 修正への同意事項によりRA 修正実行プロセスを開始します。レジストリオペレータは、レジストリオペレータと ICANN 組織の両方による修正の実行後、要求したサービスを展開することができます。

ICANN 組織は、RSEP の Web ページと TLD 別のレジストリ契約 Web ページに、承認済レジストリサービスの通知および承認書を発行します。

レジストリオペレータが承認書なしで展開した場合、同レジストリオペレータは、法令準拠違反と判断される場合があります。

RSEP プロセスワークフロー

これらの実行ノートへの照会を含む RSEP プロセスのハイレベル提示については、RSEP プロセスワークフローを参照してください。

達成

このウェブページは、RSEPプロセスの運用上の向上の一部として、2019年6月に更新されました (ICANN 組織ブログの投稿を参照) 。達成した実装に関する注記についてはここからご覧いただけます。

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