[要約] 要約：RFC 3375は、レジストリとレジストラ間のプロトコル要件を定義するものであり、ドメイン名の登録と管理を効率的に行うためのガイドラインを提供しています。目的：RFC 3375の目的は、異なるレジストリとレジストラ間の相互運用性を確保し、ドメイン名の登録プロセスをスムーズにすることです。また、セキュリティやパフォーマンスの向上も目指しています。
Network Working Group S. Hollenbeck
Request for Comments: 3375 Verisign, Inc.
Category: Informational September 2002
Generic Registry-Registrar Protocol Requirements
一般的なレジストリ登録プロトコル要件
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models.
このドキュメントでは、共有レジストリのインターネットドメイン名の登録と管理のためのクライアントサーバープロトコルの高レベルの機能およびインターフェイス要件について説明します。プロトコル設計のために詳細な特定の技術的要件はここには示されていません。代わりに、このドキュメントは、複数のレジストリおよびレジストラの運用モデルをサポートするためにプロトコルに必要な基本的な機能とインターフェイスに焦点を当てています。
Conventions Used In This Document
このドキュメントで使用されている規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Table of Contents
目次
1. Introduction ....................................... 2
1.1 Definitions, Acronyms, and Abbreviations ........... 2
2. General Description ................................ 4
2.1 System Perspective ................................. 4
2.2 System Functions ................................... 4
2.3 User Characteristics ............................... 5
2.4 Assumptions ........................................ 5
3. Functional Requirements ............................ 5
3.1 Session Management ................................. 6
3.2 Identification and Authentication .................. 6
3.3 Transaction Identification ......................... 7
3.4 Object Management .................................. 7
3.5 Domain Status Indicators ........................... 13
3.6 Transaction Completion Status ...................... 13
4. External Interface Requirements .................... 14
4.1 User, Hardware, and Software Interfaces ............ 14
4.2 Communications Interfaces .......................... 14
5. Performance Requirements ........................... 14
6. Design Constraints ................................. 14
6.1 Standards Compliance ............................... 14
6.2 Hardware Limitations ............................... 15
7. Service Attributes ................................. 15
7.1 Reliability ........................................ 15
7.2 Availability ....................................... 15
7.3 Scalability ........................................ 16
7.4 Maintainability .................................... 16
7.5 Extensibility ...................................... 16
7.6 Security ........................................... 16
8. Other Requirements ................................. 17
8.1 Database Requirements .............................. 17
8.2 Operational Requirements ........................... 17
8.3 Site Adaptation Requirements ....................... 17
8.4 Data Collection Requirements ....................... 17
9. Internationalization Requirements .................. 18
10. IANA Considerations ................................ 18
11. Security Considerations ............................ 18
12. Acknowledgements ................................... 19
13. References ......................................... 19
14. Editor's Address ................................... 20
15. Full Copyright Statement ........................... 21
The advent of shared domain name registration systems illustrates the utility of a common, generic protocol for registry-registrar interaction. A standard generic protocol will allow registrars to communicate with multiple registries through a common interface, reducing operational complexity. This document describes high level functional and interface requirements for a generic provisioning protocol suitable for registry-registrar operations. Detailed technical requirements are not addressed in this document.
共有ドメイン名登録システムの出現は、レジストリと登録の相互作用のための一般的な一般的なプロトコルの有用性を示しています。標準の一般的なプロトコルにより、レジストラは共通のインターフェイスを介して複数のレジストリと通信し、運用上の複雑さを削減できます。このドキュメントでは、レジストリ登録操作に適した一般的なプロビジョニングプロトコルの高レベルの機能およびインターフェイス要件について説明します。このドキュメントでは、詳細な技術的要件は扱われていません。
ccTLD: Country Code Top Level Domain. ".us" is an example of a ccTLD.
CCTLD：カントリーコードトップレベルドメイン。「.us」はcctldの例です。
DNS: Domain Name System
DNS：ドメイン名システム
gTLD: Generic Top Level Domain. ".com" is an example of a gTLD.
GTLD：一般的なトップレベルドメイン。「.com」はGTLDの例です。
IANA: Internet Assigned Numbers Authority
IANA：インターネットに割り当てられた番号当局
IETF: Internet Engineering Task Force
IETF：インターネットエンジニアリングタスクフォース
IP Address: Either or both IPv4 or IPv6 address.
IPアドレス：IPv4またはIPv6アドレスのいずれかまたは両方。
IPv4: Internet Protocol version 4
IPv4：インターネットプロトコルバージョン4
IPv6: Internet Protocol version 6
IPv6：インターネットプロトコルバージョン6
RRP: Registry-Registrar Protocol
RRP：レジストリ登録プロトコル
TLD: Top Level Domain. A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy.
TLD：トップレベルのドメイン。ドメイン名階層のトップレベルのルートの下に存在するGTLDとCCTLDの両方を記述するために使用される一般的な用語。
Exclusive Registration System: A domain name registration system in which registry services are limited to a single registrar. Exclusive Registration Systems are either loosely coupled (in which case the separation between registry and registrar systems is readily evident), or tightly coupled (in which case the separation between registry and registrar systems is obscure).
排他的登録システム：レジストリサービスが単一のレジストラに限定されるドメイン名登録システム。排他的な登録システムは、ゆるく結合されています（この場合、レジストラシステムとレジストラシステムの分離は容易に明白です）、またはしっかりと結合されています（この場合、レジストリシステムとレジストラシステムの分離はあいまいです）。
Name Space: The range of values that can be assigned within a particular node of the domain name hierarchy.
名前スペース：ドメイン名階層の特定のノード内で割り当てることができる値の範囲。
Object: A generic term used to describe entities that are created, updated, deleted, and otherwise managed by a generic registry-registrar protocol.
オブジェクト：一般的なレジストリ登録プロトコルによって作成、更新、削除、およびその他の方法で管理されるエンティティを記述するために使用される一般的な用語。
Registrant: An entity that registers domain names in a registry through the services provided by a registrar. Registrants include individuals, organizations, and corporations.
登録者：レジストラが提供するサービスを通じてレジストリ内のドメイン名を登録するエンティティ。登録者には、個人、組織、および企業が含まれます。
Registrar: An entity that provides front-end domain name registration services to registrants, providing a public interface to registry services.
レジストラ：レジストリサービスにパブリックインターフェイスを提供し、登録者にフロントエンドドメイン名登録サービスを提供するエンティティ。
Registry: An entity that provides back-end domain name registration services to registrars, managing a central repository of information associated with domain name delegations. A registry is typically responsible for publication and distribution of zone files used by the Domain Name System.
レジストリ：レジストラにバックエンドドメイン名登録サービスを提供し、ドメイン名代表に関連する情報の中央リポジトリを管理するエンティティ。レジストリは通常、ドメイン名システムで使用されるゾーンファイルの公開と配布を担当します。
Shared Registration System: A domain name registration system in which registry services are shared among multiple independent registrars. Shared Registration Systems require a loose coupling between registrars and a registry.
共有登録システム：レジストリサービスが複数の独立したレジストラ間で共有されるドメイン名登録システム。共有登録システムには、レジストラとレジストリ間のゆるい結合が必要です。
Thick Registry: A registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the registry repository.
厚いレジストリ：技術情報（ゾーンファイルの作成に必要な情報）とソーシャル情報（運用、ビジネス、または法的慣行の実装に必要な情報）の両方を含む登録エンティティに関連するすべての情報が、レジストリ内に保存されるレジストリリポジトリ。
Thin Registry: A registry in which all elements of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry.
Thin Registry：登録エンティティに関連するソーシャル情報のすべての要素が、共有レジストリとレジストリが提供するレジストラの間に配布されるレジストリ。
Zone: The complete set of information for a particular "pruned" subtree of the domain space. The zone concept is described fully in [RFC1035].
ゾーン：ドメイン空間の特定の「剪定された」サブツリーの完全な情報セット。ゾーンの概念は[RFC1035]で完全に説明されています。
A basic understanding of domain name registration systems provides focus for the enumeration of functional and interface requirements of a protocol to serve those systems. This section provides a high-level description of domain name registration systems to provide context for the requirements identified later in this document.
ドメイン名登録システムの基本的な理解は、これらのシステムにサービスを提供するためのプロトコルの機能的およびインターフェイス要件の列挙に焦点を当てます。このセクションでは、ドメイン名登録システムの高レベルの説明を提供して、このドキュメントの後半で特定された要件のコンテキストを提供します。
A domain name registration system consists of a protocol and associated software and hardware that permits registrars to provide Internet domain name registration services within the name spaces administered by a registry. A registration system can be shared among multiple competing registrars, or it can be served by a single registrar that is either tightly or loosely coupled with back-end registry services. The system providing registration services for the .com, .net, and .org gTLDs is an example of a shared registration system serving multiple competing registrars. The systems providing registration services for some ccTLDs and the .gov and .mil gTLDs are examples of registration systems served by a single registrar.
ドメイン名登録システムは、レジストリが管理する名前スペース内でインターネットドメイン名登録サービスをレジストラが提供できるプロトコルと関連するソフトウェアとハードウェアで構成されています。登録システムは、複数の競合するレジストラ間で共有することも、バックエンドレジストリサービスとしっかりとまたはゆるく結合した単一のレジストラが提供することもできます。.com、.net、および.org gtldsの登録サービスを提供するシステムは、複数の競合するレジストラにサービスを提供する共有登録システムの例です。一部のCCTLDSおよび.GOVおよび.MIL GTLDに登録サービスを提供するシステムは、単一のレジストラが提供する登録システムの例です。
Registrars access a registry through a protocol to register objects and perform object management functions. Required functions include session management; object creation, update, renewal, and deletion; object query; and object transfer.
レジストラは、プロトコルを介してレジストリにアクセスしてオブジェクトを登録し、オブジェクト管理機能を実行します。必要な関数にはセッション管理が含まれます。オブジェクトの作成、更新、更新、削除。オブジェクトクエリ;およびオブジェクト転送。
A registry generates DNS zone files for the name spaces it serves. Zone files are created and distributed to a series of name servers that provide the foundation for the domain name system.
レジストリは、提供する名前スペースのDNSゾーンファイルを生成します。ゾーンファイルは作成され、ドメイン名システムの基礎を提供する一連の名前サーバーに配布されます。
Protocol users fall into two broad categories: entities that use protocol client implementations and entities that use protocol server implementations, though an entity can provide both client and server services if it provides intermediate services. A protocol provides a loose coupling between these communicating entities.
プロトコルユーザーは、プロトコルクライアントの実装とプロトコルサーバーの実装を使用するエンティティを使用するエンティティの2つの幅広いカテゴリに分類されますが、エンティティは中級サービスを提供する場合はクライアントサービスとサーバーサービスの両方を提供できます。プロトコルは、これらの通信エンティティ間のゆるい結合を提供します。
There is one and only one registry that is authoritative for a given name space and zone.
特定の名前のスペースとゾーンに対して権威あるレジストリは1つだけあります。
A registry can be authoritative for more than one name space and zone. Some registry operations can be billable. The impact of a billable operation can be mitigated through the specification of non-billable operations that allow a registrar to make informed decisions before executing billable operations.
レジストリは、複数の名前のスペースとゾーンに対して権威あるものにすることができます。一部のレジストリ操作は請求可能です。請求可能な操作の影響は、請求可能な操作を実行する前にレジストラが情報に基づいた決定を下すことを可能にする請求不可能な操作の仕様を通じて軽減できます。
A registry can choose to implement a subset of the features provided by a generic registry-registrar protocol. A thin registry, for example, might not provide services to register social information. Specification of minimal implementation compliance requirements is thus an exercise left for a formal protocol definition document that addresses the functional requirements specified here.
レジストリは、一般的なレジストリ登録プロトコルによって提供される機能のサブセットを実装することを選択できます。たとえば、薄いレジストリは、ソーシャル情報を登録するためのサービスを提供しない場合があります。したがって、最小限の実装コンプライアンス要件の仕様は、ここで指定された機能要件に対処する正式なプロトコル定義文書のために残された演習です。
A protocol that meets the requirements described here can be called something other than "Generic Registry Registrar Protocol".
ここで説明する要件を満たすプロトコルは、「一般的なレジストリレジストラプロトコル」以外のものと呼ぶことができます。
The requirements described in this document are not intended to limit the set of objects that can be managed by a generic registry-registrar protocol.
このドキュメントで説明されている要件は、一般的なレジストリ登録プロトコルによって管理できるオブジェクトのセットを制限することを意図したものではありません。
This section describes functional requirements for a registry-registrar protocol. Technical requirements that describe how these requirements are to be met are out of scope for this document.
このセクションでは、レジストリ登録プロトコルの機能要件について説明します。これらの要件がどのように満たされるかを説明する技術的要件は、このドキュメントの範囲外です。
[1] The protocol MUST provide services to explicitly establish a client session with a registry server.
[1] プロトコルは、レジストリサーバーでクライアントセッションを明示的に確立するためのサービスを提供する必要があります。
[2] In a connection-oriented environment, a server MUST respond to connection attempts with information that identifies the server and the default server protocol version.
[2] 接続指向の環境では、サーバーは、サーバーとデフォルトのサーバープロトコルバージョンを識別する情報との接続試行に応答する必要があります。
[3] The protocol MUST provide services that allow a client to request use of a specific protocol version as part of negotiating a session.
[3] プロトコルは、セッションの交渉の一環として、クライアントが特定のプロトコルバージョンの使用を要求できるようにするサービスを提供する必要があります。
[4] The protocol MUST provide services that allow a server to decline use of a specific protocol version as part of negotiating a session.
[4] プロトコルは、セッションの交渉の一環として、サーバーが特定のプロトコルバージョンの使用を拒否できるようにするサービスを提供する必要があります。
[5] A session MUST NOT be established if the client and server are unable to reach agreement on the protocol version to be used for the requested session.
[5] クライアントとサーバーが要求されたセッションに使用されるプロトコルバージョンで合意に達することができない場合、セッションを確立してはなりません。
[6] The protocol MUST provide services to explicitly end an established session.
[6] プロトコルは、確立されたセッションを明示的に終了するためのサービスを提供する必要があります。
[7] The protocol MUST provide services that provide transactional atomicity, consistency, isolation, and durability in the advent of session management failures.
[7] プロトコルは、セッション管理の障害の出現において、トランザクションの原子性、一貫性、分離、耐久性を提供するサービスを提供する必要があります。
[8] The protocol MUST provide services to confirm that a transaction has been completed if a session is aborted prematurely.
[8] プロトコルは、セッションが早期に中止された場合にトランザクションが完了したことを確認するためにサービスを提供する必要があります。
[1] The protocol or another layered protocol MUST provide services to identify registrar clients and registry servers before granting access to other protocol services.
[1] プロトコルまたは別の層状プロトコルは、他のプロトコルサービスへのアクセスを付与する前に、レジストラクライアントとレジストリサーバーを特定するためのサービスを提供する必要があります。
[2] The protocol or another layered protocol MUST provide services to authenticate registrar clients and registry servers before granting access to other protocol services.
[2] プロトコルまたは別の層状プロトコルは、他のプロトコルサービスへのアクセスを付与する前に、レジストラクライアントとレジストリサーバーを認証するためのサービスを提供する必要があります。
[3] The protocol or another layered protocol MUST provide services to negotiate an authentication mechanism acceptable to both client and server.
[3] プロトコルまたは別の層状プロトコルは、クライアントとサーバーの両方に許容できる認証メカニズムをネゴシエートするためのサービスを提供する必要があります。
[1] Registry operations that create, modify, or delete objects MUST be associated with a registry-unique identifier. The protocol MUST allow each transaction to be identified in a permanent and globally unique manner to facilitate temporal ordering and state management services.
[1] オブジェクトを作成、変更、または削除するレジストリ操作は、レジストリユニーク識別子に関連付けられている必要があります。このプロトコルは、各トランザクションを永続的かつグローバルにユニークな方法で識別して、一時的な秩序化と国家管理サービスを促進する必要があります。
This section describes requirements for object management, including identification, registration, association, update, transfer, renewal, deletion, and query.
このセクションでは、識別、登録、協会、更新、転送、更新、削除、クエリなど、オブジェクト管理の要件について説明します。
Some objects, such as name servers and contacts, have utility in multiple registries. However, maintaining disjoint copies of object information in multiple registries can lead to inconsistencies that have adverse consequences for the Internet. For example, changing a name server name in one registry, but not in a second registry that refers to the server for domain name delegation, can produce unexpected DNS query results.
名前サーバーや連絡先などの一部のオブジェクトは、複数のレジストリにユーティリティを持っています。ただし、複数のレジストリにオブジェクト情報の分離コピーを維持することは、インターネットに悪影響を与える矛盾につながる可能性があります。たとえば、ドメイン名の代表団のサーバーを参照する2番目のレジストリでは、1つのレジストリで名前サーバー名を変更すると、予期しないDNSクエリ結果が生成される可能性があります。
[1] The protocol MUST provide services to associate an object identifier with every object.
[1] プロトコルは、オブジェクト識別子をすべてのオブジェクトに関連付けるサービスを提供する必要があります。
[2] Object identifiers MUST be globally unique.
[2] オブジェクト識別子はグローバルに一意でなければなりません。
[3] An object's identifier MUST NOT change during the lifetime of the object in a particular repository, even if administrative control of the object changes over time.
[3] オブジェクトの識別子は、オブジェクトの管理制御が時間とともに変更されたとしても、特定のリポジトリ内のオブジェクトの寿命の間に変更してはなりません。
[4] An object identifier MUST contain information that unambiguously identifies the object.
[4] オブジェクト識別子には、オブジェクトを明確に識別する情報を含める必要があります。
[5] Object identifier format specified by the protocol SHOULD be easily parsed and understood by humans.
[5] プロトコルによって指定されたオブジェクト識別子形式は、人間が簡単に解析して理解する必要があります。
[6] An object's identifier MUST be generated and stored when an object is created.
[6] オブジェクトの識別子を生成して保存する必要があります。
[1] The protocol MUST provide services to register Internet domain names.
[1] プロトコルは、インターネットドメイン名を登録するためのサービスを提供する必要があります。
[2] The protocol MUST permit a starting and ending time for a domain name registration to be negotiated, thereby allowing a registry to implement policies allowing a range of registration validity periods (the start and end points in time during which one normally assumes that an object will be active), and enabling registrars to select a period for each registration they submit from within the valid range based on out-of-band negotiation between the registrar and the registrant. Registries SHOULD be allowed to accept indefinitely valid registrations if the policy that they are implementing permits, and to specify a default validity period if one is not selected by a registrar. Registries MUST be allowed to specify minimal validity periods consistent with prevailing or preferred practices for fee-for-service recovery. The protocol MUST provide features to ensure that both registry and registrar have a mutual understanding of the validity period at the conclusion of a successful registration event.
[2] プロトコルは、ドメイン名登録を交渉するための開始時間と終了時間を許可する必要があります。アクティブ）、およびレジストラがレジストラと登録者の間の帯域外交渉に基づいて有効な範囲内から提出する各登録の期間を選択できるようにします。レジストリは、許可を実装しているポリシーの場合、無期限に有効な登録を受け入れ、レジストラが選択していない場合はデフォルトの有効期間を指定することを許可する必要があります。レジストリは、サービス料金の回復のための一般的または優先慣行と一致する最小限の妥当性期間を指定することを許可する必要があります。プロトコルは、レジストラとレジストラの両方が、成功した登録イベントの終了時に有効期間を相互に理解できるようにするための機能を提供する必要があります。
[3] The protocol MUST provide services to register name servers. Name server registration MUST NOT be limited to a specific period of time. Name servers MUST be registered with a valid IPv4 or IPv6 address when a "glue record" is required for delegation. A name server MAY be registered with multiple IP addresses. Multiple name servers using distinct server names MAY share an IP address.
[3] プロトコルは、名前サーバーを登録するためのサービスを提供する必要があります。名前サーバーの登録は、特定の期間に限定されてはなりません。委任には「接着剤レコード」が必要な場合、名前サーバーは有効なIPv4またはIPv6アドレスに登録する必要があります。名前サーバーは、複数のIPアドレスで登録される場合があります。個別のサーバー名を使用した複数の名前サーバーは、IPアドレスを共有する場合があります。
[4] The protocol MUST provide services to manage delegation of zone authority. Names of name servers MUST NOT be required to be tied to the name of the zone(s) for which the server is authoritative.
[4] プロトコルは、ゾーン当局の委任を管理するためのサービスを提供する必要があります。名前サーバーの名前は、サーバーが信頼できるゾーンの名前に関連付ける必要はありません。
[5] The protocol MUST provide services to register social information describing human and organizational entities. Registration of social information MUST NOT be limited to a specific period of time. Social information MAY include a name (individual name, organization name, or both), address (including street address, city, state or province (if applicable), postal code, and country), voice telephone number, email address, and facsimile telephone number.
[5] プロトコルは、人間および組織の実体を説明する社会情報を登録するためのサービスを提供する必要があります。ソーシャル情報の登録は、特定の期間に限定されてはなりません。ソーシャル情報には、名前（個々の名前、組織名、またはその両方）、住所（路上住所、市、州、または州（該当する場合は郵便番号、および国）、音声電話番号、電子メールアドレス、ファクシミリ電話が含まれます。番号。
[6] Protocol services to register an object MUST be available to all authorized registrars.
[6] オブジェクトを登録するためのプロトコルサービスは、すべての承認されたレジストラが利用できる必要があります。
[1] The protocol MUST provide services to associate name servers with domain names to delegate authority for zones. A domain name MAY have multiple authoritative name servers. Name servers MAY be authoritative for multiple zones.
[1] プロトコルは、ゾーンの権限を委任するために、名前のサーバーをドメイン名に関連付けるサービスを提供する必要があります。ドメイン名には、複数の権威ある名前サーバーがある場合があります。名前サーバーは、複数のゾーンに対して権威ある場合があります。
[2] The protocol MUST provide services to associate IP addresses with name servers. A name server MAY have multiple IP addresses. An IP address MAY be associated with multiple name server registrations.
[2] プロトコルは、IPアドレスを名前サーバーに関連付けるサービスを提供する必要があります。名前サーバーには複数のIPアドレスがある場合があります。IPアドレスは、複数の名前サーバー登録に関連付けられている場合があります。
[3] The protocol MUST provide services to associate social information with other objects. Social information associations MUST be identified by type. "Registrant" is an example social information type that might be associated with an object such as a domain name.
[3] プロトコルは、ソーシャル情報を他のオブジェクトに関連付けるためのサービスを提供する必要があります。ソーシャル情報協会は、タイプごとに特定する必要があります。「登録者」は、ドメイン名などのオブジェクトに関連付けられる可能性のあるソーシャル情報タイプの例です。
[4] The protocol MUST provide services to associate object management capabilities on a per-registrar basis.
[4] プロトコルは、登録ごとにオブジェクト管理機能を関連付けるサービスを提供する必要があります。
[5] Some managed objects represent shared resources that might be referenced by multiple registrars. The protocol MUST provide services that allow a registrar to associate an existing shared resource object with other registered objects sponsored by a second registrar. For example, authority for the example.tld zone (example.tld domain object managed by registrar X) and authority for the test.tld zone (test.tld domain object managed by registrar Y) might be delegated to server ns1.example.tld (managed by registrar X). Registrar X maintains administrative control over domain object example.tld and server object ns1.example.tld, and registrar Y maintains administrative control over domain object test.tld. Registrar Y does not have administrative control over server object ns1.example.tld.
[5] いくつかの管理されたオブジェクトは、複数のレジストラが参照できる共有リソースを表しています。プロトコルは、レジストラが既存の共有リソースオブジェクトを2番目のレジストラがスポンサーになった他の登録オブジェクトに関連付けることを可能にするサービスを提供する必要があります。たとえば、example.tldゾーンの権限（レジストラxによって管理された例.tldドメインオブジェクト）およびtest.tldゾーン（レジストラyによって管理されるtest.tldドメインオブジェクト）の権限は、サーバーns1.example.tldに委任される場合があります。（レジストラXが管理）。レジストラXは、ドメインオブジェクトのexample.tldおよびサーバーオブジェクトns1.example.tldに対する管理制御を維持し、レジストラyはドメインオブジェクトTest.tldに対する管理制御を維持します。レジストラYは、サーバーオブジェクトns1.example.tldを管理する管理制御を持っていません。
[1] The protocol MUST provide services to update information associated with registered Internet domain names.
[1] プロトコルは、登録されたインターネットドメイン名に関連する情報を更新するためのサービスを提供する必要があります。
[2] The protocol MUST provide services to update information associated with registered name servers.
[2] プロトコルは、登録名サーバーに関連付けられた情報を更新するためのサービスを提供する必要があります。
[3] The protocol MUST provide services to update social information associated with registered human and organizational entities.
[3] このプロトコルは、登録された人間および組織エンティティに関連するソーシャル情報を更新するためのサービスを提供する必要があります。
[4] The protocol MUST provide services to limit requests to update a registered object to the registrar that currently sponsors the registered object.
[4] プロトコルは、現在登録されているオブジェクトを後援しているレジストラに登録オブジェクトを更新するためのリクエストを制限するサービスを提供する必要があります。
[5] The protocol MUST provide services to explicitly reject unauthorized attempts to update a registered object.
[5] プロトコルは、登録されたオブジェクトを更新するための不正な試みを明示的に拒否するためのサービスを提供する必要があります。
[1] The protocol MUST provide services to transfer domain names among authorized registrars. Name servers registered in a domain being transferred MUST be transferred along with the domain itself. For example, name servers "ns1.example.tld" and "ns2.example.tld" MUST be implicitly transferred when domain "example.tld" is transferred.
[1] プロトコルは、承認されたレジストラ間でドメイン名を転送するサービスを提供する必要があります。転送されるドメインに登録された名前サーバーは、ドメイン自体とともに転送する必要があります。たとえば、「ns1.example.tld」と「ns2.example.tld」という名前のサーバーは、domain "example.tld"が転送されたときに暗黙的に転送する必要があります。
[2] The protocol MUST provide services to describe all objects, including associated objects, that are transferred as a result of an object transfer.
[2] プロトコルは、オブジェクト転送の結果として転送される関連オブジェクトを含むすべてのオブジェクトを記述するためのサービスを提供する必要があります。
[3] The protocol MUST provide services to transfer social information objects among authorized registrars.
[3] プロトコルは、承認されたレジストラ間でソーシャル情報オブジェクトを転送するためのサービスを提供する必要があります。
[4] Protocol transfer requests MUST be initiated by the registrar who wishes to become the new administrator of an object.
[4] プロトコル転送要求は、オブジェクトの新しい管理者になりたいと希望するレジストラが開始する必要があります。
[5] The protocol MUST provide services to confirm registrar authorization to transfer an object.
[5] プロトコルは、オブジェクトを転送するためのレジストラ許可を確認するためのサービスを提供する必要があります。
[6] The protocol MUST provide services that allow the requesting registrar to cancel a requested object transfer before the request has been approved or rejected by the original sponsoring registrar. Requests to cancel the transfer of registered objects MUST be limited to the registrar that requested transfer of the registered object. Unauthorized attempts to cancel the transfer of a registered object MUST be explicitly rejected.
[6] プロトコルは、リクエストが要求されたオブジェクト転送をキャンセルできるようにするサービスを提供する必要があります。リクエストが元のスポンサーレジストラによって承認または拒否される前に。登録されたオブジェクトの転送をキャンセルするリクエストは、登録されたオブジェクトの転送を要求するレジストラに制限する必要があります。登録されたオブジェクトの転送をキャンセルしようとする不正な試みは、明示的に拒否されなければなりません。
[7] The protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. Requests to approve or reject the transfer of registered objects MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected.
[7] プロトコルは、元のスポンサーレジストラが要求されたオブジェクト転送を承認または拒否できるようにするサービスを提供する必要があります。登録されたオブジェクトの転送を承認または拒否するリクエストは、現在登録されているオブジェクトを後援しているレジストラに限定する必要があります。登録されたオブジェクトの転送を承認または拒否しようとする不正な試みは、明示的に拒否されなければなりません。
[8] The protocol MUST provide services that allow both the original sponsoring registrar and the potential new registrar to monitor the status of both pending and completed transfer requests.
[8] プロトコルは、元のスポンサーレジストラと潜在的な新しいレジストラの両方が、保留中および完了した転送要求の両方のステータスを監視できるようにするサービスを提供する必要があります。
[9] Transfer of an object MAY extend the object's registration period. If an object's registration period will be extended as the result of a transfer, the new expiration date and time MUST be returned after successful completion of a transfer request.
[9] オブジェクトの転送は、オブジェクトの登録期間を延長する場合があります。転送の結果としてオブジェクトの登録期間が延長される場合、転送リクエストが正常に完了した後、新しい有効期限の日付と時刻を返す必要があります。
[10] Requests to initiate the transfer of a registered object MUST be available to all authorized registrars.
[10] 登録されたオブジェクトの転送を開始するためのリクエストは、すべての許可されたレジストラが利用できる必要があります。
[11] Registrars might become non-functional and unable to respond to transfer requests. It might be necessary for one registrar to assume management responsibility for the objects associated with another registrar in the event of registrar failure. The protocol MUST NOT restrict the ability to transfer objects in the event of registrar failure.
[11] レジストラは機能的ではなく、転送リクエストに応答できない場合があります。あるレジストラが、レジストラの障害が発生した場合に別のレジストラに関連付けられたオブジェクトの管理責任を負う必要があるかもしれません。プロトコルは、レジストラの障害が発生した場合にオブジェクトを転送する機能を制限してはなりません。
[1] The protocol MUST provide services to renew or extend the validity period of registered domain names. If applicable, the new expiration date and time MUST be returned after successful completion of a request to renew or extend the validity period.
[1] プロトコルは、登録ドメイン名の有効期間を更新または延長するためのサービスを提供する必要があります。該当する場合は、有効期間を更新または延長するというリクエストが正常に完了した後、新しい有効期限日と時間を返しなければなりません。
[2] Requests to renew or extend the validity period of a registered object MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to renew or extend the validity period of a registered object MUST be explicitly rejected.
[2] 登録されたオブジェクトの有効期間を更新または延長するという要求は、現在登録されているオブジェクトを後援しているレジストラに限定する必要があります。登録されたオブジェクトの有効期間を更新または延長するための不正な試みは、明示的に拒否されなければなりません。
[1] The protocol MUST provide services to remove a domain name from the registry.
[1] プロトコルは、レジストリからドメイン名を削除するためのサービスを提供する必要があります。
[2] The protocol MUST provide services to remove a name server from the registry.
[2] プロトコルは、レジストリから名前サーバーを削除するためのサービスを提供する必要があります。
[3] The protocol MUST provide services to remove a social information object from the registry.
[3] プロトコルは、レジストリからソーシャル情報オブジェクトを削除するためのサービスを提供する必要があります。
[4] Requests to remove a registered object MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to remove a registered object MUST be explicitly rejected.
[4] 登録されたオブジェクトを削除するリクエストは、現在登録されているオブジェクトを後援しているレジストラに制限する必要があります。登録されたオブジェクトを削除しようとする不正な試みは、明示的に拒否されなければなりません。
This section describes requirements for a lightweight query mechanism whose sole purpose is to determine if an object exists in a registry.
このセクションでは、オブジェクトがレジストリに存在するかどうかを判断することを唯一の目的とする軽量クエリメカニズムの要件について説明します。
[1] The protocol MUST provide services to determine if a domain name exists in the registry. Domain names MUST be searchable by fully qualified name.
[1] プロトコルは、レジストリにドメイン名が存在するかどうかを判断するためのサービスを提供する必要があります。ドメイン名は、完全な資格のある名前で検索可能でなければなりません。
[2] The protocol MUST provide services to determine if a name server exists in the registry. Name servers MUST be searchable by fully qualified name.
[2] プロトコルは、レジストリに名前サーバーが存在するかどうかを判断するためのサービスを提供する必要があります。名前サーバーは、完全な資格のある名前で検索可能でなければなりません。
[3] The protocol MUST provide services to determine if a social information object exists in the registry. Social information MUST be searchable by a registry-unique identifier.
[3] プロトコルは、ソーシャル情報オブジェクトがレジストリに存在するかどうかを判断するためのサービスを提供する必要があります。ソーシャル情報は、レジストリユニーク識別子によって検索可能でなければなりません。
[4] A query to determine if an object exists in the registry MUST return only a positive or negative response so that server software that responds to this query can be optimized for speed.
[4] レジストリにオブジェクトが存在するかどうかを判断するクエリは、このクエリに応答するサーバーソフトウェアを速度に対して最適化できるように、正または負の応答のみを返す必要があります。
[5] Requests to determine the existence of a registered object MUST be available to all authorized registrars.
[5] 登録されたオブジェクトの存在を決定するためのリクエストは、すべての許可されたレジストラが利用できる必要があります。
This section describes requirements for a query mechanism whose purpose is to provide detailed information describing objects that exist in a registry.
このセクションでは、レジストリに存在するオブジェクトを説明する詳細情報を提供することを目的とするクエリメカニズムの要件について説明します。
[1] The protocol MUST provide services to retrieve information describing a domain name from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the domain, the creation date and time, the expiration date and time (if any), the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), the current status of the domain, authorization information, identifiers describing social information associated with the domain, and the subordinate name servers registered in the domain. Authorization information MUST only be returned to the current sponsoring registrar.
[1] プロトコルは、レジストリからドメイン名を説明する情報を取得するためのサービスを提供する必要があります。返された情報には、現在のスポンサーレジストラの識別子、ドメインを最初に登録したレジストラの識別子、作成日と時間、有効期限（もしあれば）、最後の更新の日付と時刻（任意）、最後の更新を実行したレジストラの識別子、最後に完了した転送の日時（存在する場合）、ドメインの現在のステータス、承認情報、ドメインに関連するソーシャル情報を説明する識別子、および下位名ドメインに登録されたサーバー。承認情報は、現在のスポンサーレジストラにのみ返品する必要があります。
[2] The protocol MUST provide services to retrieve information describing a name server from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the name server, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), and the IP addresses currently associated with the name server.
[2] プロトコルは、レジストリから名前サーバーを説明する情報を取得するためのサービスを提供する必要があります。返された情報には、現在のスポンサーレジストラの識別子、名前サーバーを最初に登録したレジストラの識別子、作成日と時刻、最後の成功したアップデートの日時（もしあれば）、レジストラの識別子が含まれている必要があります。最後の更新、最後に完了した転送の日付と時刻（ある場合）、および現在名前サーバーに関連付けられているIPアドレスを実行しました。
[3] The protocol MUST provide services to retrieve social information from the registry. Returned information MUST include identification attributes (which MAY include name, address, telephone numbers, and email address), the identifier of the registrar that originally registered the information, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), and authorization information. Authorization information MUST only be returned to the current sponsoring registrar.
[3] プロトコルは、レジストリからソーシャル情報を取得するためのサービスを提供する必要があります。返された情報には、識別属性（名前、住所、電話番号、電子メールアドレスが含まれる場合があります）、情報、作成の日付と時刻、最後の成功した更新の日付と時刻を元々登録したレジストラの識別子を含める必要があります（場合の場合）任意）、最後の更新を実行したレジストラの識別子、最後に完了した転送の日付と時刻（ある場合）、および認可情報。承認情報は、現在のスポンサーレジストラにのみ返品する必要があります。
[4] The protocol MUST provide services to identify all associated object references, such as name servers associated with domains (including delegations and hierarchical relationships) and contacts associated with domains. This information MUST be visible if the object associations have an impact on the success or failure of protocol operations.
[4] プロトコルは、ドメインに関連付けられた名前サーバー（代表団や階層関係を含む）やドメインに関連付けられた連絡先など、関連するすべてのオブジェクト参照を特定するためのサービスを提供する必要があります。この情報は、オブジェクトの関連付けがプロトコル操作の成功または失敗に影響を与える場合、目に見える必要があります。
[5] Requests to retrieve information describing a registered object MAY be granted by the registrar that currently sponsors the registered object. Unauthorized attempts to retrieve information describing a registered object MUST be explicitly rejected.
[5] 登録されたオブジェクトを説明する情報を取得するリクエストは、現在登録されているオブジェクトを後援しているレジストラによって付与される場合があります。登録されたオブジェクトを説明する情報を取得しようとする不正な試みは、明示的に拒否されなければなりません。
[1] The protocol MUST provide status indicators that identify the operational state of a domain name. Indicators MAY be provided to identify a newly created state (the domain has been registered but has not yet appeared in a zone), a normal active state (the domain can be modified and is published in a zone), an inactive state (the domain can be modified but is not published in a zone because it has no authoritative name servers), a hold state (the domain can not be modified and is not published in a zone), a lock state (the domain can not be modified and is published in a zone), a pending transfer state, and a pending removal state.
[1] プロトコルは、ドメイン名の動作状態を識別するステータスインジケーターを提供する必要があります。新しく作成された状態（ドメインは登録されていますが、ゾーンにはまだ表示されていない）、通常のアクティブ状態（ドメインは変更でき、ゾーンで公開されます）、非アクティブ状態（ドメインで公開されています）を識別するためのインジケータを提供できます。修正できますが、権威ある名前サーバーがないためゾーンで公開されていません）、ホールド状態（ドメインは変更できず、ゾーンで公開されません）、ロック状態（ドメインは変更できず、変更できず、ゾーンで公開）、保留中の転送状態、および保留中の除去状態。
[2] If provided, protocol indicators for hold and lock status MUST allow independent setting by both registry and registrar.
[2] 提供されている場合、ホールドおよびロックステータスのプロトコルインジケーターは、レジストラとレジストラの両方による独立した設定を許可する必要があります。
[3] A domain MAY have multiple statuses at any given time. Some statuses MAY be mutually exclusive.
[3] ドメインは、いつでも複数のステータスを持つ場合があります。一部のステータスは相互に排他的である場合があります。
[1] The protocol MUST provide services that unambiguously note the success or failure of every transaction. Individual success and error conditions MUST be noted distinctly.
[1] プロトコルは、すべてのトランザクションの成功または失敗を明確に指摘するサービスを提供する必要があります。個々の成功とエラーの条件は明確に注意する必要があります。
External interfaces define the interaction points between a system and entities that communicate with the system. Specific areas of interest include user interfaces, hardware interfaces, software interfaces, and communications interfaces.
外部インターフェイスは、システムと通信するシステムとエンティティの間の相互作用ポイントを定義します。関心のある特定の領域には、ユーザーインターフェイス、ハードウェアインターフェイス、ソフトウェアインターフェイス、および通信インターフェイスが含まれます。
[1] The protocol MUST define a wire format for data exchange, not an application design for user, hardware, or software interfaces so that any application able to create the same bits on the wire, and to maintain the image of the same integrity constraints, is a valid implementation of the protocol.
[1] プロトコルは、ユーザー、ハードウェア、またはソフトウェアインターフェイスのアプリケーション設計ではなく、データ交換用のワイヤー形式を定義する必要があります。これにより、ワイヤー上に同じビットを作成できるアプリケーションが、同じ整合性の制約の画像を維持できるようにする必要があります。プロトコルの有効な実装。
[1] Registries, registrars, and registrants interact using a wide spectrum of communications interfaces built upon multiple protocols, including transport layer protocols such as TCP and application layer protocols such as SMTP. The protocol MUST only be run over IETF approved protocols that feature congestion control, such as TCP and SCTP.
[1] レジストリ、レジストラ、登録者は、TCPなどの輸送層プロトコルやSMTPなどのアプリケーション層プロトコルを含む複数のプロトコル上に構築された幅広い通信インターフェイスを使用して対話します。プロトコルは、TCPやSCTPなどの輻輳制御を特徴とするIETF承認のプロトコルに対してのみ実行する必要があります。
[1] Run-time performance is an absolutely critical aspect of protocol usability. While performance is very heavily dependent on the hardware and software architecture that implements a protocol, protocol features can have a direct impact on the ability of the underlying architecture to provide optimal performance. The protocol MUST be usable in both high volume and low volume operating environments.
[1] ランタイムパフォーマンスは、プロトコルの使いやすさの絶対に重要な側面です。パフォーマンスはプロトコルを実装するハードウェアおよびソフトウェアアーキテクチャに大きく依存していますが、プロトコル機能は、基礎となるアーキテクチャの能力に最適なパフォーマンスを提供する能力に直接影響を与える可能性があります。プロトコルは、大量および低ボリューム動作環境の両方で使用可能でなければなりません。
Protocol designers need to be aware of issues beyond functional and interface requirements when balancing protocol design decisions. This section describes additional factors that might have an impact on protocol design, including standards compliance and hardware limitations.
プロトコル設計者は、プロトコルの設計上の決定のバランスをとる際に、機能的要件やインターフェース要件を超えた問題を認識する必要があります。このセクションでは、標準コンプライアンスやハードウェアの制限など、プロトコル設計に影響を与える可能性のある追加の要因について説明します。
[1] The protocol MUST conform to current IETF standards. Standards for domain and host name syntax, IP address syntax, security, and transport are particularly relevant. Emerging standards for the Domain Name System MUST be considered as they approach maturity.
[1] プロトコルは、現在のIETF標準に準拠する必要があります。ドメインおよびホスト名の構文、IPアドレスの構文、セキュリティ、および輸送の標準は特に関連しています。ドメイン名システムの新たな標準は、成熟度に近づく際に考慮する必要があります。
[2] The protocol MUST NOT reinvent services offered by lower layer protocol standards. For example, the use of a transport that provides reliability is to be chosen over use of a non-reliable transport with the protocol itself using retransmission to achieve reliability.
[2] プロトコルは、下層のプロトコル標準で提供されるサービスを再発明してはなりません。たとえば、信頼性を提供する輸送の使用は、信頼性を達成するための再送信を使用して、プロトコル自体を使用して、信頼できない輸送を使用することよりも選択されることです。
[1] The protocol MUST NOT define any features that preclude hardware independence.
[1] プロトコルは、ハードウェアの独立性を排除する機能を定義してはなりません。
Elements of service beyond functional and interface requirements are essential factors to consider as part of a protocol design effort. This section describes several important service elements to be addressed by protocol designers, including reliability, availability, scalability, maintainability, extensibility, and security.
機能的要素とインターフェイスの要件を超えたサービスの要素は、プロトコル設計の取り組みの一部として考慮すべき重要な要素です。このセクションでは、信頼性、可用性、スケーラビリティ、保守性、拡張性、セキュリティなど、プロトコル設計者によって対処されるいくつかの重要なサービス要素について説明します。
[1] Reliability is a measure of the extent to which a protocol provides a consistent, dependable level of service. Reliability is an important attribute for a domain name management protocol. An unreliable protocol increases the risk of data exchange errors, which at one extreme can have a direct impact on protocol usability and at the other extreme can introduce discontinuity between registry and registrar data stores. The protocol MUST include features that maximize reliability at the application protocol layer. Services provided by underlying transport, session, and presentation protocols SHOULD also be considered when addressing application protocol reliability.
[1] 信頼性は、プロトコルが一貫した信頼できるレベルのサービスを提供する程度の尺度です。信頼性は、ドメイン名管理プロトコルにとって重要な属性です。信頼できないプロトコルは、データ交換エラーのリスクを高めます。これは、ある極端ではプロトコルの使いやすさに直接影響を与える可能性があり、もう1つの極端な場合、レジストラデータストアとレジストラデータストアの間に不連続性が発生する可能性があります。プロトコルには、アプリケーションプロトコル層の信頼性を最大化する機能を含める必要があります。基礎となる輸送、セッション、およびプレゼンテーションプロトコルが提供するサービスも、アプリケーションプロトコルの信頼性に対処する際に考慮する必要があります。
[2] The protocol MUST be run over the most reliable transport option available in a given environment. The protocol MUST NOT implement a service that is otherwise available in an applicable standard transport.
[2] プロトコルは、特定の環境で利用可能な最も信頼性の高い輸送オプションを介して実行する必要があります。プロトコルは、該当する標準輸送で利用できるサービスを実装してはなりません。
[3] Default protocol actions for when a request or event times out MUST be well defined.
[3] リクエストまたはイベントタイムアウトが明確に定義する必要がある場合のデフォルトのプロトコルアクション。
[1] Availability is a measure of the extent to which the services provided by a protocol are accessible for an intended use. Availability of an application layer protocol is primarily dependent on the software and hardware systems that implement the protocol.
[1] 可用性は、プロトコルが提供するサービスに使用できるようにアクセスできる程度の尺度です。アプリケーションレイヤープロトコルの可用性は、主にプロトコルを実装するソフトウェアおよびハードウェアシステムに依存します。
The protocol MUST NOT include any features that impinge on the underlying availability of the software and hardware systems needed to service the protocol.
プロトコルには、プロトコルのサービスに必要なソフトウェアおよびハードウェアシステムの基礎となる可用性に衝突する機能を含めるべきではありません。
[1] Scalability is a measure of the extent to which a protocol can accommodate use growth while preserving acceptable operational characteristics. The protocol MUST be capable of operating at an acceptable level as the load on registry and registrar systems increases.
[1] スケーラビリティとは、プロトコルが使用成長に対応しながら、許容可能な運用特性を維持できる程度の尺度です。プロトコルは、レジストリおよびレジストラシステムの負荷が増加するにつれて、許容レベルで動作できる必要があります。
[1] Maintainability is a measure of the extent to which a protocol can be adapted or modified to address unforeseen operational needs or defects. The protocol SHOULD be developed under the nominal working group processes of the IETF to provide a well-known mechanism for ongoing maintenance.
[1] 保守性は、予期せぬ運用上のニーズまたは欠陥に対処するために、プロトコルを適応または変更できる程度の尺度です。プロトコルは、IETFの名目ワーキンググループプロセスの下で開発され、継続的なメンテナンスのためのよく知られたメカニズムを提供する必要があります。
[1] Extensibility is a measure of the extent to which a protocol can be adapted for future uses that were not readily evident when the protocol was originally designed. The protocol SHOULD provide features that at a minimum allow for the management of new object types without requiring revisions to the protocol itself.
[1] 拡張性とは、プロトコルが元々設計されたときに容易に明白ではなかった将来の使用にプロトコルを適合させる程度の尺度です。プロトコルは、プロトコル自体の改訂を必要とせずに、新しいオブジェクトタイプの管理を最小限に抑える機能を提供する必要があります。
[2] The requirements described in this document are not intended to limit the set of objects that might be managed by the protocol. The protocol MUST include features that allow extension to object types that are not described in this document.
[2] このドキュメントで説明されている要件は、プロトコルによって管理される可能性のあるオブジェクトのセットを制限することを意図したものではありません。プロトコルには、このドキュメントで説明されていないオブジェクトタイプに拡張機能を可能にする機能を含める必要があります。
[3] The protocol MUST provide an optional field within all commands whose format and use will be controlled by individual registry policy.
[3] プロトコルは、形式と使用が個々のレジストリポリシーによって制御されるすべてのコマンド内にオプションのフィールドを提供する必要があります。
[1] Transactional privacy and integrity services MUST be available at some protocol layer.
[1] トランザクションプライバシーおよび整合性サービスは、一部のプロトコルレイヤーで利用できる必要があります。
[2] This document describes requirements for basic user identification and authentication services. A generic protocol MAY include additional security services to protect against the attacks described here. A generic protocol MUST depend on other-layered protocols to provide security services that are not provided in the generic protocol itself. A generic protocol that relies on security services from other-layered protocols MUST specify the protocol layers needed to provide security services.
[2] このドキュメントでは、基本的なユーザー識別と認証サービスの要件について説明します。一般的なプロトコルには、ここで説明する攻撃から保護するための追加のセキュリティサービスが含まれる場合があります。一般的なプロトコルは、一般的なプロトコル自体で提供されていないセキュリティサービスを提供するために、他の層のプロトコルに依存する必要があります。他の層のプロトコルからのセキュリティサービスに依存する一般的なプロトコルは、セキュリティサービスを提供するために必要なプロトコル層を指定する必要があります。
Certain aspects of anticipated operational environments have to be considered when designing a generic registry-registrar protocol. Areas of concern include database operations, operations, site adaptation, and data collection.
一般的なレジストリ登録プロトコルを設計する際には、予想される運用環境の特定の側面を考慮する必要があります。関心のある分野には、データベース操作、操作、サイト適応、およびデータ収集が含まれます。
[1] The protocol MUST NOT have any database dependencies. However, efficient use of database operations and resources has to be considered as part of the protocol design effort. The protocol SHOULD provide atomic features that can be efficiently implemented to minimize database load.
[1] プロトコルには、データベースの依存関係が必要です。ただし、データベースの操作とリソースの効率的な使用は、プロトコル設計の取り組みの一部として考慮する必要があります。プロトコルは、データベースの負荷を最小限に抑えるために効率的に実装できる原子機能を提供する必要があります。
[1] Registry-registrar interactions at the protocol level SHOULD operate without human intervention. However, intermediate services that preserve the integrity of the protocol MAY be provided. For example, an intermediate service that determines if a registrant is authorized to register a name in a name space can be provided.
[1] プロトコルレベルでのレジストリと登録の相互作用は、人間の介入なしに動作するはずです。ただし、プロトコルの完全性を維持する中間サービスが提供される場合があります。たとえば、登録者が名前スペースに名前を登録することを許可されているかどうかを判断する中間サービスを提供できます。
[2] The protocol MUST provide services that allow clients and servers to maintain a consistent understanding of the current date and time to effectively manage objects with temporal properties.
[2] プロトコルは、クライアントとサーバーが現在の日付と時刻の一貫した理解を維持して、時間特性を持つオブジェクトを効果的に管理できるようにするサービスを提供する必要があります。
[1] Registries and registrars have varying business and operational requirements. Several factors, including governance standards, local laws, customs, and business practices all play roles in determining how registries and registrars are operated. The protocol MUST be flexible enough to operate in diverse registry-registrar environments.
[1] レジストリとレジストラには、さまざまなビジネスおよび運用要件があります。ガバナンス基準、現地法、税関、ビジネス慣行などのいくつかの要因はすべて、レジストリとレジストラの運営方法を決定する上で役割を果たします。プロトコルは、多様なレジストリ登録環境で動作するほど柔軟でなければなりません。
[1] Some of the data exchanged between a registrar and registry might be considered personal, private, or otherwise sensitive. Disclosure of such information might be restricted by laws and/or business practices. The protocol MUST provide services to identify data collection policies.
[1] レジストラとレジストリの間で交換されるデータの一部は、個人、プライベート、またはその他の敏感と見なされる場合があります。そのような情報の開示は、法律やビジネス慣行によって制限される場合があります。プロトコルは、データ収集ポリシーを特定するためのサービスを提供する必要があります。
[2] Some of the social information exchanged between a registrar and registry might be required to create, manage, or operate Internet or DNS infrastructure facilities, such as zone files. Such information is subject to public disclosure per relevant IETF standards.
[2] レジストラとレジストリの間で交換されるソーシャル情報の一部は、ゾーンファイルなどのインターネットまたはDNSインフラストラクチャ施設の作成、管理、または運用に必要な場合があります。このような情報は、関連するIETF標準ごとの公開開示の対象となります。
[1] [RFC1035] describes Internet host and domain names using characters traditionally found in a subset of the 7-bit US-ASCII character set. More recent standards, such as [RFC2130] and [RFC2277], describe the need to develop protocols for an international Internet. These and other standards MUST be considered during the protocol design process to ensure world-wide usability of a generic registry registrar protocol.
[1] [RFC1035]は、7ビットのUS-ASCII文字セットのサブセットで伝統的に見つかった文字を使用して、インターネットホストとドメイン名を説明しています。[RFC2130]や[RFC2277]などの最近の基準は、国際的なインターネットのプロトコルを開発する必要性を説明しています。これらおよびその他の標準は、一般的なレジストリレジストラプロトコルの世界的な使いやすさを確保するために、プロトコル設計プロセス中に考慮する必要があります。
[2] The protocol MUST allow exchange of data in formats consistent with current international agreements for the representation of such objects. In particular, this means that addresses MUST include country, that telephone numbers MUST start with the international prefix "+", and that appropriate thought be given to the usability of information in both local and international contexts. This means that some elements (like names and addresses) might need to be represented multiple times, or formatted for different contexts (for instance English/French in Canada, or Latin/ideographic in Japan).
[2] このプロトコルは、そのようなオブジェクトの表現に関する現在の国際協定と一致する形式のデータ交換を許可する必要があります。特に、これは、住所には国を含める必要があり、電話番号が国際的なプレフィックス「」から開始されなければならないことを意味し、その適切な考えは、ローカルおよび国際的なコンテキストの両方で情報の使いやすさに与えられます。これは、一部の要素（名前や住所など）を複数回表現するか、さまざまなコンテキスト（たとえばカナダの英語/フランス語、または日本のラテン語/包帯）に対してフォーマットする必要があることを意味します。
[3] All date and time values specified in a generic registry-registrar protocol MUST be expressed in Universal Coordinated Time. Dates and times MUST include information to represent a four-digit calendar year, a calendar month, a calendar day, hours, minutes, seconds, fractional seconds, and the time zone for Universal Coordinated Time. Calendars apart from the Gregorian calendar MUST NOT be used
[3] 一般的なレジストリ登録プロトコルで指定されたすべての日付と時刻の値は、普遍的な調整時間で表現する必要があります。日付と時間には、4桁の暦年、暦月、暦日、時間、分、秒、分数秒、普遍的な調整時間のタイムゾーンを表す情報を含める必要があります。グレゴリオカレンダー以外のカレンダーは使用しないでください
This document does not require any action on the part of IANA. Protocol specifications that require IANA action MUST follow the guidelines described in [RFC2434].
このドキュメントでは、IANAの側でのアクションは必要ありません。IANAアクションを必要とするプロトコル仕様は、[RFC2434]で説明されているガイドラインに従う必要があります。
Security services, including confidentiality, authentication, access control, integrity, and non-repudiation SHOULD be applied to protect interactions between registries and registrars as appropriate. Confidentiality services protect sensitive exchanged information from inadvertent disclosure. Authentication services confirm the claimed identity of registries and registrars before engaging in online transactions. Access control services control access to data and services based on identity. Integrity services guarantee that exchanged data has not been altered between the registry and the registrar. Non-repudiation services provide assurance that the sender of a transaction can not deny being the source of the transaction, and that the recipient cannot deny being the receiver of the transaction.
機密性、認証、アクセス制御、整合性、および非控除を含むセキュリティサービスは、必要に応じてレジストリとレジストラ間の相互作用を保護するために適用する必要があります。機密性サービスは、繊細な交換された情報を不注意な開示から保護します。認証サービスは、オンライン取引に従事する前に、レジストリとレジストラの請求された身元を確認します。アクセス制御サービスは、IDに基づいてデータとサービスへのアクセスを制御します。整合性サービスは、レジストラとレジストラの間で交換データが変更されていないことを保証します。非繰り返しサービスは、トランザクションの送信者が取引のソースであることを否定できず、受信者がトランザクションの受信者であることを否定できないという保証を提供します。
This document was originally written as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
このドキュメントは、もともと個別の提出インターネットドラフトとして書かれていました。Provregワーキンググループは後にワーキンググループの文書としてそれを採用し、多くの貴重なコメントを提供し、改善を提案しました。著者は、WGチェアのエドワード・ルイスとJaap Akkerhuisのプロセスと編集上の貢献の努力を認めたいと考えています。
Specific comments that helped guide development of this document were provided by Harald Tveit Alvestrand, Christopher Ambler, Karl Auerbach, Jorg Bauer, George Belotsky, Eric Brunner-Williams, Jordyn Buchanan, Randy Bush, Bruce Campbell, Dan Cohen, Andre Cormier, Kent Crispin, Dave Crocker, Ayesha Damaraju, Lucio De Re, Mats Dufberg, Peter Eisenhauer, Sheer El-Showk, Urs Eppenberger, Patrik Faltstrom, Paul George, Patrick Greenwell, Jarle Greipsland, Olivier Guillard, Alf Hansen, Paul Hoffman, Paul Kane, Shane Kerr, Elmar Knipp, Mike Lampson, Matt Larson, Ping Lu, Klaus Malorny, Bill Manning, Michael Mealling, Patrick Mevzek, Peter Mott, Catherine Murphy, Martin Oldfield, Geva Patz, Elisabeth Porteneuve, Ross Wm. Rader, Budi Rahardjo, Annie Renard, Scott Rose, Takeshi Saigoh, Marcos Sanz, Marcel Schneider, J. William Semich, James Seng, Richard Shockey, Brian Spolarich, William Tan, Stig Venaas, Herbert Vitzthum, and Rick Wesson.
このドキュメントの開発を導くのに役立つ具体的なコメントは、ハラルド・トヴェイト・アルベスランド、クリストファー・アンブラー、カール・アウアーバッハ、ヨルグ・バウアー、ジョージ・ベロツキー、エリック・ブルナー・ウィリアムズ、ジョーディン・ブキャナン、ランディ・ブッシュ、ブルース・キャンベル、ダン・コーエン、アンドレ・コルミエによって提供されました。、デイブ・クロッカー、アイシャ・ダマラジュ、ルシオ・デ・レ、マット・デュフバーグ、ピーター・アイゼンハウアー、シアー・ショー、ウルス・エッペンバーガー、パトリック・フォルトストロム、ポール・ジョージ、パトリック・グリーンウェル、ジャール・グレイプランド、オリビエ・ギラード、アルフ・ハンセン、ポール・ホフマン、ポール・ホフマン、ポール・ホフマン、シェーンカー、エルマー・ナップ、マイク・ランプソン、マット・ラーソン、ピン・ルー、クラウス・マロルニー、ビル・マニング、マイケル・ミーリング、パトリック・メフェク、ピーター・モット、キャサリン・マーフィー、マーティン・オールドフィールド、ゲバ・パッツ、エリザベス・ポルティネーブ、ロスWM。レーダー、ブディ・ラハルジョ、アニー・レナード、スコット・ローズ、タケシ・サイゴー、マルコス・サンツ、マルセル・シュナイダー、J。
Normative References:
規範的参照：
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
Informative References:
有益な参照：
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Cripsin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop", RFC 2130, April 1997.
[RFC2130] Weider、C.、Preston、C.、Simonsen、K.、Alvestrand、H.、Atkinson、R.、Cripsin、M。and P. Svanberg、「IABキャラクターセットワークショップのレポート」、RFC 2130、1997年4月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H。、「キャラクターセットと言語に関するIETFポリシー」、BCP 18、RFC 2277、1998年1月。
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Scott Hollenbeck Verisign Global Registry Services 21345 Ridgetop Circle Dulles、VA 20166-6503 USA
EMail: shollenbeck@verisign.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。