[要約] RFC 2769は、ルーティングポリシーシステムのレプリケーションに関する要件を定義しています。その目的は、異なるルータ間でルーティングポリシーの情報を効果的に共有し、ネットワークのパフォーマンスと信頼性を向上させることです。
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.
Copyright（c）The Internet Society（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.
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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.
熟したデータベース仕様と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.
ルーティングレジストリ情報を認証する2つの方法が提案されています。
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]。多くのRPSLデータオブジェクトはRIPEから変化しておらず、RPSLはRFC-1786に記録されているRIPE-181仕様を参照しています[2]。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へのいくつかの追加は、それらの1つを見つけた後にすべてのリポジトリを見つけるために必要です。これらの追加については、セクション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.
データを交換するために、何らかの形のカプセル化を使用する必要があります。Defactoのカプセル化は、RFC-822の本文にあるプレーンテキストファイルまたはプレーンテキストが、メールヘッダーから派生した認証に必要な情報を含むプレーンテキストファイルまたはプレーンテキストです。Meritは、プレーンテキストファイルの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.
承認チェックを繰り返すには、オブジェクトのバックリビジョンを取得できる必要があります。これがどのように達成されるかは、実装の地元の問題です。非常に簡単な方法の1つは、状態が削除されている場合でも、トラバーサルデータ構造をすべての現在のオブジェクトに保持することです。オブジェクトのバージョンが効果的になったシーケンス番号を保持し、オブジェクトの以前のバージョンへのリンクを維持します。オブジェクトの以前のバージョンを見つけるには、オブジェクトのバージョンのシーケンス番号が検索されるシーケンス番号よりも低くなるまで参照を振り返ることが含まれます。
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.
誰が変更を加え、どのような変更を加えることができるかを制御する必要があります。認証と認証を区別するものとWHOの区別。
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-BY」、「MNT-ROUTES」、または「MNT-lower」属性。これらのメンテナーオブジェクトには、「auth」属性が含まれています。AUTH属性には、請求されたアイデンティティと、クレームの認証に使用される公共暗号化キーの請求されたアイデンティティと何らかの形式を含む認証方法とデータが含まれています。
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.
リポジトリオブジェクトには、アクセスメソッドを記述する属性とリポジトリのサポートされている認証方法も含まれています。「クエリアドレス」属性は、ホスト名とクエリの指示に使用されるポート番号を提供します。「Response-Auth-Type」属性は、クエリに応答するときにリポジトリが使用できる認証タイプを提供します。「送信アドレス」属性は、ホスト名とリポジトリにオブジェクトを送信するために使用されるポート番号を提供します。「submit-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
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
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.
Query-Addressこの属性は、クエリを指示するためのURLを提供します。「RPS-Query」または「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.
Response-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.
submit-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.
Repository-Certこの属性は、RPSLキーキャットオブジェクトの形で公開キー証明書への参照を提供します。この属性は、リポジトリが複数の署名方法を使用できるようにすることができます。
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.
ハートビートインターバルハートビートメタオブジェクトは、示されている間隔ごとに1つのハートビートメタオブジェクトの速度でこのリポジトリによって送信されます。この属性の値は、「dddd hh：mm：ss」という形式で表されるものとします。ここで、「dddd」は日数を表し、「hh」は「mm」分、「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.
期限切れの期間、リポジトリからハートビートまたは新しい登録が受信されない場合、このリポジトリからのオブジェクトは認可されていないと見なされ、承認目的で使用できません。この属性の値は、「dddd hh：mm：ss」という形式で表されるものとします。ここで、「dddd」は日数を表し、「hh」は「mm」分、「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」、および「ルート」、「as block」、「as block」、「route」があるオブジェクトタイプです。別のリポジトリにオブジェクトを置くことを容易にするために、「委任された」属性が追加されます。
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-by」のみが考慮されます。
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委任：熟している...出典：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は、指定された範囲を熟したリポジトリに重複する、より特定のINETNUMオブジェクトのストレージを単純に委任するだけです。このInetnumの正確な一致は、熟したリポジトリにも存在する可能性があり、メンテナーオブジェクトを参照する属性のフックを提供します。この場合、RIPEリポジトリにオブジェクトを追加すると、IANA INETNUMオブジェクトの「MNT-lower」、「MNT-Routes」、および「MNT-by」フィールドは考慮されません。代わりに、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.
No-auth：このデータは、認証モデルの初期遷移使用中にリポジトリに追加されましたが、承認は、完全性が「承認」されていない他のオブジェクトに依存していました。このような追加は移行中に許可されていますが、後で許可されます。
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-failed：権威あるリポジトリは、認可をチェックしていません。もしそうなら、承認は失敗したでしょう。この属性は、オブジェクトをローカルストレージに配置する前にミラーリングしているリポジトリによって追加されたり、トランザクションをさらに伝播するために使用されるカプセル化メタオブジェクトにこの属性を追加することもできます。許可を強制しなかったことが意図的であり、移行の一部である場合（たとえば、警告のみ）、権威あるリポジトリは、トランザクションをさらに伝播するために使用されるカプセル化メタオブジェクトにこの属性を追加する場合があります。
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-by」属性によって参照されるメンテナーによって許可されない限り、別のオブジェクトが上書きできません。整合性属性が「承認された」以外のものである場合、オブジェクトは、適切に承認された追加であったトランザクションによって上書きまたは削除される可能性があります。
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. トランザクションシーケンス交換は、特定の一連のトランザクションのリクエストです。多くの場合、リクエストは、最後のトランザクションのミラーに知られている最新のシーケンス番号のものです。これはポーリングで使用されます。
3. Transaction flooding is accomplished through a unicast adjacency.
3. 取引洪水は、ユニキャストの隣接を通じて達成されます。
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.
コミットリクエストは、複数の代替リポジトリに送信できます。1つのコミット完了応答は、トランザクションが完了したことを肯定的な確認で提出者に応答するのに十分です。ただし、リポジトリまたは提出者には、オプションで複数の必要がある場合があります。
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.
データベースの変更を送信するための事実上の方法は、電子メールによるものです。この方法は、外部アプリケーションによってサポートされる必要があります。Meritは、PGP-From認証方法をRADB（[4]の「PGPKEY」に置き換えた）に追加しました。ここでは、メールヘッダーは本質的に無視され、メールメッセージの本文に署名する必要があります。
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つの「タイムスタンプ」と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：mm：ss [ / - ] xx：yy」です。ここで、「yyyy」は4桁の年を指定します。「mm」は月を表します。、「mm」、ss "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.
トランザクションの送信に使用されるプロトコル、およびローカルでコミットされたトランザクションの確認の受信には、このドキュメントでは指定されていません。このプロトコルは、提出されたテキストの周りに追加のカプセルを定義する場合があります。このセクションの残りの部分は、そのようなプロトコルの1つの例を示しています。実装は、別のカプセル化を自由に選択できます。
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」Meta-Objectには、次の属性が含まれる場合があります。
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.
Response-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".
Transaction-Confirm-Typeこの属性はオプションで単一です。確認型キーワードを提供する必要があります。キーワードは、「なし」、「レガシー」、「通常」、「コミット」です。確認タイプの後に、オプション「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.
「Transaction-Submit-End Meta-Objectは、同じ名前で単一の属性で構成されています。同じデータベース名と識別子を対応する「トランザクションサブミット - ビグイン」属性と識別子を含める必要があります。
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」Meta-Objectには、次の属性がある場合があります。
transaction-confirm This attribute is mandatory and single. It contains the database name and identifier associated with the transaction.
Transaction-confirmこの属性は必須で単一です。トランザクションに関連付けられたデータベース名と識別子が含まれています。
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.
確認された操作この属性はオプションで複数です。キーワードの1つが含まれています。「追加」、「削除」、または「変更」に続いて、オブジェクトタイプと操作されたオブジェクトのキーフィールドが続きます。
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.
コミットステータスこの属性は必須で単一です。「成功した「エラー」、または「保持」のキーワードの1つが含まれています。「エラー」キーワードの後にオプションのテキスト文字列が続く場合があります。「保有」キーワードは、認証のための依存オブジェクトを含むリポジトリが有効期限を切ったときに返されます。。
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.
トランザクションを再配布するために、各リポジトリは1つ以上の他のリポジトリとの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整数です。同じ発信リポジトリによって配布される連続したトランザクションには、連続したシーケンス番号があります。レジストリによって発信される最初のトランザクションには、シーケンス番号1が割り当てられます。各リポジトリは、少なくとも64ビットの署名されていない整数まで描かれた範囲から描かれたシーケンス番号を使用する必要があります。
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：mm：ss [ / - ] xx：yy」です。ここで、「yyyy」は4桁の年を指定します。「mm」は月を表します。、「mm」、ss "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-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:
リモートリポジトリがリモートリポジトリが再作成できない方法で提出されたオブジェクトを変更する必要がある場合、「Override-Objects」Meta-Objectを追加して、これらのオブジェクトの変更されたバージョンを追加できます。修正の例は、NICハンドルの自動割り当てです。「Override-Objects」メタオブジェクトには、次の属性が含まれています。
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.
トランザクションを他のリポジトリに再配布する準備として、発信元リポジトリは次のプロトコルカプセル化を実行する必要があります。このプロトコルのカプセル化には、以下に説明する「転送メソッド」の1つに従って再分配されたテキストを変換することが含まれます。
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:
変換された再配分されたテキストは、最初に1つの「トランザクションビン」メタオブジェクトで準備されています。1つのNewline文字は、このメタオブジェクトを再配布されたテキストから分離します。このメタオブジェクトには、次の属性があります。
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.
Transfer-Methodこの属性はオプションで一本値です。その値は「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.
「トランザクション」メタオブジェクトと変換された再配分されたテキストは、「送信されたテキスト」と呼ばれるものを構成します。元のリポジトリは、送信されたテキストを1つ以上のピアリポジトリに配布する場合があります。
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. 「トランザクション」メタオブジェクトを脱カプセル化し、「トランザクションビグイン」メタオブジェクトで指定された転送メソッド属性の値に従って元の再配布されたテキストをデコードする必要があります。
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. トランザクションの構文的正確性を検証する必要があります。実装により、RPSLとの構文の適合性の構成可能レベルが可能になる場合があります[1]。これにより、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依存性」メタオブジェクトのトランザクションシーケンス番号内にある最新のオブジェクト（必要に応じて以前のバージョンに戻ることによって）のみを使用する必要があります。
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」Meta-Objectには、次の属性が含まれている場合があります。
transaction-request This attribute is mandatory and single. It contains the name of the database whose transactions are being requested.
Transaction-Requestこの属性は必須で単一です。トランザクションが要求されているデータベースの名前が含まれています。
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.
「Transaction-Request」オブジェクトを受信すると、リポジトリは次のアクションを実行します。「シーケンスビグイン」属性が指定されていない場合、リポジトリはリクエストの最初のシーケンス番号が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).
少なくとも1つのトランザクションを発信した各リポジトリは、定期的に「ハートビート」メタオブジェクトを送信する必要があります。このメタオブジェクトの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：mm：ss [ / - ] xx：yy」です。ここで、「yyyy」は4桁の年を指定します。「mm」は月を表します。、「mm」、ss "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つ以上のピアリポジトリからコミット確認を要求する場合があります。「Commit-Request」には2つの属性が含まれています。
commit-request This attribute is mandatory and single. It contains the name of the database for whom a commit confirmation is being requested.
Commit-Requestこの属性は必須で単一です。コミット確認が要求されているデータベースの名前が含まれています。
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.
「Commit-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）、リポジトリは、トランザクションの保留中のコミットリクエストが存在するかどうかを確認する必要があります。もしそうなら、それは要求者に「コミットレスポンス」メタオブジェクトを送信する必要があります。このメタオブジェクトには3つの属性があります。コミットレスポンスこの属性は必須で単一です。コミットレスポンスが送信されているデータベースの名前が含まれています。
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.
コミットステータスこの属性は必須で単一です。「保持されている」、「エラー」、または「成功した」キーワードの1つが含まれています。「エラー」キーワードの後に、オプションのテキスト文字列が続く場合があります。「保留」キーワードは、承認のための依存オブジェクトを含むリポジトリが有効になったときに返されます。
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. <class> .dbこのオプションファイルが存在する場合、x.dbのrpslオブジェクトがclass <class>のrpslオブジェクトが含まれています。ファイルの形式は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-Labelこのファイルには、スナップショット時のタイムスタンプとリポジトリの最新のシーケンス番号を記録するトランザクションラベルオブジェクトが含まれています。
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.
これらの各ファイルは、オプションで圧縮されているGZIPを圧縮できます。これは、ファイル名に接尾辞.gzを追加することによって表されます。これらの各ファイルは、オプションでPGP署名されています。この場合、ASCII装甲とプラットフォームに依存しないテキストモードを備えた分離された署名は、署名されているファイルのファイル名にappending .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.
スナップショットを正常に再生した後、リポジトリは、スナップショット内のオブジェクトの1つの以前のバージョンに依存する3番目のリポジトリからトランザクションを受信する可能性があります。これは、ダウンロードされているリポジトリの有効期限内にのみ発生する可能性があり、さらに可能なネットワークパーティション期間があります。この依存関係は、リポジトリがRPSの承認/認証を再確認したい場合にのみ重要です。この場合、3つの許可された選択肢があります。最も単純な代替案は、リポジトリがトランザクションを受け入れ、整合性の「no-auth」でマークすることです。2番目の選択肢は、この期間中に信頼できるリポジトリのみをピアにし、信頼できるリポジトリと同じ完全性を持つトランザクションを受け入れることです（おそらく「承認された」）。最も好ましい代替品は、最大のスナップショットをダウンロードすることではなく、少なくとも数日年齢のリポジトリが期限切れになると、少なくとも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オブジェクト自体は署名されていませんが、トランザクション本体全体に署名されていることに注意してください。レジストリ間でトランザクションを交換する場合、再配置されたテキストの最初の「リポジトリシグネチャ」メタオブジェクトの前に、メタオブジェクト（たとえば「auth依存性」）も署名されています。
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.
送信者が提供する認証方法がメッセージを処理するリポジトリによって使用されない場合でも、トランザクションは署名を含めて無傷のままでなければなりません。元のリポジトリは、トランザクションからクリアテキストパスワードの署名を削除し、それをキーワード「Clear-Text-PassWD」に置き、その後メンテナーのIDに置き換えることを選択する場合があります。
signature: clear-text-passwd <maintainer-name>
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はライン指向です。ラインの継続がサポートされていますが、ほとんどの属性は単一の行に適合します。属性名の後には、コロンが続き、次に任意の量のホワイトスペース、次に属性値が続きます。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オブジェクトは属性のセットです。オブジェクトは、1つ以上の空白線によって互いに分離されます。完全な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
ルート：140.222.0.0/16 DESCR：ANS通信原点：AS1673メンバー：RS-AnsospFagGregate MNT-BY：ANS変更：tck@ans.net 19980115出典：ANS
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. オブジェクトを提出する2.承認チェック3.承認に必要なシーケンス4.再配布
Figure 1: Initial Object Submission and Redistribution
図1：初期オブジェクトの提出と再配布
transaction-submit-begin: ANS 1 response-auth-type: PGP transaction-confirm-type: normal
トランザクション - サブリット - ビグイン：ANS 1 Response-Auth-Type：PGP Transaction-Confirm-Type：正常
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-BY：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
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
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-BY：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-----
auth-dependency: ARIN
sequence: 555
timestamp: 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-----
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).
上記のリポジトリ署名は、別のファイルの署名が分離されており、実例のみであることに注意してください。リポジトリ署名は、「トランザクションラベル」メタオブジェクト（を含む）から最初の「リポジトリシグネチャー」メタオブジェクトの前の最後の空白行までカバーします（最後の空白線と「リポジトリシグネチャ」オブジェクトを除く）。
transaction-begin: 1276 transfer-method: plain
トランザクションビン：1276転送メソッド：プレーン
transaction-label: ANS
sequence: 6666
timestamp: 19990401 13:30:10 +05:00
integrity: authorized
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-BY：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-----
auth-dependency: ARIN
sequence: 555
timestamp: 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.
Transaction-BeginとTransaction-Labelオブジェクトの分離により、さまざまな洪水ピーリングで異なるエンコーディングが可能になります。
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. トランザクションの再配布2.シーケンス番号を使用したトランザクションの時点でのフルDBに対する認証を再確認します3.許可パス/失敗4.オプションで署名してから再配布します
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. トランザクションの再配布2.シーケンス番号を使用したトランザクションの時点でのフルDBに対する認証を再確認します。
Figure 3: Redistribution to Lightweight Mirrors
図3：軽量ミラーへの再配布
B Technical Discussion
B技術的な議論
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.
このドキュメントは、特定のソフトウェア設計、プログラミング言語の選択、または基礎となるデータベースまたは基礎となるオペレーティングシステムを義務付けていません。例には、実例のためにのみ説明されています。
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つの主要な方法があります。電子メールはサーバーに送信できます。この方法は非推奨かもしれませんが、少なくとも移行中にサポートする必要があります。2番目の方法が推奨され、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非構造化シングルラインクエリ形式を使用したクエリを除き、クエリを含む他のすべての操作のために予約された数値スペースではなく2番目のポートを使用することが賢明かもしれません。
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.
BSD SendMailのスタイルで、専用のデーモン、またはBSD INETDなどの汎用デーモンを介して起動する、接続の取り扱いを処理するスタイルには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ファイルと、Traversalのインデックスファイルの維持されたBerkeley 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.
個別のトランザクションログを維持する必要があります。ある年齢を超えて、オブジェクトの古いバージョンと古いトランザクションログエントリを削除できますが、おそらくアーカイブするのが賢明です。
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.
大規模なトランザクションをコミットしたり、全体としてそれらを拒否する機能は、単純なデータベース設計の問題を引き起こします。この形式のコミット操作は、メモリマップされたファイルを使用して非常に簡単にサポートできます。変更は、仮想メモリのみで行うことができ、その後、コミットまたは廃棄されます。
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.
読み取りのロックは必須ではありません。書き込みアクセスの前にロックすることが不可欠です。ロックする最も簡単なアプローチは、データベースの粒度またはデータベースとオブジェクトタイプの粒度でロックすることです。より細かいロック粒度も実装できます。複数のデータベースがあるため、デッドロックの回避を考慮する必要があります。通常のデッドロック回避メカニズムは、単一の操作で必要なすべてのロックを取得するか、規定の順序でロックを取得することです。
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.
リポジトリのオペレーターが独自のリポジトリを反映する理由はたくさんあります。おそらく最も明白なのは、冗長性と災害復旧の比較的容易さです。もう1つの理由は、少数の実装（ただし複数）の広範な使用と、主要なリポジトリソフトウェアのリリースがトランザクションに完全にコミットする前にトランザクションを受け入れることを保証したいという要望です。
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.
コミットミラー確認が必要な別のソフトウェア実装を使用してミラーがセットアップされている場合、ソフトウェアのバグが失敗したトランザクションは、バグがどこにでも固定されるまですべてのトランザクションのリモート処理を停止するのではなく、他のトランザクションが無期限に続行できるように延期されます。
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.
リポジトリは、他のリポジトリのサブセットを信頼する可能性があります。この信頼は、データの完全なセットのミラー画像を維持するために必要なリポジトリの処理量を減らすことができます。たとえば、リポジトリのサブセットは、合理的なセキュリティ対策を講じるという点で信頼できる場合があり、組織自体はデータを変更しないという整合性を持ち、これらのリポジトリは同様のリポジトリの限られたセットのみを信頼しています。これらのリポジトリのいずれかがトランザクションシーケンスを受け取り、認可チェックを繰り返す場合、リポジトリはチェックを繰り返す必要はないと信じる他の主要なリポジトリです。さらに、信頼は、処理の削減にある程度の利益を得るために相互に存在する必要はありません。
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.
トランザクションシーケンスがリポジトリからリポジトリに渡されると、各リポジトリは転送する前にトランザクションシーケンスに署名します。受信リポジトリが、信頼できるリポジトリがトランザクションシーケンスに署名していることを発見した場合、信頼できるリポジトリが先行リポジトリを信頼するか、承認チェックを繰り返したため、認可されたと見なすことができます。
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.
かなりの量の不揮発性ストレージが必要になります。現在、1日あたり推定100トランザクションがあります。ストレージが限られた数の書き込みを備えたフラッシュメモリである場合、またはフラッシュへの書き込みを避ける他の理由がある場合、ルーターは数日ごとに不揮発性コピーを更新することができます。クラッシュが発生した場合に更新を取得するためにトランザクションシーケンスリクエストを行うことができ、数日間の延期された書き込みを失った後、数百の更新しか返されません。ルーターは、トランザクションの頻繁なまたは連続的な供給を引き受けることができます。
Alternately, router filters can be reconfigured periodically as they are today.
あるいは、ルーターフィルターは、現在のように定期的に再構成できます。
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. 「近いリアルタイムミラーリング」トランザクション交換の形式を変更して、このドキュメントの仕様に準拠します。
2. Implement commit protocol and confirmation support.
2. コミットプロトコルと確認サポートを実装します。
3. Implement remote recheck of authorization. Prior to this step all repositories must be trusted.
3. 許可のリモート再確認を実装します。このステップの前に、すべてのリポジトリを信頼する必要があります。
4. Allow further decentralization of the repositories.
4. リポジトリのさらに分散化を許可します。
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.
また、ソフトウェアに再配布可能（ポリシーオブジェクトなど）と学歴のないオブジェクト（人）の両方を含めることはできません。これは、再現できないオブジェクトなしでこれらのトランザクションの署名を検証する方法がないためです。
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.、Meyer、D.、Bates、T.、Karrenberg、D.、M。Terpsstra、「ルーティングポリシー仕様言語」、RFC 2622、6月1999年。
[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] Bates、T.、Gerich、E.、Joncheray、L.、Jouanigot、J-M.、Karrenberg、D.、Terpsstra、M。and J. Yu、「ルーティングレジストリにおける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.、Meyer、D。、およびS. Murphy、「ルーティングポリシーシステムセキュリティ」、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
Curtis Villamizar Avici Systems Email：curtis@avici.com
Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU
Cengiz alaettinoglu isiメール：cengiz@isi.edu
Ramesh Govindan ISI EMail: govindan@ISI.EDU
Ramesh Govindan ISIメール：govindan@isi.edu
David M. Meyer Cisco EMail: dmm@cisco.com
David M. Meyer Cisco Email：dmm@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。