rfc2769.txt

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

   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

   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.

   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.

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.



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.

   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.

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

   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://[e-mail]
     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


   The attributes of the repository object are listed below.

     repository      key  mandatory  single
     query-address        mandatory  multiple
     response-auth-type   mandatory  multiple
     submit-address       mandatory  multiple
     submit-auth-type     mandatory  multiple
     repository-cert      mandatory  multiple
     expire               mandatory  single
     heartbeat-interval   mandatory  single
     descr                optional   multiple
     remarks              optional   multiple
     admin-c              mandatory  multiple
     tech-c               mandatory  multiple
     notify               optional   multiple
     mnt-by               mandatory  multiple
     changed              mandatory  multiple
     source               mandatory  single

   In the above object type only a small number of the attribute types
   are new.  These are:

   repository  This attribute provides the name of the repository.  This
      is the key field for the object and is single and must be globally
      unique.  This is the same name used in the source attribute of all
      objects in that repository.

   query-address  This attribute provides a url for directing queries.
      "rps-query" or "whois" can be used as the protocol identifier.

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





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.

   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.

   The remaining attributes in the repository object are defined in
   RPSL.

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.

   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.






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.

     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.

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.

   The "integrity" attribute may have the values "legacy", "no-auth",
   "auth-failed", or "authorized".  If absent, the integrity is
   considered to be "authorized".  The integrity values have the
   following meanings:

   legacy:  This data existed prior to the use of an adequate
      authorization model.  The data is highly suspect.

   no-auth:  This data was added to a repository during an initial
      transition use of an authorization model but authorization
      depended on other objects whose integrity was not "authorized".
      Such an addition is being allowed during the transition but would
      be disallowed later.

   auth-failed:  The authoritative repository is not checking
      authorization.  Had it been doing so, authorization would have
      failed.  This attribute may be added by a repository that is
      mirroring before placing the object in its local storage, or can
      add this attribute to an encapsulating meta-object used to further
      propagate the transaction.  If the failure to enforce
      authorization is intentional and part of a transition (for
      example, issuing warnings only), then the authoritative repository
      may add this attribute to the encapsulating meta-object used to
      further propagate the transaction.



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


   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.

   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