RFC2769 日本語訳
2769 Routing Policy System Replication. C. Villamizar, C.Alaettinoglu, R. Govindan, D. Meyer. February 2000. (Format: TXT=95255 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
Routing Policy System Replication
Status of this Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
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.
Abstract
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.
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.
Villamizar, et al. Standards Track [Page 1] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 1] RFC 2769 Routing Policy System Replication February 2000
Table of Contents
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
Villamizar, et al. Standards Track [Page 2] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 2] RFC 2769 Routing Policy System Replication February 2000
1 Overview
1 Overview
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.
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.
Two methods of authenticating the routing registry information have been proposed.
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.
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
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
Villamizar, et al. Standards Track [Page 3] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 3] RFC 2769 Routing Policy System Replication February 2000
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.
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.
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.
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.
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 Data Representation
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 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].
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.
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.
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
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
Villamizar, et al. Standards Track [Page 4] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 4] RFC 2769 Routing Policy System Replication February 2000
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.
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.
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.
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.
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.
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.
3 Authentication and Authorization
3 Authentication and Authorization
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.
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 Authentication is the means to determine who is attempting to make a change.
o Authorization is the determination of whether a transaction
passing a specific authentication check is allowed to perform a
given operation.
o Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.
A submitted transaction contains a claimed identity. Depending on the type of transaction, the authorization will depend on related objects.
A submitted transaction contains a claimed identity. Depending on the type of transaction, the authorization will depend on related objects.
Villamizar, et al. Standards Track [Page 5] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 5] RFC 2769 Routing Policy System Replication February 2000
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.
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.
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.
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 Repository Hierarchy
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.
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.
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.
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.
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.
Each repository may have an "expire" attribute. The expire attribute is used to determine if a repository must be updated before a local transaction that depends on it can proceed.
The repository object also contains attributes describing the access methods and supported authentication methods of the repository. The "query-address" attribute provides a host name and a port number used to direct queries. The "response-auth-type" attribute provides the authentication types that may be used by the repository when responding to queries. The "submit-address" attribute provides a host name and a port number used to submit objects to the repository. The "submit-auth-type" attribute provides the authentication types that may be used by the repository when responding to submissions.
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.
5 Additions to RPSL
5 Additions to 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.
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.
Villamizar, et al. Standards Track [Page 6] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 6] RFC 2769 Routing Policy System Replication February 2000
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.
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.
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.
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.
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.
5.1 repository object
5.1 repository object
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].
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].
The root repository contains references to other repositories. An object of the following form identifies another repository.
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
Villamizar, et al. Standards Track [Page 7] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 7] RFC 2769 Routing Policy System Replication February 2000
The attributes of the repository object are listed below.
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
repository key mandatory single query-address mandatory multiple response-auth-type mandatory multiple submit-address mandatory multiple submit-auth-type mandatory multiple repository-cert mandatory multiple expire mandatory single heartbeat-interval mandatory single descr optional multiple remarks optional multiple admin-c mandatory multiple tech-c mandatory multiple notify optional multiple mnt-by mandatory multiple changed mandatory multiple source mandatory single
In the above object type only a small number of the attribute types are new. These are:
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.
repository This attribute provides the name of the repository. This is the key field for the object and is single and must be globally unique. This is the same name used in the source attribute of all objects in that repository.
query-address This attribute provides a url for directing queries.
"rps-query" or "whois" can be used as the protocol identifier.
query-address This attribute provides a url for directing queries. "rps-query" or "whois" can be used as the protocol identifier.
response-auth-type This attribute provides an authentication type
that may be used by the repository when responding to user
queries. Its syntax and semantics is same as the auth attribute
of the maintainer class.
response-auth-type 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.
submit-address This attribute provides a url for submitting objects
to the repository.
submit-address This attribute provides a url for submitting objects to the repository.
submit-auth-type This attribute provides the authentication types
that are allowed by the repository for users when submitting
registrations.
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 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.
Villamizar, et al. Standards Track [Page 8] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 8] RFC 2769 Routing Policy System Replication February 2000
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 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.
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.
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.
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.
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.
The remaining attributes in the repository object are defined in RPSL.
The remaining attributes in the repository object are defined in RPSL.
5.2 delegated attribute
5.2 delegated attribute
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.
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.
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.
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.
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.
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.
Villamizar, et al. Standards Track [Page 9] RFC 2769 Routing Policy System Replication February 2000
Villamizar, et al. Standards Track [Page 9] RFC 2769 Routing Policy System Replication February 2000
The following is an example of the use of a "delegated" attribute.
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 delegated: RIPE ... source: 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.
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.
5.3 integrity attribute
5.3 integrity attribute
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:
「保全」属性に、「いいえ-auth」という「レガシー」が「auth失敗する」か、または「認可した」値があるかもしれません。 休むなら、保全が「認可される」と考えられます。 保全値には、以下の意味があります:
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がありません: このデータは承認モデルの初期の変遷使用の間倉庫に加えられましたが、承認は保全が「認可されなかった」他のオブジェクトによりました。 そのような追加は、変遷の間許容されますが、後で禁じられるでしょう。
auth-failed: The authoritative repository is not checking
authorization. Had it been doing so, authorization would have
failed. This attribute may be added by a repository that is
mirroring before placing the object in its local storage, or can
add this attribute to an encapsulating meta-object used to further
propagate the transaction. If the failure to enforce
authorization is intentional and part of a transition (for
example, issuing warnings only), then the authoritative repository
may add this attribute to the encapsulating meta-object used to
further propagate the transaction.
authによって失敗される: 正式の倉庫は承認をチェックしていません。 そうしていたなら、承認は失敗したでしょうに。 この属性は、地方のストレージにオブジェクトを置く前にそれが映す予定である倉庫によって言い足されるかもしれないか、または要約メタオブジェクトへのこの属性がさらに以前はトランザクションをよく伝播していたと言い足すことができます。 承認を実施しないことが意図的であるか、そして、次に、(例えば、警告だけを発行します)、正式の倉庫がそうする変遷の一部が、要約メタオブジェクトへのこの属性がさらに以前はトランザクションをよく伝播していたと言い足します。
Villamizar, et al. Standards Track [Page 10] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[10ページ]。
authorized: Authorization checks were passed. The maintainer
contained a "referral-by" attribute, a form of authentication
deemed adequate by the repository was used, and all objects that
were needed for authorization were objects whose integrity was
"authorized".
認可される: 許可検査は通過されました。 維持装置は「近く紹介」属性を含みました、そして、倉庫によって適切であると考えられた認証のフォームは使用されました、そして、承認に必要であったすべての目的が保全が「認可された」オブジェクトでした。
Normally once an object is added to a repository another object cannot overwrite it unless authorized to do so by the maintainers referenced by the "mnt-by" attributes in the object itself. If the integrity attribute is anything but "authorized", an object can be overwritten or deleted by any transaction that would have been a properly authorized addition had the object of lesser integrity not existed.
通常、オブジェクトがいったん倉庫に加えられて、オブジェクト自体の「近くmnt」属性によって参照をつけられる維持装置でそうするのは認可されない場合、別のオブジェクトがそれを上書きできません。 保全属性が決して「認可されていない」なら、より少ない保全のオブジェクトが存在しなかったなら適切に認可された追加であったどんなトランザクションも、オブジェクトを上書きするか、または削除できます。
During such a transition grandfathered data and data added without proper authorization becomes advisory until a properly authorized addition occurs. After transition additions of this type would no longer be accepted. Those objects already added without proper authorization would remain but would be marked as candidates for replacement.
変遷が除外したそのようなものの間、適切に認可された追加が起こるまで、適切な承認なしで加えられたデータとデータは顧問になります。 変遷の後に、このタイプの追加はもう受け入れられないでしょう。 適切な承認なしで既に加えられたそれらのオブジェクトは、残っているでしょうが、交換の候補としてマークされるでしょう。
6 Interactions with a Repository or Mirror
倉庫か鏡との6回の相互作用
This section presents an overview of the transaction distribution mechanisms. The detailed format of the meta-objects for encapsulating and distributing transactions, and the rules for processing meta-objects are described in Section 7. There are a few different types of interactions between routing repositories or mirrors.
このセクションはトランザクションをカプセル化して、分配するためにトランザクション分配メカニズムの概要に. メタオブジェクトの詳細な形式を提示します、そして、処理メタオブジェクトのための規則はセクション7で説明されます。 ルーティング倉庫か鏡の間には、いくつかの異なったタイプの相互作用があります。
Initial submission of transactions: Transactions may include
additions, changes, and deletions. A transaction may operate on
more than one object and must be treated as an atomic operation.
By definition initial submission of transactions is not applicable
to a mirror. Initial submission of transactions is described in
Section 6.1.
トランザクションの服従に頭文字をつけてください: トランザクションは追加、変化、および削除を含むかもしれません。 トランザクションを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
そして、トランザクションが公約する、確認: 倉庫が示すかもしれない、任意に、aが遂行する道具は議定書を作って、それがそれがより多くのsubmitterにトランザクションa応答を与える完成指示はそのaを示します。
Villamizar, et al. Standards Track [Page 11] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[11ページ]。
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.
トランザクションは、うまくいって、地方の倉庫のクラッシュによって失われないでしょう。 submitterは任意にそのような確認を要求するかもしれません。 セクション6.3でこれについて議論します。
6.1 Initial Transaction Submission
6.1 初期のトランザクション服従
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メールカプセル化で提出されたオブジェクトのオブジェクトかセットです。 このフォームは遅れている互換性のためにまだサポートされています。 好まれた形で、何らかのメタ情報が好まれた形の確認などの提案が包含します。 カプセル化が使用されているとsubmitterがホストに接して、ポートが倉庫で指定したところでは、反対してください。 これは即座の確認を許します。 既存のRIPEコードによって提供されたインタフェースと同様のメールインタフェースが望まれているなら、外部プログラムはメールインタフェースを提供できます。
The encapsulation of a transaction submission and response is described in detail in Section 7.
トランザクション服従と応答のカプセル化はセクション7で詳細に説明されます。
6.2 Redistribution of Transactions
6.2 トランザクションの再分配
Redistribution of transactions can be accomplished using one of:
以下について1つを使用することでトランザクションの再分配を実行できます。
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に提供します。
6.3 Transaction Commit and Confirmation
トランザクションが遂行する6.3と確認
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であるなら、服従が完成の確証を必要とするか、または無病誤診確認に対するより高度合いの保護が望まれているなら、倉庫方針の問題、aが公約されるとき、実行されるかもしれません。
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
Aが公約される、要求はそれらができていると確認するために別の倉庫への初期のトランザクション服従を処理するトランザクション系列を唱える倉庫からの要求です。
Villamizar, et al. Standards Track [Page 12] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[12ページ]。
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.
Aは要求を遂行します。1つ以上の代替の倉庫に送ることができます。 人は公約します。完成応答は、積極的確認で取引が完了されたとsubmitterに応答するために十分です。 しかしながら、倉庫かsubmitterが任意に1以上を必要とするかもしれません。
7 Data Format Summaries, Transaction Encapsulation and Processing
7 データの形式概要、トランザクションカプセル化、および処理
RIPE-181 [2] and RPSL [1] data is represented externally as ASCII text. Objects consist of a set of attributes. Attributes are name/value pairs. A single attribute is represented as a single line with the name followed by a colon followed by whitespace characters (space, tab, or line continuation) and followed by the value. Within a value all consecutive whitespace characters is equivalent to a single space. Line continuation is supported by putting a white space or '+' character to the beginning of the continuation lines. An object is externally represented as a sequence of attributes. Objects are separated by blank lines.
RIPE-181[2]とRPSL[1]データはASCIIテキストとして外部的に表されます。 オブジェクトは1セットの属性から成ります。 属性は名前/値の組です。 ただ一つの属性を空白キャラクタ(スペース、タブ、または系列継続)でコロンが名前のあとに続いている単線が従ったので表されて、値はあとに続いています。 値の中では、すべての連続した空白キャラクタがシングルスペースに同等です。 線継続は'+'継続行の始まりへの余白を置くか、キャラクタによってサポートされます。 オブジェクトは属性の系列として外部的に表されます。 オブジェクトは空白行によって分離されます。
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オブジェクト表現に一致しています。 それらはほとんどデリミタとしてメッセージかキャリーへのプロトコルに機能します。操作を求める要求。
7.1 Transaction Submit and Confirm
トランザクションが提出して、確認する7.1
The de-facto method for submitting database changes has been via email. This method should be supported by an external application. Merit has added the pgp-from authentication method to the RADB (replaced by "pgpkey" in [4]), where the mail headers are essentially ignored and the body of the mail message must be PGP signed.
データベース変化を提出するためのデファクトメソッドはメールを使用しました。 このメソッドは外部のアプリケーションでサポートされるべきです。 長所が加えた、pgp、-、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.
この仕様はトランザクション服従のために異なったカプセル化を定義します。 オブジェクトのグループを倉庫に提出するとき、ユーザはオブジェクト、ちょうど1「タイムスタンプ」、および1「署名」のそのグループにメタオブジェクトを追加しなければなりません、そのオーダーで。
Villamizar, et al. Standards Track [Page 13] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[13ページ]。
The "timestamp" meta-object contains a single attribute:
「タイムスタンプ」メタオブジェクトはただ一つの属性を含んでいます:
timestamp This attribute is mandatory and single-valued. This
attribute specifies the time at which the user submits the
transaction to the repository. The format of this attribute is
"YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY" specifies the four
digit year, "MM" represents the month, "DD" the date, "hh" the
hour, "mm" the minutes, "ss" the seconds of the timestamp, and
"xx" and "yy" represents the hours and minutes respectively that
that timestamp is ahead or behind UTC.
タイムスタンプThis属性は、義務的で単一に評価されています。 この属性はユーザが倉庫にトランザクションを提出する時を指定します。 この属性の形式はそうです。"YYYY"が4ケタ年を指定して、「mm」が月、"DD"を表す"hhする"の「mm」の"ssする"の日付、時間、議事録、タイムスタンプの秒、"xx"、および"yy"が数時間とそれぞれ、そのタイムスタンプが先にある数分かUTCの後ろに表す「YYYYMMDD hh:mm:ss[+/-]xx: yy。」
A repository may reject a transaction which does not include the "timestamp" meta-object. The timestamp object is used to prevent replaying registrations. How this is actually used is a local matter. For example, a repository can accept a transaction only if the value of the timestamp attribute is greater than the timestamp attribute in the previous registration received from this user (maintainer), or the repository may only accept transactions with timestamps within its expire window.
倉庫は「タイムスタンプ」メタオブジェクトを含んでいないトランザクションを拒絶するかもしれません。 タイムスタンプオブジェクトは、登録証明書を再演するのを防ぐのに使用されます。 これが実際にどう使用されるかは、地域にかかわる事柄です。 例えば、タイムスタンプ属性の値がタイムスタンプが中にある状態でこのユーザ(維持装置)、または倉庫から受け取られていている前の登録におけるタイムスタンプ属性がトランザクションを受け入れるだけであるかもしれないより大きい場合にだけ倉庫がトランザクションを受け入れることができる、それ、窓を吐き出してください。
Each "signature" meta-object contains a single attribute:
それぞれの「署名」メタオブジェクトはただ一つの属性を含んでいます:
signature This attribute is mandatory and single-valued. This
attribute, a block of free text, contains the signature
corresponding to the authentication method used for the
transaction. When the authentication method is a cryptographic
hash (as in PGP-based authentication), the signature must include
all text up to (but not including) the last blank line before the
first "signature" meta-object.
署名This属性は、義務的で単一に評価されています。 この属性(1ブロックの無料のテキスト)はトランザクションに使用される認証方法に対応する署名を含んでいます。 認証方法が暗号のハッシュ(PGPベースの認証のように)であるときに、署名は最初の「署名」メタオブジェクトの前にすべてのテキストを最後の(しかし、包含しない)空白行まで含まなければなりません。
A repository must reject a transaction that does not include any "signature" meta-object.
倉庫はどんな「署名」メタオブジェクトも含んでいないトランザクションを拒絶しなければなりません。
The group of objects submitted by the user, together with the "timestamp" and "signature" meta-objects, constitute the "submitted text" of the transaction.
「タイムスタンプ」と「署名」メタオブジェクトと共にユーザによって提出されたオブジェクトのグループはトランザクションの「提出されたテキスト」を構成します。
The protocol used for submitting a transaction, and for receiving confirmation of locally committed transactions, is not specified in this document. This protocol may define additional encapsulations around the submitted text. The rest of this section gives an example of one such protocol. Implementations are free to choose another encapsulation.
トランザクションを提出して、局所的に遂行されたトランザクションの確認を受け取るのに使用されるプロトコルは本書では指定されません。 このプロトコルは提出されたテキストの周りで追加カプセル化を定義するかもしれません。 このセクションの残りはそのようなプロトコルの1つに関する例を出します。 実装は自由に別のカプセル化を選ぶことができます。
Villamizar, et al. Standards Track [Page 14] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[14ページ]。
The meta-objects "transaction-submit-begin" and "transaction-submit- end" delimit a transaction. A transaction is handled as an atomic operation. If any part of the transaction fails none of the changes take effect. For this reason a transaction can only operate on a single database.
メタオブジェクト、「トランザクションが提出される、始まり、」 「トランザクション終わりを提出すること」はトランザクションを区切ります。 トランザクションは原子操作として扱われます。 トランザクションのどれか部分が変化のいずれにも失敗しないなら、効いてください。 この理由で、トランザクションはただ一つのデータベースを作動させることができるだけです。
A socket connection is used to request queries or submit transactions. An email interface may be provided by an external program that connects to the socket. A socket connection must use the "transaction-submit-begin" and "transaction-submit-end" delimiters but can request a legacy style confirmation. Multiple transactions may be sent prior to the response for any single transaction. Transactions may not complete in the order sent.
ソケット接続は、質問を要求するか、またはトランザクションを提出するのに使用されます。 ソケットに接続する外部プログラムでメールインタフェースを提供するかもしれません。 ソケット接続が使用しなければならない、「トランザクションが提出される、始まり、」 「トランザクションは終わりを提出する」デリミタにもかかわらず、缶が要求するaレガシースタイル確認。 どんな単一取引のための応答の前にも多数の取引を送るかもしれません。 トランザクションは送られた注文で完成しないかもしれません。
The "transaction-submit-begin" meta-object may contain the following attributes.
「トランザクションが提出される、始まり、」 メタオブジェクトは以下の属性を含むかもしれません。
transaction-submit-begin This attribute is mandatory and single.
The value of the attribute contains name of the database and an
identifier that must be unique over the course of the socket
connection.
トランザクションが提出される、始まり、This属性は、義務的であって、ただ一つです。 属性の値はソケット接続の過程の上でユニークであるに違いないデータベースと識別子の名前を含んでいます。
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.
Thisが結果と考える応答authタイプは、任意であって、複数です。 系列の残りは応答で許容している認証タイプを指定します。 これは、応答が倉庫のそばで暗号で署名したよう要求するのに使用されます。
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".
トランザクションがタイプを確認しているThis属性は、任意であって、ただ一つです。 確認タイプキーワードを提供しなければなりません。 キーワードは「なにも」、「レガシー」、「標準」、「公約してください」です。 オプションは「冗長な」状態で確認タイプのあとに続くことができます。
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.
「トランザクションが終わりを提出しているメタオブジェクトは同じ名前でただ一つの属性から成ります。」 対応として同じデータベース名と識別子を含まなければならない、「トランザクションが提出される、始まり、」 結果と考えます。
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).
確認タイプが「なにも」でないなら、確認を送ります。 確認タイプが「レガシー」であるなら、ソケット(sendmailプログラムへの服従に適した)の上に現在RIPEデータベースコードによって送られるフォームに関するメールメッセージを返すでしょう。
A "normal" confirmation does not require completion of the commit protocol. A "commit" confirmation does. A "verbose" confirmation may contain additional detail.
「正常な」確認が完成を必要としない、プロトコルを遂行してください。 確認がする「公約してください。」 「冗長な」確認は追加詳細を含むかもしれません。
Villamizar, et al. Standards Track [Page 15] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[15ページ]。
A transaction confirmation is returned as a "transaction-confirm" meta-object. The "transaction-confirm" meta-object may have the following attributes.
aがメタオブジェクトを「トランザクションで確認する」とき、トランザクション確認を返します。 「」 メタオブジェクトには以下の属性があるかもしれないとトランザクションで確認してください。
transaction-confirm This attribute is mandatory and single. It
contains the database name and identifier associated with the
transaction.
This属性が義務的であって、ただ一つであるとトランザクションで確認してください。 それはトランザクションに関連しているデータベース名と識別子を含んでいます。
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.
Thisが結果と考える動作確認済みは、任意であって、複数です。 それは「加えてください」、「削除」または「変更」がオブジェクト・タイプで従って、オブジェクトのキーフィールドが作動させたキーワードの1つを含んでいます。
commit-status This attribute is mandatory and single. It contains
one of the keywords "succeeded, "error", or "held". The "error"
keyword may be followed by an optional text string. The "held"
keyword is returned when a repository containing a dependent
object for authorization has expired.
状態を公約しているThis属性は、義務的であって、ただ一つです。 それは「引き継がれる、「誤り」、「保持」にされる」というキーワードの1つを含んでいます。 任意のテキスト文字列は「誤り」キーワードを支えるかもしれません。 承認のための依存するオブジェクトを含む倉庫が期限が切れたとき、「保持された」キーワードを返します。
7.2 Redistribution of Transactions
7.2 トランザクションの再分配
In order to redistribute transactions, each repository maintains a TCP connection with one or more other repositories. After locally committing a submitted transaction, a repository assigns a sequence number to the transaction, signs and encapsulates the transaction, and then sends one copy to each neighboring (or "peer") repository. In turn, each repository authenticates the transaction (as described in Section 7.6), may re-sign the transaction and redistributes the transaction to its neighbors. We use the term "originating repository" to distinguish the repository that redistributes a locally submitted transaction.
トランザクションを再配付するために、各倉庫は他の1つ以上の倉庫とのTCP接続を維持します。 局所的に提出されたトランザクションを遂行した後に、倉庫は、一連番号をトランザクションに割り当てて、トランザクションに署名して、カプセル化して、次に、それぞれの隣接している(「じっと見る」)倉庫あたりのコピー1部を送ります。 順番に、各倉庫は、隣人にトランザクションを認証して(セクション7.6で説明されるように)、トランザクションを再契約するかもしれなくて、トランザクションを再配付します。 私たちは、局所的に提出されたトランザクションを再配付する倉庫を区別するために「倉庫を溯源し」ながら、用語を使用します。
This document also specifies two other methods for redistributing transactions to other repositories: a database snapshot format used for initializing a new registry, and a polling technique used by mirrors.
また、このドキュメントは他の倉庫にトランザクションを再配付するための他の2つのメソッドを指定します: データベーススナップ形式は初期値設定に新しい登録、および鏡によって使用される世論調査のテクニックを使用しました。
In this section, we first describe how a repository may encapsulate the submitted text of a transaction. We then describe the protocol for flooding transactions or polling for transactions, and the database snapshot contents and format.
このセクションで、私たちは最初に、倉庫がどうトランザクションの提出されたテキストをカプセル化するかもしれないかを説明します。 そして、私たちは氾濫トランザクションのためのプロトコルかトランザクションのための世論調査、データベーススナップコンテンツ、および形式について説明します。
7.3 Redistribution Protocol Description
7.3 再分配プロトコル記述
The originating repository must first authenticate a submitted transaction using methods described in [3].
起因する倉庫は、最初に、[3]で説明されたメソッドを使用することで提出されたトランザクションを認証しなければなりません。
Villamizar, et al. Standards Track [Page 16] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[16ページ]。
Before redistributing a transaction, the originating repository must encapsulate the submitted text of the transaction with several meta- objects, which are described below.
トランザクションを再配付する前に、起因する倉庫は数個のメタオブジェクトでトランザクションの提出されたテキストをカプセル化しなければなりません。(それは、以下で説明されます)。
The originating repository must prepend the submitted text with exactly one "transaction-label" meta-object. This meta-object contains the following attributes:
起因する倉庫はちょうど1がある提出されたテキストがメタオブジェクトと「トランザクションでラベルする」prependがそうしなければなりません。 このメタオブジェクトは以下の属性を含んでいます:
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.
トランザクションラベルThis属性は、義務的であって、ただ一つです。 この属性の値は、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.
Thisが結果と考える系列は、義務的であって、ただ一つです。 この属性の値は起因する倉庫によってトランザクションに割り当てられた一連番号を指定する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.
タイムスタンプThis属性は、義務的で単一に評価されています。 この属性は起因する倉庫が提出されたテキストをカプセル化する時を指定します。 この属性の形式はそうです。"YYYY"が4ケタ年を指定して、「mm」が月、"DD"を表す"hhする"の「mm」の"ssする"の日付、時間、議事録、タイムスタンプの秒、"xx"、および"yy"が数時間とそれぞれ、そのタイムスタンプが先にある数分かUTCの後ろに表す「YYYYMMDD hh:mm:ss[+/-]xx: yy。」
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".
Thisが結果と考える保全は、任意で単一に評価されています。 それには、「いいえ-auth」という「レガシー」が「auth失敗する」か、または「認可した」値があるかもしれません。 休むなら、保全が「認可される」と考えられます。
The originating repository may append to the submitted text one or more "auth-dependency" meta-objects. These meta-objects are used to indicate which other repositories' objects were used by the originating registry to authenticate the submitted text. The "auth- dependency" meta-objects should be ordered from the most preferred repository to the least preferred repository. This order is used by a remote repository to tie break between the multiple registrations of an object with the same level of integrity. The "auth-dependency" meta-object contains the following attributes:
起因する倉庫は1「auth-依存」のメタオブジェクトを提出されたテキストに追加するかもしれません。 これらのメタオブジェクトは、どの他の倉庫のオブジェクトが起因する登録によって使用されるか、そして、提出されたテキストを認証したのを示すのに使用されます。 「authの依存」メタオブジェクトは最も都合のよい倉庫から最も都合のよくない倉庫まで命令されるべきです。 このオーダーはリモート倉庫によって同じレベルの保全があるオブジェクトの複数の登録証明書の間のタイブレークに使用されます。 「auth-依存」メタオブジェクトは以下の属性を含んでいます:
auth-dependency This attribute mandatory and single-valued. It
equals a repository name from which an object is used to
authorize/authenticate this transaction.
auth-依存This属性義務的で単一に評価されています。 それはオブジェクトがこのトランザクションを認可するか、または認証するのに使用される倉庫名と等しいです。
Villamizar, et al. Standards Track [Page 17] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[17ページ]。
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.
系列This属性義務的で単一に評価されています。 それはこのトランザクションを処理する時点で起因する倉庫で知られていた依存する倉庫のトランザクション一連番号と等しいです。
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.
タイムスタンプThis属性義務的で単一に評価されています。 それはこのトランザクションを処理する時点で起因する倉庫で知られていた依存する倉庫に関するタイムスタンプと等しいです。
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.
オーバーライドオブジェクトのA無料のテキスト注意。
Other repositories may or may not honor override requests, or limit the kinds of overrides they allow.
他の倉庫は、オーバーライド要求を光栄に思うか、またはそれらが許容するオーバーライドの種類を制限するかもしれません。
Following this, the originating repository must append exactly one "repository-signature" meta-object. The "repository-signature" meta-object contains the following attributes:
これに続いて、起因する倉庫はまさに1つの「倉庫署名」メタオブジェクトを追加しなければなりません。 「倉庫署名」メタオブジェクトは以下の属性を含んでいます:
repository-signature This attribute is mandatory and single-valued.
It contains the name of the repository.
倉庫署名This属性は、義務的で単一に評価されています。 それは倉庫の名前を含んでいます。
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.
Thisが結果と考える保全は、任意で単一に評価されています。 それには、「いいえ-auth」という「レガシー」が「auth失敗する」か、または「認可した」値があるかもしれません。 休むなら、値はトランザクションラベルで値と同じです。 異価が使用されているなら、ここの値は優先します。
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.
署名This属性は、任意で単一に評価されています。 この属性(1ブロックの無料のテキスト)は、倉庫オブジェクトの倉庫本命属性にキーを使用することで倉庫の署名を含んでいます。 認証方法が暗号のハッシュ(PGPベースの認証のように)であるときに、署名はこれが結果と考えるすべてのテキストupto(しかし、包含しない)を含まなければなりません。 すなわち、このオブジェクトの「倉庫署名」と「保全」属性は含まれています。 暗号の認証がいたる所で入手できないかもしれないので、この属性は任意です。 しかしながら、それが利用可能であるところで使用は非常にお勧めです。
A repository must reject a redistributed transaction that does not include any "repository-signature" meta-object.
倉庫はどんな「倉庫署名」メタオブジェクトも含んでいない再配付されたトランザクションを拒絶しなければなりません。
Villamizar, et al. Standards Track [Page 18] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[18ページ]。
The transaction-label, the submitted text, the dependency objects, the override-objects, the overridden objects, and the repository's signature together constitute what we call the "redistributed text".
トランザクションラベル、提出されたテキスト、依存オブジェクト、オーバーライドオブジェクト、くつがえされたオブジェクト、および一緒に倉庫の署名はいわゆる「再配付されたテキスト」を構成します。
In preparation for redistributing the transaction to other repositories, the originating repository must perform the following protocol encapsulation. This protocol encapsulation may involve transforming the redistributed text according to one of the "transfer-method"s described below.
他の倉庫にトランザクションを再配付することに備えて、起因する倉庫は以下のプロトコルカプセル化を実行しなければなりません。 このプロトコルカプセル化は、以下で説明された「転写法」sの1つに応じて再配付されたテキストを変えることを伴うかもしれません。
The transformed redistributed text is first prepended with exactly one "transaction-begin" meta-object. One newline character separates this meta-object from the redistributed text. This meta-object has the following attributes:
変成している再配付されたテキストは最初に、まさに1つの「トランザクションで始まっている」メタオブジェクトでprependedされます。 1つのニューラインキャラクタが再配付されたテキストとこのメタオブジェクトを切り離します。 このメタオブジェクトには、以下の属性があります:
transaction-begin This attribute is mandatory and single. The value
of this attribute is the length, in bytes, of the transformed
redistributed text.
トランザクションで始まっているThis属性は、義務的であって、ただ一つです。 この属性の値は変成している再配付されたテキストのバイトで表現される長さです。
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.
Thisが結果と考える転写法は、任意で単一に評価されています。 値は"gzip"であるか「単に。」 属性の値は倉庫が再配付されたテキストに実行したテキストコード化の種類について説明します。 この属性が指定されないなら、値が「明瞭である」と思われます。 これらのタイプの両方をコード化して、実装は解読できなければなりません。
The "transaction-begin" meta-object and the transformed redistributed text constitute what we call the "transmitted text". The originating repository may distribute the transmitted text to one or more peer repositories.
「トランザクションで始まっている」メタオブジェクトと変成している再配付されたテキストはいわゆる「伝えられたテキスト」を構成します。 起因する倉庫は1つ以上の同輩倉庫に伝えられたテキストを配布するかもしれません。
When a repository receives the transmitted text of a transaction, it must perform the following steps. After performing the following steps, a transaction may be marked successful or failed.
倉庫がトランザクションの伝えられたテキストを受け取るとき、それは以下のステップを実行しなければなりません。 以下のステップを実行した後に、トランザクションは、うまくいくとマークされるか、または失敗されるかもしれません。
1. It must decapsulate the "transaction-begin" meta-object, then
decode the original redistributed text according to the value of
the transfer-method attribute specified in the "transaction-begin"
meta-object.
1. それは、「トランザクションで始まっている」メタオブジェクトをdecapsulateして、「トランザクションで始まっている」メタオブジェクトで指定された転写法属性の値に従って、次に、オリジナルの再配付されたテキストを解読しなければなりません。
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-依存」メタオブジェクトに続いて、起因する倉庫の署名が再配付されたテキストの最初の「倉庫署名」メタオブジェクトに合っていることを確かめるべきです。
Villamizar, et al. Standards Track [Page 19] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[19ページ]。
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-依存」メタオブジェクトで言及しなかった倉庫からオブジェクトを使用してはいけません。 また、倉庫は「auth-依存」メタオブジェクトのトランザクション一連番号の中にある最新のオブジェクト(必要なら、前にバージョンをロールバックするのによる)を使用するだけであるはずです。
A non-originating repository must redistribute a failed transaction in order not to cause a gap in the sequence. (If the transaction was to fail at the originating registry, it would simply not be assigned a sequence number).
非の起因する倉庫は系列のギャップを引き起こさない命令における失敗したトランザクションを再配付しなければなりません。 (トランザクションが起因する登録で失敗することであるなら、一連番号はそれに絶対に割り当てられません。)
To the redistributed text of a transaction, a repository may append another "repository-signature" meta-object. This indicates that the repository has verified the transaction's integrity and marked it in the "integrity" attribute of this object. The signature covers the new redistributed text from (and including) the transaction-label object to this object's signature attribute (including the "repository-signature" and "integrity" attributes of this object, but excluding the "signature" attribute). The original redistributed text, together with the new "repository-signature" meta-object constitutes the modified redistributed text.
トランザクションの再配付されたテキストに、倉庫は別の「倉庫署名」メタオブジェクトを追加するかもしれません。 これは、倉庫がこのオブジェクトの「保全」属性でトランザクションの保全について確かめて、それをマークしたのを示します。 署名は(そして、包含)トランザクションラベルオブジェクトからこのオブジェクトの署名属性(このオブジェクトの「倉庫署名」と「保全」属性を含んでいますが、「署名」属性を除く)まで新しい再配付されたテキストをカバーしています。 オリジナルの再配付されたテキストであり、新しい「倉庫署名」と共にメタオブジェクトは変更された再配付されたテキストを構成します。
To redistribute a successful or failed transaction, the repository must encapsulate the (original or modified) redistributed text with a "transaction-begin" object. This step is essentially the same as
うまくいっているか失敗したトランザクションを再配付するために、倉庫は「トランザクションで始まっている」オブジェクトで(オリジナルか変更される)の再配付されたテキストをカプセル化しなければなりません。 このステップは本質的には同じです。
Villamizar, et al. Standards Track [Page 20] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[20ページ]。
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.
それは起因する倉庫のそばで働きました。(倉庫が無料でものからの異なった「転写法」を使用できるのを除いて、容認されたトランザクションには、いました。
7.3.1 Explicitly Requesting Transactions
7.3.1 明らかにトランザクションを要求すること。
A repository may also explicitly request one or more transactions belonging to a specified originating repository. This is useful for catching up after a repository has been off-line for a period of time. It is also useful for mirrors which intermittently poll a repository for recently received transactions.
また、倉庫は明らかに指定された起因する倉庫に属す1つ以上のトランザクションを要求するかもしれません。 これは倉庫がしばらくオフラインになった後に追いつくことの役に立ちます。 また、それも最近容認されたトランザクションのために断続的に倉庫に投票する鏡の役に立ちます。
To request a range of transactions from a peer, a repository must send a "transaction-request" meta-object to the peer. A "transaction-request" meta-object may contain the following attributes:
同輩からさまざまなトランザクションを要求するために、倉庫は「トランザクション要求」メタオブジェクトを同輩に送らなければなりません。 「トランザクション要求」メタオブジェクトは以下の属性を含むかもしれません:
transaction-request This attribute is mandatory and single. It
contains the name of the database whose transactions are being
requested.
Thisが結果と考えるトランザクション要求は、義務的であって、ただ一つです。 それはトランザクションが要求されているデータベースの名前を含んでいます。
sequence-begin This attribute is optional and single. It contains
the sequence number of the first transaction being requested.
系列で始まっているThis属性は、任意であって、ただ一つです。 それは要求されている最初のトランザクションの一連番号を含んでいます。
sequence-end This attribute is optional and single. It contains the
sequence number of the last transaction being requested.
系列終わりのThis属性は、任意であって、ただ一つです。 それは要求されている最後のトランザクションの一連番号を含んでいます。
Upon receiving a "transaction-request" object, a repository performs the following actions. If the "sequence-begin" attribute is not specified, the repository assumes the request first sequence number to be 1. The last sequence number is the lesser of the value of the "sequence-end" attributed and the highest completed transaction in the corresponding database. The repository then, in order, transmits the requested range of transactions. Each transaction is prepared exactly according to the rules for redistribution specified in Section 7.3.
「トランザクション要求」オブジェクトを受けると、倉庫は以下の動作を実行します。 「系列で始まっている」属性が指定されないなら、倉庫は、要求が1である最初の一連番号であると仮定します。 結果と考えられた「系列終わり」の値と対応するデータベースで最も高い終了したトランザクションでは最後の一連番号は、より少ないです。 そして、倉庫はオーダーで要求された範囲のトランザクションを伝えます。 ちょうど規則に従って、各トランザクションはセクション7.3で指定された再分配のために準備されます。
After transmitting all the transactions, the peer repository must send a "transaction-response" meta-object. This meta-object has the following attributes:
すべてのトランザクションを伝えた後に、同輩倉庫は「トランザクション応答」メタオブジェクトを送らなければなりません。 このメタオブジェクトには、以下の属性があります:
transaction-response This attribute is mandatory and single. It
contains the name of the database whose transactions are were
requested.
Thisが結果と考えるトランザクション応答は、義務的であって、ただ一つです。 それはデータベースの名前を含んでいます。トランザクションがだれのものであるかは要求されました。
Villamizar, et al. Standards Track [Page 21] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[21ページ]。
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.
系列で始まっているThis属性は、任意であって、義務的です。 それはオリジナルの要求における、「系列で始まっている」属性の値を含んでいます。 対応する属性がオリジナルの要求で指定されなかったなら、それは省略されます。
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.
系列終わりのThis属性は、任意であって、義務的です。 それはオリジナルの要求における、「系列終わり」属性の値を含んでいます。 対応する属性がオリジナルの要求で指定されなかったなら、それは省略されます。
After receiving a "transaction-response" meta-object, a repository may tear down the TCP connection to its peer. This is useful for mirrors that intermittently resynchronize transactions with a repository. If the TCP connection stays open, repositories exchange subsequent transactions according to the redistribution mechanism specified in Section 7.3. While a repository is responding to a transaction-request, it MAY forward heartbeats and other transactions from the requested repository towards the requestor.
「トランザクション応答」メタオブジェクトを受けた後に、倉庫は同輩とのTCP接続を取りこわすかもしれません。 これは倉庫でトランザクションを断続的に再連動させる鏡の役に立ちます。 TCP接続が開くままであるなら、セクション7.3で指定された再分配メカニズムに応じて、倉庫はその後のトランザクションを交換します。 倉庫がトランザクション要求に応じている間、それは鼓動と他のトランザクションを要求された倉庫から要請者に向かって送るかもしれません。
7.3.2 Heartbeat Processing
7.3.2 鼓動処理
Each repository that has originated at least one transaction must periodically send a "heartbeat" meta-object. The interval between two successive transmissions of this meta-object is configurable but must be less than 1 day. This meta-object serves to indicate the liveness of a particular repository. The repository liveness determines how long transactions are held (See Section 7.6).
少なくとも1つのトランザクションを溯源した各倉庫は定期的に「鼓動」メタオブジェクトを送らなければなりません。 このメタオブジェクトの2つの連続した送信の間隔は、構成可能ですが、1日未満でなければなりません。 このメタオブジェクトは、特定の倉庫の活性を示すのに役立ちます。 倉庫活性は、トランザクションがどれくらい長い間保持されるかを(セクション7.6を見てください)決定します。
The "heartbeat" meta-object contains the following attributes:
「鼓動」メタオブジェクトは以下の属性を含んでいます:
heartbeat This attribute is mandatory and single. It contains the
name of the repository which originates this meta-object.
Thisが結果と考える鼓動は、義務的であって、単一です。 それはこのメタオブジェクトを溯源する倉庫の名前を含んでいます。
sequence This attribute is mandatory and single. It contains the
highest transaction sequence number that has been assigned by the
repository.
Thisが結果と考える系列は、義務的であって、ただ一つです。 それは倉庫によって割り当てられた中で最も高いトランザクション一連番号を含んでいます。
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.
タイムスタンプThis属性は、義務的であって、ただ一つです。 それはこのメタオブジェクトが生成された時を含んでいます。 この属性の形式はそうです。"YYYY"が4ケタ年を指定して、「mm」が月、"DD"を表す"hhする"の「mm」の"ssする"の日付、時間、議事録、タイムスタンプの秒、"xx"、および"yy"が数時間とそれぞれ、そのタイムスタンプが先にある数分かUTCの後ろに表す「YYYYMMDD hh:mm:ss[+/-]xx: yy。」
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
鼓動メタオブジェクトを受けると、倉庫は最初に、最新の以前に受信された鼓動メッセージに関するタイムスタンプをチェックしなければなりません。 そのタイムスタンプが容認された鼓動でタイムスタンプを超えているなら
Villamizar, et al. Standards Track [Page 22] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[22ページ]。
message, the repository must silently discard the heartbeat message. Otherwise, it must record the timestamp and sequence number in the heartbeat message, and redistribute the heartbeat message, without modification, to each of its peer repositories.
メッセージ、倉庫は静かに鼓動メッセージを捨てなければなりません。 さもなければ、タイムスタンプと一連番号を鼓動メッセージに記録して、鼓動メッセージを再配付しなければなりません、変更なしで、それぞれの同輩倉庫に。
If the heartbeat message is from a repository previously unknown to the recipient, the recipient may send a "transaction-request" to one or more of its peers to obtain all transactions belonging to the corresponding database. If the heartbeat message contains a sequence number higher than the highest sequence number processed by the recipient, the recipient may send a "transaction-request" to one or more of its peers to obtain all transactions belonging to the corresponding database.
鼓動メッセージが受取人にとっての、以前に未知の倉庫から来ているなら、受取人は、対応するデータベースに属すすべてのトランザクションを得るために「トランザクション要求」を同輩のより多くのひとりに送るかもしれません。 鼓動メッセージが最も高い一連番号が受取人に処理されたより高い一連番号を含んでいるなら、受取人は、対応するデータベースに属すすべてのトランザクションを得るために「トランザクション要求」を同輩のより多くのひとりに送るかもしれません。
7.4 Transaction Commit
7.4トランザクションは公約します。
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.
Submittersが、より強い確認を必要とするかもしれない、それらのトランザクション(セクション6.3)のために、公約してください。 このセクションは倉庫がこのより強い確認を提供するかもしれない簡単な要求応答プロトコルについて説明します、他の1つ以上の倉庫がトランザクションを遂行したかどうか確かめることによって。 この要求応答プロトコルの実装は任意です。
After it has redistributed a transaction, the originating repository may request a commit confirmation from one or more peer repositories by sending to them a "commit-request" meta-object. The "commit- request" contains two attributes:
トランザクションを再配付した後に、起因する倉庫が、aが1つ以上の同輩倉庫からそれらに発信することによって確認を遂行するよう要求するかもしれない、「要求を公約する、」 メタオブジェクト 「要求を遂行してください」は2つの属性を含んでいます:
commit-request This attribute is mandatory and single. It contains
the name of the database for whom a commit confirmation is being
requested.
要求を公約しているThis属性は、義務的であって、ただ一つです。 それはaが確認を遂行するデータベースの名前を含んでいます。要求されています。
sequence This attribute is mandatory and single. It contains the
transaction sequence number for which a commit confirmation is
being requested.
Thisが結果と考える系列は、義務的であって、ただ一つです。 どのaが確認を遂行するかが要求されているので、それはトランザクション一連番号を含んでいます。
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.
aを受ける倉庫、「要求を公約する、」 要求を再配付してはいけません。 対応するトランザクションが処理されるまで、それは応答を遅らせなければなりません。 この理由、ほとんど未定の倉庫必須生活費州が要求を遂行するので。 応答を送る前にリクエスタとの接続が迷子になるなら、それはこの状態を捨てるべきです。 その場合には、要求を再送するのは、リクエスタの責任です。
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)チェックしなければなりません。 そうだとすれば、aを送らなければならない、「応答を公約する、」 リクエスタへのメタオブジェクト。 このメタオブジェクトには、3つの属性があります:
Villamizar, et al. Standards Track [Page 23] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[23ページ]。
commit-response This attribute is mandatory and single. It contains
the name of the database for whom a commit response is being sent.
応答を公約しているThis属性は、義務的であって、ただ一つです。 それはaが応答を遂行するデータベースの名前を含んでいます。送ります。
sequence This attribute is mandatory and single. It contains the
transaction sequence number for which a commit response is being
sent.
Thisが結果と考える系列は、義務的であって、ただ一つです。 どのaに応答を遂行させるかので、それはトランザクション一連番号を含んでいます。
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.
状態を公約しているThis属性は、義務的であって、ただ一つです。 それは「誤り」と「保持する」か、または「成功する」というキーワードの1つを含んでいます。 任意のテキスト文字列は「誤り」キーワードを支えるかもしれません。 承認のための依存するオブジェクトを含む倉庫が期限が切れたとき、「保持された」キーワードを返します。
7.5 Database Snapshot
7.5 データベーススナップ
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.
データベーススナップはデータベースの完本を提供します。 それは倉庫初期化か災害復旧のためだけに意図します。 データベーススナップがそう、バンドメカニズムから。 1セットのファイルは定期的にソース倉庫に作成されます。 そして、これらのファイルをバンド(例えば、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 Thisファイルは空白行によって切り離された倉庫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.
プレゼントがRPSLを含んでいるなら、X.の<のクラスの>の.db Thisの任意のファイルはクラス<のクラス>のものであるX.dbで反対します。 ファイルの形式はX.dbのものと同じです。
X.transaction-label This file contains a transaction-label object
that records the timestamp and the latest sequence number of the
repository at the time of the snapshot.
X.トランザクションラベルThisファイルはスナップ時点で倉庫のタイムスタンプと最新の一連番号を記録するトランザクションラベルオブジェクトを入れてあます。
Each of these files can be optionally compressed uzing gzip. This is signified by appending the suffix .gz to the file name. Each of these files can optionally be PGP signed. In this case, the detached signature with ASCII armoring and platform-independent text mode is stored in a file whose name is constructed by appending .sig to the file name of the file being signed.
それぞれのこれらのファイルは任意に圧縮されたuzing gzipであるかもしれません。 これは、接尾語.gzをファイル名に追加することによって、意味されています。 それぞれのこれらのファイルは任意に署名されるPGPであるかもしれません。 この場合、ASCII装甲とプラットホームから独立しているテキストモードがある離れている署名は名前が調印されるファイルのファイル名に.sigを追加することによって構成されるファイルに保存されます。
In order to construct a repository's contents from a snapshot, a repository downloads these files. After uncompressing and checking signatures, the repository records these objects in its database. No
スナップから倉庫のコンテンツを構成するために、倉庫はこれらのファイルをダウンロードします。 署名を解凍して、チェックした後に、倉庫はこれらのオブジェクトをデータベースに記録します。 いいえ
Villamizar, et al. Standards Track [Page 24] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[24ページ]。
RPS authorization/authentication is done on these objects. The transaction-label object provides the seed for the replication protocol to receive the follow on transactions from this repository. Hence, it is not crucial to download an up to the minute snapshot.
これらのオブジェクトでRPS承認/認証をします。 模写プロトコルがトランザクションでこの倉庫から尾行を受けるように、トランザクションラベルオブジェクトは種子を提供します。 したがって、最新式のスナップをダウンロードするのは重要ではありません。
After successfully playing a snapshot, it is possible that a repository may receive a transaction from a third repository that has a dependency on an earlier version of one of the objects in the snapshot. This can only happen within the expire period of the repository being downloaded, plus any possible network partition period. This dependency is only important if the repository wants to re-verify RPS authorization/authentication. There are three allowed alternatives in this case. The simplest alternative is for the repository to accept the transaction and mark it with integrity "no- auth". The second choice is to only peer with trusted repositories during this time period, and accept the transaction with the same integrity as the trusted repository (possibly as "authorized"). The most preferred alternative is not to download an up to the minute snapshot, but to download an older snapshot, at minimum twice the repositories expire time, in practice few days older. Upon replaying an older snapshot, the replication protocol will fetch the more current transactions from this repository. Together they provide the necessary versions of objects to re-verify rps authorization/authentication.
首尾よくスナップをプレーした後に、倉庫がスナップにオブジェクトの1つの以前のバージョンに依存を持っている3番目の倉庫からトランザクションを受けるのは、可能です。 これが起こることができるだけである、ダウンロードされる倉庫の期間、およびあらゆる可能なネットワークパーティションの期間を吐き出してください。 この依存はRPS承認/認証について再確かめる倉庫必需品である場合にだけ重要です。 この場合、3つの許容選択肢があります。 最も簡単な代替手段は、倉庫がトランザクションを受け入れて、保全「いいえauth」をそれに付けることです。 第二希望は、この期間、信じられた倉庫でじっと見るだけであり、信じられた倉庫と同じ保全でトランザクションを受け入れる(ことによると「認可される」ように)ことです。 最も都合のよい代替手段が最新式のスナップをダウンロードしないことですが、最小限で、より古いスナップをダウンロードするために、倉庫の2倍は実際には数日より古い時間を吐き出します。 より古いスナップを再演すると、模写プロトコルはこの倉庫から、より現在のトランザクションをとって来るでしょう。 彼らは、rps承認/認証について再確かめるためにオブジェクトの必要なバージョンを一緒に、提供します。
7.6 Authenticating Operations
7.6 操作を認証すること。
The "signature" and "repository-signature" meta-objects represent signatures. Where multiple of these objects are present, the signatures should be over the original contents, not over other signatures. This allows signatures to be checked in any order.
「署名」と「倉庫署名」メタオブジェクトは署名を表します。 複数であるところでは、これらのオブジェクトが存在している、オリジナルコンテンツの上に署名が他の署名の上にあるのではなく、あるべきです。 これで、署名は順不同にチェックします。
A maintainer can also sign a transaction using several authentication methods (some of which may be available in some repositories only).
また、いくつかの認証方法(それの或るものはいくつかの倉庫だけで利用可能であるかもしれない)を使用することで維持装置はトランザクションに署名することができます。
In the case of PGP, implementations should allow the signatures of the "signature" and "repository-signature" meta-objects to be either the detached signatures produced by PGP or regular signatures produced by PGP. In either case, ASCII armoring and platform- independent text mode should be used.
PGPの場合では、実装は、「署名」と「倉庫署名」メタオブジェクトの署名がPGPによって起こされた離れている署名かPGPによって起こされた定期的な署名のどちらかであることを許容するべきです。 どちらの場合ではも、ASCII装甲とプラットホームの独立しているテキストモードは使用されるべきです。
Note that the RPSL objects themselves are not signed but the entire transaction body is signed. When exchanging transactions among registries, the meta-objects (e.g. "auth-dependency") prior to the first "repository-signature" meta object in the redistributed text are also signed over.
RPSLオブジェクト自体が署名されませんが、全体のトランザクション本体が署名されることに注意してください。 また、登録の中でトランザクションを交換するとき、再配付されたテキストの最初の「倉庫署名」メタオブジェクトの前のメタオブジェクト(例えば、「auth-依存」)を署名して正式に引き渡します。
Villamizar, et al. Standards Track [Page 25] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[25ページ]。
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.
トランザクションは元の状態のままにならなければなりません、署名を含んでいて、submitterによって提供された認証方法がメッセージを扱う倉庫によって使用されないでも。 維持装置のイドがあとに続いた状態で、起因する倉庫は、トランザクションからクリアテキストパスワード署名を取り除くのを選んで、それを「明確なテキストpasswd」というキーワードに取り替えるかもしれません。
signature: clear-text-passwd <maintainer-name>
署名: 明確なテキストpasswd<維持装置名の>。
Note that this does not make the system less secure since clear text password is an indication of total trust to the originating repository by the maintainer.
これでシステムがクリアテキストパスワードが維持装置による起因する倉庫への総信頼のしるしであるので、より安全でなくならないことに注意してください。
A repository may sign a transaction that it verified. If at any point the signature of a trusted repository is encountered, no further authorization or authentication is needed.
倉庫はそれが確かめたトランザクションに署名するかもしれません。 信じられた倉庫の署名が任意な点で遭遇するなら、どんなさらなる承認も認証も必要ではありません。
Villamizar, et al. Standards Track [Page 26] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[26ページ]。
A Examples
例
RPSL provides an external representation of RPSL objects and attributes. An attribute is a name/value pair. RPSL is line oriented. Line continuation is supported, however most attributes fit on a single line. The attribute name is followed by a colon, then any amount of whitespace, then the attribute value. An example of the ASCII representation of an RPSL attribute is the following:
RPSLはRPSLオブジェクトと属性の外部の表現を提供します。 属性は名前/値の組です。 RPSLは系列指向しています。 属性が単線に最も合っても、線継続はサポートされます。 コロンが属性名のあとに続いていて、その時がどんな量の空白であり、次に、属性は値です。 RPSL属性のASCII表現に関する例は以下です:
route: 140.222.0.0/16
以下を発送してください。 140.222.0.0/16
An RPSL object is a set of attributes. Objects are separated from each other by one or more blank lines. An example of a complete RPSL object follows:
RPSLオブジェクトは1セットの属性です。 オブジェクトは1つ以上の空白行によって互いから分離されます。 完全なRPSLオブジェクトに関する例は従います:
route: 140.222.0.0/16
descr: ANS Communications
origin: AS1673
member-of: RS-ANSOSPFAGGREGATE
mnt-by: ANS
changed: tck@ans.net 19980115
source: ANS
以下を発送してください。 140.222.0.0/16descr: ANS Communications発生源: AS1673、メンバー、-、: 近くRS-ANSOSPFAGGREGATE mnt: ANSは変化しました: tck@ans.net 19980115ソース: ANS
A.1 Initial Object Submission and Redistribution
A.1の初期のオブジェクト服従と再分配
Figure 1 outlines the steps involved in submitting an object and the initial redistribution from the authoritative registry to its flooding peers.
図1はオブジェクトを提出するのにかかわるステップと初期の正式の登録から氾濫同輩までの再分配について概説します。
If the authorization check requires objects from other repositories, then the sequence numbers of the local copies of those databases is required for mirrors to recheck the authorization.
許可検査が他の倉庫からオブジェクトを必要とするなら、鏡が承認を再確認するのにそれらのデータベースの地方のコピーの一連番号が必要です。
To simply resubmit the object from the prior example, the submitter or a client application program acting on the submitter's behalf must submit a transaction. The legacy method was to send PGP signed email. The preferred method is for an interactive program to encapsulate a request between "transaction-submit-begin" and "transaction-submit-end" meta-objects and encapsulate that as a signed block as in the following example:
先の例、submitterまたはクライアントアプリケーション・プログラムからオブジェクトを単に再提出するために、submitterの利益に影響すると、トランザクションは提出されなければなりません。 レガシーメソッドはメールであると署名されるPGPを送ることでした。 そして、適した方法が要求をカプセル化する双方向番組のためのものである、「トランザクションが提出される、始まり、」 「トランザクションは終わりを提出する」というメタオブジェクト、aが以下の例のようにブロックに署名したので、それをカプセル化してください:
Villamizar, et al. Standards Track [Page 27] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[27ページ]。
+--------------+
| Transaction |
| signed by |
| submitter |
+--------------+
|
| 1
v
+---------------------+ 2
| Primary repository |---->+----------+
| identified by | | database |
| RPSL source |<----+----------+
+---------------------+ 3
|
| 4
v
+----------------+
| Redistributed |
| transaction |
+----------------+
+--------------+ | トランザクション| | 署名されます。| | submitter| +--------------+ | | 1 +に対して---------------------+ 2 | プライマリ倉庫|---->+----------+ | 特定されます。| | データベース| | RPSLソース| <、-、-、--+----------+ +---------------------+ 3 | | 4 +に対して----------------+ | 再配付します。| | トランザクション| +----------------+
1. submit object
2. authorization check
3. sequence needed for authorization
4. redistribute
1. 3系列が4が再配付する承認に必要としたオブジェクト2許可検査を提出してください。
Figure 1: Initial Object Submission and Redistribution
図1: 初期のオブジェクト服従と再分配
transaction-submit-begin: ANS 1
response-auth-type: PGP
transaction-confirm-type: normal
トランザクションが提出される、始まり、: ANS1応答authタイプ: PGP、トランザクションはタイプを確認します: 標準
route: 140.222.0.0/16
descr: ANS Communications
origin: AS1673
member-of: RS-ANSOSPFAGGREGATE
mnt-by: ANS
changed: curtis@ans.net 19990401
source: ANS
以下を発送してください。 140.222.0.0/16descr: ANS Communications発生源: AS1673、メンバー、-、: 近くRS-ANSOSPFAGGREGATE mnt: ANSは変化しました: curtis@ans.net 19990401ソース: ANS
timestamp: 19990401 10:30:00 +08:00
タイムスタンプ: 19990401 10:30:00 +08:00
Villamizar, et al. Standards Track [Page 28] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[28ページ]。
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-----
署名: + -----PGP署名を始めてください。----- + バージョン: 個人のプライバシー5.0+MessageIDのためのPGP: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI++iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U+Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX+Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv+PGBIEN3/NlMは+ =c93c+と等しいです。-----終わりのPGP署名-----
transaction-submit-end: ANS 1
トランザクションは終わりを提出します: ANS1
The signature covers the everything after the first blank line after the "transaction-submit-begin" object to the last blank line before the "signature" meta-object. If multiple signatures are needed, it would be quite easy to email this block and ask the other party to add a signature-block and return or submit the transaction. Because of delay in obtaining multiple signatures the accuracy of the "timestamp" cannot be strictly enforced. Enforcing accuracy to within the "expire" time of the database might be a reasonable compromise. The tradeoff is between convenience, allowing a longer time to obtain multiple signatures, and increased time of exposure to replay attack.
署名がカバーしている、後の最初の空白行の後のすべて、「トランザクションが提出される、始まり、」 「署名」メタオブジェクトの前に最後の空白行に反対してください。 複数の署名が必要であるなら、このブロックをメールして、トランザクションを署名欄を加えて、返すか、または提出するように相手に頼むのはかなり簡単でしょう。 複数の署名を得るのが遅れるので、厳密に「タイムスタンプ」の精度を励行されることができません。 「期限が切れてください」というデータベースの時間まで精度を実施するのは、妥当な感染であるかもしれません。 暴露の便利と、複数の署名を得るより長い時間を許容して、増強された時間の間には、反射攻撃には見返りがあります。
The ANS repository would look at its local database and make authorization checks. If the authorization passes, then the sequence number of any other database needed for the authorization is obtained.
ANS倉庫は、ローカルのデータベースを見て、許可検査をするでしょう。 承認が終わるなら、承認に必要であるいかなる他のデータベースの一連番号も得ます。
If this operation was successful, then a confirmation would be returned. The confirmation would be of the form:
この操作がうまくいくなら、確認を返すでしょうに。 確認はフォームのものでしょう:
transaction-confirm: ANS 1
confirmed-operation: change route 140.222.0.0/16 AS1673
commit-status: commit
timestamp: 19990401 10:30:10 +05:00
以下をトランザクションで確認してください。 ANS1動作確認済み: 状態を公約する状態でルート140.222.0.0/16AS1673を変えてください: タイムスタンプを遂行してください: 19990401 10:30:10 +05:00
A.2 Transaction Redistribution Encoding
A.2トランザクション再分配コード化
Having passed the authorization check the transaction is given a sequence number and stored in the local transaction log and is then flooded. The meta-object flooded to another database would be signed by the repository and would be of the following form:
トランザクションを許可検査に通過したのは、一連番号を与えて、地方に取引ログを保存して、次に、水につかっています。 別のデータベースへあふれるメタオブジェクトは、倉庫によって署名されて、以下の書類のものでしょう:
Villamizar, et al. Standards Track [Page 29] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[29ページ]。
transaction-label: ANS
sequence: 6666
timestamp: 19990401 13:30:10 +05:00
integrity: authorized
トランザクションラベル: ANS系列: 6666年のタイムスタンプ: 19990401 13: 30:10 +05:00保全: 認可されます。
route: 140.222.0.0/16
descr: ANS Communications
origin: AS1673
member-of: RS-ANSOSPFAGGREGATE
mnt-by: ANS
changed: curtis@ans.net 19990401
source: ANS
以下を発送してください。 140.222.0.0/16descr: ANS Communications発生源: AS1673、メンバー、-、: 近くRS-ANSOSPFAGGREGATE mnt: ANSは変化しました: curtis@ans.net 19990401ソース: ANS
timestamp: 19990401 10:30:00 +08:00
タイムスタンプ: 19990401 10:30:00 +08:00
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
署名: + -----PGP署名を始めてください。----- + バージョン: 個人のプライバシー5.0+MessageIDのためのPGP: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI++iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U+Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX+Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv+PGBIEN3/NlMは+ =c93c+と等しいです。-----終わりのPGP署名-----
auth-dependency: ARIN
sequence: 555
timestamp: 19990401 13:30:08 +05:00
auth-依存: ARIN系列: 555タイムスタンプ: 19990401 13:30:08 +05:00
auth-dependency: RADB
sequence: 4567
timestamp: 19990401 13:27:54 +05:00
auth-依存: RADB系列: 4567年のタイムスタンプ: 19990401 13:27:54 +05:00
repository-signature: ANS
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
倉庫署名: ANS署名: + -----PGP署名を始めてください。----- + バージョン: 個人のプライバシー5.0+MessageIDのためのPGP: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI++iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U+Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX+Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv+PGBIEN3/NlMは+ =c93c+と等しいです。-----終わりのPGP署名-----
Villamizar, et al. Standards Track [Page 30] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[30ページ]。
Note that the repository-signature above is a detached signature for another file and is illustrative only. The repository-signature covers from the "transaction-label" meta-object (including) to the last blank line before the first "repository-signature" meta-object (excluding the last blank line and the "repository-signature" object).
上の倉庫署名が別のファイルのための離れている署名であり、説明に役立っていることに注意してください。単に。 「トランザクションラベル」メタオブジェクト(含んでいる)から最後の空白までの倉庫署名カバーは最初の「倉庫署名」メタオブジェクト(最後の空白行と「倉庫署名」オブジェクトを除いた)の前に立ち並びます。
A.3 Transaction Protocol Encoding
A.3トランザクションプロトコルコード化
transaction-begin: 1276
transfer-method: plain
トランザクションで始まってください: 1276年の転写法: 平野
transaction-label: ANS
sequence: 6666
timestamp: 19990401 13:30:10 +05:00
integrity: authorized
トランザクションラベル: ANS系列: 6666年のタイムスタンプ: 19990401 13: 30:10 +05:00保全: 認可されます。
route: 140.222.0.0/16
descr: ANS Communications
origin: AS1673
member-of: RS-ANSOSPFAGGREGATE
mnt-by: ANS
changed: curtis@ans.net 19990401
source: ANS
以下を発送してください。 140.222.0.0/16descr: ANS Communications発生源: AS1673、メンバー、-、: 近くRS-ANSOSPFAGGREGATE mnt: ANSは変化しました: curtis@ans.net 19990401ソース: ANS
timestamp: 19990401 10:30:00 +08:00
タイムスタンプ: 19990401 10:30:00 +08:00
signature:
+ -----BEGIN PGP SIGNATURE-----
+ Version: PGP for Personal Privacy 5.0
+ MessageID: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI
+
+ iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U
+ Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX
+ Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv
+ PGBIEN3/NlM=
+ =c93c
+ -----END PGP SIGNATURE-----
署名: + -----PGP署名を始めてください。----- + バージョン: 個人のプライバシー5.0+MessageIDのためのPGP: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI++iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U+Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX+Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv+PGBIEN3/NlMは+ =c93c+と等しいです。-----終わりのPGP署名-----
auth-dependency: ARIN
sequence: 555
timestamp: 19990401 13:30:08 +05:00
auth-依存: ARIN系列: 555タイムスタンプ: 19990401 13:30:08 +05:00
auth-dependency: RADB
sequence: 4567
timestamp: 19990401 13:27:54 +05:00
auth-依存: RADB系列: 4567年のタイムスタンプ: 19990401 13:27:54 +05:00
Villamizar, et al. Standards Track [Page 31] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[31ページ]。
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-----
倉庫署名: ANS署名: + -----PGP署名を始めてください。----- + バージョン: 個人のプライバシー5.0+MessageIDのためのPGP: UZi4b7kjlzP7rb72pATPywPxYfQj4gXI++iQCVAwUANsrwkP/OhQ1cphB9AQFOvwP/Ts8qn3FRRLQQHKmQGzy2IxOTiF0QXB4U+Xzb3gEvfeg8NWhAI32zBw/D6FjkEw7P6wDFDeok52A1SA/xdP5wYE8heWQmMJQLX+Avf8W49d3CF3qzh59UC0ALtA5BjI3r37ubzTf3mgtw+ONqVJ5+lB5upWbqKN9zqv+PGBIEN3/NlMは+ =c93c+と等しいです。-----終わりのPGP署名-----
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.
以前、トランザクションを同輩に送って、倉庫prependsは「トランザクションで始まっている」メタオブジェクトです。 「トランザクション始まってください」という属性の値はトランザクションで、八重奏の数です、それの後に「トランザクションで始まっている」メタオブジェクトと最初の空白行を数えないで。
Separating transaction-begin and transaction-label objects enables different encodings at different flooding peerings.
分離して、トランザクションで始まってください。そうすれば、トランザクションラベルオブジェクトは異なった氾濫peeringsで異なったencodingsを有効にします。
A.4 Transaction Redistribution
A.4トランザクション再分配
The last step in Figure 1 was redistributing the submitter's transaction through flooding (or later through polling). Figure 2 illustrates the further redistribution of the transaction.
図1における最後のステップは氾濫(より遅く世論調査で)を通してsubmitterのトランザクションを再配付したことです。 図2はトランザクションのさらなる再分配を例証します。
If the authorization check was repeated, the mirror may optionally add a repository-signature before passing the transaction any further. A "signature" can be added within that block. The previous signatures should not be signed.
許可検査が繰り返されたなら、トランザクションをこれ以上通過する前に、鏡は任意に倉庫署名を加えるかもしれません。 そのブロックの中で「署名」を加えることができます。 前の署名に署名するべきではありません。
Figure 3 illustrates the special case referred to as a "lightweight mirror". This is specifically intended for routers.
図3は「軽量の鏡」と呼ばれた特別なケースを例証します。 これはルータのために明確に意図します。
The lightweight mirror must trust the mirror from which it gets a feed. This is a safe assumption if the two are under the same administration (the mirror providing the feed is a host owned by the same ISP who owns the routers). The lightweight mirror simply checks the signature of the adjacent repository to insure data integrity.
軽量の鏡はそれが給送を得る鏡を信じなければなりません。 2が同じ管理の下にあるなら(給送を提供する鏡はルータを所有しているのと同じISPによって所有されていたホストです)、これは安全な仮定です。 軽量の鏡は、データ保全を保障するために単に隣接している倉庫の署名をチェックします。
Villamizar, et al. Standards Track [Page 32] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[32ページ]。
+----------------+
| Redistributed |
| transaction |
+----------------+
|
| 1
v
+--------------------+ 2
| |---->+----------+
| Mirror repository | | database |
| |<----+----------+
+--------------------+ 3
|
| 4
v
+------------------+
|+----------------+|
|| Redistributed ||
|| transaction ||
|+----------------+|
| Optional |
| signature |
+------------------+
+----------------+ | 再配付します。| | トランザクション| +----------------+ | | 1 +に対して--------------------+ 2 | |---->+----------+ | 鏡の倉庫| | データベース| | | <、-、-、--+----------+ +--------------------+ 3 | | 4 +に対して------------------+ |+----------------+| || 再配付します。|| || トランザクション|| |+----------------+| | 任意| | 署名| +------------------+
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を使用することで完全なDBに対して承認を再確認してください。承認は、4 任意にその時が再配付するサインに渡すか、または失敗します。
Figure 2: Further Transaction Redistribution
図2: さらなるトランザクション再分配
Villamizar, et al. Standards Track [Page 33] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[33ページ]。
+----------------+
| Redistributed |
| transaction |
+----------------+
| 1
v
+--------------------+ 2
| |---->+----------+
| Mirror repository | | database |
| |<----+----------+
+--------------------+ 3
| 4
v
+----------------+
| Redistributed |
| transaction |
+----------------+
| 5
v
+--------------------+
| Lightweight | 6 +----------+
| Mirror repository |---->| database |
| (router?) | +----------+
+--------------------+
+----------------+ | 再配付します。| | トランザクション| +----------------+ | 1 +に対して--------------------+ 2 | |---->+----------+ | 鏡の倉庫| | データベース| | | <、-、-、--+----------+ +--------------------+ 3 | 4 +に対して----------------+ | 再配付します。| | トランザクション| +----------------+ | 5 +に対して--------------------+ | ライト級| 6 +----------+ | 鏡の倉庫|、-、-、--、>| データベース| | (ルータ)? | +----------+ +--------------------+
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を使用することで完全なDBに対して承認を再確認してください。承認は、4サインに渡すか、または失敗して、5 まさしくチェック鏡の署名6を再配付します。許可検査なしで変化を適用してください。
Figure 3: Redistribution to Lightweight Mirrors
図3: 軽量の鏡への再分配
Villamizar, et al. Standards Track [Page 34] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[34ページ]。
B Technical Discussion
B技術面の協議
B.1 Server Processing
B.1サーバ処理
This document does not mandate any particular software design, programming language choice, or underlying database or underlying operating system. Examples are given solely for illustrative purposes.
言語選択、基本的なデータベースまたは基本的なオペレーティングシステムをプログラムして、このドキュメントは少しの特定のソフトウェアデザインも強制しません。 例は唯一説明に役立った目的のために出されます。
B.1.1 getting connected
接続されるB.1.1
There are two primary methods of communicating with a repository server. E-mail can be sent to the server. This method may be deprecated but at least needs to be supported during transition. The second method is preferred, connect directly to a TCP socket.
倉庫サーバとコミュニケートする2つのプライマリメソッドがあります。メールをサーバに送ることができます。このメソッドは、推奨しないかもしれませんが、少なくとも変遷の間、サポートされる必要があります。 メソッドが好まれる秒に、直接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ポート接続を保有して、質問を含む他のすべての操作に予約された数のスペースでないところの2番目のポートを使用するのは、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などの汎用のデーモンを通して始められる取り扱い接続開始の2つのスタイルは、あります。 メールを通常、連続して扱って、メール配送エージェントとして機能するとしてプロセスでソケットに接続を作るフロントエンドプログラムで扱うことができます。
B.1.2 rolling transaction logs forward and back
取引ログが行き帰り進めるB.1.2回転
There is a need to be able to easily look back at previous states of any database in order to repeat authorization checks at the time of a transaction. This is difficult to do with the RIPE database implementation, which uses a sequentially written ASCII file and a set of Berkeley DB maintained index files for traversal. At the very minimum, the way in which deletes or replacements are implemented would need to be altered.
トランザクション時点で許可検査を繰り返すために容易にどんなデータベースの前のも見返すことができる必要があります。 これはRIPEデータベース実装を処理するのが難しいです。(実装は縦断に索引ファイルであることが保守された連続して書かれたASCIIファイルとバークレー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.
オブジェクトの先のバージョンで容易に視点をサポートするために、各オブジェクトに入ったトランザクションの一連番号は、オブジェクトで保たれる必要があるでしょう。 指針がオブジェクトの前のに必要でしょう。 削除は、削除された属性がある新しいオブジェクトとして実装される必要があるでしょう、オブジェクトの旧バージョンを置き換えますが、それに指針を保有して戻して。
Villamizar, et al. Standards Track [Page 35] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[35ページ]。
A separate transaction log needs to be maintained. Beyond some age, the older versions of objects and the the older transaction log entries can be removed although it is probably wise to archive them.
別々の取引ログは、維持される必要があります。 それらを格納するのがたぶん賢明ですが、いくらかの時代を超えたところまでオブジェクトの旧式のバージョンと、より古いトランザクション航空日誌記入事項を取り除くことができます。
B.1.3 committing or disposing of transactions
トランザクションを遂行するか、または処分するB.1.3
The ability to commit large transaction, or reject them as a whole poses problems for simplistic database designs. This form of commit operation can be supported quite easily using memory mapped files. The changes can be made in virtual memory only and then either committed or disposed of.
大口の取引を遂行するか、またはそれらを拒絶する全体で能力は安易なデータベースデザインのために問題を引き起こします。 これが形成する、サポートしている全く容易に使用しているメモリが写像しているファイルであったかもしれないなら操作を遂行してください。 次に、変更を仮想記憶だけで行って、遂行されるか、または処分できます。
B.1.4 dealing with concurrency
並行性に対処するB.1.4
Multiple connections may be active. In addition, a single connection may have multiple outstanding operations. It makes sense to have a single process or thread coordinate the responses for a given connection and have multiple processes or threads each tending to a single operation. The operations may complete in random order.
複数の接続が活発であるかもしれません。 さらに、単独結合には、複数の傑出している操作があるかもしれません。 それは、単一のプロセスかスレッドが与えられた接続のために応答を調整して、複数のプロセスを持っているのを持つ意味になるか、またはただ一つの操作に各傾向があることに糸を通します。 操作は無作為にオーダーを終了するかもしれません。
Locking on reads is not essential. Locking before write access is essential. The simplest approach to locking is to lock at the database granularity or at the database and object type granularity. Finer locking granularity can also be implemented. Because there are multiple databases, deadlock avoidance must be considered. The usual deadlock avoidance mechanism is to acquire all necessary locks in a single operation or acquire locks in a prescribed order.
読書をつなぐのは不可欠ではありません。 以前ロックするのは書きます。アクセスは不可欠です。 ロックへの最も簡単なアプローチはデータベース粒状において、または、データベースとオブジェクト・タイプ粒状においてロックすることです。 また、粒状をロックしているファイナーは実装することができます。 複数のデータベースがあるので、デッドロック回避を考えなければなりません。 普通のデッドロック回避メカニズムは、ただ一つの操作ですべての必要な錠を入手するか、または処方されたオーダーで錠を入手することです。
B.2 Repository Mirroring for Redundancy
冗長のためのB.2倉庫ミラーリング
There are numerous reasons why the operator of a repository might mirror their own repository. Possibly the most obvious are redundancy and the relative ease of disaster recovery. Another reason might be the widespread use of a small number of implementations (but more than one) and the desire to insure that the major repository software releases will accept a transaction before fully committing to the transaction.
倉庫のオペレータがそれら自身の倉庫を映すかもしれない多数の理由があります。 ことによると最も明白であるのは、冗長と災害復旧の相対的な容易さです。 別の理由は、少ない数の実装(しかし、1以上)の普及使用と主要な倉庫ソフトウェアリリースがトランザクションに完全に公約する前にトランザクションを受け入れるのを保障する願望であるかもしれません。
The operation of a repository mirror used for redundancy is quite straightforward. The transactions of the primary repository host can be immediately fed to the redundant repository host. For tighter assurances that false positive confirmations will be sent, as a matter of policy the primary repository host can require commit confirmation before making a transaction sequence publicly available.
冗長に使用される倉庫鏡の操作はかなり簡単です。 すぐに、プライマリ倉庫ホストのトランザクションを余分な倉庫ホストに食べさせることができます。 無病誤診確認を送るというよりきつい保証には、トランザクション系列を公的に利用可能にする前に、プライマリ倉庫ホストが必要とすることができる方針の問題として、確認を遂行してください。
There are many ways in which the integrity of local data can be assured regardless of a local crash in the midst of transaction disk writes. For example, transactions can be implemented as memory
トランザクションの中での地方のクラッシュにかかわらずディスクが書くことをローカルのデータの保全を保証できる多くの方法があります。 例えば、メモリとしてトランザクションを実装することができます。
Villamizar, et al. Standards Track [Page 36] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[36ページ]。
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.
異なったソフトウェア実行を使用する、鏡が設定している確認が必要とした鏡を遂行してください、延期された無期限に許容している他が続かせるトランザクションであるつもりであったならバグがいたる所で修理されるまですべてのトランザクションのリモート処理を止めるよりむしろ当然のaソフトウェアのバグに失敗するどんなトランザクション。
B.3 Trust Relationships
B.3信頼関係
If all repositories trust each other then there is never a need to repeat authorization checks. This enables a convenient interim step for deployment prior to the completion of software supporting that capability. The opposite case is where no repository trusts any other repository. In this case, all repositories must roll forward transactions gradually, checking the authorization of each remote transaction.
すべての倉庫であるなら、互いを信じてください、そして、次に、許可検査を繰り返す必要が決してありません。 これはその能力をサポートするソフトウェアの完成の前に展開のための便利な中間の段階を可能にします。 反対のケースはどんな倉庫もいかなる他の倉庫も信じないところです。 この場合すべての倉庫必須前進復帰トランザクション、徐々に、それぞれのリモートトランザクションの承認をチェックします。
It is likely that repositories will trust a subset of other repositories. This trust can reduce the amount of processing a repository required to maintain mirror images of the full set of data. For example, a subset of repositories might be trustworthy in that they take reasonable security measures, the organizations themselves have the integrity not to alter data, and these repositories trust only a limited set of similar repositories. If any one of these repositories receives a transaction sequence and repeats the authorization checks, other major repositories which trusts that repository need not repeat the checks. In addition, trust need not be mutual to reap some benefit in reduced processing.
倉庫は他の倉庫の部分集合を信じそうでしょう。 この信頼は倉庫がデータのフルセットの鏡像を維持するのを必要とした処理の量を減少させることができます。 例えば、合理的な安全策を取るので、倉庫の部分集合は信頼できるかもしれません、そして、組織自体には、データを変更しない保全があります、そして、これらの倉庫は限られたセットの同様の倉庫だけを信じます。 これらの倉庫のどれかがトランザクション系列を受け取って、許可検査を繰り返すなら、その倉庫がそうしなければならないそれの受託がチェックを繰り返さない他の主要な倉庫です。 さらに、信頼は、減少している処理における何らかの利益を獲得するために互いである必要はありません。
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.
トランザクション系列が倉庫から倉庫まで通過されるとき、それを進める前に、各倉庫は、トランザクションが系列であると署名します。 受信倉庫が、どんな信じられた倉庫もトランザクション系列に調印したのがわかるなら、信じられた倉庫が前の倉庫を信じたか、または許可検査を繰り返したので、認可されているとそれを考えることができます。
Villamizar, et al. Standards Track [Page 37] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[37ページ]。
B.4 A Router as a Minimal Mirror
B.4は最小量の鏡としてルータです。
A router could serve as a minimal repository mirror. The following simplifications can be made.
ルータは最小量の倉庫鏡として機能できました。 以下の簡素化をすることができます。
1. No support for repeating authorization checks or transaction
authentication checks need be coded in the router.
1. 繰り返している許可検査かトランザクション認証チェックのサポートは全くルータでコード化される必要はありません。
2. The router must be adjacent only to trusted mirrors, generally
operated by the same organization.
2. 一般に、ルータは、信じられた鏡だけに隣接していて、同じ組織は運用していなければなりません。
3. The router would only check the authentication of the adjacent
repository mirrors.
3. ルータは隣接している倉庫鏡の認証をチェックするだけでしょう。
4. No support for transaction submission or query need be coded in
the router. No commit support is needed.
4. トランザクション服従か質問のサポートは全くルータでコード化される必要はありません。 いいえはサポートを遂行します。必要です。
5. The router can dispose of any object types or attributes not
needed for configuration of route filters.
5. ルータはルートフィルタの構成に必要でないどんなオブジェクト・タイプや属性も処分できます。
The need to update router configurations could be significantly reduced if the router were capable of acting as a limited repository mirror.
ルータが限られた倉庫鏡として機能できるなら、ルータ構成をアップデートする必要性はかなり減少できるでしょうに。
A significant amount of non-volatile storage would be needed. There are currently an estimated 100 transactions per day. If storage were flash memory with a limited number of writes, or if there were some other reason to avoid writing to flash, the router could only update the non-volatile copy every few days. A transaction sequence request can be made to get an update in the event of a crash, returning only a few hundred updates after losing a few days of deferred writes. The routers can still take a frequent or continuous feed of transactions.
かなりの量の非揮発性記憶装置が必要でしょう。 現在、1日あたりおよそ100のトランザクションがあります。 ストレージが限られた数があるフラッシュメモリである、書く、ひらめくように書くのを避けるある他の理由がある場合にだけ、ルータはあらゆる数日単位で非揮発性のコピーをアップデートするかもしれないでしょうに。 クラッシュの場合、アップデートを得るのをトランザクション系列要求をすることができます、と延期されることの数日を失った後に数100のアップデートだけを返すのは書きます。 ルータはまだトランザクションの頻繁であるか連続した給送がかかっているかもしれません。
Alternately, router filters can be reconfigured periodically as they are today.
交互に、ルータフィルタは今日それらのように定期的に再構成できます。
B.5 Dealing with Errors
誤りに対処するB.5
If verification of an authorization check fails, the entire transaction must be rejected and no further advancement of the repository can occur until the originating repository corrects the problem. If the problem is due to a software bug, the offending transaction can be removed manually once the problem is corrected. If a software bug exists in the receiving software, then the
許可検査の検証が失敗するなら、全体のトランザクションを拒絶しなければなりません、そして、起因する倉庫が問題を修正するまで、倉庫のさらなる前進は全く起こることができません。 問題がソフトウェアのバグのためであるなら、問題がいったん直るようになると、手動で怒っているトランザクションを取り除くことができます。 そして、ソフトウェアのバグは受信ソフトウェアに存在しています。
Villamizar, et al. Standards Track [Page 38] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[38ページ]。
transaction sequence is stalled until the bug is corrected. It is better for software to error on the side of denying a transaction than acceptance, since an error on the side of acceptance will require later removal of the effects of the transaction.
バグが直るまで、トランザクション系列は失速されています。 ソフトウェアには、トランザクションを否定することの側では、それが承認より誤りに良いです、承認の側における誤りがトランザクションの効果の後の取り外しを必要とするので。
C Deployment Considerations
C展開問題
This section described deployment considerations. The intention is to raise issues rather than to provide a deployment plan.
このセクションは展開問題について説明しました。 意志は展開プランを提供するというよりむしろ問題を提起することです。
This document calls for a transaction exchange mechanism similar to but not identical to the existing "near real time mirroring" supported by the code base widely used by the routing registries. As an initial step, the transaction exchange can be implemented without the commit protocol or the ability to recheck transaction authorization. This is a fairly minimal step from the existing capabilities.
このドキュメントはルーティング登録によって広く使用されるコードベースによってサポートされた既存の「近いリアルタイムのミラーリング」と同様ですが、同じでなくトランザクション交換メカニズムを求めます。 初期のステップで、トランザクション交換を実装することができる、プロトコルかトランザクション承認を再確認する能力を遂行してください。 これは既存の能力からのかなり最小量のステップです。
The transition can be staged as follows:
以下の通り変遷を上演できます:
1. Modify the format of "near real time mirroring" transaction
exchange to conform to the specifications of this document.
1. このドキュメントの仕様に従うように「近いリアルタイムのミラーリング」トランザクション交換の形式を変更してください。
2. Implement commit protocol and confirmation support.
2. 道具はプロトコルと確認サポートを遂行します。
3. Implement remote recheck of authorization. Prior to this step all
repositories must be trusted.
3. 道具リモートである、承認を再確認してください。 このステップ前に、すべての倉庫を信じなければなりません。
4. Allow further decentralization of the repositories.
4. 倉庫のさらなる分散を許してください。
D Privacy of Contact Information
問い合わせ先のDプライバシー
The routing registries have contained contact information. The redistribution of this contact information has been a delicate issue and in some countries has legal implications.
ルーティング登録は問い合わせ先を含みました。 この問い合わせ先の再分配は、デリケートな発行であり、いくつかの国に法的な意味を持っています。
The person and role objects contain contact information. These objects are referenced by NIC-handles. There are some attributes such as the "changed" and "notify" attributes that require an email address. All of the fields that currently require an email address must also accept a NIC-handle.
人と役割のオブジェクトは問い合わせ先を含んでいます。 これらのオブジェクトはNIC-ハンドルによって参照をつけられます。 「変化」や「通知してください」というEメールアドレスを必要とする属性などのいくつかの属性があります。 また、現在Eメールアドレスを必要とする分野のすべてが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
デフォルトで人と役割のオブジェクトを再配付するべきではありません。 そして服従がNIC-ハンドルよりむしろ変えられた分野などの分野にEメールアドレスを保管しているならsubmitterが彼らが、そのEメールアドレスが再配付されるのを許しているのを意識しているべきである。
Villamizar, et al. Standards Track [Page 39] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[39ページ]。
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.
ソフトウェアで、それらのオブジェクト・タイプは他のオブジェクト・タイプの追加の承認に必要でない限り、他の全体のオブジェクト・タイプの再分配を制限するのが可能になるはずです。 これはsubmitterの署名を無効にするでしょう、したがって、属性を取り除くか、または変更している状態でオブジェクトを再配付して、その後の認証チェックを不可能にするのは可能ではありません。 倉庫は与えられたタイプのオブジェクトの部分集合を再配付するはずがありません。
Software should also not let a transaction contain both redistributable (e.g. policy objects) and non-redustributable objects (e.g. person) since there is no way to verify the signature of these transactions without the non-redustributable objects.
ソフトウェアで、また、非redustributableオブジェクトなしでこれらのトランザクションの署名について確かめる方法が全くないので、トランザクションは再配付可能(例えば、政策目的)と非redustributableオブジェクト(例えば、人)の両方を含むはずがありません。
When redistributing legacy data, contact information in attributes such as "changed" and "notify" should be stripped to maintain privacy. The "integrity" attribute on these objects should already be set to "legacy" indicating that their origin is questionable, so the issue of not being able to recheck signatures is not as significant.
レガシーデータを再配付するとき、プライバシーを維持するために「変えられる」ような属性と「通知してください」の問い合わせ先を剥取るべきです。 これらのオブジェクトの「保全」属性が既にそれらの発生源が疑わしいのを示す「レガシー」へのセットであるべきであるので、署名を再確認できない問題は重要ではありません。
References
参照
[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
Meyer, D., Bates, T., Karrenberg, D. and M. Terpstra, "Routing
Policy Specification Language", RFC 2622, June 1999.
[1]AlaettinogluとC.とVillamizarとC.とGerichとE.とKessensとD.とマイヤーとD.とベイツとT.とKarrenbergとD.とM.テルプストラ、「ルート設定方針仕様言語」、RFC2622、1999年6月。
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP
Routing Policies in a Routing Registry (ripe-81++)", RFC 1786,
March 1995.
[2] ベイツとT.とGerichとE.とJoncherayとL.、JouanigotとJ-M.とKarrenbergとD.とテルプストラとM.とJ.ユー、「ルート設定登録(熟している81++)のIPルート設定方針の表現」RFC1786(1995年3月)。
[3] Villamizar, C., Alaettinoglu, C., Meyer, D. and S. Murphy,
"Routing Policy System Security", RFC 2725, June 1999.
[3]VillamizarとC.とAlaettinogluとC.とマイヤーとD.とS.マーフィー、「ルート設定方針システムセキュリティ」、RFC2725、1999年6月。
[4] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC
2726, December 1999.
[4]Zsako、J.、「熟しているデータベース更新のためのPGP認証」、RFC2726、1999年12月。
Villamizar, et al. Standards Track [Page 40] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[40ページ]。
Security Considerations
セキュリティ問題
An authentication and authorization model for routing policy object submission is provided by [3]. Cryptographic authentication is addressed by [4]. This document provides a protocol for the exchange of information among distributed routing registries such that the authorization model provided by [3] can be adhered to by all registries and any deviation (hopefully accidental) from those rules on the part of a registry can be identified by other registries or mirrors.
[3]はルーティング政策目的提案のための認証と承認モデルを提供します。 暗号の認証は[4]によって扱われます。 このドキュメントは、すべての登録で[3]によって提供された承認モデルを固く守ることができて、他の登録か鏡で、登録側のそれらの規則からのどんな逸脱(願わくは偶然の)も特定できるように分配されたルーティング登録の中の情報交換にプロトコルを提供します。
Authors' Addresses
作者のアドレス
Curtis Villamizar Avici Systems EMail: curtis@avici.com
カーティスVillamizar Avici Systemsはメールされます: 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
デヴィッドM.マイヤーコクチマスメール: dmm@cisco.com
Villamizar, et al. Standards Track [Page 41] RFC 2769 Routing Policy System Replication February 2000
Villamizar、他 規格はルート設定方針システム模写2000年2月にRFC2769を追跡します[41ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Villamizar, et al. Standards Track [Page 42]
Villamizar、他 標準化過程[42ページ]
一覧
スポンサーリンク
