Skip to main content
Resources

レジストリサービス評価ポリシー

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

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

RSEP プロセスウェブページ

(公開日:2006年7月25日、発効日:2006年8月15日)

1.定義

1.1 レジストリサービスは、次のように定義されています:

  1. レジストリサービスとは、(i)以下のタスクにおいて重要なレジストリの業務であり、ドメイン名とネームサーバーの登録に関係するレジストラからのデータ受信、TLDのゾーンサーバーに関連するステータス情報のレジストラへの供給、レジストリ契約で要求される、TLD内のドメインネームサーバー登録に関連する連絡先とその他の情報の公開、また(ii)レジストリ契約の発効日時点でレジストリオペレータから随時供給される以下のものを指します。
  2. コンセンサスポリシー(上記にて定義)の策定によりレジストリオペレータが供給を要請されるその他の製品あるいはサービス。
  3. レジストリオペレータとして指定を受けているためにレジストリオペレータのみが提供することができるその他の製品あるいはサービス、
  4. 上記の(A)、(B)、(C)の範囲内でのレジストリサービスへの重大な変更。(定義は2005年11月8日にICANN理事会が指定した.NET Agreementからのもの http://www.icann.org/minutes/resolutions-08nov05.htm)。

1.2 セキュリティ - 提案されているレジストリサービスによるセキュリティへの影響とは、(A)レジストリデータの不正な開示、改ざん、挿入または破壊、または(B)適用されるすべての標準に従うインターネット上の情報またはリソースへの不正アクセスまたは開示、を意味する。(定義については、http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5に掲載されているGNSO勧告を参照)。

1.3 安定性 - 安定性への影響とは、提案されたレジストリサービスが、(A)IETFが主催する関連するStandards-TrackまたはBest Current Practice RFCsのような、確立された、認知され、権威のある標準化団体によって信頼され発行されている適用可能な関連標準に準拠していないこと、あるいは(B)インターネットサーバーまたはエンドシステムへの応答のスループット、応答時間、一貫性または応答一貫性に悪影響を及ぼす条件を生み出し、これが、確立され認定された信頼できる標準化団体によって信頼され、 関連するStandards-TrackやBest Current PracticeのRFCやレジストリオペレータの委任情報やプロビジョニングサービスに依存している、ことを意味する。(定義については、http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5に掲載されているGNSO勧告を参照)。

1.4 レジストリサービステクニカル評価パネル-レジストリサービステクニカル評価パネルは、インターネットインフラストラクチャとDNSで利用される複雑なシステムと標準プロトコルの設計、管理、実装の専門家20人で構成される(総称して「レジストリサービス技術評価 パネル」)。レジストリサービス技術評価パネルのメンバーはその委員長によって選ばれます。レジストリサービス技術評価パネルの委員長は、ICANNと支援組織のレジストリ部会の両方が合意できる人物であり、ジェネリックトップレベルドメイン(gTLD)のレジストリポリシーに対しての責任者となります。レジストリサービス技術評価パネルの全てのメンバーと委員長は、公平かつセキュリティと安定性の規定に則って、パネルの前に問題を審査することを求めた合意を履行するものとします。レジストリサービス技術評価パネルに付託される各問題に対して、委員長は問題を評価するメンバーを5人以内、レジストリサービス技術評価パネルから選びます。それらのメンバーのうちのいずれも、その時点で競争上、財政上、または法的紛争における利益を持たず、付託により検討される特定の技術的な問題に対して適切に配慮できるものとします。(定義については、http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5に掲載されているGNSO勧告を参照)。

2. 提案されたレジストリサービスの審査プロセス

2.1 レジストリオペレータあるいはスポンサー組織による新たなレジストリサービスの審査

レジストリオペレータあるいはスポンサー組織は、いかなる場合も既存のTLDレジストリサービスのアーキテクチャや運用を変更すること、または新たなTLDレジストリサービス(RSEP実装に関する注記の手順を参照)を導入することを決定できます。

2.2 変更でICANNの審査が要求されるかどうかの判断

第2.4項に記載されているICANNと協議しているgTLDレジストリオペレータまたはスポンサー組織は、ICANNとレジストリオペレータとの間の契約に基づいてサービスの変更に承認が必要かどうかを判断する(RSEP実装に関する注記の手順を参照)。

2.3 提案された変更に関する情報のICANNへの通知

本ポリシーでは、新たなレジストリサービスを提案者が新たなレジストリサービスへの要求の提出に先立ってICANNと協同することが推奨されています。レジストリサービス評価ポリシーと承認手続きの目的は、変更の前に、第三者に影響を及ぼす可能性がある変更について、gTLDレジストリオペレータとICANNとの間で協議することを促進する環境を作り出すことです。

gTLDレジスト運用者やスポンサー組織は、かかる変更において承認手続きの対象となるかどうかをICANNが評価できるように、変更に関する十分な情報をICANNに提供する必要があります。提供される情報は、外部ユーザーが理解できるように、変更についての技術的な説明と、外部のユーザーへの影響の評価が含まれる必要があります。レジストリオペレータやスポンサー組織が外部の組織や団体からの意見を求めていた場合は、その意見収集のプロセスと結果の詳細もこれらの情報に含める必要があります。本プロセスのこの段階では、これらの情報はICANNスタッフから機密としてみなされます(RSEP実装に関する注記の手順1と2を参照)。

2.4 前審期間

レジストリオペレータが前述の範囲でレジストリサービスを変更する可能性があることをICANNに書面で通知した後には、以下のプロセスが適用されます。

  1. ICANNはレジストリサービスがICANNによるさらなる審査を必要とするか否かについての「前審」を行うために15暦日を与えられます。この前審ではかかるレジストリサービスが(i) 重大なセキュリティと安定性に関する問題を提起する可能性があるか、あるいは(ii)重大な競合的な問題を提起するかを適切に決定するためです。
  2. レジストリオペレータは、ICANNが十分な情報を基に「前審」できるように、ICANNへの通知の際に、提案したレジストリサービスの実施可能性について十分な情報を提供しなければなりません。レジストリオペレータから提供される情報と「機密扱い」とされる情報は、ICANNによって機密として扱われます。レジストリオペレータは、提案されたレジストリサービスの目的とDNSユーザーへの影響を説明するために必要となる情報については、「機密」として扱わないものとします。
  3. ICANNは前審期間中に専門家(守秘義務契約を順守する法人または個人)からレジストリサービスの競合、セキュリティと安定性について「前審」するために助言を求めることができます。ICANNがそのような専門家へ機密情報を開示することを決定する場合、その専門家を証明する情報と、専門家に伝達する情報について、レジストリオペレータへ通知するものとしますセキュリティまたは安定性の観点から、ICANNは、下記の2.4(F)に記載されているレジストリサービス技術評価パネルから専門家を選出して処理することができます。
  4. ICANNが15日間の「前審」期間に提案されたレジストリサービスがセキュリティと安定性(1.3と1.4節で定義)、または競合の重大な問題を引き起こさないと判断する場合、レジストリオペレータは決定と同時にサービスを展開できます。

提案されたサービスを実施するために、レジストリ契約の重大な変更が必要となる場合、前審はICANN理事会へ付託されます(RSEP実装に関する注記の手順5を参照)。

2.5 競合問題

ICANNが15日間の「前審」期間にレジストリサービスが重大な競合問題を発生させる恐れがあるとの合理的な判断を下す場合、ICANNは決定してから5営業日以内、あるいは15日間の期限日から2営業日以内のいずれかの早い方までに適切な政府の競合機関またはその問題に対する管轄権を持つ公的機関へ問題を付託し、レジストリオペレータに通知します。

付託に関する通知は、伝達日にICANNのWebサイト上に掲載されます。

かかる付託の以降は、当該レジストリサービスに関連するいかなる競合問題についてICANNはそれ以上の責任を持たず、レジストリオペレータもICANNに対してそれ以上義務を負いません。かかる委託が発生した場合、レジストリオペレータは付託された政府の競合機関(RSEP実装に関する注記の手順4-6を参照)から許可を受けない限り、付託から45日後までレジストリサービスを展開しないものとします。

2.6 セキュリティと安定性の問題

ICANNが15日間の「前審」期間にレジストリサービスが重大なセキュリティと安定性の問題(1.3と1.4節で定義))を発生させる恐れがあるとの合理的な判断を下す場合、ICANNは決定を下してから5営業日以内、あるいは15日間の期限日から2営業日以内のいずれかの早い方までにレジストリサービス技術評価パネル(1.5節で定義)へ提案を付託し、同時に提案について公聴の機会を設けます。

