Network Working Group C. Villamizar
Request for Comments: 2769 Avici Systems
Category: Standards Track C. Alaettinoglu
R. Govindan
ISI
D. Meyer
Cisco
February 2000
Network Working Group C. Villamizar
Request for Comments: 2769 Avici Systems
Category: Standards Track C. Alaettinoglu
R. Govindan
ISI
D. Meyer
Cisco
February 2000
Routing Policy System Replication
路由策略系统复制
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”应按照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定义了用于在路由策略系统中表示信息的基础语言。路由策略系统信息的存储库称为路由注册表。路由注册表提供了一种交换信息的方法，这些信息是解决许多对Internet运行非常重要的问题所必需的。路由策略系统的实现和部署必须保持一定程度的完整性才能发挥任何作用。路由策略系统安全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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 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分布在不太可信的存储库中，也可以避免损害数据完整性和安全性。
Two methods of authenticating the routing registry information have been proposed.
提出了两种验证路由注册表信息的方法。
authorization and authentication checks on transactions: The integrity of the routing registry data is insured by repeating authorization checks as transactions are processed. As transactions are flooded each remote registry has the option to repeat the authorization and authentication checks. This scales with the total number of changes to the registry regardless of how many registries exist. When querying, the integrity of the repository must be such that it can be trusted. If an organization is unwilling to trust any of the available repositories or mirrors they have the option to run their own mirror and repeat authorization checks at that mirror site. Queries can then be directed to a mirror under their own administration which presumably can be trusted.
事务的授权和身份验证检查：在处理事务时，通过重复授权检查来确保路由注册表数据的完整性。当事务被淹没时，每个远程注册表都可以选择重复授权和身份验证检查。无论存在多少个注册中心，这都会随着注册中心更改的总数进行缩放。查询时，存储库的完整性必须确保它是可信的。如果组织不愿意信任任何可用的存储库或镜像，他们可以选择运行自己的镜像，并在镜像站点重复授权检查。然后可以将查询定向到其自己管理下的镜像，该镜像可能是可信的。
signing routing registry objects: An alternate which appears on the surface to be attractive is signing the objects themselves. Closer examination reveals that the approach of signing objects by itself is flawed and when used in addition to signing transactions and rechecking authorizations as changes are made adds nothing. In order for an insertion of critical objects such as inetnums and routes to be valid, authorization checks must be made which allow the insertion. The objects on which those authorization checks are made may later change. In order to later repeat the authorization checks the state of other objects, possibly in other repositories would have to be known. If the repository were not trusted then the change history on the object would have to be traced back to the object's insertion. If the repository were not trusted, the change history of any object that was depended upon for authorization would also have to be rechecked. This trace back would have to go back to the epoch or at least to a point where only trusted objects were being relied upon for the authorizations. If the depth of the search is at all limited, authorization could be falsified simply by exceeding the search depth with a chain of authorization references back to falsified
对路由注册表对象进行签名：表面上看起来很吸引人的另一种方法是对对象本身进行签名。仔细检查发现，单独对对象进行签名的方法是有缺陷的，当在进行更改时，除了对事务进行签名和重新检查授权之外，使用这种方法不会增加任何效果。为了使关键对象（如inetnums和routes）的插入有效，必须进行允许插入的授权检查。对其进行授权检查的对象稍后可能会更改。为了以后重复授权检查其他对象的状态，可能需要知道其他存储库中的其他对象的状态。如果存储库不受信任，那么对象上的更改历史必须追溯到对象的插入。如果存储库不受信任，则还必须重新检查授权所依赖的任何对象的更改历史记录。这种追溯必须追溯到那个时代，或者至少追溯到授权只依赖于可信对象的点。如果搜索的深度是有限的，那么授权可能会被伪造，只需超过搜索深度，并将一系列授权引用返回到伪造
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.
物体。这将是非常低效的。简单地验证对象是否已签名并不能保证添加对象的操作已得到正确授权。
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数据对象与RIME保持不变，RPSL引用了RFC-1786[2]中记录的RIME-181规范。RPSL提供外部数据表示。数据可能以不同的方式存储在路由注册表内部。分布式注册表数据的完整性要求使用[3]中所述的RPSL的授权和身份验证附加项。
Some additions to RPSL are needed to locate all of the repositories after having located one of them and to make certain parameters selectable on a per repository basis readily available. These additions are described in Section 5.
需要对RPSL进行一些添加，以便在定位其中一个存储库之后定位所有存储库，并使某些参数在每个存储库的基础上随时可用。第5节介绍了这些新增内容。
Some form of encapsulation must be used to exchange data. The de-facto encapsulation has been that which the RIPE tools accept, a plain text file or plain text in the body of an RFC-822 formatted mail message with information needed for authentication derived from
必须使用某种形式的封装来交换数据。事实上的封装是成熟的工具可以接受的，即在RFC-822格式的邮件消息体中的纯文本文件或纯文本，其中包含从中派生的身份验证所需的信息
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.
邮件标题。Merit使用纯文本文件的PGP签名部分或邮件消息正文的PGP签名部分稍微修改了这一点。
The exchange that occurs during flooding differs from the initial submission. In order to repeat the authorization checks the state of all repositories containing objects referenced by the authorization checks needs to be known. To accomplish this a sequence number is associated with each transaction in a repository and the flooded transactions must contain the sequence number of each repository on which authorization of the transaction depends.
洪水期间发生的交换与初始提交不同。为了重复授权检查，需要知道包含授权检查引用的对象的所有存储库的状态。为了实现这一点，序列号与存储库中的每个事务相关联，并且被淹没的事务必须包含事务授权所依赖的每个存储库的序列号。
In order to repeat authorization checks it must be possible to retrieve back revisions of objects. How this is accomplished is a matter local to the implementation. One method which is quite simple is to keep the traversal data structures to all current objects even if the state is deleted, keep the sequence number that the version of the object became effective and keep back links to prior versions of the objects. Finding a prior version of an object involves looking back through the references until the sequence number of the version of the object is less than or equal to the sequence number being searched for.
为了重复授权检查，必须能够检索对象的修订版本。如何实现这一点是实施的局部问题。一种非常简单的方法是，即使状态被删除，也将遍历数据结构保留到所有当前对象，保留对象版本生效的序列号，并保留到对象先前版本的链接。查找对象的先前版本涉及通过引用进行回溯，直到对象版本的序列号小于或等于正在搜索的序列号。
The existing very simple forms of encapsulation are adequate for the initial submission of a database transaction and should be retained as long as needed for backward compatibility. A more robust encapsulation and submission protocol, with optional confirmation is defined in Section 6.1. An encapsulation suitable for exchange of transaction between repositories is addressed in Section 6. Query encapsulation and protocol is outside the scope of this document.
现有的非常简单的封装形式对于数据库事务的初始提交是足够的，并且应该在需要向后兼容时保留。第6.1节定义了一个更健壮的封装和提交协议，并提供可选的确认。第6节介绍了适合于存储库之间事务交换的封装。查询封装和协议不在本文档的范围内。
3 Authentication and Authorization
3认证和授权
Control must be exercised over who can make changes and what changes they can make. The distinction of who vs what separates authentication from authorization.
必须控制谁可以做出改变以及他们可以做出什么改变。身份验证与授权之间的区别。
o Authentication is the means to determine who is attempting to make a change.
o 身份验证是确定谁试图进行更改的手段。
o Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.
o 授权是确定是否允许通过特定身份验证检查的事务执行给定的操作。
A submitted transaction contains a claimed identity. Depending on the type of transaction, the authorization will depend on related objects.
提交的事务包含声明的标识。根据事务的类型，授权将取决于相关对象。
The "mnt-by", "mnt-routes", or "mnt-lower" attributes in those related objects reference "maintainer" objects. Those maintainer objects contain "auth" attributes. The auth attributes contain an authorization method and data which generally contains the claimed identity and some form of public encryption key used to authenticate the claim.
这些相关对象中的“mnt by”、“mnt routes”或“mnt lower”属性引用“maintainer”对象。这些维护者对象包含“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.
每个存储库可能都有一个“expire”属性。expire属性用于确定在依赖于存储库的本地事务可以继续之前，是否必须更新存储库。
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.
repository对象还包含描述存储库的访问方法和支持的身份验证方法的属性。“查询地址”属性提供用于指导查询的主机名和端口号。“response auth type”属性提供存储库在响应查询时可能使用的身份验证类型。“提交地址”属性提供用于将对象提交到存储库的主机名和端口号。“提交身份验证类型”属性提供存储库在响应提交时可能使用的身份验证类型。
5 Additions to RPSL
5对RPSL的补充
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.
属性可以是强制性的，也可以是可选的。它们可以是单个或多个。一个或多个属性可能是键字段的一部分。某些属性可能具有唯一性的要求。
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
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
存储库密钥强制单个查询地址强制多响应身份验证类型强制多提交地址强制多提交身份验证类型强制多存储库证书强制多过期强制单心跳间隔强制单描述可选多备注可选多管理员c强制多个tech-c强制多个通知可选多个mnt由强制多个更改强制多个源强制单个
In the above object type only a small number of the attribute types are new. These are:
在上述对象类型中，只有少数属性类型是新的。这些是：
repository This attribute provides the name of the repository. This is the key field for the object and is single and must be globally unique. This is the same name used in the source attribute of all objects in that repository.
存储库此属性提供存储库的名称。这是对象的关键字段，是单个字段，并且必须全局唯一。这与该存储库中所有对象的源属性中使用的名称相同。
query-address This attribute provides a url for directing queries. "rps-query" or "whois" can be used as the protocol identifier.
查询地址此属性提供用于定向查询的url。“rps查询”或“whois”可用作协议标识符。
response-auth-type This attribute provides an authentication type that may be used by the repository when responding to user queries. Its syntax and semantics is same as the auth attribute of the maintainer class.
响应身份验证类型此属性提供存储库在响应用户查询时可能使用的身份验证类型。其语法和语义与maintainer类的auth属性相同。
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.
提交身份验证类型此属性提供存储库在提交注册时允许用户使用的身份验证类型。
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.
heartbeat interval heartbeat元对象由该存储库以每个指定间隔发送一个heartbeat元对象的速率发送。该属性的值应以“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.
请注意，上面提到的“heartbeat”元对象，与本文档中描述的其他元对象一样，是交换信息协议的一部分，但不放在数据库本身中。有关heartbeat元对象的描述，请参见第7.3.2节。
The remaining attributes in the repository object are defined in RPSL.
repository对象中的其余属性在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对象类型，特定条目应仅出现在一个存储库中。这些是具有自然层次结构的对象类型，“as块”、“aut num”、“inetnum”和“路由”。为了便于将对象放入另一个存储库，添加了“委托”属性。
delegated The delegated attribute is allowed in any object type with a hierarchy. This attribute indicates that further searches for object in the hierarchy must be made in one or more alternate repositories. The current repository may be listed. The ability to list more than one repository serves only to accommodate grandfathered objects (those created prior to using an authorization model). The value of a delegated attribute is a list of repository names.
委托在具有层次结构的任何对象类型中都允许委托属性。此属性表示必须在一个或多个备用存储库中进一步搜索层次结构中的对象。可能会列出当前存储库。列出多个存储库的功能仅用于容纳grandfathered对象（在使用授权模型之前创建的对象）。委派属性的值是存储库名称的列表。
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的精确匹配也可能存在于成熟的存储库中，以便为引用maintainer对象的属性提供挂钩。在这种情况下，将对象添加到成熟存储库时，不会考虑IANA inetnum对象中的“mnt lower”、“mnt ROTES”和“mnt by”字段，而是使用成熟副本中的值。
The "integrity" attribute can be contained in any RPSL object. It is intended solely as a means to facilitate a transition period during which some data has been moved from repositories prior to the use of a strong authorization model and is therefore questionable, or when some repositories are not properly checking authorization.
“完整性”属性可以包含在任何RPSL对象中。它仅用于促进过渡期，在此期间，一些数据在使用强授权模型之前已从存储库中移动，因此存在问题，或者某些存储库未正确检查授权。
The "integrity" attribute may have the values "legacy", "no-auth", "auth-failed", or "authorized". If absent, the integrity is considered to be "authorized". The integrity values have the following meanings:
“完整性”属性的值可能为“遗留”、“无身份验证”、“身份验证失败”或“已授权”。如果不存在，完整性将被视为“授权”。完整性值具有以下含义：
legacy: This data existed prior to the use of an adequate authorization model. The data is highly suspect.
遗留：此数据在使用适当的授权模型之前就存在。这些数据非常可疑。
no-auth: This data was added to a repository during an initial transition use of an authorization model but authorization depended on other objects whose integrity was not "authorized". Such an addition is being allowed during the transition but would be disallowed later.
无授权：此数据是在使用授权模型的初始转换期间添加到存储库的，但授权依赖于完整性未“授权”的其他对象。这种添加在过渡期间是允许的，但稍后将被禁止。
auth-failed: The authoritative repository is not checking authorization. Had it been doing so, authorization would have failed. This attribute may be added by a repository that is mirroring before placing the object in its local storage, or can add this attribute to an encapsulating meta-object used to further propagate the transaction. If the failure to enforce authorization is intentional and part of a transition (for example, issuing warnings only), then the authoritative repository may add this attribute to the encapsulating meta-object used to further propagate the transaction.
身份验证失败：权威存储库未检查授权。如果它一直这样做，授权就会失败。此属性可以由在将对象放入其本地存储之前进行镜像的存储库添加，也可以将此属性添加到用于进一步传播事务的封装元对象中。如果强制授权的失败是故意的，并且是转换的一部分（例如，仅发出警告），那么权威存储库可以将此属性添加到用于进一步传播事务的封装元对象中。
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".
已授权：已通过授权检查。维护人员包含一个“reference by”属性，使用了存储库认为适当的身份验证形式，授权所需的所有对象都是完整性被“授权”的对象。
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”属性所引用的维护人员授权这样做。如果integrity属性不是“authorized”，则如果不存在完整性较差的对象，则任何事务都可以覆盖或删除该对象，而该事务本来是经过适当授权的添加。
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.
在这种转换过程中，未经适当授权添加的grandfathered数据和数据将成为建议，直到发生适当授权的添加。过渡后，将不再接受这种类型的添加。未经适当授权已添加的对象将保留，但将标记为替换对象。
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电子邮件封装提交的一个或一组对象。此表单仍然支持向后兼容。首选表单允许在提交中包含一些元信息，例如首选确认表单。如果使用任何一种封装，提交者将连接到存储库对象中指定的主机和端口。这允许立即确认。如果需要类似于现有成熟代码提供的接口的电子邮件接口，那么外部程序可以提供电子邮件接口。
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.
提交请求可以发送到多个备用存储库。一个提交完成响应足以向提交者提供事务已完成的肯定确认。但是，存储库或提交者可能需要不止一个。
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.
RIME-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 authentication方法添加到RADB（在[4]中替换为“pgpkey”），其中邮件头基本上被忽略，邮件正文必须经过pgp签名。
This specification defines a different encapsulation for transaction submission. When submitting a group of objects to a repository, a user MUST append to that group of objects, exactly one "timestamp" and one or more "signature" meta-objects, in that order.
此规范为事务提交定义了不同的封装。当将一组对象提交到存储库时，用户必须按照该顺序向该组对象添加一个“时间戳”和一个或多个“签名”元对象。
The "timestamp" meta-object contains a single attribute:
“timestamp”元对象包含一个属性：
timestamp This attribute is mandatory and single-valued. This attribute specifies the time at which the user submits the transaction to the repository. The format of this attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four digit year, "MM" represents the month, "DD" the date, "hh" the hour, "mm" the minutes, "ss" the seconds of the timestamp, and "xx" and "yy" represents the hours and minutes respectively that that timestamp is ahead or behind UTC.
时间戳此属性是必需的且为单值。此属性指定用户将事务提交到存储库的时间。此属性的格式为“YYYYMMDD hh:mm:ss[+/-]xx:yy”，其中“yyy”指定四位数的年份，“mm”表示月份，“DD”表示日期，“hh”表示小时，“mm”表示分钟，“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.
存储库可能会拒绝不包含“时间戳”元对象的事务。timestamp对象用于防止重放注册。如何实际使用这是一个局部问题。例如，只有当时间戳属性的值大于从该用户（维护者）收到的上一次注册中的时间戳属性时，存储库才能接受事务，或者存储库只能接受在其过期窗口内带有时间戳的事务。
Each "signature" meta-object contains a single attribute:
每个“签名”元对象都包含一个属性：
signature This attribute is mandatory and single-valued. This attribute, a block of free text, contains the signature corresponding to the authentication method used for the transaction. When the authentication method is a cryptographic hash (as in PGP-based authentication), the signature must include all text up to (but not including) the last blank line before the first "signature" meta-object.
签名此属性是必需的且为单值。此属性是一个自由文本块，包含与用于事务的身份验证方法相对应的签名。当身份验证方法是加密散列（如基于PGP的身份验证）时，签名必须包括第一个“签名”元对象前最后一个空行之前的所有文本（但不包括）。
A repository must reject a transaction that does not include any "signature" meta-object.
存储库必须拒绝不包含任何“签名”元对象的事务。
The group of objects submitted by the user, together with the "timestamp" and "signature" meta-objects, constitute the "submitted text" of the transaction.
用户提交的对象组与“时间戳”和“签名”元对象一起构成事务的“提交文本”。
The protocol used for submitting a transaction, and for receiving confirmation of locally committed transactions, is not specified in this document. This protocol may define additional encapsulations around the submitted text. The rest of this section gives an example of one such protocol. Implementations are free to choose another encapsulation.
本文档中未指定用于提交事务和接收本地提交事务确认的协议。该协议可以围绕提交的文本定义额外的封装。本节其余部分给出了一个此类协议的示例。实现可以自由选择其他封装。
The meta-objects "transaction-submit-begin" and "transaction-submit-end" delimit a transaction. A transaction is handled as an atomic operation. If any part of the transaction fails none of the changes take effect. For this reason a transaction can only operate on a single database.
元对象“transaction submit begin”和“transaction submit end”定义了一个事务。事务作为原子操作处理。如果事务的任何部分失败，则所有更改都不会生效。因此，事务只能在单个数据库上运行。
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”元对象可能包含以下属性。
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.
响应身份验证类型此属性是可选的和多个的。行的其余部分指定响应中可接受的身份验证类型。这用于请求由存储库以加密方式签名的响应。
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".
事务确认类型此属性是可选的，并且是单一的。必须提供确认类型关键字。关键词是“无”、“遗留”、“正常”、“提交”。确认类型后面可以跟着选项“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”元对象由一个同名的属性组成。它必须包含与相应的“transaction submit begin”属性相同的数据库名称和标识符。
Unless the confirmation type is "none" a confirmation is sent. If the confirmation type is "legacy", then an email message of the form currently sent by the RIPE database code will be returned on the socket (suitable for submission to the sendmail program).
除非确认类型为“无”，否则将发送确认。如果确认类型为“legacy”，则将在套接字上返回当前由成熟数据库代码发送的表单的电子邮件消息（适合提交给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”元对象可能具有以下属性。
transaction-confirm This attribute is mandatory and single. It contains the database name and identifier associated with the transaction.
事务确认此属性是必需的和单一的。它包含与事务关联的数据库名称和标识符。
confirmed-operation This attribute is optional and multiple. It contains one of the keywords "add", "delete" or "modify" followed by the object type and key fields of the object operated on.
已确认操作此属性为可选且多个。它包含一个关键字“添加”、“删除”或“修改”，后跟操作对象的对象类型和关键字段。
commit-status This attribute is mandatory and single. It contains one of the keywords "succeeded, "error", or "held". The "error" keyword may be followed by an optional text string. The "held" keyword is returned when a repository containing a dependent object for authorization has expired.
提交状态此属性是必需的和单一的。它包含一个关键字“succeed”、“error”或“hold”。“error”关键字后面可以跟一个可选文本字符串。“hold”关键字在包含授权从属对象的存储库过期时返回。
In order to redistribute transactions, each repository maintains a TCP connection with one or more other repositories. After locally committing a submitted transaction, a repository assigns a sequence number to the transaction, signs and encapsulates the transaction, and then sends one copy to each neighboring (or "peer") repository. In turn, each repository authenticates the transaction (as described in Section 7.6), may re-sign the transaction and redistributes the transaction to its neighbors. We use the term "originating repository" to distinguish the repository that redistributes a locally submitted transaction.
为了重新分发事务，每个存储库都与一个或多个其他存储库保持TCP连接。在本地提交提交的事务后，存储库为该事务分配一个序列号，签名并封装该事务，然后向每个相邻（或“对等”）存储库发送一个副本。反过来，每个存储库对事务进行身份验证（如第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.
本文档还指定了将事务重新分发到其他存储库的两种其他方法：用于初始化新注册表的数据库快照格式和镜像使用的轮询技术。
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:
原始存储库必须在提交的文本前加上一个“事务标签”元对象。此元对象包含以下属性：
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:ss[+/-]xx:yy”，其中“yyy”指定四位数的年份，“mm”表示月份，“DD”表示日期，“hh”表示小时，“mm”表示分钟，“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:
原始存储库可以将一个或多个“auth dependency”元对象附加到提交的文本中。这些元对象用于指示原始注册表使用了哪些其他存储库的对象来验证提交的文本。“auth dependency”元对象应该从最首选的存储库排序到最不首选的存储库。远程存储库使用此顺序来连接具有相同完整性级别的对象的多个注册之间的中断。“auth dependency”元对象包含以下属性：
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 dependency此属性为强制且单值属性。它等于一个存储库名称，从中使用对象来授权/验证此事务。
sequence This attribute mandatory and single-valued. It equals the transaction sequence number of the dependent repository known at the originating repository at the time of processing this transaction.
将此属性排序为强制和单值。它等于处理此事务时原始存储库中已知的从属存储库的事务序列号。
timestamp This attribute mandatory and single-valued. It equals the timestamp of the dependent repository known at the originating repository at the time of processing this transaction.
此属性的时间戳必须是单值的。它等于处理此事务时原始存储库中已知的依赖存储库的时间戳。
If the originating repository needs to modify submitted objects in a way that the remote repositories can not re-create, it can append an "override-objects" meta-object followed by the modified versions of these objects. An example modification can be auto assignment of NIC handles. The "override-objects" meta-object contains the following attributes:
如果原始存储库需要以远程存储库无法重新创建的方式修改提交的对象，它可以附加一个“覆盖对象”元对象，后跟这些对象的修改版本。一个示例修改可以是NIC句柄的自动分配。“覆盖对象”元对象包含以下属性：
override-objects A free text remark.
用自由文本注释替代对象。
Other repositories may or may not honor override requests, or limit the kinds of overrides they allow.
其他存储库可能会也可能不会接受覆盖请求，或者限制它们允许的覆盖类型。
Following this, the originating repository must append exactly one "repository-signature" meta-object. The "repository-signature" meta-object contains the following attributes:
在此之后，原始存储库必须恰好附加一个“存储库签名”元对象。“repository signature”元对象包含以下属性：
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.
签名此属性是可选的且为单值。此属性是一个自由文本块，包含使用存储库对象的存储库证书属性中的密钥的存储库签名。当身份验证方法是加密哈希（如在基于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.
在准备将事务重新分发到其他存储库时，原始存储库必须执行以下协议封装。该协议封装可能涉及根据下面描述的“传输方法”之一转换重新分发的文本。
The transformed redistributed text is first prepended with exactly one "transaction-begin" meta-object. One newline character separates this meta-object from the redistributed text. This meta-object has the following attributes:
转换后的重新分发文本首先以一个“transaction begin”元对象作为前缀。一个换行符将此元对象与重新分发的文本分隔开。此元对象具有以下属性：
transaction-begin This attribute is mandatory and single. The value of this attribute is the length, in bytes, of the transformed redistributed text.
事务开始此属性是必需的且为单一属性。此属性的值是转换后的重新分发文本的长度（以字节为单位）。
transfer-method This attribute is optional and single-valued. Its value is either "gzip", or "plain". The value of the attribute describes the kind of text encoding that the repository has performed on the redistributed text. If this attribute is not specified, its value is assumed to be "plain". An implementation must be capable of encoding and decoding both of these types.
传输方法此属性是可选的且为单值。其值为“gzip”或“plain”。该属性的值描述存储库对重新分发的文本执行的文本编码类型。如果未指定此属性，则假定其值为“普通”。实现必须能够对这两种类型进行编码和解码。
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.
“transaction begin”元对象和转换后的重新分发文本构成了我们所谓的“传输文本”。原始存储库可以将传输的文本分发到一个或多个对等存储库。
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. 它必须解除“transaction begin”元对象的封装，然后根据“transaction begin”元对象中指定的transfer method属性值对原始重新分发的文本进行解码。
2. It should then extract the "transaction-label" meta-object from the transmitted text. If this transaction has already been processed, or is currently being held, the repository must silently discard this incarnation of the same transaction.
2. 然后，它应该从传输的文本中提取“事务标签”元对象。如果此事务已被处理，或当前处于保留状态，则存储库必须以静默方式放弃同一事务的此化身。
3. It should verify that the signature of the originating repository matches the first "repository-signature" meta-object in the redistributed text following the "auth-dependency" meta-objects.
3. 它应该验证原始存储库的签名是否与“auth dependency”元对象之后重新分发的文本中的第一个“repository signature”元对象匹配。
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 dependency”元对象中未提及的存储库中的对象。存储库还应仅使用“auth dependency”元对象的事务序列号内的最新对象（如有必要，可回滚到早期版本）。
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
要重新分发成功或失败的事务，存储库必须使用“transaction begin”对象封装（原始或修改的）重新分发的文本。此步骤基本上与
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.
存储库还可以显式请求属于指定原始存储库的一个或多个事务。这对于在存储库离线一段时间后进行跟踪非常有用。对于为最近接收的事务间歇性轮询存储库的镜像，它也很有用。
To request a range of transactions from a peer, a repository must send a "transaction-request" meta-object to the peer. A "transaction-request" meta-object may contain the following attributes:
要从对等方请求一系列事务，存储库必须向对等方发送“事务请求”元对象。“事务请求”元对象可能包含以下属性：
transaction-request This attribute is mandatory and single. It contains the name of the database whose transactions are being requested.
事务请求此属性是必需的且是单一的。它包含请求其事务的数据库的名称。
sequence-begin This attribute is optional and single. It contains the sequence number of the first transaction being requested.
序列开始此属性是可选的，并且是单一的。它包含被请求的第一个事务的序列号。
sequence-end This attribute is optional and single. It contains the sequence number of the last transaction being requested.
序列结束此属性是可选的，并且是单一的。它包含被请求的最后一个事务的序列号。
Upon receiving a "transaction-request" object, a repository performs the following actions. If the "sequence-begin" attribute is not specified, the repository assumes the request first sequence number to be 1. The last sequence number is the lesser of the value of the "sequence-end" attributed and the highest completed transaction in the corresponding database. The repository then, in order, transmits the requested range of transactions. Each transaction is prepared exactly according to the rules for redistribution specified in Section 7.3.
接收到“事务请求”对象后，存储库将执行以下操作。如果未指定“sequence begin”属性，则存储库将假定请求的第一个序列号为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.
在接收到“transaction response”元对象后，存储库可能会断开与对等方的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天。此元对象用于指示特定存储库的活跃性。存储库活跃度决定事务的保存时间（参见第7.6节）。
The "heartbeat" meta-object contains the following attributes:
“heartbeat”元对象包含以下属性：
heartbeat This attribute is mandatory and single. It contains the name of the repository which originates this meta-object.
heartbeat此属性是必需的且是单一的。它包含发起此元对象的存储库的名称。
sequence This attribute is mandatory and single. It contains the highest transaction sequence number that has been assigned by the repository.
序列此属性是必需的且是单一的。它包含存储库分配的最高事务序列号。
timestamp This attribute is mandatory and single. It contains the time at which this meta-object was generated. The format of this attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four digit year, "MM" represents the month, "DD" the date, "hh" the hour, "mm" the minutes, "ss" the seconds of the timestamp, and "xx" and "yy" represents the hours and minutes respectively that that timestamp is ahead or behind UTC.
时间戳此属性是必需的且是单一的。它包含生成此元对象的时间。此属性的格式为“YYYYMMDD hh:mm:ss[+/-]xx:yy”，其中“yyy”指定四位数的年份，“mm”表示月份，“DD”表示日期，“hh”表示小时，“mm”表示分钟，“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
在接收到heartbeat元对象后，存储库必须首先检查之前接收到的最新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.
消息时，存储库必须以静默方式放弃心跳消息。否则，它必须在heartbeat消息中记录时间戳和序列号，并在不修改的情况下将heartbeat消息重新分发到其每个对等存储库。
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.
如果心跳消息来自接收方之前未知的存储库，则接收方可以向其一个或多个对等方发送“事务请求”，以获取属于相应数据库的所有事务。如果心跳消息包含的序列号高于接收方处理的最高序列号，则接收方可向其一个或多个对等方发送“事务请求”，以获取属于相应数据库的所有事务。
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节）。本节描述了一个简单的请求-响应协议，通过该协议，存储库可以通过验证一个或多个其他存储库是否提交了事务来提供更有力的确认。此请求-响应协议的实现是可选的。
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:
在重新分发事务后，原始存储库可以通过向一个或多个对等存储库发送“提交请求”元对象来请求提交确认。“提交请求”包含两个属性：
commit-request This attribute is mandatory and single. It contains the name of the database for whom a commit confirmation is being requested.
提交请求此属性是必需的且为单一属性。它包含请求提交确认的数据库的名称。
sequence This attribute is mandatory and single. It contains the transaction sequence number for which a commit confirmation is being requested.
序列此属性是必需的且是单一的。它包含请求提交确认的事务序列号。
A repository that receives a "commit-request" must not redistribute the request. It must delay the response until the corresponding transaction has been processed. For this reason, the repository must keep state about pending commit requests. It should discard this state if the connection to the requester is lost before the response is sent. In that event, it is the responsibility of the requester to resend the request.
接收“提交请求”的存储库不得重新分发该请求。它必须延迟响应，直到处理了相应的事务。因此，存储库必须保持关于挂起的提交请求的状态。如果在发送响应之前与请求者的连接丢失，则应放弃此状态。在这种情况下，请求者有责任重新发送请求。
Once a transaction has been processed (Section 7.3), a repository must check to see if there exists any pending commit request for the transaction. If so, it must send a "commit-response" meta-object to the requester. This meta-object has three attributes:
一旦处理了事务（第7.3节），存储库必须检查是否存在该事务的任何未决提交请求。如果是这样，它必须向请求者发送一个“提交-响应”元对象。此元对象有三个属性：
commit-response This attribute is mandatory and single. It contains the name of the database for whom a commit response is being sent.
提交响应此属性是必需的且是单一的。它包含为其发送提交响应的数据库的名称。
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.
提交状态此属性是必需的和单一的。它包含关键字“保持”、“错误”或“成功”之一。“error”关键字后面可以跟一个可选的文本字符串。当包含授权依赖对象的存储库过期时，将返回“HOLD”关键字。
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中属于类<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此文件包含一个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.
这些文件中的每一个都可以通过uzip压缩。这是通过在文件名后面附加后缀.gz来表示的。这些文件中的每一个都可以选择性地进行PGP签名。在这种情况下，带有ASCII铠装和独立于平台的文本模式的分离签名存储在一个文件中，该文件的名称是通过将.sig附加到被签名文件的文件名来构造的。
In order to construct a repository's contents from a snapshot, a repository downloads these files. After uncompressing and checking signatures, the repository records these objects in its database. No
为了从快照构建存储库的内容，存储库将下载这些文件。解压缩和检查签名后，存储库将这些对象记录在其数据库中。不
RPS authorization/authentication is done on these objects. The transaction-label object provides the seed for the replication protocol to receive the follow on transactions from this repository. Hence, it is not crucial to download an up to the minute snapshot.
RPS授权/身份验证是在这些对象上完成的。transaction label对象为复制协议提供种子，以从此存储库接收后续事务。因此，下载最新快照并不重要。
After successfully playing a snapshot, it is possible that a repository may receive a transaction from a third repository that has a dependency on an earlier version of one of the objects in the snapshot. This can only happen within the expire period of the repository being downloaded, plus any possible network partition period. This dependency is only important if the repository wants to re-verify RPS authorization/authentication. There are three allowed alternatives in this case. The simplest alternative is for the repository to accept the transaction and mark it with integrity "no-auth". The second choice is to only peer with trusted repositories during this time period, and accept the transaction with the same integrity as the trusted repository (possibly as "authorized"). The most preferred alternative is not to download an up to the minute snapshot, but to download an older snapshot, at minimum twice the repositories expire time, in practice few days older. Upon replaying an older snapshot, the replication protocol will fetch the more current transactions from this repository. Together they provide the necessary versions of objects to re-verify rps authorization/authentication.
成功播放快照后，存储库可能会从依赖于快照中某个对象的早期版本的第三个存储库接收事务。这只能发生在正在下载的存储库的过期期内，再加上任何可能的网络分区期。只有当存储库希望重新验证RPS授权/身份验证时，此依赖关系才很重要。在这种情况下，有三种允许的替代方案。最简单的替代方法是存储库接受事务并用完整性标记为“no auth”。第二种选择是在此期间仅与受信任的存储库进行对等，并以与受信任的存储库相同的完整性（可能为“已授权”）接受事务。最首选的替代方法不是下载最新的快照，而是下载较旧的快照，至少是存储库过期时间的两倍，实际上要早几天。在重播较旧的快照时，复制协议将从此存储库中获取较新的事务。它们一起提供了重新验证rps授权/身份验证所需的对象版本。
The "signature" and "repository-signature" meta-objects represent signatures. Where multiple of these objects are present, the signatures should be over the original contents, not over other signatures. This allows signatures to be checked in any order.
“签名”和“存储库签名”元对象表示签名。如果存在多个此类对象，则签名应位于原始内容之上，而不是位于其他签名之上。这允许以任何顺序检查签名。
A maintainer can also sign a transaction using several authentication methods (some of which may be available in some repositories only).
维护人员还可以使用多种身份验证方法（其中一些可能仅在某些存储库中可用）对事务进行签名。
In the case of PGP, implementations should allow the signatures of the "signature" and "repository-signature" meta-objects to be either the detached signatures produced by PGP or regular signatures produced by PGP. In either case, ASCII armoring and platform-independent text mode should be used.
在PGP的情况下，实现应该允许“签名”和“存储库签名”元对象的签名是PGP生成的分离签名或PGP生成的常规签名。无论哪种情况，都应使用ASCII铠装和独立于平台的文本模式。
Note that the RPSL objects themselves are not signed but the entire transaction body is signed. When exchanging transactions among registries, the meta-objects (e.g. "auth-dependency") prior to the first "repository-signature" meta object in the redistributed text are also signed over.
请注意，RPSL对象本身没有签名，但整个事务体都有签名。在注册表之间交换事务时，在重新分发的文本中第一个“存储库签名”元对象之前的元对象（例如“身份验证依赖项”）也会被签名。
Transactions must remain intact, including the signatures, even if an authentication method provided by the submitter is not used by a repository handling the message. An originating repository may chose to remove clear text passwords signatures from a transaction, and replace it with the keyword "clear-text-passwd" followed by the maintainer's id.
事务必须保持完整，包括签名，即使处理消息的存储库没有使用提交者提供的身份验证方法。原始存储库可以选择从事务中删除明文密码签名，并将其替换为关键字“明文密码”，后跟维护者的id。
signature: clear-text-passwd <maintainer-name>
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对象是一组属性。对象之间用一个或多个空行隔开。完整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
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
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 submit begin”和“transaction submit end”元对象之间的请求，并将其封装为签名块，如以下示例所示：
+--------------+
| Transaction |
| signed by |
| submitter |
+--------------+
|
| 1
v
+---------------------+ 2
| Primary repository |---->+----------+
| identified by | | database |
| RPSL source |<----+----------+
+---------------------+ 3
|
| 4
v
+----------------+
| Redistributed |
| transaction |
+----------------+
+--------------+
| 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响应验证类型：PGP事务确认类型：正常
route: 140.222.0.0/16
descr: ANS Communications
origin: AS1673
member-of: RS-ANSOSPFAGGREGATE
mnt-by: ANS
changed: curtis@ans.net 19990401
source: ANS
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
timestamp: 19990401 10:30:00 +08:00
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-----
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.
签名覆盖从“transaction submit begin”对象后的第一个空行到“signature”元对象前的最后一个空行的所有内容。如果需要多个签名，通过电子邮件发送此区块并要求另一方添加签名区块并返回或提交交易将非常容易。由于获得多个签名的延迟，“时间戳”的准确性无法严格执行。在数据库的“过期”时间内强制执行准确性可能是一种合理的折衷。在方便性（允许更长时间获得多个签名）和增加重放攻击暴露时间之间进行权衡。
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
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
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
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
timestamp: 19990401 10:30:00 +08:00
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-----
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: ARIN
sequence: 555
timestamp: 19990401 13:30:08 +05:00
auth-dependency: RADB
sequence: 4567
timestamp: 19990401 13:27:54 +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-----
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
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
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
timestamp: 19990401 10:30:00 +08:00
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-----
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: ARIN
sequence: 555
timestamp: 19990401 13:30:08 +05:00
auth-dependency: RADB
sequence: 4567
timestamp: 19990401 13:27:54 +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-----
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.
在将事务发送到对等方之前，存储库会预先准备一个“transaction begin”元对象。“transaction begin”属性的值是事务中的八位字节数，不包括“transaction begin”元对象及其后的第一个空行。
Separating transaction-begin and transaction-label objects enables different encodings at different flooding peerings.
分离事务开始和事务标签对象可以在不同的对等点上使用不同的编码。
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.
轻型镜像必须信任从中获取提要的镜像。这是一个安全的假设，如果两者处于相同的管理之下（提供提要的镜像是由拥有路由器的同一ISP拥有的主机）。轻量级镜像只是检查相邻存储库的签名，以确保数据完整性。
+----------------+
| Redistributed |
| transaction |
+----------------+
|
| 1
v
+--------------------+ 2
| |---->+----------+
| Mirror repository | | database |
| |<----+----------+
+--------------------+ 3
|
| 4
v
+------------------+
|+----------------+|
|| Redistributed ||
|| transaction ||
|+----------------+|
| Optional |
| signature |
+------------------+
+----------------+
| 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。使用序号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?) | +----------+
+--------------------+
+----------------+
| 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。使用序号3在事务处理时根据完整数据库重新检查授权。授权通过/失败4。签名并重新分发5。只需查看镜像签名6。在没有授权检查的情况下应用更改
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.
与存储库服务器通信有两种主要方法。电子邮件可以发送到服务器。此方法可能不推荐使用，但至少需要在转换期间得到支持。首选第二种方法，直接连接到TCP套接字。
Traditionally the whois service is supported for simple queries. It might be wise to retain the whois port connection solely for simple queries and use a second port not in the reserved number space for all other operations including queries except those queries using the whois unstructured single line query format.
传统上，whois服务支持简单查询。最好仅为简单查询保留whois端口连接，并为所有其他操作（包括使用whois非结构化单行查询格式的查询除外）使用不在保留编号空间中的第二个端口。
There are two styles of handling connection initiation is the dedicated daemon, in the style of BSD sendmail, or launching through a general purpose daemon such as BSD inetd. E-mail is normally handled sequentially and can be handled by a front end program which will make the connection to a socket in the process as acting as a mail delivery agent.
有两种处理连接启动的方式，一种是专用守护程序，一种是BSD sendmail，另一种是通过通用守护程序（如BSD inetd）启动。电子邮件通常是按顺序处理的，可以由前端程序来处理，该程序将连接到进程中的套接字，充当邮件传递代理。
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文件和一组Berkeley DB维护的索引文件进行遍历。至少，删除或替换的实现方式需要改变。
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.
存储库的操作员可能镜像自己的存储库的原因有很多。最明显的可能是冗余和相对容易的灾难恢复。另一个原因可能是广泛使用少量实现（但不止一个）以及希望确保主要存储库软件版本在完全提交事务之前接受事务。
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.
需要大量的非易失性存储。目前估计每天有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.
person和role对象包含联系人信息。这些对象由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
默认情况下，不应重新分发person和role对象。如果提交文件在某个字段中包含电子邮件地址，例如更改的字段，而不是NIC句柄，则提交人应意识到他们正在允许重新分发该电子邮件地址，并且
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句柄的提交。
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.Terpstra，“路由策略规范语言”，RFC 2622，1999年6月。
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
[2] Bates，T.，Gerich，E.，Joncheray，L.，Jouanigot，J-M.，Karrenberg，D.，Terpstra，M.和J.Yu，“路由注册表中IP路由策略的表示（RIME-81++）”，RFC 17861995年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 27251999年6月。
[4] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC 2726, December 1999.
[4] Zsako，J.，“成熟数据库更新的PGP认证”，RFC2726，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系统电子邮件：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电子邮件：dmm@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。