rfc2622.txt

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

   pairs.  Each attribute-value pair is written on a separate line.  The
   attribute name starts at column 0, followed by character ":" and
   followed by the value of the attribute.  The attribute which has the
   same name as the object's class should be specified first.  The
   object's representation ends when a blank line is encountered.  An
   attribute's value can be split over multiple lines, by having a
   space, a tab or a plus ('+') character as the first character of the
   continuation lines.  The character "+" for line continuation allows
   attribute values to contain blank lines.  More spaces may optionally
   be used after the continuation character to increase readability.
   The order of attribute-value pairs is significant.

   An object's description may contain comments.  A comment can be
   anywhere in an object's definition, it starts at the first "#"
   character on a line and ends at the first end-of-line character.
   White space characters can be used to improve readability.

   An integer can be specified using (1) the C programming language
   notation (e.g. 1, 12345); (2) sequence of four 1-octet integers (in
   the range from 0 to 255) separated by the character dot "."  (e.g.
   1.1.1.1, 255.255.0.0), in this case a 4-octet integer is formed by
   concatenating these 1-octet integers in the most significant to least
   significant order; (3) sequence of two 2-octet integers (in the range
   from 0 to 65535) separated by the character colon ":" (e.g. 3561:70,
   3582:10), in this case a 4-octet integer is formed by concatenating
   these 2-octet integers in the most significant to least significant
   order.

3 Contact Information

   The mntner, person and role classes, admin-c, tech-c, mnt-by,
   changed, and source attributes of all classes describe contact
   information.  The mntner class also specifies authenticaiton
   information required to create, delete and update other objects.
   These classes do not specify routing policies and each registry may
   have different or additional requirements on them.  Here we present
   the common denominator for completeness which is the RIPE database
   implementation [16].  Please consult your routing registry for the
   latest specification of these classes and attributes.  The "Routing
   Policy System Security" document [20] describes the authenticaiton
   and authorization model in more detail.

3.1 mntner Class

   The mntner class specifies authenticaiton information required to
   create, delete and update RPSL objects.  A provider, before he/she
   can create RPSL objects, first needs to create a mntner object.  The



Alaettinoglu, et al.        Standards Track                     [Page 7]

RFC 2622                          RPSL                         June 1999


   attributes of the mntner class are shown in Figure 1.  The mntner
   class was first described in [13].

   The mntner attribute is mandatory and is the class key.  Its value is
   an RPSL name.  The auth attribute specifies the scheme that will be
   used to identify and authenticate update requests from this
   maintainer.  It has the following syntax:

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

   E.g.
          auth: NONE

  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>            optional, 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


                     Figure 1:  mntner Class Attributes


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

   The <scheme-id>'s currently defined are: NONE, MAIL-FROM, PGP-KEY 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-KEY, it
   is a pointer to key-certif object [22] containing the PGP public key
   of the user.  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



Alaettinoglu, et al.        Standards Track                     [Page 8]

RFC 2622                          RPSL                         June 1999


   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
   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.  Only exception to this
   is the admin-c attribute which is mandatory for the aut-num class.
   We do not further discuss them in other sections.




Alaettinoglu, et al.        Standards Track                     [Page 9]

RFC 2622                          RPSL                         June 1999


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

   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:

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

   E.g.:
      phone: [phone]

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





Alaettinoglu, et al.        Standards Track                    [Page 10]

RFC 2622                          RPSL                         June 1999


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

  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


   role:        RIPE NCC Operations
   trouble:
   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.




Alaettinoglu, et al.        Standards Track                    [Page 11]

RFC 2622                          RPSL                         June 1999


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

   Attribute     Value                      Type
   route         <address-prefix>           mandatory, single-valued,
                                            class key
   origin        <as-number>                mandatory, single-valued,
                                            class key
   member-of     list of <route-set-names>  optional, multi-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, multi-valued


                        Figure 7:  route Class Attributes


      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

                             Figure 8:  Route Objects




Alaettinoglu, et al.        Standards Track                    [Page 12]

RFC 2622                          RPSL                         June 1999


5 Set Classes

   To specify policies, it is often useful to define sets of objects.
   For this purpose we define as-set, route-set, rtr-set, filter-set,
   and peering-set classes.  These classes define a named set.  The
   members of these sets can be specified either directly by listing
   them in the sets' definition, or indirectly by having member objects
   refer to the sets' names, or a combination of both methods.