rfc2280.txt

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

   The mntner attribute is mandatory and is the class key attribute.
   Its value is an RPSL name.  The auth attribute specifies the scheme
   that will be used



Alaettinoglu, et. al.       Standards Track                     [Page 6]

RFC 2280                          RPSL                      January 1998


Attribute Value                    Type
mntner    <object-name>            mandatory, single-valued, class key
descr     <free-form>              mandatory, single-valued
auth      see description in text  mandatory, multi-valued
upd-to    <email-address>          mandatory, multi-valued
mnt-nfy   <email-address>          optional, multi-valued
tech-c    <nic-handle>             mandatory, multi-valued
admin-c   <nic-handle>             mandatory, multi-valued
remarks   <free-form>              optional, multi-valued
notify    <email-address>          optional, multi-valued
mnt-by    list of <mntner-name>    mandatory, multi-valued
changed   <email-address> <date>   mandatory, multi-valued
source    <registry-name>          mandatory, single-valued

   to identify and authenticate update requests from this maintainer.
   It has the following syntax:

      auth: <scheme-id> <auth-info>

      E.g.
             auth: NONE
             auth: CRYPT-PW dhjsdfhruewf
             auth: MAIL-FROM .*@ripe\.net

   The <scheme-id>'s currently defined are: NONE, MAIL-FROM, PGP and
   CRYPT-PW.  The <auth-info> is additional information required by a
   particular scheme: in the case of MAIL-FROM, it is a regular
   expression matching valid email addresses; in the case of CRYPT-PW,
   it is a password in UNIX crypt format; and in the case of PGP, it is
   a PGP public key.  If multiple auth attributes are specified, an
   update request satisfying any one of them is authenticated to be from
   the maintainer.

   The upd-to attribute is an email address.  On an unauthorized update
   attempt of an object maintained by this maintainer, an email message
   will be sent to this address.  The mnt-nfy attribute is an email
   address.  A notification message will be forwarded to this email
   address whenever an object maintained by this maintainer is added,
   changed or deleted.

   The descr attribute is a short, free-form textual description of the
   object.  The tech-c attribute is a technical contact NIC handle.
   This is someone to be contacted for technical problems such as
   misconfiguration.  The admin-c attribute is an administrative contact
   NIC handle.  The remarks attribute is a free text explanation or
   clarification.  The notify attribute is an email address to which
   notifications of changes to this object should be sent.  The mnt-by
   attribute is a list of mntner object names.  The authorization for



Alaettinoglu, et. al.       Standards Track                     [Page 7]

RFC 2280                          RPSL                      January 1998


   changes to this object is governed by any of the maintainer objects
   referenced.  The changed attribute documents who last changed this
   object, and when this change was made.  Its syntax has the following
   form:

      changed: <email-address> <YYYYMMDD>

      E.g.
      changed: [e-mail] 19900401

   The <email-address> identifies the person who made the last change.
   <YYYYMMDD> is the date of the change.  The source attribute specifies
   the registry where the object is registered.  Figure 2 shows an
   example mntner object.  In the example, UNIX crypt format password
   authentication is used.

      mntner:      RIPE-NCC-MNT
      descr:       RIPE-NCC Maintainer
      admin-c:     DK58
      tech-c:      OPS4-RIPE
      upd-to:      [e-mail]
      mnt-nfy:     [e-mail]
      auth:        CRYPT-PW lz1A7/JnfkTtI
      mnt-by:      RIPE-NCC-MNT
      changed:     [e-mail] 19970820
      source:      RIPE

                       Figure 2:  An example mntner object.

   The descr, tech-c, admin-c, remarks, notify, mnt-by, changed and
   source attributes are attributes of all RPSL classes.  Their syntax,
   semantics, and mandatory, optional, multi-valued, or single-valued
   status are the same for for all RPSL classes.  We do not further
   discuss them in other sections.

3.2 person Class

   A person class is used to describe information about people.  Even
   though it does not describe routing policy, we still describe it here
   briefly since many policy objects make reference to person objects.
   The person class was first described in [14].

   The attributes of the person class are shown in Figure 3.  The person
   attribute is the full name of the person.  The phone and the fax-no
   attributes have the following syntax:






Alaettinoglu, et. al.       Standards Track                     [Page 8]

RFC 2280                          RPSL                      January 1998


Attribute  Value                    Type
person     <free-form>              mandatory, single-valued
nic-hdl    <nic-handle>             mandatory, single-valued, class key
address    <free-form>              mandatory, multi-valued
phone      see description in text  mandatory, multi-valued
fax-no     same as phone            optional, multi-valued
e-mail     <email-address>          mandatory, multi-valued


                     Figure 3:  person Class Attributes

         phone: +<country-code> <city> <subscriber> [ext. <extension>]

      E.g.:
         phone: [phone]
         phone: [phone] ext. 4711


   Figure 4 shows an example person object.


      person:      Daniel Karrenberg
      address:     RIPE Network Coordination Centre (NCC)
      address:     Singel 258
      address:     NL-1016 AB  Amsterdam
      address:     Netherlands
      phone:       [phone]
      fax-no:      [phone]
      e-mail:      [e-mail]
      nic-hdl:     DK58
      changed:     [e-mail] 19970616
      source:      RIPE


                       Figure 4:  An example person object.

