rfc2769.txt

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

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


   sequence-begin  This attribute is optional and mandatory.  It
      contains the value of the "sequence-begin" attribute in the
      original request.  It is omitted if the corresponding attribute
      was not specified in the original request.

   sequence-end  This attribute is optional and mandatory.  It contains
      the value of the "sequence-end" attribute in the original request.
      It is omitted if the corresponding attribute was not specified in
      the original request.

   After receiving a "transaction-response" meta-object, a repository
   may tear down the TCP connection to its peer.  This is useful for
   mirrors that intermittently resynchronize transactions with a
   repository.  If the TCP connection stays open, repositories exchange
   subsequent transactions according to the redistribution mechanism
   specified in Section  7.3.  While a repository is responding to a
   transaction-request, it MAY forward heartbeats and other transactions
   from the requested repository towards the requestor.

7.3.2  Heartbeat Processing

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

   The "heartbeat" meta-object contains the following attributes:

   heartbeat  This attribute is mandatory and single.  It contains the
      name of the repository which originates this meta-object.

   sequence  This attribute is mandatory and single.  It contains the
      highest transaction sequence number that has been assigned by the
      repository.

   timestamp  This attribute is mandatory and single.  It contains the
      time at which this meta-object was generated.  The format of this
      attribute is "YYYYMMDD hh:mm:ss [+/-]xx:yy", where "YYYY"
      specifies the four digit year, "MM" represents the month, "DD" the
      date, "hh" the hour, "mm" the minutes, "ss" the seconds of the
      timestamp, and "xx" and "yy" represents the hours and minutes
      respectively that that timestamp is ahead or behind UTC.

   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


   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

   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.

   After it has redistributed a transaction, the originating repository
   may request a commit confirmation from one or more peer repositories
   by sending to them a "commit-request" meta-object.  The "commit-
   request" contains two attributes:

   commit-request  This attribute is mandatory and single.  It contains
      the name of the database for whom a commit confirmation is being
      requested.

   sequence  This attribute is mandatory and single.  It contains the
      transaction sequence number for which a commit confirmation is
      being requested.

   A repository that receives a "commit-request" must not redistribute
   the request.  It must delay the response until the corresponding
   transaction has been processed.  For this reason, the repository must
   keep state about pending commit requests.  It should discard this
   state if the connection to the requester is lost before the response
   is sent.  In that event, it is the responsibility of the requester to
   resend the request.

   Once a transaction has been processed (Section 7.3), a repository
   must check to see if there exists any pending commit request for the
   transaction.  If so, it must send a "commit-response" meta-object to
   the requester.  This meta-object has three attributes:



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


   commit-response  This attribute is mandatory and single.  It contains
      the name of the database for whom a commit response is being sent.

   sequence  This attribute is mandatory and single.  It contains the
      transaction sequence number for which a commit response is being
      sent.

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

7.5  Database Snapshot

   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.

   A snapshot of repository X contains the following set of files:

   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.<class>.db  This optional file if present contains the RPSL objects
      in X.db that are of class <class>.  The format of the file is same
      as that of X.db.

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

   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.

   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


   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.

   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.

7.6  Authenticating Operations

   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.

   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.





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


   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.

     signature: clear-text-passwd <maintainer-name>

   Note that this does not make the system less secure since clear text
   password is an indication of total trust to the originating
   repository by the maintainer.

   A repository may sign a transaction that it verified.  If at any
   point the signature of a trusted repository is encountered, no
   further authorization or authentication is needed.



































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


A  Examples

   RPSL provides an external representation of RPSL objects and
   attributes.  An attribute is a name/value pair.  RPSL is line
   oriented.  Li