Network Working Group C. Villamizar
Request for Comments: 2769 Avici Systems
Category: Standards Track C. Alaettinoglu
R. Govindan
ISI
D. Meyer
Cisco
February 2000
Routing Policy System Replication
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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 RFC 2119.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されます。
Abstract
抽象
The RIPE database specifications and RPSL define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any use. The Routing Policy System Security RFC [3] addresses the need to assure integrity of the data by proposing an authentication and authorization model. This document addresses the need to distribute data over multiple repositories and delegate authority for data subsets to other repositories without compromising the authorization model established in Routing Policy System Security RFC.
RIPEデータベース仕様とRPSLは、ルーティングポリシーシステムにおいて情報を表現するための基礎として使用する言語を定義します。ルーティングポリシーシステム情報のリポジトリは、ルーティングレジストリとして知られています。ルーティングレジストリは、インターネットの操作に重要性の多くの問題に対処するために必要な情報を交換する手段を提供します。ルーティングポリシーシステムの実装と展開は、任意の使用であるとの整合性をある程度維持しなければなりません。ルーティングポリシーシステムセキュリティRFC [3]は、認証と承認のモデルを提案することにより、データの整合性を確保する必要性に対処しています。この文書では、ルーティングポリシーシステムセキュリティのRFCに設立認可モデルを損なうことなく、他のリポジトリへのデータのサブセットのために複数のリポジトリと委任権限を介してデータを配布する必要性に対処しています。
Table of Contents
目次
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Data Representation . . . . . . . . . . . . . . . . . . . . . 4
3 Authentication and Authorization . . . . . . . . . . . . . . . 5
4 Repository Hierarchy . . . . . . . . . . . . . . . . . . . . . 6
5 Additions to RPSL . . . . . . . . . . . . . . . . . . . . . . 6
5.1 repository object . . . . . . . . . . . . . . . . . . . . 7
5.2 delegated attribute . . . . . . . . . . . . . . . . . . . 9
5.3 integrity attribute . . . . . . . . . . . . . . . . . . . 10
6 Interactions with a Repository or Mirror . . . . . . . . . . . 11
6.1 Initial Transaction Submission . . . . . . . . . . . . . 12
6.2 Redistribution of Transactions . . . . . . . . . . . . . 12
6.3 Transaction Commit and Confirmation . . . . . . . . . . . 12
7 Data Format Summaries, Transaction Encapsulation and Processing 13
7.1 Transaction Submit and Confirm . . . . . . . . . . . . . 13
7.2 Redistribution of Transactions . . . . . . . . . . . . . 16
7.3 Redistribution Protocol Description . . . . . . . . . . . 16
7.3.1 Explicitly Requesting Transactions . . . . . . . . 21
7.3.2 Heartbeat Processing . . . . . . . . . . . . . . . 22
7.4 Transaction Commit . . . . . . . . . . . . . . . . . . . 23
7.5 Database Snapshot . . . . . . . . . . . . . . . . . . . . 24
7.6 Authenticating Operations . . . . . . . . . . . . . . . . 25
A Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A.1 Initial Object Submission and Redistribution . . . . . . 27
A.2 Transaction Redistribution Encoding . . . . . . . . . . . 29
A.3 Transaction Protocol Encoding . . . . . . . . . . . . . . 31
A.4 Transaction Redistribution . . . . . . . . . . . . . . . 32
B Technical Discussion . . . . . . . . . . . . . . . . . . . . . 35
B.1 Server Processing . . . . . . . . . . . . . . . . . . . . 35
B.1.1 getting connected . . . . . . . . . . . . . . . . . 35
B.1.2 rolling transaction logs forward and back . . . . . 35
B.1.3 committing or disposing of transactions . . . . . . 36
B.1.4 dealing with concurrency . . . . . . . . . . . . . 36
B.2 Repository Mirroring for Redundancy . . . . . . . . . . . 36
B.3 Trust Relationships . . . . . . . . . . . . . . . . . . . 37
B.4 A Router as a Minimal Mirror . . . . . . . . . . . . . . 38
B.5 Dealing with Errors . . . . . . . . . . . . . . . . . . . 38
C Deployment Considerations . . . . . . . . . . . . . . . . . . 39
D Privacy of Contact Information . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Security Considerations . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 42
1 Overview
1。概要
A routing registry must maintain some degree of integrity to be of any use. The IRR is increasingly used for purposes that have a stronger requirement for data integrity and security. There is also a desire to further decentralize the IRR. This document proposes a means of decentralizing the routing registry in a way that is consistent with the usage of the IRR and which avoids compromising data integrity and security even if the IRR is distributed among less trusted repositories.
ルーティングレジストリは、任意の使用であるとの整合性をある程度維持しなければなりません。 IRRは、ますますデータの整合性とセキュリティのための強力な要件を持っている目的のために使用されます。さらにIRRを分散したいという願望もあります。この文書では、IRRの使用法と一致していると、データの整合性とIRRは、信頼性の低いリポジトリ間で分散されている場合でも、セキュリティを犠牲にする回避方法でルーティングレジストリを分散する手段を提案しています。
Two methods of authenticating the routing registry information have been proposed.
ルーティングレジストリ情報を認証する二つの方法が提案されています。
authorization and authentication checks on transactions: The integrity of the routing registry data is insured by repeating authorization checks as transactions are processed. As transactions are flooded each remote registry has the option to repeat the authorization and authentication checks. This scales with the total number of changes to the registry regardless of how many registries exist. When querying, the integrity of the repository must be such that it can be trusted. If an organization is unwilling to trust any of the available repositories or mirrors they have the option to run their own mirror and repeat authorization checks at that mirror site. Queries can then be directed to a mirror under their own administration which presumably can be trusted.
取引上の許可と認証チェック：ルーティングレジストリデータの整合性は、トランザクションが処理される認証チェックを繰り返すことによって、被保険者です。取引が殺到しているように、各リモートレジストリが許可および認証チェックを繰り返すオプションを持っています。これは関係なく、多くのレジストリが存在するかのレジストリへの変更の合計数に比例します。照会すると、リポジトリの整合性は、それが信頼できるようなものでなければなりません。組織は、彼らは自分のミラーを実行し、そのミラーサイトでの権限チェックを繰り返すオプションを持って利用できるリポジトリまたはミラーのいずれかを信頼して不本意である場合。その後、問合せは、おそらく、信頼することができ、自分の管理下に鏡に向けることができます。
signing routing registry objects: An alternate which appears on the surface to be attractive is signing the objects themselves. Closer examination reveals that the approach of signing objects by itself is flawed and when used in addition to signing transactions and rechecking authorizations as changes are made adds nothing. In order for an insertion of critical objects such as inetnums and routes to be valid, authorization checks must be made which allow the insertion. The objects on which those authorization checks are made may later change. In order to later repeat the authorization checks the state of other objects, possibly in other repositories would have to be known. If the repository were not trusted then the change history on the object would have to be traced back to the object's insertion. If the repository were not trusted, the change history of any object that was depended upon for authorization would also have to be rechecked. This trace back would have to go back to the epoch or at least to a point where only trusted objects were being relied upon for the authorizations. If the depth of the search is at all limited, authorization could be falsified simply by exceeding the search depth with a chain of authorization references back to falsified objects. This would be grossly inefficient. Simply verifying that an object is signed provides no assurance that addition of the object addition was properly authorized.
ルーティングレジストリに署名すると、オブジェクト：魅力的に表面に現れ代替は、オブジェクト自体に署名されます。クローサー検査はそれ自体でオブジェクトに署名のアプローチは欠陥があるとの取引に署名し、変更が行われるよう権限を再確認することに加えて、使用時に何も加えないことが明らかになりました。このようinetnumsやルートなどの重要なオブジェクトを挿入するための順序を有効にするには、認証チェックは、挿入を可能にするにしなければなりません。これらの認証チェックが行われたオブジェクトが、後で変更することがあります。後で承認を繰り返すために知らなければならない可能性が他のリポジトリには、他のオブジェクトの状態をチェックします。リポジトリが信頼されていなかった場合は、オブジェクトの変更履歴は、オブジェクトの挿入にさかのぼるしなければならないであろう。リポジトリが信頼されていなかった場合は、承認のために依存して任意のオブジェクトの変更履歴も再チェックしなければならないであろう。このトレースバックは、バックエポックまたは少なくとも唯一の信頼できるオブジェクトは、承認のために依拠されていたポイントに行かなければならないでしょう。検索の深さは全く制限されている場合、許可が戻って偽造オブジェクトへの許可参照のチェーンで検索の深さを超えて、単に偽造することができます。これは、著しく非効率的になります。単に署名されるオブジェクトは、オブジェクトの追加の添加が適切に承認されたという保証を提供しないことを確認します。
A minor distinction is made between a repository and a mirror. A repository has responsibility for the initial authorization and authentication checks for transactions related to its local objects which are then flooded to adjacent repositories. A mirror receives flooded transactions from remote repositories but is not the authoritative source for any objects. From a protocol standpoint, repositories and mirrors appear identical in the flooding topology.
マイナーの区別はリポジトリとミラーの間で行われます。リポジトリはその後、隣接するリポジトリにフラッディングされ、そのローカルオブジェクトに関連する取引のための最初の認可および認証チェックのために責任を負っています。ミラーは、リモートリポジトリからフラッディングトランザクションを受信するが、任意のオブジェクトの信頼できるソースではありません。プロトコルの観点から、リポジトリとミラーが洪水のトポロジで同じように見えます。
Either a repository or a mirror may recheck all or a subset of transactions that are flooded to it. A repository or mirror may elect not to recheck authorization and authentication on transactions received from a trusted adjacency on the grounds that the adjacent repository is trusted and would not have flooded the information unless authorization and authentication checks had been made.
リポジトリまたはミラーのいずれかの全部またはそれにフラッディングされるトランザクションの部分集合を再確認することができます。リポジトリまたはミラーは、隣接するリポジトリが信頼され、認可および認証チェックが行われていた場合を除き情報に殺到していないことを理由に、信頼できる隣接から受信した取引の認可と認証を再確認しないことを選択できます。
If it can be arranged that all adjacencies are trusted for a given mirror, then there is no need to implement the code to check authorization and authentication. There is only a need to be able to check the signatures on the flooded transactions of the adjacent repository. This is an important special case because it could allow a router to act as a mirror. Only changes to the registry database would be received through flooding, which is a very low volume. Only the signature of the adjacent mirror or repository would have to be checked.
それはすべての隣接が与えられた鏡のために信頼されるように配置することができた場合は、認可および認証をチェックするためのコードを実装する必要はありません。隣接するリポジトリの浸水取引上の署名をチェックすることができるようにする必要が唯一の存在です。それは、ルータがミラーとして機能する可能性がありますので、これは重要な特殊なケースです。レジストリデータベースへの変更だけでは非常に低い音量で洪水、を介して受信されるだろう。隣接するミラーまたはリポジトリの唯一の署名をチェックする必要があります。
2 Data Representation
2データ表現
RPSL provides a complete description of the contents of a routing repository [1]. Many RPSL data objects remain unchanged from the RIPE, and RPSL references the RIPE-181 specification as recorded in RFC-1786 [2]. RPSL provides external data representation. Data may be stored differently internal to a routing registry. The integrity of the distributed registry data requires the use of the authorization and authentication additions to RPSL described in [3].
RPSL [1]ルーティングリポジトリの内容の完全な説明を提供します。 [2]多くのRPSLデータオブジェクトは、RIPEから変わらない、およびRFC-1786に記録されRPSLは、RIPE-181仕様を参照します。 RPSLは、外部データ表現を提供します。データは、ルーティングレジストリに異なって内部に格納することができます。分散レジストリデータの整合性は、[3]で説明RPSLへの認可と認証の追加を使用する必要があります。
Some additions to RPSL are needed to locate all of the repositories after having located one of them and to make certain parameters selectable on a per repository basis readily available. These additions are described in Section 5.
RPSLにいくつかの追加はそのうちの一つを設置した後のリポジトリのすべてを検索すると、特定のパラメータが容易に入手でき、リポジトリごとに選択可能にするために必要とされています。これらの追加は、セクション5で説明されています。
Some form of encapsulation must be used to exchange data. The de-facto encapsulation has been that which the RIPE tools accept, a plain text file or plain text in the body of an RFC-822 formatted mail message with information needed for authentication derived from the mail headers. Merit has slightly modified this using the PGP signed portion of a plain text file or PGP signed portion of the body of a mail message.
カプセル化のいくつかの形式は、データを交換するために使用する必要があります。事実上のカプセル化は、RIPEツールは、メールヘッダに由来する認証に必要な情報をRFC-822形式のメールメッセージの本文にテキストファイルまたはプレーンテキストを受け入れるものでした。メリットは、わずかにメールメッセージの本文の一部に署名したテキストファイルまたはPGPのPGP署名された部分を使用してこれを修正しました。
The exchange that occurs during flooding differs from the initial submission. In order to repeat the authorization checks the state of all repositories containing objects referenced by the authorization checks needs to be known. To accomplish this a sequence number is associated with each transaction in a repository and the flooded transactions must contain the sequence number of each repository on which authorization of the transaction depends.
洪水時に発生する交換は、最初の投稿とは異なります。認可を繰り返すために知る必要が権限チェックによって参照されるオブジェクトを含むすべてのリポジトリの状態をチェックします。このシーケンス番号を達成するために、リポジトリ内の各トランザクションに関連付けられていると浸水の取引は、取引の承認が依存する各リポジトリのシーケンス番号が含まれている必要があります。
In order to repeat authorization checks it must be possible to retrieve back revisions of objects. How this is accomplished is a matter local to the implementation. One method which is quite simple is to keep the traversal data structures to all current objects even if the state is deleted, keep the sequence number that the version of the object became effective and keep back links to prior versions of the objects. Finding a prior version of an object involves looking back through the references until the sequence number of the version of the object is less than or equal to the sequence number being searched for.
認証チェックを繰り返すためには、オブジェクトのリビジョンをバック取り出すことが可能でなければなりません。これが達成されてどのように実装するローカルの問題です。非常にシンプルである一つの方法は、状態が削除された場合でも、現在のすべてのオブジェクトに横断データ構造を保持するオブジェクトのバージョンが有効になったシーケンス番号を維持し、オブジェクトの以前のバージョンへのリンクをバックに保つことです。オブジェクトの前バージョンを見つけることは、オブジェクトのバージョンのシーケンス番号が検索されるシーケンス番号より小さいか等しくなるまで参照を介して振り返ることを含みます。
The existing very simple forms of encapsulation are adequate for the initial submission of a database transaction and should be retained as long as needed for backward compatibility. A more robust encapsulation and submission protocol, with optional confirmation is defined in Section 6.1. An encapsulation suitable for exchange of transaction between repositories is addressed in Section 6. Query encapsulation and protocol is outside the scope of this document.
カプセル化の既存の非常にシンプルなフォームでは、データベースのトランザクションの最初の提出に適していると限り下位互換性のために、必要に応じて保持されるべきです。オプションの確認をより強固なカプセル化と服従プロトコルは、6.1節で定義されています。リポジトリとの間のトランザクションの交換に適したカプセルは、第6章クエリカプセル化プロトコルで対処され、この文書の範囲外です。
3 Authentication and Authorization
3認証と承認
Control must be exercised over who can make changes and what changes they can make. The distinction of who vs what separates authentication from authorization.
コントロールは変更を加えることができ、彼らが作ることができるどのような変更、誰の上に行使しなければなりません。承認から認証を分離するもの対の区別。
o Authentication is the means to determine who is attempting to make a change.
O認証は、変更を行うためにしようとしているかを決定するための手段です。
o Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.
O許可は、特定の認証チェックを通過するトランザクションが特定の操作を実行できるかどうかの決意です。
A submitted transaction contains a claimed identity. Depending on the type of transaction, the authorization will depend on related objects.
提出されたトランザクションは、要求されたアイデンティティが含まれています。トランザクションの種類に応じて、認可が関連オブジェクトに依存します。
The "mnt-by", "mnt-routes", or "mnt-lower" attributes in those related objects reference "maintainer" objects. Those maintainer objects contain "auth" attributes. The auth attributes contain an authorization method and data which generally contains the claimed identity and some form of public encryption key used to authenticate the claim.
「MNTバイ」、「MNT-ルート」、または「MNT - 低級」は、それらの関連オブジェクトの属性「保守」オブジェクトを参照。これらのメンテナオブジェクトは、「認証」属性が含まれています。認証属性は、一般的に要求されたアイデンティティとの主張を認証するために使用される公開暗号鍵を何らかの形で含まれている認証方式とデータが含まれています。
Authentication is done on transactions. Authentication should also be done between repositories to insure the integrity of the information exchange. In order to comply with import, export, and use restrictions throughout the world no encryption capability is specified. Transactions must not be encrypted because it may be illegal to use decryption software in some parts of the world.
認証は、トランザクションで行われます。認証はまた、情報交換の整合性を保証するために、リポジトリ間で行われるべきです。世界中でインポート、エクスポート、および使用制限を遵守するためには何の暗号化機能が指定されていません。世界の一部の地域では復号化ソフトウェアを使用することは違法かもしれないので取引は暗号化されてはなりません。
4 Repository Hierarchy
4リポジトリの階層
With multiple repositories, "repository" objects are needed to propagate the existence of new repositories and provide an automated means to determine the supported methods of access and other characteristics of the repository. The repository object is described in Section 5.
複数のリポジトリを使用すると、「リポジトリ」のオブジェクトは、新しいリポジトリの存在を伝播し、アクセスとリポジトリの他の特性のサポート方法を決定するための自動化された手段を提供するために必要とされます。リポジトリ・オブジェクトは、セクション5に記載されています。
In each repository there should be a special repository object named ROOT. This should point to the root repository or to a higher level repository. This is to allow queries to be directed to the local repository but refer to the full set of registries for resolution of hierarchically allocated objects.
各リポジトリでROOTという名前の特別なリポジトリオブジェクトがあるはずです。これは、ルートのリポジトリにまたはより高いレベルのリポジトリを指している必要があります。これは、クエリがローカルリポジトリに向けることを可能にするが、階層的に割り当てられたオブジェクトの解決のためにレジストリのフルセットを参照することです。
Each repository may have an "expire" attribute. The expire attribute is used to determine if a repository must be updated before a local transaction that depends on it can proceed.
各リポジトリは、「有効期限切れ」の属性を有することができます。有効期限切れ属性はリポジトリは、それが進むことができますに依存してローカル・トランザクションの前に更新されなければならないかどうかを判断するために使用されています。
The repository object also contains attributes describing the access methods and supported authentication methods of the repository. The "query-address" attribute provides a host name and a port number used to direct queries. The "response-auth-type" attribute provides the authentication types that may be used by the repository when responding to queries. The "submit-address" attribute provides a host name and a port number used to submit objects to the repository. The "submit-auth-type" attribute provides the authentication types that may be used by the repository when responding to submissions.
リポジトリオブジェクトは、アクセス方法を記述する属性を含む、リポジトリの認証方法をサポート。 「クエリ・アドレス」属性は、ホスト名と直接クエリに使用するポート番号を提供します。 「応答-AUTH-type」属性は、クエリに応答するとき、リポジトリによって使用されることができる認証タイプを提供します。 「提出-アドレス」属性は、ホスト名とリポジトリにオブジェクトを提出するために使用するポート番号を提供します。 「提出-のauth-type」属性は、提出に応答するときに、リポジトリによって使用される認証タイプを提供します。
5 Additions to RPSL
RPSLへ5件の追加
There are very few additions to RPSL defined here. The additions to RPSL are referred to as RPSL "objects". They reside in the repository database and can be retrieved with ordinary queries. Objects consist of "attributes", which are name/value pairs.
ここで定義されRPSLに非常にいくつかの追加があります。 RPSLへの追加は、RPSL「オブジェクト」と呼ばれています。彼らは、リポジトリ・データベースに存在し、通常のクエリで取得することができます。オブジェクトは名前/値のペアです「属性」、で構成されています。
Attributes may be mandatory or optional. They may be single or multiple. One or more attributes may be part of a key field. Some attributes may have the requirement of being unique.
属性は、必須または任意でよいです。彼らは、単一または複数のかもしれません。 1つ以上の属性は、キーフィールドの一部であってもよいです。一部の属性は、ユニークであることの要件を有することができます。
Most of the data formats described in this document are encapsulations used in transaction exchanges. These are referred to as "meta-objects". These "meta-objects", unlike RPSL "objects" do not reside in the database but some must be retained in a transaction log. A similar format is used to represent "meta-objects". They also consist of "attributes" which are name/value pairs.
この文書に記載されたデータフォーマットのほとんどは、トランザクションの交換に使用されるカプセル化されています。これらは、「メタオブジェクト」と呼ばれています。 RPSL「オブジェクト」とは異なり、これらの「メタオブジェクト」には、データベースに存在しませんが、いくつかは、トランザクション・ログに保持されなければなりません。同様の形式は、「メタオブジェクト」を表すために使用されます。彼らはまた、名前/値のペアです「属性」で構成されています。
This section contains all of the additions to RPSL described in this document. This section describes only RPSL objects. Other sections described only meta-objects.
このセクションでは、この文書で説明RPSLへの追加がすべて含まれています。このセクションでは、唯一のRPSLオブジェクトについて説明します。他のセクションでは、唯一のメタオブジェクトを説明しました。
A root repository must be agreed upon. Ideally such a repository would contain only top level delegations and pointers to other repositories used in these delegations. It would be wise to allow only cryptographically strong transactions in the root repository [3].
ルートリポジトリが合意されなければなりません。理想的には、このようなリポジトリは、これらの代表団で使用される他のリポジトリにのみ、トップレベルの代表団とポインタが含まれています。ルートのリポジトリにのみ、暗号強度の高い取引を可能にするのが賢明だろう[3]。
The root repository contains references to other repositories. An object of the following form identifies another repository.
ルートリポジトリは、他のリポジトリへの参照が含まれています。次の形式のオブジェクトが別のリポジトリを識別する。
repository: RIPE query-address: whois://whois.ripe.net response-auth-type: PGPKEY-23F5CE35 # pointer to key-cert object response-auth-type: none remarks: you can request rsa signature on queries remarks: PGP required on submissions submit-address: mailto://auto-dbm@ripe.net submit-address: rps-query://whois.ripe.net:43 submit-auth-type: pgp-key, crypt-pw, mail-from remarks: these are the authentication types supported mnt-by: maint-ripe-db expire: 0000 04:00:00 heartbeat-interval: 0000 01:00:00 ... remarks: admin and technical contact, etc source: IANA
リポジトリ：RIPE問合せアドレス：WHOIS：//whois.ripe.net応答-AUTH型：キー-CERTのオブジェクト応答-AUTH型にPGPKEY-23F5CE35の＃ポインタ：なし備考：あなたは、クエリの発言にRSA署名を要求することができます。 mailto：//auto-dbm@ripe.net提出-アドレス：RPS-クエリ：//whois.ripe.net：43提出-AUTH型：提出-アドレスを提出に必要なPGP PGPキー、暗号-PW、メールからの発言：これらは、MNT-によってサポートされる認証タイプです：MAINT-熟し-dbが有効期限切れ：0000 4時○○分00秒ハートビートインターバル：0000 1時00分00秒...備考：管理者と技術的な接触などのソース：IANA
The attributes of the repository object are listed below.
リポジトリ・オブジェクトの属性は以下の通りです。
repository key mandatory single query-address mandatory multiple response-auth-type mandatory multiple submit-address mandatory multiple submit-auth-type mandatory multiple repository-cert mandatory multiple expire mandatory single heartbeat-interval mandatory single descr optional multiple remarks optional multiple admin-c mandatory multiple tech-c mandatory multiple notify optional multiple mnt-by mandatory multiple changed mandatory multiple source mandatory single
リポジトリキー必須単一のクエリ・アドレス必須複数回答-AUTH型必須複数提出-アドレス必須複数提出-AUTH型必須複数のリポジトリ-CERT必須複数の必須単一のハートビート間隔の必須単一DESCRオプションの複数の発言を期限切れにオプションの複数の管理-C必須複数技術-C多重必須複数MNT-によって必須複数の通知オプションは、単一の必須の必須の複数のソースを変更しました
In the above object type only a small number of the attribute types are new. These are:
上記のオブジェクトタイプでは、属性タイプのほんの数が新しいです。これらは：
repository This attribute provides the name of the repository. This is the key field for the object and is single and must be globally unique. This is the same name used in the source attribute of all objects in that repository.
リポジトリこの属性は、リポジトリの名前を提供します。これは、オブジェクトのキーフィールドであり、単一で、グローバルに一意でなければなりません。これは、リポジトリ内のすべてのオブジェクトのソース属性で使用したのと同じ名前です。
query-address This attribute provides a url for directing queries. "rps-query" or "whois" can be used as the protocol identifier.
クエリ・アドレスこの属性は、クエリを指示するためのURLを提供します。 「RPS-クエリ」または「WHOIS」は、プロトコル識別子として使用することができます。
response-auth-type This attribute provides an authentication type that may be used by the repository when responding to user queries. Its syntax and semantics is same as the auth attribute of the maintainer class.
応答-AUTH-typeこの属性は、ユーザのクエリに応答するとき、リポジトリによって使用されることができる認証の種類を提供します。その構文と意味はメンテナクラスの認証属性と同じです。
submit-address This attribute provides a url for submitting objects to the repository.
提出-アドレスは、この属性は、リポジトリにオブジェクトを提出するためのURLを提供します。
submit-auth-type This attribute provides the authentication types that are allowed by the repository for users when submitting registrations.
提出-のauth-typeこの属性は、登録を提出する際、ユーザーのリポジトリで許可されている認証の種類を提供します。
repository-cert This attribute provides a reference to a public key certificate in the form of an RPSL key-cert object. This attribute can be multiple to allow the repository to use more than one method of signature.
この属性はRPSL鍵証明書オブジェクトの形式で公開鍵証明書への参照を提供するリポジトリCERT。この属性は、リポジトリは、署名の複数の方法を使用することを可能にするために、複数であってもよいです。
heartbeat-interval Heartbeat meta-objects are sent by this repository at the rate of one heartbeat meta-object per the interval indicated. The value of this attribute shall be expressed in the form "dddd hh:mm:ss", where the "dddd" represents days, "hh" represents hours, "mm" minutes and "ss" seconds.
ハートビート間隔ハートビートメタオブジェクトが示さ間隔ごとに心拍メタオブジェクトの速度でこのリポジトリによって送信されます。この属性の値は形で表現されなければならない「HHをDDDD：MM：SS」、「DDDD」は日を表し、「HH」時間、「ミリメートル」分と「SS」秒を表します。
expire If no heartbeat or new registrations are received from a repository for expire period, objects from this repository should be considered non-authoritative, and cannot be used for authorization purposes. The value of this attribute shall be expressed in the form "dddd hh:mm:ss", where the "dddd" represents days, "hh" represents hours, "mm" minutes and "ss" seconds. This value should be bigger than heartbeat-interval.
ハートビートまたは新規登録が期限切れになる期間のリポジトリから受信されない場合は有効期限が切れ、このリポジトリからオブジェクトを非権威と見なされるべきであり、認証目的のために使用することはできません。この属性の値は形で表現されなければならない「HHをDDDD：MM：SS」、「DDDD」は日を表し、「HH」時間、「ミリメートル」分と「SS」秒を表します。この値は、ハートビート間隔よりも大きくする必要があります。
Please note that the "heartbeat" meta-objects mentioned above, like other meta-objects described in this document are part of the protocol to exchange information but are not placed in the database itself. See Section 7.3.2 for a description of the heartbeat meta-object.
この文書に記載された他のメタオブジェクトのように、上述した「ハートビート」のメタオブジェクトは情報を交換するためのプロトコルの一部であるが、データベース自体に配置されていないことに注意してください。ハートビートメタオブジェクトの説明については、7.3.2項を参照してください。
The remaining attributes in the repository object are defined in RPSL.
リポジトリオブジェクトの残りの属性はRPSLで定義されています。
For many RPSL object types a particular entry should appear only in one repository. These are the object types for which there is a natural hierarchy, "as-block", "aut-num", "inetnum", and "route". In order to facilitate putting an object in another repository, a "delegated" attribute is added.
多くのRPSLオブジェクト型の場合、特定のエントリは、1つのリポジトリにのみ表示されます。これらは、天然の階層が存在するためのオブジェクト・タイプである「としてブロック」、「AUT-NUM」、「のinetnum」、および「ルート」。別のリポジトリ内のオブジェクトを置くことを容易にするために、「委任」属性が付加されます。
delegated The delegated attribute is allowed in any object type with a hierarchy. This attribute indicates that further searches for object in the hierarchy must be made in one or more alternate repositories. The current repository may be listed. The ability to list more than one repository serves only to accommodate grandfathered objects (those created prior to using an authorization model). The value of a delegated attribute is a list of repository names.
委任委任属性は、階層構造を持つ任意のオブジェクト型で許可されています。この属性は、階層内のオブジェクトのための更なる検索が1つ以上の代替リポジトリに行われなければならないことを示しています。現在のリポジトリを挙げることができます。複数のリポジトリをリストする能力のみ適用除外オブジェクト（事前許可モデルを使用して作成されたもの）を収容するのに役立ちます。委任属性の値は、リポジトリ名のリストです。
If an object contains a "delegated" attribute, an exact key field match of the object may also be contained in each repository listed in the "delegated" attribute. For the purpose of authorizing changes only the "mnt-by" in the object in the repository being modified is considered.
オブジェクトが「委任」属性が含まれている場合は、オブジェクトの正確なキー・フィールドの一致は、「委任」属性に記載されている各リポジトリに含まれていてもよいです。修飾されているリポジトリ内のオブジェクトの変化にのみ「MNTバイ」を許可する目的であると考えられます。
The following is an example of the use of a "delegated" attribute.
以下は、「委任」属性の使用例です。
inetnum: 193.0.0.0 - 193.0.0.255 delegated: RIPE ... source: IANA
inetnum：193.0.0.0 - 193.0.0.255委任：RIPE ...ソース：IANA
This inetnum simply delegates the storage of any more specific inetnum objects overlapping the stated range to the RIPE repository. An exact match of this inetnum may also exist in the RIPE repository to provide hooks for the attributes referencing maintainer objects. In this case, when adding objects to the RIPE repository, the "mnt-lower", "mnt-routes", and "mnt-by" fields in the IANA inetnum object will not be considered, instead the values in the RIPE copy will be used.
これのinetnumは単に委任RIPEリポジトリに記載された範囲と重なるそれ以上の特定のinetnumオブジェクトの格納。これのinetnumの正確な一致はまた、保守・オブジェクトを参照する属性のフックを提供するために、RIPEリポジトリ内に存在してもよいです。 RIPEリポジトリにオブジェクトを追加するとき、この場合、「MNT低級」、「MNT-ルート」、および「MNTバイ」のIANAのinetnumオブジェクト内のフィールドは、RIPEコピーの値がする代わりに、考慮されません利用される。
The "integrity" attribute can be contained in any RPSL object. It is intended solely as a means to facilitate a transition period during which some data has been moved from repositories prior to the use of a strong authorization model and is therefore questionable, or when some repositories are not properly checking authorization.
「整合性」属性は、RPSLオブジェクトに格納することができます。それは、単にいくつかのリポジトリが適切に許可をチェックしていないときに、いくつかのデータは、強力な認証モデルを使用する前に、リポジトリから移動し、したがって、疑問である、またはされた時の移行期間を容易にするための手段として意図されています。
The "integrity" attribute may have the values "legacy", "no-auth", "auth-failed", or "authorized". If absent, the integrity is considered to be "authorized". The integrity values have the following meanings:
「整合性」属性が値「レガシー」、「認証なし」、「認証に失敗した」、または「許可」を有していてもよいです。不在の場合は、整合性が「許可」していると考えられます。インテグリティ値は以下の意味があります。
legacy: This data existed prior to the use of an adequate authorization model. The data is highly suspect.
レガシー：このデータは、適切な許可モデルを使用する前に存在していました。データは非常に疑わしいです。
no-auth: This data was added to a repository during an initial transition use of an authorization model but authorization depended on other objects whose integrity was not "authorized". Such an addition is being allowed during the transition but would be disallowed later.
認証なし：このデータは、許可モデルの初期のトランジションの使用時にリポジトリに追加されなかったが、承認は、その整合性「認可」されなかった他のオブジェクトに依存していました。そのような添加は、遷移中に許可されているが、後で許可されるであろう。
auth-failed: The authoritative repository is not checking authorization. Had it been doing so, authorization would have failed. This attribute may be added by a repository that is mirroring before placing the object in its local storage, or can add this attribute to an encapsulating meta-object used to further propagate the transaction. If the failure to enforce authorization is intentional and part of a transition (for example, issuing warnings only), then the authoritative repository may add this attribute to the encapsulating meta-object used to further propagate the transaction.
auth-失敗しました：権威リポジトリは、許可をチェックされていません。認証が失敗しただろう、そうされていました。この属性は、そのローカルストレージにオブジェクトを配置する前にミラーリングされているリポジトリで添加してもよいし、さらにトランザクションを伝播するために使用されるカプセル化メタオブジェクトにこの属性を追加することができます。権限を適用する障害が意図的と（例えば、のみ警告を発する）遷移の一部である場合、権限のリポジトリはさらに、トランザクションを伝播するために使用されるカプセル化メタオブジェクトにこの属性を追加してもよいです。
authorized: Authorization checks were passed. The maintainer contained a "referral-by" attribute, a form of authentication deemed adequate by the repository was used, and all objects that were needed for authorization were objects whose integrity was "authorized".
認可：認可のチェックが渡されました。メンテナを使用した「紹介・バイ」属性は、認証のフォームがリポジトリで十分なものとみなさを含有し、承認のために必要とされたすべてのオブジェクトは、その整合性「許可」されたオブジェクトです。
Normally once an object is added to a repository another object cannot overwrite it unless authorized to do so by the maintainers referenced by the "mnt-by" attributes in the object itself. If the integrity attribute is anything but "authorized", an object can be overwritten or deleted by any transaction that would have been a properly authorized addition had the object of lesser integrity not existed.
通常、一度オブジェクトが他のオブジェクトがそれを上書きすることはできませんリポジトリに追加された「MNT-による」オブジェクト自身の属性によって参照メンテナによってそうする権限がない限り。整合性の属性は何もなく、「許可」である場合、オブジェクトは適切に承認さらには低い整合性のオブジェクトが存在していなかったされていたであろう任意のトランザクションによって上書きされたり削除することができます。
During such a transition grandfathered data and data added without proper authorization becomes advisory until a properly authorized addition occurs. After transition additions of this type would no longer be accepted. Those objects already added without proper authorization would remain but would be marked as candidates for replacement.
適切に許可添加が行われるまで適用除外データとデータが適切な許可なしに加え、このような遷移の間に顧問となります。移行後はこのタイプの追加はもはや受け入れられないであろう。すでに適切な承認なしに追加、それらのオブジェクトが残っているだろうが、代替の候補としてマークされるだろう。
6 Interactions with a Repository or Mirror
リポジトリまたはミラー6つの相互作用
This section presents an overview of the transaction distribution mechanisms. The detailed format of the meta-objects for encapsulating and distributing transactions, and the rules for processing meta-objects are described in Section 7. There are a few different types of interactions between routing repositories or mirrors.
このセクションでは、トランザクション分配メカニズムの概要を説明します。トランザクションをカプセル化し、配布するためのメタオブジェクト、およびメタオブジェクトを処理するためのルールの詳細なフォーマットは、ルーティングリポジトリまたはミラーとの間の相互作用のいくつかの異なるタイプがあり、セクション7に記載されています。
Initial submission of transactions: Transactions may include additions, changes, and deletions. A transaction may operate on more than one object and must be treated as an atomic operation. By definition initial submission of transactions is not applicable to a mirror. Initial submission of transactions is described in Section 6.1.
トランザクションの初期提出：トランザクションは、追加、変更、および削除を含むことができます。トランザクションは、複数のオブジェクト上で動作することができるとアトミックオペレーションとして扱われなければなりません。定義により、トランザクションの最初の提出は、ミラーには適用されません。取引の最初の提出は、セクション6.1に記載されています。
Redistribution of Transactions: The primary purpose of the interactions between registries is the redistribution of transactions. There are a number of ways to redistribute transactions. This is discussed in Section 6.2.
トランザクションの再配分：レジストリとの間の相互作用の主な目的は、トランザクションの再配分です。トランザクションを再配布するためにいくつかの方法があります。これは、6.2節で議論されます。
Queries: Query interactions are outside the scope of this document.
クエリ：クエリの相互作用が、この文書の範囲外です。
Transaction Commit and Confirmation: Repositories may optionally implement a commit protocol and a completion indication that gives the submitter of a transaction a response that indicates that a transaction has been successful and will not be lost by a crash of the local repository. A submitter may optionally request such a confirmation. This is discussed in Section 6.3.
トランザクションは、コミットと確認：リポジトリは、必要に応じてコミットプロトコルとトランザクションの提出者に取引が成功したとローカルリポジトリのクラッシュによって失われないことを示す応答を与える完了表示を実施することができます。提出者は、必要に応じて、確認を要求することができます。これは、6.3節で説明されています。
The simplest form of transaction submission is an object or set of objects submitted with RFC-822 email encapsulation. This form is still supported for backwards compatibility. A preferred form allows some meta-information to be included in the submission, such as a preferred form of confirmation. Where either encapsulation is used, the submitter will connect to a host and port specified in the repository object. This allows immediate confirmation. If an email interface similar to the interface provided by the existing RIPE code is desired, then an external program can provide the email interface.
トランザクションの提出の最も単純な形式は、RFC-822メールのカプセル化とともに提出オブジェクトまたはオブジェクトのセットです。このフォームはまだ後方互換性のためにサポートされています。好ましい形態は、このような確認の好ましい形態として、いくつかのメタ情報は、提出に含まれることを可能にします。いずれかのカプセル化が使用される場合には、提出者は、リポジトリ・オブジェクトに指定されたホストとポートに接続します。これは、即時に確認することができます。既存のRIPEコードによって提供されるインタフェースに似た電子メールインタフェースが所望される場合には、外部のプログラムは、電子メールインターフェースを提供することができます。
The encapsulation of a transaction submission and response is described in detail in Section 7.
トランザクションの提出や応答のカプセル化は、第7節で詳細に記載されています。
Redistribution of transactions can be accomplished using one of:
トランザクションの再配布は、のいずれかを使用して達成することができます。
1. A repository snapshot is a request for the complete contents of a given repository. This is usually done when starting up a new repository or mirror or when recovering from a disaster, such as a disk crash.
1.リポジトリスナップショットは、与えられたリポジトリの完全な内容のための要求です。新しいリポジトリやミラーの起動時や災害からの復旧時にこれは通常、そのようなディスククラッシュとして、行われます。
2. A transaction sequence exchange is a request for a specific set of transactions. Often the request is for the most recent sequence number known to a mirror to the last transactions. This is used in polling.
2.トランザクションシーケンス交換は、トランザクションの特定のセットの要求です。多くの場合、要求は最後の取引にミラーに知られている最新のシーケンス番号です。これは、ポーリングに使用されています。
This section describes the operations somewhat qualitatively. Data formats and state diagrams are provided in Section 7.
このセクションでは、やや定性的操作について説明します。データ形式と状態図はセクション7に設けられています。
If a submission requires a strong confirmation of completion, or if a higher degree of protection against false positive confirmation is desired as a matter of repository policy, a commit may be performed.
提出が完了の強力な確認が必要、または偽陽性の確認に対する保護のより高度がリポジトリ政策の問題として望まれる場合には、コミットした場合に実行することができます。
A commit request is a request from the repository processing an initial transaction submission to another repository to confirm that they have been able to advance the transaction sequence up to the sequence number immediately below the transaction in the request and are willing to accept the transaction in the request as a further advance in the sequence. This indicates that either the authorization was rechecked by the responding repository and passed or that the responding repository trusts the requesting repository and has accepted the transaction.
コミット要求は、他のリポジトリへの最初のトランザクションの提出を処理するリポジトリからの要求が、彼らはすぐに要求トランザクション以下のシーケンス番号にトランザクションシーケンスを進めることができたとトランザクションを受け入れて喜んでいることを確認することですシーケンスのさらなる進歩として要求。これは、許可のいずれかが応答リポジトリで再チェックし、渡されたか、応答リポジトリが要求するリポジトリを信頼し、そのトランザクションを受け入れたことを示しました。
A commit request can be sent to more than one alternate repository. One commit completion response is sufficient to respond to the submitter with a positive confirmation that the transaction has been completed. However, the repository or submitter may optionally require more than one.
コミット要求は、複数の代替リポジトリに送信することができます。一つは、完了応答をコミットトランザクションが完了している正の確認と提出者への対応に十分です。しかし、リポジトリまたは提出者は、必要に応じて複数を必要とするかもしれません。
7 Data Format Summaries, Transaction Encapsulation and Processing
7つのデータフォーマットの概要、トランザクションのカプセル化と処理
RIPE-181 [2] and RPSL [1] data is represented externally as ASCII text. Objects consist of a set of attributes. Attributes are name/value pairs. A single attribute is represented as a single line with the name followed by a colon followed by whitespace characters (space, tab, or line continuation) and followed by the value. Within a value all consecutive whitespace characters is equivalent to a single space. Line continuation is supported by putting a white space or '+' character to the beginning of the continuation lines. An object is externally represented as a sequence of attributes. Objects are separated by blank lines.
RIPE-181 [2]、RPSL [1]のデータは、ASCIIテキストとして外部に表されています。オブジェクトは、属性のセットで構成されています。属性は、名前/値のペアです。単一の属性は、空白文字（スペース、タブ、または行の継続）、続いて、その値が続くコロンが続く名前を持つ単一の線として表されています。値内のすべての連続した空白文字は単一のスペースに相当します。行の継続は、継続行の先頭に空白や「+」文字を置くことによってサポートされています。オブジェクトは、外部からの属性の列で表現されます。オブジェクトは空行で区切られています。
Protocol interactions between registries are activated by passing "meta objects". Meta objects are not part of RPSL but conform to RPSL object representation. They serve mostly as delimiters to the protocol messages or to carry the request for an operation.
登録簿間のプロトコルの相互作用は、「メタオブジェクト」を渡すことによって活性化されます。メタオブジェクトは、RPSLの一部ではないが、RPSLオブジェクト表現に準拠しています。彼らは主にプロトコルメッセージに区切り文字として、あるいは動作の要求を運ぶのに役立ちます。
The de-facto method for submitting database changes has been via email. This method should be supported by an external application. Merit has added the pgp-from authentication method to the RADB (replaced by "pgpkey" in [4]), where the mail headers are essentially ignored and the body of the mail message must be PGP signed.
データベースの変更を提出するための事実上の方法は、電子メールを介してきました。このメソッドは、外部アプリケーションによってサポートされる必要があります。メリットは、メールヘッダは、本質的に無視され、メールメッセージの本文は、PGPを締結しなければならない（[4]に「pgpkey」に置き換え）RADBにPGP-から認証方法を追加しました。
This specification defines a different encapsulation for transaction submission. When submitting a group of objects to a repository, a user MUST append to that group of objects, exactly one "timestamp" and one or more "signature" meta-objects, in that order.
この仕様は、トランザクションの提出のためのさまざまなカプセル化を定義します。リポジトリへのオブジェクトのグループを送信する場合、ユーザは、この順序で、オブジェクトのグループ、正確に一つの「タイムスタンプ」と1つ以上の「署名」メタオブジェクトに追加しなければなりません。
The "timestamp" meta-object contains a single attribute:
「タイムスタンプ」メタオブジェクトは、単一の属性が含まれています。
timestamp This attribute is mandatory and single-valued. This attribute specifies the time at which the user submits the transaction to the repository. The format of this attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four digit year, "MM" represents the month, "DD" the date, "hh" the hour, "mm" the minutes, "ss" the seconds of the timestamp, and "xx" and "yy" represents the hours and minutes respectively that that timestamp is ahead or behind UTC.
タイムスタンプこの属性は必須と単一値です。この属性は、ユーザーがリポジトリにトランザクションを送信する時刻を指定します。この属性の形式は "YYYYMMDD hh：mm：ssを[+/-] XX：YY" である "YYYY" は4桁の年を指定し、 "MM" は、月の日付を "DD" を表し、 "HH"時間、「ミリメートル」分、「SS」のタイムスタンプの秒、および「XX」と「YY」は、そのタイムスタンプが先か、UTCの後ろにあることを、それぞれ時間と分を表します。
A repository may reject a transaction which does not include the "timestamp" meta-object. The timestamp object is used to prevent replaying registrations. How this is actually used is a local matter. For example, a repository can accept a transaction only if the value of the timestamp attribute is greater than the timestamp attribute in the previous registration received from this user (maintainer), or the repository may only accept transactions with timestamps within its expire window.
リポジトリは、「タイムスタンプ」メタオブジェクトが含まれていないトランザクションを拒否することができます。タイムスタンプオブジェクトは、再生登録を防ぐために使用されます。これは、実際に使用されてどのようにローカルの問題です。タイムスタンプ属性の値がこのユーザ（保守）から受信した以前の登録のタイムスタンプ属性よりも大きい場合にのみ、たとえば、リポジトリは、トランザクションを受け入れることができ、またはリポジトリは、その期限切れウィンドウ内のタイムスタンプとのトランザクションを受け入れることができます。
Each "signature" meta-object contains a single attribute:
各「署名」メタオブジェクトは、単一の属性が含まれています。
signature This attribute is mandatory and single-valued. This attribute, a block of free text, contains the signature corresponding to the authentication method used for the transaction. When the authentication method is a cryptographic hash (as in PGP-based authentication), the signature must include all text up to (but not including) the last blank line before the first "signature" meta-object.
署名この属性は必須と単一値です。この属性は、フリーテキストのブロックは、トランザクションのために使用する認証方式に対応する署名が含まれています。認証方式は、暗号ハッシュ（PGPベースの認証のように）である場合、署名は最初の「署名」メタオブジェクトの前の最後の空白行を（しかし含まない）までのすべてのテキストを含める必要があります。
A repository must reject a transaction that does not include any "signature" meta-object.
リポジトリは任意の「署名」メタオブジェクトが含まれていないトランザクションを拒否しなければなりません。
The group of objects submitted by the user, together with the "timestamp" and "signature" meta-objects, constitute the "submitted text" of the transaction.
一緒に「タイムスタンプ」と「署名」のメタオブジェクトと、ユーザによって提出されたオブジェクトのグループは、トランザクションの「送信されたテキスト」を構成します。
The protocol used for submitting a transaction, and for receiving confirmation of locally committed transactions, is not specified in this document. This protocol may define additional encapsulations around the submitted text. The rest of this section gives an example of one such protocol. Implementations are free to choose another encapsulation.
トランザクションを提出するため、ローカルにコミットされたトランザクションの確認を受信するために使用されるプロトコルは、この文書で指定されていません。このプロトコルは、送信されたテキストの周りに追加のカプセル化を定義することができます。このセクションの残りの部分は、そのようなプロトコルの例を示します。実装は、別のカプセル化を自由に選択できます。
The meta-objects "transaction-submit-begin" and "transaction-submit-end" delimit a transaction. A transaction is handled as an atomic operation. If any part of the transaction fails none of the changes take effect. For this reason a transaction can only operate on a single database.
メタオブジェクト「取引提出-始まり」と「取引提出エンドは、」トランザクションを区切ります。トランザクションは、アトミックオペレーションとして扱われます。トランザクションの一部が失敗した場合は、変更のどれも有効になりません。このため、取引は、単一のデータベースを操作することができます。
A socket connection is used to request queries or submit transactions. An email interface may be provided by an external program that connects to the socket. A socket connection must use the "transaction-submit-begin" and "transaction-submit-end" delimiters but can request a legacy style confirmation. Multiple transactions may be sent prior to the response for any single transaction. Transactions may not complete in the order sent.
ソケット接続は、クエリを要求したり、トランザクションを提出するために使用されます。電子メールインタフェースはソケットに接続する外部プログラムによって提供されてもよいです。ソケット接続は、「トランザクション・提出始まり」と「取引提出エンド」区切り文字を使用する必要がありますが、従来のスタイルの確認を要求することができます。複数のトランザクションは、前の任意の単一のトランザクションのレスポンスに送信することができます。トランザクションが送ら順に完了しない場合があります。
The "transaction-submit-begin" meta-object may contain the following attributes.
「取引提出-始める」メタオブジェクトは以下の属性が含まれていてもよいです。
transaction-submit-begin This attribute is mandatory and single. The value of the attribute contains name of the database and an identifier that must be unique over the course of the socket connection.
この属性は必須と単一のトランザクションが提出-始めます。属性の値は、データベースの名前とソケット接続にわたって一意である必要があり識別子が含まれています。
response-auth-type This attribute is optional and multiple. The remainder of the line specifies an authentication type that would be acceptable in the response. This is used to request a response cryptographically signed by the repository.
応答のauth-typeこの属性はオプションと複数のです。行の残りは応答で許容されるであろう認証タイプを指定します。これは、暗号リポジトリによって署名された応答を要求するために使用されます。
transaction-confirm-type This attribute is optional and single. A confirmation type keyword must be provided. Keywords are "none", "legacy", "normal", "commit". The confirmation type can be followed by the option "verbose".
トランザクション・確認型は、この属性はオプションであり、単一です。確認タイプのキーワードが提供されなければなりません。キーワードは、「通常」、「コミット」、「なし」、「レガシー」です。確認のタイプは「冗長」オプションを続けることができます。
The "transaction-submit-end meta-object consists of a single attribute by the same name. It must contain the same database name and identifier as the corresponding "transaction-submit-begin" attribute.
「取引提出エンドのメタオブジェクトは、同じ名前の単一の属性で構成されています。それは、対応するのと同じデータベース名と識別子を含まなければならない 『』取引提出-begin属性。
Unless the confirmation type is "none" a confirmation is sent. If the confirmation type is "legacy", then an email message of the form currently sent by the RIPE database code will be returned on the socket (suitable for submission to the sendmail program).
確認タイプが「なし」ではありませんない限り確認が送信されます。確認タイプが「レガシー」であれば、現在RIPEデータベース・コードによって送信されたフォームの電子メールメッセージは、（sendmailプログラムへの提出に適している）のソケットに返されます。
A "normal" confirmation does not require completion of the commit protocol. A "commit" confirmation does. A "verbose" confirmation may contain additional detail.
「通常」の確認がコミットプロトコルの完了を必要としません。 「コミット」の確認はありません。 「冗長」の確認は、追加の詳細が含まれていてもよいです。
A transaction confirmation is returned as a "transaction-confirm" meta-object. The "transaction-confirm" meta-object may have the following attributes.
取引確認は、「トランザクション確認」メタオブジェクトとして返されます。 「トランザクション確認」メタオブジェクトには、以下の属性を有することができます。
transaction-confirm This attribute is mandatory and single. It contains the database name and identifier associated with the transaction.
この属性は必須とシングルで取引を確認してください。これは、トランザクションに関連付けられているデータベース名と識別子が含まれています。
confirmed-operation This attribute is optional and multiple. It contains one of the keywords "add", "delete" or "modify" followed by the object type and key fields of the object operated on.
確認操作この属性はオプションと複数のです。これは、上の操作オブジェクト型とオブジェクトのキーフィールドに続いて、「追加」「削除」または「変更」のキーワードのいずれかが含まれています。
commit-status This attribute is mandatory and single. It contains one of the keywords "succeeded, "error", or "held". The "error" keyword may be followed by an optional text string. The "held" keyword is returned when a repository containing a dependent object for authorization has expired.
コミット・ステータスをこの属性は必須とシングルです。これは、キーワードのいずれかを含むエラー 『のキーワードオプションのテキスト文字列が続くことができる。『『』エラー「は、成功しました 『』、または』開催された承認のための依存オブジェクトを含むリポジトリの有効期限が切れた時に開催された』キーワードが返されます。
In order to redistribute transactions, each repository maintains a TCP connection with one or more other repositories. After locally committing a submitted transaction, a repository assigns a sequence number to the transaction, signs and encapsulates the transaction, and then sends one copy to each neighboring (or "peer") repository. In turn, each repository authenticates the transaction (as described in Section 7.6), may re-sign the transaction and redistributes the transaction to its neighbors. We use the term "originating repository" to distinguish the repository that redistributes a locally submitted transaction.
トランザクションを再配布するために、各リポジトリは、一つ以上の他のリポジトリとのTCP接続を維持します。ローカル送信トランザクションをコミットした後、リポジトリは、トランザクションにシーケンス番号を割り当て徴候およびトランザクションをカプセル化し、各隣接（または「ピア」）リポジトリ1つのコピーを送信します。順番に、各リポジトリは（セクション7.6で説明したように）トランザクションを再署名することができる、トランザクションを認証し、その近傍にトランザクションを再分配します。私たちは、ローカルに提出されたトランザクションを再配布するリポジトリを区別するために、用語「元のリポジトリ」を使用します。
This document also specifies two other methods for redistributing transactions to other repositories: a database snapshot format used for initializing a new registry, and a polling technique used by mirrors.
新しいレジストリを初期化するために使用されるデータベーススナップショット形式、およびミラーが使用するポーリング方式：この文書は、他の2つの他のリポジトリへのトランザクションを再配布するための方法を指定します。
In this section, we first describe how a repository may encapsulate the submitted text of a transaction. We then describe the protocol for flooding transactions or polling for transactions, and the database snapshot contents and format.
このセクションでは、まず、リポジトリは、トランザクションの送信されたテキストをカプセル化する方法について説明します。私たちは、その後の取引のための氾濫取引またはポーリングのためのプロトコル、およびデータベーススナップショットの内容と形式について説明します。
The originating repository must first authenticate a submitted transaction using methods described in [3].
発信リポジトリは、最初の[3]に記載の方法を使用して送信トランザクションを認証しなければなりません。
Before redistributing a transaction, the originating repository must encapsulate the submitted text of the transaction with several meta-objects, which are described below.
トランザクションを再配布する前に、元のリポジトリは、以下に記載されているいくつかのメタオブジェクトとトランザクションの送信されたテキストをカプセル化しなければなりません。
The originating repository must prepend the submitted text with exactly one "transaction-label" meta-object. This meta-object contains the following attributes:
元のリポジトリは、1つの「トランザクション・ラベル」メタオブジェクトに送信されたテキストを付加する必要があります。このメタオブジェクトは、次の属性が含まれます。
transaction-label This attribute is mandatory and single. The value of this attribute conforms to the syntax of an RPSL word, and represents a globally unique identifier for the database to which this transaction is added.
トランザクション・ラベルは、この属性は必須とシングルです。この属性の値は、RPSLワードの構文に準拠しており、このトランザクションが付加されたデータベースのグローバル一意識別子を表します。
sequence This attribute is mandatory and single. The value of this attribute is an RPSL integer specifying the sequence number assigned by the originating repository to the transaction. Successive transactions distributed by the same originating repository have successive sequence numbers. The first transaction originated by a registry is assigned a sequence number 1. Each repository must use sequence numbers drawn from a range at least as large as 64 bit unsigned integers.
シーケンスこの属性は必須とシングルです。この属性の値はトランザクションに発信リポジトリによって割り当てられたシーケンス番号を指定するRPSL整数です。同じ発信元リポジトリで配布歴代トランザクションは、連続したシーケンス番号を持っています。レジストリによって発信最初のトランザクションは、各リポジトリは64ビット符号なし整数と少なくとも同じ大きさの範囲から引き出されたシーケンス番号を使用する必要が配列番号1が割り当てられます。
timestamp This attribute is mandatory and single-valued. This attribute specifies the time at which the originating repository encapsulates the submitted text. The format of this attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four digit year, "MM" represents the month, "DD" the date, "hh" the hour, "mm" the minutes, "ss" the seconds of the timestamp, and "xx" and "yy" represents the hours and minutes respectively that that timestamp is ahead or behind UTC.
タイムスタンプこの属性は必須と単一値です。この属性は、元のリポジトリが送信されたテキストをカプセル化した時刻を指定します。この属性の形式は "YYYYMMDD hh：mm：ssを[+/-] XX：YY" である "YYYY" は4桁の年を指定し、 "MM" は、月の日付を "DD" を表し、 "HH"時間、「ミリメートル」分、「SS」のタイムスタンプの秒、および「XX」と「YY」は、そのタイムスタンプが先か、UTCの後ろにあることを、それぞれ時間と分を表します。
integrity This attribute is optional and single-valued. It may have the values "legacy", "no-auth", "auth-failed", or "authorized". If absent, the integrity is considered to be "authorized".
整合性この属性はオプションであり、単一値です。これは、値が「レガシー」、「認証なし」、「認証に失敗した」、または「許可」を有していてもよいです。不在の場合は、整合性が「許可」していると考えられます。
The originating repository may append to the submitted text one or more "auth-dependency" meta-objects. These meta-objects are used to indicate which other repositories' objects were used by the originating registry to authenticate the submitted text. The "auth-dependency" meta-objects should be ordered from the most preferred repository to the least preferred repository. This order is used by a remote repository to tie break between the multiple registrations of an object with the same level of integrity. The "auth-dependency" meta-object contains the following attributes:
元のリポジトリには、提出されたテキスト、1つまたは複数の「AUTH-依存」メタオブジェクトに追加することがあります。これらのメタオブジェクトが送信されたテキストを認証するために元のレジストリによって使用された他のリポジトリのオブジェクトを示すために使用されています。 「AUTH-依存」メタオブジェクトは、少なくとも優先リポジトリに最も優先リポジトリから注文する必要があります。この順序は、完全性の同じレベルを持つオブジェクトの複数の登録の間に休憩を結ぶためにリモートリポジトリによって使用されます。 「AUTH-依存」メタオブジェクトは、次の属性が含まれます。
auth-dependency This attribute mandatory and single-valued. It equals a repository name from which an object is used to authorize/authenticate this transaction.
auth-依存この属性は必須と単一値。これは、オブジェクトがこのトランザクションを認証/許可するために使用されたリポジトリ名に等しいです。
sequence This attribute mandatory and single-valued. It equals the transaction sequence number of the dependent repository known at the originating repository at the time of processing this transaction.
シーケンスこの属性は必須と単一値。これは、このトランザクションを処理する時に元のリポジトリで知ら依存リポジトリのトランザクションシーケンス番号に等しいです。
timestamp This attribute mandatory and single-valued. It equals the timestamp of the dependent repository known at the originating repository at the time of processing this transaction.
これは必須と単一値の属性タイムスタンプ。これは、このトランザクションを処理する時に元のリポジトリで知ら依存リポジトリのタイムスタンプに等しいです。
If the originating repository needs to modify submitted objects in a way that the remote repositories can not re-create, it can append an "override-objects" meta-object followed by the modified versions of these objects. An example modification can be auto assignment of NIC handles. The "override-objects" meta-object contains the following attributes:
元のリポジトリがリモートリポジトリを再作成することができないような方法で提出されたオブジェクトを変更する必要がある場合は、これらのオブジェクトの変更されたバージョンに続いて「上書き-オブジェクトを」メタオブジェクトを追加することができます。例えば、修飾はNICハンドルの自動割り当てすることができます。 「上書き-オブジェクトを」メタオブジェクトは、次の属性が含まれます。
override-objects A free text remark.
フリーテキスト注釈をオーバーライドは、オブジェクト。
Other repositories may or may not honor override requests, or limit the kinds of overrides they allow.
他のリポジトリには、またはオーバーライド要求を尊重、またはそれらが許可オーバーライドの種類を限定しない場合があります。
Following this, the originating repository must append exactly one "repository-signature" meta-object. The "repository-signature" meta-object contains the following attributes:
これに続いて、元のリポジトリは、1つの「リポジトリ・シグネチャー」メタオブジェクトを追加する必要があります。 「リポジトリ・シグネチャは、」メタオブジェクトは、次の属性が含まれます。
repository-signature This attribute is mandatory and single-valued. It contains the name of the repository.
リポジトリ署名は、この属性は必須と単一値です。これは、リポジトリの名前が含まれています。
integrity This attribute is optional and single-valued. It may have the values "legacy", "no-auth", "auth-failed", or "authorized". If absent, the value is same as the value in the transaction-label. If a different value is used, the value here takes precedence.
整合性この属性はオプションであり、単一値です。これは、値が「レガシー」、「認証なし」、「認証に失敗した」、または「許可」を有していてもよいです。不在の場合は、値は、トランザクション・ラベルの値と同じです。別の値が使用されている場合、ここでの値が優先されます。
signature This attribute is optional and single-valued. This attribute, a block of free text, contains the repository's signature using the key in the repository-cert attribute of the repository object. When the authentication method is a cryptographic hash (as in PGP-based authentication), the signature must include all text upto (but not including) this attribute. That is, the "repository-signature" and "integrity" attributes of this object are included. This attribute is optional since cryptographic authentication may not be available everywhere. However, its use where it is available is highly recommended.
署名この属性はオプションであり、単一値です。この属性は、フリーテキストのブロックは、リポジトリ・オブジェクトのリポジトリ-CERT属性でキーを使用してリポジトリの署名が含まれています。認証方法は、（PGPベースの認証のように）暗号ハッシュである場合、署名は、すべてのテキスト点で最大（しかし含まない）、この属性を含まなければなりません。それは、「リポジトリの署名」であり、このオブジェクトの「整合性」属性が含まれています。暗号認証がどこでも利用できない場合がありますので、この属性はオプションです。しかし、それが利用可能である、その使用を強くお勧めします。
A repository must reject a redistributed transaction that does not include any "repository-signature" meta-object.
リポジトリは、任意の「リポジトリの署名」メタオブジェクトが含まれていない再配布トランザクションを拒否しなければなりません。
The transaction-label, the submitted text, the dependency objects, the override-objects, the overridden objects, and the repository's signature together constitute what we call the "redistributed text".
トランザクション・ラベル、送信されたテキスト、依存オブジェクト、オーバーライド・オブジェクト、オーバーライドされたオブジェクト、およびリポジトリの署名が一緒に私たちは「再配布テキスト」と呼んでいるものを構成します。
In preparation for redistributing the transaction to other repositories, the originating repository must perform the following protocol encapsulation. This protocol encapsulation may involve transforming the redistributed text according to one of the "transfer-method"s described below.
他のリポジトリへのトランザクションを再配布するための準備として、元のリポジトリは、以下のプロトコルカプセル化を実行する必要があります。このプロトコルカプセル化は、後述する「転写法」Sのいずれかに記載の再配布されたテキストを変換することを含むことができます。
The transformed redistributed text is first prepended with exactly one "transaction-begin" meta-object. One newline character separates this meta-object from the redistributed text. This meta-object has the following attributes:
変換再配布テキストは最初正確に一つの「トランザクション開始」メタオブジェクトに付加されます。一つの改行文字は、再配布のテキストから、このメタオブジェクトを分離します。このメタオブジェクトは、次の属性があります。
transaction-begin This attribute is mandatory and single. The value of this attribute is the length, in bytes, of the transformed redistributed text.
この属性は必須とシングルで取引を開始。この属性の値は、形質転換された再配布テキストのバイト単位の長さです。
transfer-method This attribute is optional and single-valued. Its value is either "gzip", or "plain". The value of the attribute describes the kind of text encoding that the repository has performed on the redistributed text. If this attribute is not specified, its value is assumed to be "plain". An implementation must be capable of encoding and decoding both of these types.
転送方法は、この属性はオプションであり、単一値です。その値は「GZIP」、または「プレーン」のいずれかです。属性の値は、リポジトリを再配布テキスト上で実行しているテキストエンコーディングの種類を記述する。この属性が指定されていない場合、その値は「プレーン」とします。実装は、符号化し、これらのタイプの両方を復号化することができなければなりません。
The "transaction-begin" meta-object and the transformed redistributed text constitute what we call the "transmitted text". The originating repository may distribute the transmitted text to one or more peer repositories.
「トランザクション開始」メタオブジェクトと変換再配布テキスト私たちは、「送信テキスト」と呼んでいるものを構成します。発信リポジトリは、一つ以上のピア・リポジトリに送信テキストを配布することができます。
When a repository receives the transmitted text of a transaction, it must perform the following steps. After performing the following steps, a transaction may be marked successful or failed.
リポジトリは、トランザクションの送信テキストを受信すると、次のステップを実行する必要があります。次の手順を実行した後、トランザクションが成功したか失敗したとマークすることができます。
1. It must decapsulate the "transaction-begin" meta-object, then decode the original redistributed text according to the value of the transfer-method attribute specified in the "transaction-begin" meta-object.
1.それは、その後、「トランザクション開始」メタオブジェクトに指定された転送-method属性の値に応じて、元の再配布のテキストをデコードし、「トランザクション開始」メタオブジェクトをデカプセル化しなければなりません。
2. It should then extract the "transaction-label" meta-object from the transmitted text. If this transaction has already been processed, or is currently being held, the repository must silently discard this incarnation of the same transaction.
2.次に、送信テキストから、「トランザクション・ラベル」メタオブジェクトを抽出しなければなりません。この取引はすでに処理された、または現在開催されている場合は、リポジトリは黙っ同じトランザクションのこの化身を破棄しなければなりません。
3. It should verify that the signature of the originating repository matches the first "repository-signature" meta-object in the redistributed text following the "auth-dependency" meta-objects.
3.それは、発信リポジトリの署名が「認証依存」メタオブジェクト以下の再配布のテキストで最初の「リポジトリ署名」メタオブジェクトと一致することを確認しなければなりません。
4. If not all previous (i.e., those with a lower sequence number) transactions from the same repository have been received or completely processed, the repository must "hold" this transaction.
4.同じリポジトリからすべての（低いシーケンス番号を有する、すなわち、これらの）以前のトランザクションが受信または完全に処理されていない場合、リポジトリはこのトランザクションを「保持」しなければなりません。
5. It may check whether any subsequent "repository-signature" meta-objects were appended by a trusted repository. If so, this indicates that the trusted repository verified the transaction's integrity and marked its conclusion in the integrity attribute of this object. The repository may verify the trusted repositories signature and also mark the transaction with the same integrity, and skip the remaining steps.
5.これは、後続の「リポジトリ署名」メタオブジェクトが信頼リポジトリによって添付されたかどうかをチェックすることができます。もしそうなら、これは、信頼できるリポジトリが、トランザクションの整合性を検証し、このオブジェクトの整合性属性にその結論をマークしていることを示しています。リポジトリは、信頼できるリポジトリの署名を検証しても同じ整合性とトランザクションをマークし、残りのステップをスキップすることができます。
6. It should verify the syntactic correctness of the transaction. An implementation may allow configurable levels of syntactic conformance with RPSL [1]. This enables RPSL extensions to be incrementally deployed in the distributed registry scheme.
6.これは、トランザクションの構文の正しさを確認する必要があります。実装は、[1] RPSLと構文準拠の設定レベルを可能にすることができます。これは、インクリメンタルに分散レジストリ方式で展開されるようにRPSL拡張を可能にします。
7. The repository must authorize and authenticate this transaction. To do this, it may need to reference objects and transactions from other repositories. If these objects are not available, the repository must "hold" this transaction as described in Section 7.6, until it can be authorized and authenticated later. In order to verify authorization/authentication of this transaction, the repository must not use an object from a repository not mentioned in an "auth-dependency" meta-object. The repository should also only use the latest objects (by rolling back to earlier versions if necessary) which are within the transaction sequence numbers of the "auth-dependency" meta-objects.
7.リポジトリはこの取引を承認し、認証する必要があります。これを行うには、それは他のリポジトリからのオブジェクトとトランザクションを参照する必要があります。これらのオブジェクトが使用できない場合は、セクション7.6で説明したように、それが承認され、後に認証されることができるまで、リポジトリは、このトランザクションを「ホールド」しなければなりません。この取引の承認/認証を検証するために、リポジトリは「AUTH-依存」メタオブジェクトに記載されていないリポジトリからオブジェクトを使用してはいけません。リポジトリはまた、唯一の「AUTH-依存」メタオブジェクトのトランザクションシーケンス番号の範囲内にある（以前のバージョン、必要に応じてにロールバックすることで）、最新のオブジェクトを使用する必要があります。
A non-originating repository must redistribute a failed transaction in order not to cause a gap in the sequence. (If the transaction was to fail at the originating registry, it would simply not be assigned a sequence number).
非発信元リポジトリは、シーケンスにギャップが生じないために、失敗したトランザクションを再配布する必要があります。 （トランザクションが元のレジストリに失敗した場合、それは単にシーケンス番号を割り当てられません）。
To the redistributed text of a transaction, a repository may append another "repository-signature" meta-object. This indicates that the repository has verified the transaction's integrity and marked it in the "integrity" attribute of this object. The signature covers the new redistributed text from (and including) the transaction-label object to this object's signature attribute (including the "repository-signature" and "integrity" attributes of this object, but excluding the "signature" attribute). The original redistributed text, together with the new "repository-signature" meta-object constitutes the modified redistributed text.
トランザクションの再配布テキストに、リポジトリは別の「リポジトリ・シグネチャー」メタオブジェクトを追加することがあります。これは、リポジトリは、トランザクションの整合性を検証し、このオブジェクトの「整合性」属性でそれをマークしたことを示しています。署名は、このオブジェクトの署名属性にトランザクションラベルオブジェクト（および含む）（「リポジトリの署名」と、このオブジェクトの「整合性」属性を含むのが、「署名」属性を除く）からの新しい再配布のテキストをカバーしています。一緒に新しい「リポジトリ署名」メタオブジェクトと元の再配分のテキストは、修飾された再配布のテキストを構成します。
To redistribute a successful or failed transaction, the repository must encapsulate the (original or modified) redistributed text with a "transaction-begin" object. This step is essentially the same as that performed by the originating repository (except that the repository is free to use a different "transfer-method" from the one that was in the received transaction.
成功または失敗したトランザクションを再配布するには、リポジトリは、「トランザクション開始」オブジェクトと（オリジナルまたは修正）再配布のテキストをカプセル化しなければなりません。このステップは、本質的にリポジトリが受信したトランザクションであったものから異なる「転写法」を使用して自由であることを除いて、元のリポジトリ（によって行われるものと同じです。
A repository may also explicitly request one or more transactions belonging to a specified originating repository. This is useful for catching up after a repository has been off-line for a period of time. It is also useful for mirrors which intermittently poll a repository for recently received transactions.
リポジトリはまた、明示的に指定された元のリポジトリに属する1つの以上のトランザクションを要求することができます。これは、リポジトリは、しばらくの間オフラインされた後に追いつくために有用です。また、断続的に最近受信したトランザクションのためのリポジトリをポーリングミラーするのに便利です。
To request a range of transactions from a peer, a repository must send a "transaction-request" meta-object to the peer. A "transaction-request" meta-object may contain the following attributes:
ピアからの取引の範囲を要求するには、リポジトリはピアに、「トランザクション・リクエスト」メタオブジェクトを送信する必要があります。 「トランザクション・リクエスト」メタオブジェクトは以下の属性が含まれている場合があります。
transaction-request This attribute is mandatory and single. It contains the name of the database whose transactions are being requested.
トランザクション要求は、この属性は必須とシングルです。これは、トランザクション要求されているデータベースの名前が含まれています。
sequence-begin This attribute is optional and single. It contains the sequence number of the first transaction being requested.
この属性はオプションで、単一である配列始めます。これは、要求されている最初のトランザクションのシーケンス番号が含まれています。
sequence-end This attribute is optional and single. It contains the sequence number of the last transaction being requested.
シーケンスエンドは、この属性はオプションであり、単一です。これは、要求された最後のトランザクションのシーケンス番号が含まれています。
Upon receiving a "transaction-request" object, a repository performs the following actions. If the "sequence-begin" attribute is not specified, the repository assumes the request first sequence number to be 1. The last sequence number is the lesser of the value of the "sequence-end" attributed and the highest completed transaction in the corresponding database. The repository then, in order, transmits the requested range of transactions. Each transaction is prepared exactly according to the rules for redistribution specified in Section 7.3.
「トランザクション要求」オブジェクトを受け取ると、リポジトリは次のアクションを実行します。 「配列始まる」属性が指定されていない場合は、リポジトリは、要求最初のシーケンス番号は1最後のシーケンス番号が対応で帰さ「シーケンスエンド」の値の小さい方と最高完了したトランザクションであることを前提としていデータベース。リポジトリはその後、順番に、トランザクションの要求された範囲を送信します。各トランザクションは、7.3節で指定された再分配のためのルールに従って正確に準備されます。
After transmitting all the transactions, the peer repository must send a "transaction-response" meta-object. This meta-object has the following attributes:
すべてのトランザクションを送信した後、ピア・リポジトリは、「トランザクション応答」メタオブジェクトを送信する必要があります。このメタオブジェクトは、次の属性があります。
transaction-response This attribute is mandatory and single. It contains the name of the database whose transactions are were requested.
トランザクション応答は、この属性は必須とシングルです。これは、トランザクション要求されたされているデータベースの名前が含まれています。
sequence-begin This attribute is optional and mandatory. It contains the value of the "sequence-begin" attribute in the original request. It is omitted if the corresponding attribute was not specified in the original request.
この属性はオプションで、必須である配列始めます。これは、元の要求で「配列始まる」属性の値が含まれています。対応する属性は、元の要求に指定されていなかったかどうかは省略されています。
sequence-end This attribute is optional and mandatory. It contains the value of the "sequence-end" attribute in the original request. It is omitted if the corresponding attribute was not specified in the original request.
シーケンスエンドは、この属性はオプションであり、必須です。これは、元の要求で「シーケンスエンド」属性の値が含まれています。対応する属性は、元の要求に指定されていなかったかどうかは省略されています。
After receiving a "transaction-response" meta-object, a repository may tear down the TCP connection to its peer. This is useful for mirrors that intermittently resynchronize transactions with a repository. If the TCP connection stays open, repositories exchange subsequent transactions according to the redistribution mechanism specified in Section 7.3. While a repository is responding to a transaction-request, it MAY forward heartbeats and other transactions from the requested repository towards the requestor.
「トランザクション応答」メタオブジェクトを受け取った後、リポジトリはそのピアへのTCP接続を切断します。これは断続的にリポジトリとの取引を再同期ミラーに便利です。 TCP接続が開いたままにした場合、リポジトリは、7.3節で指定された再配分メカニズムに応じて、後続のトランザクションを交換します。リポジトリは、トランザクション要求に応答しているが、それは要求者に向けて要求されたリポジトリからのハートビートやその他の取引を転送することができます。
Each repository that has originated at least one transaction must periodically send a "heartbeat" meta-object. The interval between two successive transmissions of this meta-object is configurable but must be less than 1 day. This meta-object serves to indicate the liveness of a particular repository. The repository liveness determines how long transactions are held (See Section 7.6).
少なくとも一つのトランザクションを発信した各リポジトリには、定期的に「ハートビート」メタオブジェクトを送信する必要があります。このメタオブジェクトの2つの連続送信間隔は設定可能ですが、1日未満でなければなりません。このメタオブジェクトは、特定のリポジトリの生存性を示すのに役立ちます。リポジトリの生存性は、長いトランザクションが（7.6節を参照）に保持されている方法を決定します。
The "heartbeat" meta-object contains the following attributes:
「ハートビート」のメタオブジェクトには、次の属性が含まれます。
heartbeat This attribute is mandatory and single. It contains the name of the repository which originates this meta-object.
ハートビートこの属性は必須とシングルです。これは、このメタオブジェクトを発信リポジトリの名前が含まれています。
sequence This attribute is mandatory and single. It contains the highest transaction sequence number that has been assigned by the repository.
シーケンスこの属性は必須とシングルです。これは、リポジトリによって割り当てられている最大のトランザクションシーケンス番号が含まれています。
timestamp This attribute is mandatory and single. It contains the time at which this meta-object was generated. The format of this attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four digit year, "MM" represents the month, "DD" the date, "hh" the hour, "mm" the minutes, "ss" the seconds of the timestamp, and "xx" and "yy" represents the hours and minutes respectively that that timestamp is ahead or behind UTC.
この属性は必須と単一であるタイムスタンプ。これは、このメタオブジェクトが生成された時刻が含まれています。この属性の形式は "YYYYMMDD hh：mm：ssを[+/-] XX：YY" である "YYYY" は4桁の年を指定し、 "MM" は、月の日付を "DD" を表し、 "HH"時間、「ミリメートル」分、「SS」のタイムスタンプの秒、および「XX」と「YY」は、そのタイムスタンプが先か、UTCの後ろにあることを、それぞれ時間と分を表します。
Upon receiving a heartbeat meta-object, a repository must first check the timestamp of the latest previously received heartbeat message. If that timestamp exceeds the timestamp in the received heartbeat message, the repository must silently discard the heartbeat message. Otherwise, it must record the timestamp and sequence number in the heartbeat message, and redistribute the heartbeat message, without modification, to each of its peer repositories.
ハートビートメタオブジェクトを受信すると、リポジトリは、まず最新の以前に受信したハートビートメッセージのタイムスタンプを確認する必要があります。そのタイムスタンプは、受信したハートビートメッセージのタイムスタンプを超えた場合、リポジトリはサイレントハートビートメッセージを破棄しなければなりません。それ以外の場合は、ハートビートメッセージのタイムスタンプとシーケンス番号を記録する必要があり、そのピア・リポジトリの各々に、変更することなく、ハートビートメッセージを再分配します。
If the heartbeat message is from a repository previously unknown to the recipient, the recipient may send a "transaction-request" to one or more of its peers to obtain all transactions belonging to the corresponding database. If the heartbeat message contains a sequence number higher than the highest sequence number processed by the recipient, the recipient may send a "transaction-request" to one or more of its peers to obtain all transactions belonging to the corresponding database.
ハートビートメッセージが受信者に以前は未知のリポジトリからのものである場合、受信者は、対応するデータベースに属するすべての取引を得るために、そのピアの1つまたは複数の「トランザクション・リクエスト」を送信してもよいです。ハートビートメッセージが受信者によって処理された最大のシーケンス番号より高いシーケンス番号が含まれている場合、受信者は、対応するデータベースに属するすべての取引を得るために、そのピアの1つまたは複数の「トランザクション・リクエスト」を送信してもよいです。
Submitters may require stronger confirmation of commit for their transactions (Section 6.3). This section describes a simple request-response protocol by which a repository may provide this stronger confirmation, by verifying if one or more other repositories have committed the transaction. Implementation of this request-response protocol is optional.
提出者は、その取引（6.3節）のためにコミットの強力な確認が必要な場合があります。このセクションでは、リポジトリは、1つまたは複数の他のリポジトリがトランザクションをコミットした場合は検証することにより、この強力な確認を提供することができることにより、簡単な要求 - 応答プロトコルを記述します。この要求 - 応答プロトコルの実装はオプションです。
After it has redistributed a transaction, the originating repository may request a commit confirmation from one or more peer repositories by sending to them a "commit-request" meta-object. The "commit-request" contains two attributes:
それはトランザクションを再配布した後、元のリポジトリには、彼らに「コミット要求を」メタオブジェクトを送信することによって、1つ以上のピア・リポジトリからコミット確認を要求することができます。 「コミット要求」の2つの属性が含まれています。
commit-request This attribute is mandatory and single. It contains the name of the database for whom a commit confirmation is being requested.
コミット要求をこの属性は必須とシングルです。これは、要求されている人からコミット確認のためのデータベースの名前が含まれています。
sequence This attribute is mandatory and single. It contains the transaction sequence number for which a commit confirmation is being requested.
シーケンスこの属性は必須とシングルです。これは、コミット確認が要求されているトランザクションシーケンス番号が含まれています。
A repository that receives a "commit-request" must not redistribute the request. It must delay the response until the corresponding transaction has been processed. For this reason, the repository must keep state about pending commit requests. It should discard this state if the connection to the requester is lost before the response is sent. In that event, it is the responsibility of the requester to resend the request.
「コミット要求」を受信するリポジトリは、要求を再配布してはなりません。対応するトランザクションが処理されるまで、それは応答を遅らせる必要があります。このため、リポジトリはコミット要求保留についての状態を維持しなければなりません。応答が送信される前に、依頼者への接続が失われた場合は、この状態を破棄しなければなりません。その場合には、その要求を再送信するために依頼者の責任です。
Once a transaction has been processed (Section 7.3), a repository must check to see if there exists any pending commit request for the transaction. If so, it must send a "commit-response" meta-object to the requester. This meta-object has three attributes: commit-response This attribute is mandatory and single. It contains the name of the database for whom a commit response is being sent.
トランザクションが（7.3節）に処理された後、リポジトリは任意のトランザクションのコミット要求を保留が存在するかどうかを確認する必要があります。もしそうなら、それは要求者に「コミット応答を」メタオブジェクトを送信する必要があります。コミット-responseこの属性は必須とシングルです：このメタオブジェクトには、3つの属性があります。これは、Aレスポンスをコミットが送信されている誰のためのデータベースの名前が含まれています。
sequence This attribute is mandatory and single. It contains the transaction sequence number for which a commit response is being sent.
シーケンスこの属性は必須とシングルです。これは、コミット応答が送信されているトランザクションシーケンス番号が含まれています。
commit-status This attribute is mandatory and single. It contains one of the keywords "held", "error", or "succeeded". The "error" keyword may be followed by an optional text string. The "held" keyword is returned when a repository containing a dependent object for authorization has expired.
コミット・ステータスをこの属性は必須とシングルです。それは、「エラー」「開催」のいずれかのキーワードが含まれているか、「成功しました」。 「エラー」キーワードはオプションのテキスト文字列が続くことができます。承認のための依存オブジェクトを含むリポジトリの有効期限が切れた時に「保留」のキーワードが返されます。
A database snapshot provides a complete copy of a database. It is intended only for repository initialization or disaster recovery. A database snapshot is an out of band mechanism. A set of files are created periodically at the source repository. These files are then transferred to the requestor out of band (e.g. ftp transfer). The objects in these files are then registered locally.
データベーススナップショットは、データベースの完全なコピーを提供します。これは、唯一のリポジトリの初期化や災害復旧のために意図されます。データベーススナップショットは、バンド機構から外れています。ファイルのセットは、ソースリポジトリに定期的に作成されます。これらのファイルは、その後、（例えば、FTP転送）帯域外リクエスタに転送されます。これらのファイル内のオブジェクトは、その後、ローカルに登録されています。
A snapshot of repository X contains the following set of files:
リポジトリXのスナップショットは、次のファイルセットが含まれています。
X.db This file contains the RPSL objects of repository X, separated by blank lines. In addition to the RPSL objects and blank lines, comment lines can be present. Comment lines start with the character '#'. The comment lines are ignored. The file X.db ends in a special comment line "# eof".
このファイルX.db空白行で区切られ、リポジトリXのRPSLオブジェクトが含まれています。 RPSLオブジェクトと空白行に加えて、コメント行が存在することができます。コメント行は文字「＃」で始まります。コメント行は無視されます。ファイルX.dbは特別なコメント行「＃のEOF」で終わります。
X.<class>.db This optional file if present contains the RPSL objects in X.db that are of class <class>. The format of the file is same as that of X.db.
X.存在がクラス<クラス>であるX.dbでRPSLオブジェクトが含まれている場合は、このオプションのファイル.DB <クラス>。ファイルの形式はX.db.のと同じです
X.transaction-label This file contains a transaction-label object that records the timestamp and the latest sequence number of the repository at the time of the snapshot.
X.transactionラベルは、このファイルには、スナップショットの時点でタイムスタンプとリポジトリの最新のシーケンス番号を記録トランザクションラベルオブジェクトが含まれています。
Each of these files can be optionally compressed uzing gzip. This is signified by appending the suffix .gz to the file name. Each of these files can optionally be PGP signed. In this case, the detached signature with ASCII armoring and platform-independent text mode is stored in a file whose name is constructed by appending .sig to the file name of the file being signed.
これらの各ファイルには、必要に応じてuzing gzipで圧縮することができます。これは、ファイル名に.gzという接尾辞を追加することによってシニフィエされます。これらの各ファイルには、必要に応じてPGP署名することができます。この場合、ASCIIの外装及びプラットフォームに依存しないテキストモードとの分離署名は、名前が署名されたファイルのファイル名に.SIG付加することにより構成されているファイルに格納されています。
In order to construct a repository's contents from a snapshot, a repository downloads these files. After uncompressing and checking signatures, the repository records these objects in its database. No
スナップショットからのリポジトリの内容を構築するために、リポジトリはこれらのファイルをダウンロードします。署名を解凍し、チェックした後、リポジトリはそのデータベースにこれらのオブジェクトを記録します。番号
RPS authorization/authentication is done on these objects. The transaction-label object provides the seed for the replication protocol to receive the follow on transactions from this repository. Hence, it is not crucial to download an up to the minute snapshot.
RPSの承認/認証は、これらのオブジェクト上で行われます。トランザクションラベルオブジェクトは、このリポジトリからの取引上のフォローを受信する複製プロトコルのための種子を提供します。したがって、微細なスナップショットまでダウンロードすることが重要ではありません。
After successfully playing a snapshot, it is possible that a repository may receive a transaction from a third repository that has a dependency on an earlier version of one of the objects in the snapshot. This can only happen within the expire period of the repository being downloaded, plus any possible network partition period. This dependency is only important if the repository wants to re-verify RPS authorization/authentication. There are three allowed alternatives in this case. The simplest alternative is for the repository to accept the transaction and mark it with integrity "no-auth". The second choice is to only peer with trusted repositories during this time period, and accept the transaction with the same integrity as the trusted repository (possibly as "authorized"). The most preferred alternative is not to download an up to the minute snapshot, but to download an older snapshot, at minimum twice the repositories expire time, in practice few days older. Upon replaying an older snapshot, the replication protocol will fetch the more current transactions from this repository. Together they provide the necessary versions of objects to re-verify rps authorization/authentication.
正常スナップショットを再生した後、リポジトリは、スナップショット内のオブジェクトの以前のバージョンに依存している第三のリポジトリからトランザクションを受信する可能性があります。これは、ダウンロードされているリポジトリ、加えて任意の可能なネットワークパーティション期間の期限が切れる期間内に発生する可能性があります。この依存関係は、リポジトリは、RPSの承認/認証を再検証したい場合にのみ重要です。ここでは3つの許可の選択肢があります。リポジトリは、トランザクションを受け入れるとの整合性「認証なし」とそれをマークするための最も簡単な選択肢です。 2番目の選択肢は、この期間中に、信頼できるリポジトリとピア、および信頼できるリポジトリ（おそらく「許可」など）と同じ整合性とトランザクションを受け入れることです。最も好ましい代替は、二回のリポジトリが数日古い実際には、時間を期限切れ分のスナップショットまでをダウンロードすることではなく、最低でも、古いスナップショットをダウンロードすることではありません。古いスナップショットを再生すると、レプリケーション・プロトコルは、このリポジトリからより多くの現在のトランザクションを取得します。彼らは一緒にRPSの承認/認証を再確認するために、オブジェクトの必要なバージョンを提供します。
The "signature" and "repository-signature" meta-objects represent signatures. Where multiple of these objects are present, the signatures should be over the original contents, not over other signatures. This allows signatures to be checked in any order.
「署名」および「リポジトリ署名」メタオブジェクトは、署名を表します。これらのオブジェクトの複数が存在する場合、署名はない他の署名の上に、オリジナルコンテンツの上にあるべきです。これは、署名は任意の順序で確認することができます。
A maintainer can also sign a transaction using several authentication methods (some of which may be available in some repositories only).
保守者は、（いくつかのリポジトリのみで利用可能であるいくつかの）いくつかの認証方法を使用して、トランザクションに署名することができます。
In the case of PGP, implementations should allow the signatures of the "signature" and "repository-signature" meta-objects to be either the detached signatures produced by PGP or regular signatures produced by PGP. In either case, ASCII armoring and platform-independent text mode should be used.
PGPの場合、実装は、「署名」の署名と「リポジトリ署名」メタオブジェクトは、PGPによって生成PGPまたは通常の署名によって産生さ分離署名のいずれかであることを可能にするべきです。いずれの場合も、ASCIIの外装やプラットフォームに依存しないテキストモードを使用する必要があります。
Note that the RPSL objects themselves are not signed but the entire transaction body is signed. When exchanging transactions among registries, the meta-objects (e.g. "auth-dependency") prior to the first "repository-signature" meta object in the redistributed text are also signed over.
RPSL自身が署名されていないオブジェクトが、トランザクション全体本体が署名されていることに注意してください。レジストリ間でトランザクションを交換し、メタオブジェクト（例えば「認証依存性」）前に再配布テキストの最初の「リポジトリ署名」メタオブジェクトにも上署名されています。
Transactions must remain intact, including the signatures, even if an authentication method provided by the submitter is not used by a repository handling the message. An originating repository may chose to remove clear text passwords signatures from a transaction, and replace it with the keyword "clear-text-passwd" followed by the maintainer's id.
トランザクションは、提出者が提供する認証方法は、メッセージを処理し、リポジトリによって使用されていなくても、署名を含む、無傷のままでなければなりません。元のリポジトリには、トランザクションからのクリアテキストのパスワード署名を削除し、メンテナのidに続くキーワード「クリアテキスト-passwdの」に置き換えることを選択することができます。
signature: clear-text-passwd <maintainer-name>
署名：クリアテキスト-passwdの<メンテナ名>
Note that this does not make the system less secure since clear text password is an indication of total trust to the originating repository by the maintainer.
クリアテキストのパスワードはメンテナによって元のリポジトリへの総信頼の指標であるので、これは、システムが安全性の低いことはないことに注意してください。
A repository may sign a transaction that it verified. If at any point the signature of a trusted repository is encountered, no further authorization or authentication is needed.
リポジトリは、それが検証トランザクションに署名することができます。任意の時点で、信頼できるリポジトリの署名が検出された場合、それ以上の承認や認証は必要ありません。
A Examples
例
RPSL provides an external representation of RPSL objects and attributes. An attribute is a name/value pair. RPSL is line oriented. Line continuation is supported, however most attributes fit on a single line. The attribute name is followed by a colon, then any amount of whitespace, then the attribute value. An example of the ASCII representation of an RPSL attribute is the following:
RPSLはRPSLオブジェクトと属性の外部表現を提供します。属性には、名前/値のペアです。 RPSLは行指向です。行の継続は、しかし、ほとんどの属性は、1行に収まら、サポートされています。属性名は、コロン、空白の後、任意の量、そして属性値が続いています。 RPSL属性のASCII表現の一例は以下の通りであります：
route: 140.222.0.0/16
ルート：140.222.0.0/16
An RPSL object is a set of attributes. Objects are separated from each other by one or more blank lines. An example of a complete RPSL object follows:
RPSLオブジェクトは、属性のセットです。オブジェクトは、一つ以上の空白行によって互いに分離されています。完全なRPSLオブジェクトの例は次のとおりです。
route: 140.222.0.0/16
descr: ANS Communications
origin: AS1673
member-of: RS-ANSOSPFAGGREGATE
mnt-by: ANS
changed: tck@ans.net 19980115
source: ANS
A.1 Initial Object Submission and Redistribution
A.1初期オブジェクトの提出と再配布
Figure 1 outlines the steps involved in submitting an object and the initial redistribution from the authoritative registry to its flooding peers.
図1は、その洪水ピアに権威レジストリからのオブジェクトと初期再配布を提出に必要な手順の概要を説明します。
If the authorization check requires objects from other repositories, then the sequence numbers of the local copies of those databases is required for mirrors to recheck the authorization.
認可チェックは、他のリポジトリからのオブジェクトを必要とする場合、それらのデータベースのローカルコピーのシーケンス番号は、許可を再確認するために、ミラーのために必要とされます。
To simply resubmit the object from the prior example, the submitter or a client application program acting on the submitter's behalf must submit a transaction. The legacy method was to send PGP signed email. The preferred method is for an interactive program to encapsulate a request between "transaction-submit-begin" and "transaction-submit-end" meta-objects and encapsulate that as a signed block as in the following example:
単に以前の例からオブジェクトを再送信するには、提出者または提出者に代わって、クライアント・アプリケーション・プログラムの演技は、トランザクションを提出しなければなりません。従来の方法では、PGPは、電子メールに署名し送信することでした。好ましい方法は、「トランザクション提出 - 開始」の間で要求及び「トランザクション提出エンド」メタオブジェクトをカプセル化し、次の例のように署名されたブロックとしてそれをカプセル化するための対話型プログラムのためのものです。
+--------------+
| Transaction |
| signed by |
| submitter |
+--------------+
|
| 1
v
+---------------------+ 2
| Primary repository |---->+----------+
| identified by | | database |
| RPSL source |<----+----------+
+---------------------+ 3
|
| 4
v
+----------------+
| Redistributed |
| transaction |
+----------------+
1. submit object 2. authorization check 3. sequence needed for authorization 4. redistribute
1.承認4.再配布するために必要なオブジェクト2.認可チェック3.シーケンスを提出
Figure 1: Initial Object Submission and Redistribution
図1：初期オブジェクトの提出と再配布
transaction-submit-begin: ANS 1 response-auth-type: PGP transaction-confirm-type: normal
トランザクション提出-開始：ANS 1つの応答-AUTH型：PGP取引確認型：ノーマル
route: 140.222.0.0/16 descr: ANS Communications origin: AS1673 member-of: RS-ANSOSPFAGGREGATE mnt-by: ANS changed: curtis@ans.net 19990401 source: ANS
ルート：140.222.0.0/16 DESCR：ANS通信起源：AS1673メンバーの：RS-ANSOSPFAGGREGATE MNTバイ：ANSが変更された：curtis@ans.net 19990401ソース：ANS
timestamp: 19990401 10:30:00 +08:00 signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
transaction-submit-end: ANS 1
トランザクション提出エンド：ANS 1
The signature covers the everything after the first blank line after the "transaction-submit-begin" object to the last blank line before the "signature" meta-object. If multiple signatures are needed, it would be quite easy to email this block and ask the other party to add a signature-block and return or submit the transaction. Because of delay in obtaining multiple signatures the accuracy of the "timestamp" cannot be strictly enforced. Enforcing accuracy to within the "expire" time of the database might be a reasonable compromise. The tradeoff is between convenience, allowing a longer time to obtain multiple signatures, and increased time of exposure to replay attack.
署名は、「署名」メタオブジェクト前の最後の空白行に「取引提出-始まる」オブジェクトの後の最初の空白行の後に、すべてをカバーしています。複数の署名が必要な場合は、このブロックに電子メールを送り、署名ブロックを追加し、トランザクションを返すか、提出を求めることを非常に簡単になります。 「タイムスタンプ」の精度を厳密に適用することができない複数の署名を得る際の遅延のため。データベースの「有効期限切れ」時間内に正確さを強制することは、合理的な妥協点かもしれません。トレードオフは、複数の署名を得るために、より長い時間を可能にする、利便性の間であり、そして攻撃を再生する曝露時間を増加させました。
The ANS repository would look at its local database and make authorization checks. If the authorization passes, then the sequence number of any other database needed for the authorization is obtained.
ANSのリポジトリは、ローカルデータベースを見て、認証チェックになるだろう。認証に合格した場合は、認可のために必要な他のデータベースのシーケンス番号が取得されます。
If this operation was successful, then a confirmation would be returned. The confirmation would be of the form:
この操作が成功した場合は、確認が返されます。確認は次の形式になります。
transaction-confirm: ANS 1 confirmed-operation: change route 140.222.0.0/16 AS1673 commit-status: commit timestamp: 19990401 10:30:10 +05:00
取引確認：ANS 1確認-操作：変更ルート140.222.0.0/16 AS1673-状態をコミットします。コミットタイムスタンプ：19990401 10時30分10秒05：00
A.2 Transaction Redistribution Encoding
A.2トランザクションの再配布エンコーディング
Having passed the authorization check the transaction is given a sequence number and stored in the local transaction log and is then flooded. The meta-object flooded to another database would be signed by the repository and would be of the following form:
認可チェックを通過したトランザクションは、シーケンス番号を与えられ、ローカル・トランザクション・ログに保存され、その後、フラッディングされています。別のデータベースにフラッディングメタオブジェクトは、リポジトリによって署名されると、次の形式であろう。
transaction-label: ANS sequence: 6666 timestamp: 19990401 13:30:10 +05:00 integrity: authorized
トランザクションラベル：とシーケンス：6666タイムスタンプ：19990401 13時30分10秒05：00の完全性：許可
route: 140.222.0.0/16 descr: ANS Communications origin: AS1673 member-of: RS-ANSOSPFAGGREGATE mnt-by: ANS changed: curtis@ans.net 19990401 source: ANS
ルート：140.222.0.0/16 DESCR：ANS通信起源：AS1673メンバーの：RS-ANSOSPFAGGREGATE MNTバイ：ANSが変更された：curtis@ans.net 19990401ソース：ANS
timestamp: 19990401 10:30:00 +08:00
タイムスタンプ：19990401午前10時30分00秒08：00
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
auth-dependency: ARIN sequence: 555 timestamp: 19990401 13:30:08 +05:00
AUTH依存性：ARIN順序：555のタイムスタンプ：19990401午前13時30分08秒05：00
auth-dependency: RADB sequence: 4567 timestamp: 19990401 13:27:54 +05:00
AUTH依存性：RADBシーケンス：4567タイムスタンプ：19990401 13時27分54秒05：00
repository-signature: ANS
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
Note that the repository-signature above is a detached signature for another file and is illustrative only. The repository-signature covers from the "transaction-label" meta-object (including) to the last blank line before the first "repository-signature" meta-object (excluding the last blank line and the "repository-signature" object).
上記リポジトリ署名が別のファイルの分離署名であり、単なる例示であることに留意されたいです。リポジトリ署名は（最後の空白行と「リポジトリ・シグネチャー」オブジェクトを除く）最初の「リポジトリの署名」メタオブジェクト前の最後の空白行に（含む）「トランザクションラベル」メタオブジェクトからカバーしています。
A.3 Transaction Protocol Encoding
A.3トランザクションプロトコルエンコーディング
transaction-begin: 1276
transfer-method: plain
transaction-label: ANS sequence: 6666 timestamp: 19990401 13:30:10 +05:00 integrity: authorized
トランザクションラベル：とシーケンス：6666タイムスタンプ：19990401 13時30分10秒05：00の完全性：許可
route: 140.222.0.0/16 descr: ANS Communications origin: AS1673 member-of: RS-ANSOSPFAGGREGATE mnt-by: ANS changed: curtis@ans.net 19990401 source: ANS
ルート：140.222.0.0/16 DESCR：ANS通信起源：AS1673メンバーの：RS-ANSOSPFAGGREGATE MNTバイ：ANSが変更された：curtis@ans.net 19990401ソース：ANS
timestamp: 19990401 10:30:00 +08:00
タイムスタンプ：19990401午前10時30分00秒08：00
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
auth-dependency: ARIN sequence: 555 timestamp: 19990401 13:30:08 +05:00
AUTH依存性：ARIN順序：555のタイムスタンプ：19990401午前13時30分08秒05：00
auth-dependency: RADB
sequence: 4567
timestamp: 19990401 13:27:54 +05:00 repository-signature: ANS
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
Before the transaction is sent to a peer, the repository prepends a "transaction-begin" meta-object. The value of the "transaction-begin" attribute is the number of octets in the transaction, not counting the "transaction-begin" meta-object and the first blank line after it.
トランザクションがピアに送信される前に、リポジトリは、「トランザクション開始」メタオブジェクトを付加します。 「トランザクション開始」属性の値は、「トランザクション開始」メタオブジェクトとそれの後の最初の空白行を数えていない、トランザクション内のオクテット数です。
Separating transaction-begin and transaction-label objects enables different encodings at different flooding peerings.
分離トランザクション開始およびトランザクションラベルオブジェクトが異なる洪水ピアリングで異なるエンコーディングを可能にします。
A.4 Transaction Redistribution
A.4トランザクションの再配布
The last step in Figure 1 was redistributing the submitter's transaction through flooding (or later through polling). Figure 2 illustrates the further redistribution of the transaction.
図1の最後のステップは、洪水（またはそれ以降のポーリングによる）を介して送信者のトランザクションを再配布されました。図2は、トランザクションのさらなる再分配を示します。
If the authorization check was repeated, the mirror may optionally add a repository-signature before passing the transaction any further. A "signature" can be added within that block. The previous signatures should not be signed.
認可チェックを繰り返した場合、ミラーは、必要に応じて任意の更なる取引を渡す前に、リポジトリの署名を追加することができます。 「署名」は、そのブロック内で添加することができます。前回の署名は署名するべきではありません。
Figure 3 illustrates the special case referred to as a "lightweight mirror". This is specifically intended for routers.
図3は、「軽量ミラー」と呼ばれる特殊な場合を示しています。これは、特にルータを対象としています。
The lightweight mirror must trust the mirror from which it gets a feed. This is a safe assumption if the two are under the same administration (the mirror providing the feed is a host owned by the same ISP who owns the routers). The lightweight mirror simply checks the signature of the adjacent repository to insure data integrity.
軽量ミラーは、フィードを取得し、そこからミラーを信頼する必要があります。 2つが同じ管理（飼料を提供するミラーは、ルータを所有している同じISPが所有するホストである）の下にある場合、これは安全な仮定です。軽量ミラーは、単に、データの整合性を保証する隣接リポジトリの署名をチェックします。
+----------------+
| Redistributed |
| transaction |
+----------------+
|
| 1
v
+--------------------+ 2
| |---->+----------+
| Mirror repository | | database |
| |<----+----------+
+--------------------+ 3
|
| 4
v
+------------------+
|+----------------+|
|| Redistributed ||
|| transaction ||
|+----------------+|
| Optional |
| signature |
+------------------+
1. redistribute transaction 2. recheck authorization against full DB at the time of the transaction using sequence numbers 3. authorization pass/fail 4. optionally sign then redistribute
1.必要に応じて再配布次にログイン3.許可パス/ 4不合格シーケンス番号を使用して、トランザクション時に完全DBに対するトランザクション2.再検査認可を再配布
Figure 2: Further Transaction Redistribution
図2：さらにトランザクションの再配布
+----------------+
| Redistributed |
| transaction |
+----------------+
| 1
v
+--------------------+ 2
| |---->+----------+
| Mirror repository | | database |
| |<----+----------+
+--------------------+ 3
| 4
v
+----------------+
| Redistributed |
| transaction |
+----------------+
| 5
v
+--------------------+
| Lightweight | 6 +----------+
| Mirror repository |---->| database |
| (router?) | +----------+
+--------------------+
1. redistribute transaction 2. recheck authorization against full DB at the time of the transaction using sequence numbers 3. authorization pass/fail 4. sign and redistribute 5. just check mirror signature 6. apply change with no authorization check
1.配列番号3認可パス/ 4符号を失敗し、ミラー署名6.無権限チェックと変更を適用チェックちょうど5を再配布を使用して、トランザクション時に完全DBに対するトランザクション2.再検査認可を再配布
Figure 3: Redistribution to Lightweight Mirrors
図3：軽量ミラーに再配布
B Technical Discussion
B技術的な議論
B.1 Server Processing
B.1サーバの処理
This document does not mandate any particular software design, programming language choice, or underlying database or underlying operating system. Examples are given solely for illustrative purposes.
この文書は、特定のソフトウェア設計、プログラミング言語の選択、または基礎となるデータベースまたは基礎となるオペレーティングシステムを強制しません。例は、単に例示の目的のために与えられています。
B.1.1 getting connected
B.1.1が接続されている取得します
There are two primary methods of communicating with a repository server. E-mail can be sent to the server. This method may be deprecated but at least needs to be supported during transition. The second method is preferred, connect directly to a TCP socket.
リポジトリサーバとの通信には主に2つの方法があります。 Eメールは、サーバーに送信することができます。この方法は推奨が、少なくとも遷移の間に支持される必要があることができます。第二の方法は、TCPソケットに直接接続し、好ましいです。
Traditionally the whois service is supported for simple queries. It might be wise to retain the whois port connection solely for simple queries and use a second port not in the reserved number space for all other operations including queries except those queries using the whois unstructured single line query format.
伝統的にWHOISサービスは、単純なクエリでサポートされています。単純なクエリのためだけのwhoisポート接続を保持していないwhoisの構造化されていない単一の行のクエリの形式を使用してこれらのクエリを除くクエリを含む他のすべての操作のための予約番号空間に第二のポートを使用するのが賢明かもしれません。
There are two styles of handling connection initiation is the dedicated daemon, in the style of BSD sendmail, or launching through a general purpose daemon such as BSD inetd. E-mail is normally handled sequentially and can be handled by a front end program which will make the connection to a socket in the process as acting as a mail delivery agent.
そこ接続開始を扱う2つのスタイルは、専用のデーモンはBSDのsendmailのスタイルで、されている、またはそのようなBSDのinetdのような汎用デーモンによって起動します。 Eメールは、通常は順次処理され、メール配信エージェントとして働くようなプロセスにおいてソケットへの接続を行いますフロントエンドプログラムによって処理することができます。
B.1.2 rolling transaction logs forward and back
B.1.2ローリングトランザクションが前後に記録します
There is a need to be able to easily look back at previous states of any database in order to repeat authorization checks at the time of a transaction. This is difficult to do with the RIPE database implementation, which uses a sequentially written ASCII file and a set of Berkeley DB maintained index files for traversal. At the very minimum, the way in which deletes or replacements are implemented would need to be altered.
簡単に取引時に認証チェックを繰り返すために、任意のデータベースの以前の状態で振り返ることができるようにする必要があります。これは、順番に書かれたASCIIファイルを使用し、バークレーDBのセットがトラバーサルのためのインデックスファイルを維持しRIPEデータベースの実装、で行うことが困難です。非常に最低でも、削除または置換が実施される方法を変更する必要があります。
In order to easily support a view back at prior versions of objects, the sequence number of the transaction at which each object was entered would need to be kept with the object. A pointer would be needed back to the previous state of the object. A deletion would need to be implemented as a new object with a deleted attribute, replacing the previous version of the object but retaining a pointer back to it.
容易にオブジェクトの以前のバージョンでバックビューをサポートするために、各オブジェクトが入力されたときのトランザクションのシーケンス番号がオブジェクトと一緒に保管される必要があるであろう。ポインタは、オブジェクトの前の状態に戻す必要とされるであろう。削除は、オブジェクトの以前のバージョンを置き換えますが戻ってそれへのポインタを保持、削除された属性を持つ新しいオブジェクトとして実装する必要があります。
A separate transaction log needs to be maintained. Beyond some age, the older versions of objects and the the older transaction log entries can be removed although it is probably wise to archive them.
別のトランザクションログを維持する必要があります。おそらくそれらをアーカイブするのが賢明ですが、いくつかの年齢を超えて、オブジェクトの旧バージョンと古いトランザクション・ログ・エントリーを除去することができます。
B.1.3 committing or disposing of transactions
B.1.3コミットまたは取引の処分
The ability to commit large transaction, or reject them as a whole poses problems for simplistic database designs. This form of commit operation can be supported quite easily using memory mapped files. The changes can be made in virtual memory only and then either committed or disposed of.
大規模なトランザクションをコミット、または全体が単純なデータベース設計のための問題を提起として、それらを拒否する機能。コミット操作のこの形式は、メモリマップファイルを使用して非常に簡単にサポートすることができます。変更は、次にコミットまたはのいずれかに配置された仮想メモリで行うことができます。
B.1.4 dealing with concurrency
並行処理を扱うB.1.4
Multiple connections may be active. In addition, a single connection may have multiple outstanding operations. It makes sense to have a single process or thread coordinate the responses for a given connection and have multiple processes or threads each tending to a single operation. The operations may complete in random order.
複数の接続をアクティブにすることができます。また、単一の接続は、複数の未処理の操作を有することができます。これは、単一のプロセスを持っているか、指定された接続のための応答を調整し、各単一動作傾向複数のプロセスまたはスレッドを有するスレッドに理にかなっています。操作は、ランダムな順序で完了することがあります。
Locking on reads is not essential. Locking before write access is essential. The simplest approach to locking is to lock at the database granularity or at the database and object type granularity. Finer locking granularity can also be implemented. Because there are multiple databases, deadlock avoidance must be considered. The usual deadlock avoidance mechanism is to acquire all necessary locks in a single operation or acquire locks in a prescribed order.
読み取りにロックすることは必須ではありません。書き込みアクセスする前にロックすることは不可欠です。ロックの最も簡単な方法は、データベースの粒度で、またはデータベースとオブジェクトタイプの粒度でロックすることです。より細かいロック粒度も実現することができます。複数のデータベースが存在するため、デッドロック回避を考慮しなければなりません。通常のデッドロック回避機構は、単一の操作で必要なすべてのロックを取得したり、所定の順序でロックを取得することです。
B.2 Repository Mirroring for Redundancy
B.2リポジトリは、冗長性のためのミラーリング
There are numerous reasons why the operator of a repository might mirror their own repository. Possibly the most obvious are redundancy and the relative ease of disaster recovery. Another reason might be the widespread use of a small number of implementations (but more than one) and the desire to insure that the major repository software releases will accept a transaction before fully committing to the transaction.
リポジトリのオペレータが自分のリポジトリをミラーかもしれない多数の理由があります。おそらく最も明白な冗長性と災害復旧の比較的容易です。もう一つの理由は、実装の数が少ない（しかし、複数）との主要なリポジトリソフトウェアリリースは完全にトランザクションにコミットする前に、トランザクションを受け入れることを保証したいの普及かもしれません。
The operation of a repository mirror used for redundancy is quite straightforward. The transactions of the primary repository host can be immediately fed to the redundant repository host. For tighter assurances that false positive confirmations will be sent, as a matter of policy the primary repository host can require commit confirmation before making a transaction sequence publicly available.
冗長性を確保するために使用され、リポジトリ鏡の操作は非常に簡単です。プライマリリポジトリホストのトランザクションを直ちに冗長リポジトリホストに供給することができます。政策の問題として、偽陽性の確認が送信されることをタイト保証については、プライマリ・リポジトリのホストは、トランザクションシーケンスを公開する前に確認をコミットする必要がすることができます。
There are many ways in which the integrity of local data can be assured regardless of a local crash in the midst of transaction disk writes. For example, transactions can be implemented as memory mapped file operations, with disk synchronization used as the local commit mechanism, and disposal of memory copies of pages used to handle commit failures. The old pages can be written to a separate file, the new pages written into the database. The transaction can be logged and old pages file can then be removed. In the event of a crash, the existence of a old pages file and the lack of a record of the transaction completing would trigger a transaction roll back by writing the old pages back to the database file.
ローカル・データの整合性は、トランザクションのディスクへの書き込みの真っ只中にかかわらず、地元のクラッシュの保証することができる多くの方法があります。たとえば、トランザクションがディスクローカルコミットメカニズムとして使用される同期、および障害をコミット処理するために使用されるページのメモリコピーの処分で、メモリマップされたファイル操作として実装することができます。古いページが別のファイル、データベースに書き込まれた新しいページに書き込むことができます。トランザクションがログに記録することができ、古いページファイルを除去することができます。クラッシュが発生した場合、古いページファイルの存在とバックデータベースファイルへの古いページを書き込むことによって、バックトランザクションロールを誘発するだろう完了トランザクションの記録の欠如。
The primary repository host can still sustain severe damage such as a disk crash. If the primary repository host becomes corrupted, the use of a mirror repository host provides a backup and can provide a rapid recovery from disaster by simply reversing roles.
プライマリ・リポジトリのホストは、まだ、このようなディスククラッシュなどの重篤な損傷を受けることができます。プライマリ・リポジトリのホストが破損した場合、ミラーリポジトリホストを使用すると、バックアップを提供し、単に役割を反転させることにより、災害からの迅速な復旧を提供することができます。
If a mirror is set up using a different software implementation with commit mirror confirmation required, any transaction which fails due a software bug will be deferred indefinitely allowing other transactions to proceed rather than halting the remote processing of all transactions until the bug is fixed everywhere.
ミラーはミラー確認が必要なコミットと異なるソフトウェア実装を使用して設定されている場合は、ソフトウェアの不具合により故障したすべてのトランザクションが無期限に他のトランザクションは、バグはどこにでも固定されるまで、すべてのトランザクションのリモート処理を停止するのではなく進行させること延期されます。
B.3 Trust Relationships
B.3信頼関係
If all repositories trust each other then there is never a need to repeat authorization checks. This enables a convenient interim step for deployment prior to the completion of software supporting that capability. The opposite case is where no repository trusts any other repository. In this case, all repositories must roll forward transactions gradually, checking the authorization of each remote transaction.
すべてのリポジトリがお互いを信頼した場合、承認チェックを繰り返す必要は決してありません。これは、その機能をサポートするソフトウェアが完了する前に展開するための便利な中間ステップを可能にします。何リポジトリが他のリポジトリを信頼していない場合に逆の場合です。この場合、すべてのリポジトリは、各リモート・トランザクションの承認をチェックし、徐々にトランザクションをロールフォワードしなければなりません。
It is likely that repositories will trust a subset of other repositories. This trust can reduce the amount of processing a repository required to maintain mirror images of the full set of data. For example, a subset of repositories might be trustworthy in that they take reasonable security measures, the organizations themselves have the integrity not to alter data, and these repositories trust only a limited set of similar repositories. If any one of these repositories receives a transaction sequence and repeats the authorization checks, other major repositories which trusts that repository need not repeat the checks. In addition, trust need not be mutual to reap some benefit in reduced processing.
リポジトリが他のリポジトリのサブセットを信頼する可能性があります。この信頼関係は、データのフルセットの鏡像を維持するために必要なリポジトリの処理量を減らすことができます。彼らは合理的な安全対策を講じ、組織自体がデータを変更しないように整合性を持っており、これらのリポジトリは、類似したリポジトリの限られたセットを信頼という点で、例えば、リポジトリのサブセットは、信頼できるかもしれません。これらのリポジトリのいずれか1つがトランザクションシーケンスを受信して、チェックを繰り返す必要がないのリポジトリを信頼する認証チェック、他の主要なリポジトリを繰り返します。また、信頼が低下し、処理中にいくつかの利点を享受するために、相互である必要はありません。
As a transaction sequence is passed from repository to repository each repository signs the transaction sequence before forwarding it. If a receiving repository finds that any trusted repository has signed the transaction sequence it can be considered authorized since the trusted repository either trusted a preceding repository or repeated the authorization checks.
トランザクションシーケンスは、各リポジトリをリポジトリにリポジトリから渡されたとして、それを転送する前に、トランザクションシーケンスに署名します。受信リポジトリは、任意の信頼できるリポジトリは、トランザクションシーケンスに署名したことを検出した場合には、信頼されたリポジトリが先行リポジトリをトラステッドまたは権限チェックを繰り返しいずれか以来認可とみなすことができます。
B.4 A Router as a Minimal Mirror
最小ミラーとしてB.4 Aルータ
A router could serve as a minimal repository mirror. The following simplifications can be made.
ルータは、最小限のリポジトリのミラーとしての役割を果たすことができました。次の簡略化を行うことができます。
1. No support for repeating authorization checks or transaction authentication checks need be coded in the router.
1.繰り返しの権限チェックやトランザクションの認証チェックのサポートはルータでコーディングする必要はありません。
2. The router must be adjacent only to trusted mirrors, generally operated by the same organization.
2.ルータは、一般的に同じ組織が運営する、信頼できるミラーに隣接している必要があります。
3. The router would only check the authentication of the adjacent repository mirrors.
3.ルータは、隣接するリポジトリのミラーの認証を確認します。
4. No support for transaction submission or query need be coded in the router. No commit support is needed.
4.トランザクションの提出またはクエリのサポートはルータでコーディングする必要はありません。何のサポートが必要なコミットありません。
5. The router can dispose of any object types or attributes not needed for configuration of route filters.
5.ルータは、ルートフィルタの設定のために必要ではない任意のオブジェクトの種類や属性を処分することができます。
The need to update router configurations could be significantly reduced if the router were capable of acting as a limited repository mirror.
ルータが制限されたリポジトリのミラーとして機能することができた場合、ルータの設定を更新する必要性が大幅に減少させることができます。
A significant amount of non-volatile storage would be needed. There are currently an estimated 100 transactions per day. If storage were flash memory with a limited number of writes, or if there were some other reason to avoid writing to flash, the router could only update the non-volatile copy every few days. A transaction sequence request can be made to get an update in the event of a crash, returning only a few hundred updates after losing a few days of deferred writes. The routers can still take a frequent or continuous feed of transactions.
不揮発性記憶装置、かなりの量が必要とされるであろう。一日あたりの推定100回の取引は現在ありません。ストレージは書き込みの数が限られているフラッシュメモリだった、またはフラッシュへの書き込みを回避するために、他のいくつかの理由があった場合、ルータは数日おきに、不揮発性コピーを更新することができます。場合トランザクションシーケンス要求は延期書き込みの数日を失った後、わずか数百アップデートを返し、クラッシュが発生した場合に更新を取得するために行うことができます。ルータは、まだ取引を頻繁にまたは連続的供給を取ることができます。
Alternately, router filters can be reconfigured periodically as they are today.
代わりに、ルータのフィルタは、彼らが今日あるとして、定期的に再構成することができます。
B.5 Dealing with Errors
エラーの処理B.5
If verification of an authorization check fails, the entire transaction must be rejected and no further advancement of the repository can occur until the originating repository corrects the problem. If the problem is due to a software bug, the offending transaction can be removed manually once the problem is corrected. If a software bug exists in the receiving software, then the transaction sequence is stalled until the bug is corrected. It is better for software to error on the side of denying a transaction than acceptance, since an error on the side of acceptance will require later removal of the effects of the transaction.
認証チェックの検証が失敗した場合、トランザクション全体が拒否されなければならないと元のリポジトリが問題を修正するまで、リポジトリのさらなる進展が発生しないことができます。問題は、ソフトウェアのバグが原因である場合は、問題が修正されると、問題のあるトランザクションを手動で削除することができます。ソフトウェアのバグが受信ソフトウェアに存在する場合は、バグが修正されるまで、トランザクションシーケンスが停止されます。受け入れ側のエラーは、トランザクションの効果の後の除去が必要になりますので、それは、受け入れより取引を否定側のエラーへのソフトウェアのためのより良いです。
C Deployment Considerations
Cの配置の考慮事項
This section described deployment considerations. The intention is to raise issues rather than to provide a deployment plan.
このセクションでは、展開の考慮事項を説明しました。その意図は、問題を提起するのではなく、展開計画を提供することです。
This document calls for a transaction exchange mechanism similar to but not identical to the existing "near real time mirroring" supported by the code base widely used by the routing registries. As an initial step, the transaction exchange can be implemented without the commit protocol or the ability to recheck transaction authorization. This is a fairly minimal step from the existing capabilities.
この文書では、と似ていますが、「ミラーリングほぼリアルタイム」既存と同一ではない取引の為替メカニズムを求めて広くルーティングレジストリによって使用されるコードベースでサポートされています。最初のステップとして、トランザクション交換がコミットプロトコルやトランザクションの承認を再確認する能力なしに実現することができます。これは、既存の機能からかなり最小限のステップです。
The transition can be staged as follows:
次のように遷移が上演することができます。
1. Modify the format of "near real time mirroring" transaction exchange to conform to the specifications of this document.
1.このドキュメントの仕様に準拠したトランザクション交換を「リアルタイムに近いミラーリング」の形式を変更します。
3. Implement remote recheck of authorization. Prior to this step all repositories must be trusted.
3.承認のリモート再検査を実施。この工程の前にすべてのリポジトリは、信頼されなければなりません。
D Privacy of Contact Information
連絡先情報のDプライバシー
The routing registries have contained contact information. The redistribution of this contact information has been a delicate issue and in some countries has legal implications.
ルーティングレジストリは連絡先情報を含んでいました。この連絡先情報の再分配は、デリケートな問題となって、いくつかの国で法的な意味を持っていました。
The person and role objects contain contact information. These objects are referenced by NIC-handles. There are some attributes such as the "changed" and "notify" attributes that require an email address. All of the fields that currently require an email address must also accept a NIC-handle.
人と役割のオブジェクトは連絡先情報が含まれています。これらのオブジェクトは、NIC-ハンドルによって参照されています。そのような「変更」とメールアドレスが必要な属性を「通知」などの一部の属性があります。現在、電子メールアドレスが必要なフィールドのすべてはまた、NICハンドルを受け入れる必要があります。
The person and role objects should not be redistributed by default. If a submission contains an email address in a field such as a changed field rather than a NIC-handle the submitter should be aware that they are allowing that email address to be redistributed and forfeiting any privacy. Repositories which do not feel that prior warnings of this forfeiture are sufficient legal protection should reject the submission requesting that a NIC-handle be used.
人と役割のオブジェクトは、デフォルトでは再配布すべきではありません。提出は、このような変更されたフィールドとフィールドに電子メールアドレスが含まれている場合ではなく、NIC-扱う提出者は、彼らがそのメールアドレスを再配布することが可能となり、任意のプライバシーを放棄していることに注意する必要があります。この没収の前に警告が十分な法的保護であることを感じていないリポジトリはNICハンドルを使用することを要求して提出を拒否しなければなりません。
Queries to role and person objects arriving at a mirror must be referred to the authoritative repository where whatever authentication, restrictions, or limitations deemed appropriate by that repository can be enforced directly.
ミラーに到着役割や人物オブジェクトへのクエリはどんな認証、制限、または制限が直接実施することができるリポジトリで適切と思われる権威リポジトリを参照する必要があります。
Software should make it possible to restrict the redistribution of other entire object types as long as those object types are not required for the authorization of additions of other object types. It is not possible to redistribute objects with attributes removed or altered since this would invalidate the submitter's signature and make subsequent authentication checks impossible. Repositories should not redistribute a subset of the objects of a given type.
ソフトウェアは、それが可能な限り長く、これらのオブジェクトタイプは、他のオブジェクトタイプの追加の承認には必要とされないように、他のオブジェクト全体の型の再配布を制限するために行う必要があります。これは、提出者の署名を無効にして、後続の認証チェックが不可能になるだろうので、削除または変更する属性を持つオブジェクトを再配布することはできません。リポジトリは、所与のタイプのオブジェクトのサブセットを再配布するべきではありません。
Software should also not let a transaction contain both redistributable (e.g. policy objects) and non-redustributable objects (e.g. person) since there is no way to verify the signature of these transactions without the non-redustributable objects.
ソフトウェアはまた、非redustributableオブジェクトなしにこれらの取引の署名を検証する方法がないので、トランザクションは再配布可能な（例えばポリシーオブジェクト）と非redustributableオブジェクト（例えば人物）の両方を含むせてはなりません。
When redistributing legacy data, contact information in attributes such as "changed" and "notify" should be stripped to maintain privacy. The "integrity" attribute on these objects should already be set to "legacy" indicating that their origin is questionable, so the issue of not being able to recheck signatures is not as significant.
レガシーデータを再配布する場合は、そのような「変更」と「通知」などの属性での連絡先情報を、プライバシーを維持するために取り除かれるべきです。これらのオブジェクトの「整合性」属性は、すでに彼らの起源は疑問であることを示す「レガシー」に設定する必要がありますので、署名を再確認することができないという問題がとして重要ではありません。
References
リファレンス
[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing Policy Specification Language", RFC 2622, June 1999.
[1] Alaettinoglu、C.、Villamizar、C.、Gerich、E.、Kessens、D.、マイヤー、D.、ベイツ、T.、Karrenberg、D.およびM.テルプストラ、 "ルーティングポリシー仕様言語"、RFC 2622年、1999年6月。
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
[2]ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、JM。、Karrenberg、D.、テルプストラ、M.及びJ.優、「ルーティングレジストリにIPルーティングポリシーの表現（ripe- 81 ++）」、RFC 1786、1995年3月。
[3] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy, "Routing Policy System Security", RFC 2725, June 1999.
[3] Villamizar、C.、Alaettinoglu、C.、マイヤー、D.とS.マーフィー、 "ルーティングポリシーシステム・セキュリティ"、RFC 2725、1999年6月。
[4] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC 2726, December 1999.
[4] Zsako、J.、 "RIPEデータベースの更新のためのPGP認証"、RFC 2726、1999年12月。
Security Considerations
セキュリティの考慮事項
An authentication and authorization model for routing policy object submission is provided by [3]. Cryptographic authentication is addressed by [4]. This document provides a protocol for the exchange of information among distributed routing registries such that the authorization model provided by [3] can be adhered to by all registries and any deviation (hopefully accidental) from those rules on the part of a registry can be identified by other registries or mirrors.
ポリシーオブジェクト提出をルーティングするための認証および認可モデル[3]によって提供されます。暗号認証は、[4]によって対処されます。この文書は、分散ルーティング・レジストリ間での情報交換のためのプロトコルを提供するようなレジストリの一部にそれらの規則からすべてのレジストリとの偏差（願わくは偶発）によって[3]接着することができるによって提供される認可モデルを識別することができること他のレジストリまたはミラーによります。
Authors' Addresses
著者のアドレス
Curtis Villamizar Avici Systems EMail: curtis@avici.com
カーティスVillamizar Aviciシステムズ電子メール：curtis@avici.com
Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU
チンギスメールAlaettinogl HEAT：cengiz@ısı.e
Ramesh Govindan ISI EMail: govindan@ISI.EDU
ラメシュ・ガバインダンISI Eメール：govindan@ISI.EDU
David M. Meyer Cisco EMail: dmm@cisco.com
デイビッドM.マイヤーシスコのEメール：dmm@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。