3.3 role Class

   The role class is similar to the person object.  However, instead of
   describing a human being, it describes a role performed by one or
   more human beings.  Examples include help desks, network monitoring
   centers, system administrators, etc.  Role object is particularly
   useful since often a person performing a role may change, however the
   role itself remains.

   The attributes of the role class are shown in Figure 5.  The nic-hdl
   attributes of the person and role classes share the same name space.
   The



Alaettinoglu, et. al.       Standards Track                     [Page 9]

RFC 2280                          RPSL                      January 1998


 Attribute  Value                    Type
 role       <free-form>              mandatory, single-valued
 nic-hdl    <nic-handle>             mandatory, single-valued, class key
 trouble    <free-form>              optional, multi-valued
 address    <free-form>              mandatory, multi-valued
 phone      see description in text  mandatory, multi-valued
 fax-no     same as phone            optional, multi-valued
 e-mail     <email-address>          mandatory, multi-valued


                      Figure 5:  role Class Attributes

   NIC handle of a role object cannot be used in an admin-c field.  The
   trouble attribute of role object may contain additional contact
   information to be used when a problem arises in any object that
   references this role object.  Figure 6 shows an example role object.

      role:        RIPE NCC Operations
      address:     Singel 258
      address:     1016 AB Amsterdam
      address:     The Netherlands
      phone:       [phone]
      fax-no:      [phone]
      e-mail:      [e-mail]
      admin-c:     CO19-RIPE
      tech-c:      RW488-RIPE
      tech-c:      JLSD1-RIPE
      nic-hdl:     OPS4-RIPE
      notify:      [e-mail]
      changed:     [e-mail] 19970926
      source:      RIPE


                        Figure 6:  An example role object.

4 route Class

   Each interAS route (also referred to as an interdomain route)
   originated by an AS is specified using a route object.  The
   attributes of the route class are shown in Figure 7.  The route
   attribute is the address prefix of the route and the origin attribute
   is the AS number of the AS that originates the route into the interAS
   routing system.  The route and origin attribute pair is the class
   key.

   Figure 8 shows examples of four route objects (we do not include
   contact.




Alaettinoglu, et. al.       Standards Track                    [Page 10]

RFC 2280                          RPSL                      January 1998


Attribute     Value                      Type
route         <address-prefix>           mandatory, single-valued,
                                         class key
origin        <as-number>                mandatory, single-valued,
                                         class key
withdrawn     <date>                     optional, single-valued
member-of     list of <route-set-names>  optional, single-valued
              see Section 5
inject        see Section 8              optional, multi-valued
components    see Section 8              optional, single-valued
aggr-bndry    see Section 8              optional, single-valued
aggr-mtd      see Section 8              optional, single-valued
export-comps  see Section 8              optional, single-valued
holes         see Section 8              optional, single-valued


                     Figure 7:  route Class Attributes

   attributes such as admin-c, tech-c for brevity).  Note that the last
   two route objects have the same address prefix, namely 128.8.0.0/16.
   However, they are different route objects since they are originated
   by different ASes (i.e. they have different keys).

      route: 128.9.0.0/16
      origin: AS226

      route: 128.99.0.0/16
      origin: AS226

      route: 128.8.0.0/16
      origin: AS1

      route: 128.8.0.0/16
      origin: AS2
      withdrawn: 19960624


                         Figure 8:  Route Objects

   The withdrawn attribute, if present, signifies that the originator AS
   no longer originates this address prefix in the Internet.  Its value
   is a date indicating the date of withdrawal.  In Figure 8, the last
   route object is withdrawn (i.e. no longer originated by AS2) on June
   24, 1996.







Alaettinoglu, et. al.       Standards Track                    [Page 11]

RFC 2280                          RPSL                      January 1998


5 Set Classes

   To specify policies, it is often useful to define sets of objects.
   For this purpose we define two classes: route-set and as-set.  These
   classes define a named set.  The members of these sets can be
   specified by either explicitly listing them in the set object's
   definition, or implicitly by having route and aut-num objects refer
   to the set names, or a combination of both methods.

5.1 route-set Class

   The attributes of the route-set class are shown in Figure 9.  The
   route-set attribute defines the name of the set.  It is an RPSL name
   that starts with "rs-".  The members attribute lists the members of
   the set.  The members attribute is a list of address prefixes or
   other route-set names.  Note that, the route-set class is a set of
   route prefixes, not of RPSL route objects.

   Attribute    Value                          Type
   route-set    <object-name>                  mandatory, single-valued,
                                               class key
   members      list of <address-prefixes> or  optional, single-valued
                <route-set-names>
   mbrs-by-ref  list of <mntner-names>         optional, single-valued


                   Figure 9:  route-set Class Attributes

   Figure 10 presents some example route-set objects.  The set rs-foo
   contains two address prefixes, namely 128.9.0.0/16 and 128.9.0.0/16.
   The set rs-bar contains the members of the set rs-foo and the address
   prefix 128.7.0.0/16.  The set rs-empty contains no members.

      route-set: rs-foo
      members: 128.9.0.0/16, 128.9.0.0/24

      route-set: rs-bar
      members: 128.7.0.0/16, rs-foo

      route-set: rs-empty