レジストリサービス技術評価パネルは、提案されたレジストリサービスのセキュリティまたは安定性への影響(1.2節および1.3節で定義されている)に関する書面による報告書を作成するための照会から45日後の暦日を有するものとし、該報告(及びパブリックコメントの要約 )は、ICANN理事会に転送されるものとする。当該レポートには、分析結果、判断の根拠、そしてパネルが結論を下すにあたって依拠した情報の詳細な記述や、その他のレジストリサービス技術評価パネルの意見が、ICANNスタッフからの付託に含まれていた特定の質疑に対する回答とともに含まれるものとします。ICANNからレジストリサービス技術評価パネルへの付託がある場合、レジストリオペレータはレジストリサービスのセキュリティと安定性に対して起こりうる影響に関して追加情報や分析結果を提出する場合があります。

提案されたレジストリサービスの評価に際して、レジストリサービス技術評価パネルは、提案されたレジストリサービスがセキュリティ及び安定性に重大な悪影響を与える妥当なリスクを生じているかどうかを含め、提案されたレジストリサービスのセキュリティまたは安定性への影響の可能性と重要性を報告する (RSEP実装に関する注記の手順4-6を参照)。

2.7 ICANN理事会の決定

レジストリサービス技術評価パネルにより提出されるレポートは、レジストリオペレータとの協議により決定された機密情報に扱いを基に適切に改定され、公聴のために開示されます。ICANN理事会は、レポートを受理した後に、決定を下すために30暦日が与えられます。ICANN理事会が、提案されたレジストリサービスがセキュリティと安定性に重大な悪影響を及ぼすリスクがあると合理的に判断する場合、レジストリオペレータは提案したレジストリサービスを提供することはできません。

レジストリサービス技術評価パネルの改定前のレポートは、レポートの掲載時にレジストリオペレータに提供されるものとします。レジストリオペレータはレジストリサービス技術評価パネルのレポートに意見を申し立てることも、レジストリサービスによるセキュリティと安定性への影響(RSEP実装に関する注記の手順5を参照)に関する追加情報と分析結果をICANN理事会に提出することもできます。

3. 再審

提案された新たなレジストリサービスに対するICANNの決定により影響を受けるgTLDレジストリオペレータあるいはレジストリスポンサー組織はICANN付属定款における既存の再審手続きを利用できます。

再審手続きに関する情報への正式な情報源はICANN付随定款(第4条:(第2節 http://www.icann.org/general/bylaws.htm#IV)です。ICANNポリシーと相反するスタッフの行為、あるいはICANN理事会の重要な情報を検討することなく実施された行為に対して、再審は適用されます。過去の再審査プロセスに関する情報は

http://www.icann.org/committees/reconsideration

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