rfc2769.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   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.

   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.

   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.

   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




Villamizar, et al.          Standards Track                    [Page 11]

RFC 2769           Routing Policy System Replication       February 2000


      transaction has been successful and will not be lost by a crash of
      the local repository.  A submitter may optionally request such a
      confirmation.  This is discussed in Section 6.3.

6.1  Initial Transaction Submission

   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.

   The encapsulation of a transaction submission and response is
   described in detail in Section 7.


6.2  Redistribution of Transactions

   Redistribution of transactions can be accomplished using one of:

   1. A repository snapshot is a request for the complete contents of a
      given repository.  This is usually done when starting up a new
      repository or mirror or when recovering from a disaster, such as a
      disk crash.

   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.

   3. Transaction flooding is accomplished through a unicast adjacency.

   This section describes the operations somewhat qualitatively.  Data
   formats and state diagrams are provided in Section 7.

6.3  Transaction Commit and Confirmation

   If a submission requires a strong confirmation of completion, or if a
   higher degree of protection against false positive confirmation is
   desired as a matter of repository policy, a commit may be performed.

   A commit request is a request from the repository processing an
   initial transaction submission to another repository to confirm that
   they have been able to advance the transaction sequence up to the



Villamizar, et al.          Standards Track                    [Page 12]

RFC 2769           Routing Policy System Replication       February 2000


   sequence number immediately below the transaction in the request and
   are willing to accept the transaction in the request as a further
   advance in the sequence.  This indicates that either the
   authorization was rechecked by the responding repository and passed
   or that the responding repository trusts the requesting repository
   and has accepted the transaction.

   A commit request can be sent to more than one alternate repository.
   One commit completion response is sufficient to respond to the
   submitter with a positive confirmation that the transaction has been
   completed.  However, the repository or submitter may optionally
   require more than one.

7  Data Format Summaries, Transaction Encapsulation and Processing

   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.

   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.

7.1  Transaction Submit and Confirm

   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.

   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.








Villamizar, et al.          Standards Track                    [Page 13]

RFC 2769           Routing Policy System Replication       February 2000


   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.

   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.

   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.








Villamizar, et al.          Standards Track                    [Page 14]

RFC 2769           Routing Policy System Replication       February 2000


   The meta-objects "transaction-submit-begin" and "transaction-submit-
   end" delimit a transaction.  A transaction is handled as an atomic
   operation.  If any part of the transaction fails none of the changes
   take effect.  For this reason a transaction can only operate on a
   single database.

   A socket connection is used to request queries or submit
   transactions.  An email interface may be provided by an external
   program that connects to the socket.  A socket connection must use
   the "transaction-submit-begin" and "transaction-submit-end"
   delimiters but can request a legacy style confirmation.  Multiple
   transactions may be sent prior to the response for any single
   transaction.  Transactions may not complete in the order sent.

   The "transaction-submit-begin" meta-object may contain the following
   attributes.

   transaction-submit-begin  This attribute is mandatory and single.
      The value of the attribute contains name of the database and an
      identifier that must be unique over the course of the socket
      connection.

   response-auth-type  This attribute is optional and multiple.  The
      remainder of the line specifies an authentication type that would
      be acceptable in the response.  This is used to request a response
      cryptographically signed by the repository.

   transaction-confirm-type  This attribute is optional and single.  A
      confirmation type keyword must be provided.  Keywords are "none",
      "legacy", "normal", "commit".  The confirmation type can be
      followed by the option "verbose".

   The "transaction-submit-end meta-object consists of a single
   attribute by the same name.  It must contain the same database name
   and identifier as the corresponding "transaction-submit-begin"
   attribute.

   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).

   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


   A transaction confirmation is returned as a "transaction-confirm"
   meta-object.  The "transaction-confirm" meta-object may have the
   following attributes.

   transaction-confirm  This attribute is mandatory and single.  It
      contains the database name and identifier associated with the
      transaction.

   confirmed-operation  This attribute is optional and multiple.  It
      contains one of the keywords "add", "delete" or "modify" followed
      by the object type and key fields of the object operated on.

   commit-status  This attribute is mandatory and single.  It contains
      one of the keywords "succeeded, "error", or "held".  The "error"
      keyword may be followed by an optional text string.  The "held"
      keyword is returned when a repository containing a dependent
      object for authorization has expired.

7.2  Redistribution of Transactions

   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.

   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.