Skip to main content
Resources

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

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

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

レジストリサービスと評価プロセス

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

1. 定義

1.1 レジストリサービスは以下のように定義されます。

  1. レジストリサービスとは、(i)以下のタスクにおいて重要なレジストリの業務であり、ドメイン名とネームサーバーの登録に関係するレジストラからのデータ受信、TLDのゾーンサーバーに関連するステータス情報のレジストラへの供給、レジストリ契約で要求される、TLD内のドメインネームサーバー登録に関連する連絡先とその他の情報の公開、また(ii)レジストリ契約の発効日時点でレジストリ運用者から随時供給される以下のものを指します。

  2. コンセンサスポリシー(上記にて定義)の策定によりレジストリ運用者が供給を要請されるその他の製品あるいはサービス。

  3. レジストリ運用者として指定を受けているためにレジストリ運用者のみが提供することができるその他の製品あるいはサービス、

  4. 上記の(A)、(B)、(C)の範囲内でのレジストリサービスへの重大な変更。(定義については、ICANN理事会において2005年11月8日に具体化された.NET契約: 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による標準化過程やベストカレントプラクティスRFCのような、広く認知されている権威のある標準規格の推進団体により公表された、権威のある適切かつ妥当な基準を順守していない、あるいは(B)標準化過程やベストカレントプラクティス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レジストリサービス(実装に関する注記の手順1を参照)を導入することを決定できます。

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

gTLDレジストリ運用者またはスポンサー組織は、2.4において定められるICANNとの協議において、サービスへの変更がICANNとレジストリ運用者との契約に基づく承認を必要とするか否かを決定します(実装に関する注記の手順1を参照)。

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

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

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

2.4 前審期間

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

  1. ICANNはレジストリサービスがICANNによるさらなる審査を必要とするか否かについての「前審」を行うために15暦日を与えられます。この前審ではかかるレジストリサービスが(i)重大なセキュリティと安定性に関する問題を提起する可能性があるか、あるいは(ii)重大な競合的な問題を提起するかを適切に決定するためです。

  2. レジストリ運用者は、ICANNが十分な情報を基に「前審」できるように、ICANNへの通知の際に、提案したレジストリサービスの実施可能性について十分な情報を提供しなければなりません。レジストリ運用者から提供される情報と「機密扱い」とされる情報は、ICANNによって機密として扱われます。レジストリ運用者は、提案されたレジストリサービスの目的とDNSユーザーへの影響を説明するために必要となる情報については、「機密」として扱わないものとします。

  3. ICANNは前審期間中に専門家(守秘義務契約を順守する法人または個人)からレジストリサービスの競合、セキュリティと安定性について「前審」するために助言を求めることができます。ICANNがそのような専門家へ機密情報を開示することを決定する場合、その専門家を証明する情報と、専門家に伝達する情報について、レジストリ運用者へ通知するものとしますセキュリティと安定性の検討のために、ICANNは後述の2.4 (F)に記載されるレジストリサービス技術評価パネルから1名の専門家を任命する場合があります。

  4. ICANNが15日間の「前審」期間に提案されたレジストリサービスがセキュリティと安定性(1.3と1.4節で定義)、または競合の重大な問題を引き起こさないと判断する場合、レジストリ運用者は決定と同時にサービスを展開できます。

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

2.5 競合問題

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

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

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

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

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

レジストリサービス技術評価パネルには、提案されたレジストリサービスのセキュリティと安定性(1.2と1.3節で定義)への影響について書面のレポートを準備するために委託から45暦日が与えられ、レポートは(すべての公聴結果の要約とともに)ICANN理事会に送られます。当該レポートには、分析結果、判断の根拠、そしてパネルが結論を下すにあたって依拠した情報の詳細な記述や、その他のレジストリサービス技術評価パネルの意見が、ICANNスタッフからの付託に含まれていた特定の質疑に対する回答とともに含まれるものとします。ICANNからレジストリサービス技術評価パネルへの付託がある場合、レジストリ運用者はレジストリサービスのセキュリティと安定性に対して起こりうる影響に関して追加情報や分析結果を提出する場合があります。

提案されたレジストリサービスを評価する際に、レジストリサービス技術評価パネルは、提案されたレジストリサービスによってセキュリティと安定性に重大な悪影響を及ぼす一定のリスクが発生するかどうかなど、提案されたレジストリサービスによるセキュリティと安定性への影響の可能性と重大性を報告するものとします(実装に関する注記の手順5~7を参照)。

2.7 ICANN理事会の決定

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

レジストリサービス技術評価パネルの改定前のレポートは、レポートの掲載時にレジストリ運用者に提供されるものとします。レジストリ運用者はレジストリサービス技術評価パネルのレポートに意見を申し立てることも、レジストリサービスによるセキュリティと安定性への影響(実装に関する注記の手順7~8を参照)に関する追加情報と分析結果を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."