9 inet-rtr Class

Routers are specified using the inet-rtr class.  The attributes of the
inet-rtr class are shown in Figure 35.  The inet-rtr attribute is a valid
DNS name of the router described.  Each alias attribute, if present, is a
canonical DNS name for the router.  The local-as attribute specifies the AS
number of the AS which owns/operates this router.

  Attribute  Value                    Type
  inet-rtr   <dns-name>               mandatory, single-valued, class key
  alias      <dns-name>               optional, multi-valued
  local-as   <as-number>              mandatory, single-valued
  ifaddr     see description in text  mandatory, multi-valued
  peer       see description in text  optional, multi-valued
  member-of  list of <rtr-set-names>  optional, multi-valued


                   Figure 35:  inet-rtr Class Attributes

   The value of an ifaddr attribute has the following syntax:

   <ipv4-address> masklen <integer> [action <action>]

   The IP address and the mask length are mandatory for each interface.
   Optionally an action can be specified to set other parameters of this
   interface.

   Figure 36 presents an example inet-rtr object.  The name of the
   router is "amsterdam.ripe.net".  "amsterdam1.ripe.net" is a canonical
   name for the router.  The router is connected to 4 networks.  Its IP
   addresses and mask lengths in those networks are specified in the
   ifaddr attributes.

    inet-rtr: Amsterdam.ripe.net
    alias:    amsterdam1.ripe.net
    local-as: AS3333
    ifaddr:   192.87.45.190 masklen 24
    ifaddr:   192.87.4.28   masklen 24
    ifaddr:   193.0.0.222   masklen 27
    ifaddr:   193.0.0.158   masklen 27
    peer:     BGP4 192.87.45.195 asno(AS3334), flap_damp()


                           Figure 36:  inet-rtr Objects

   Each peer attribute, if present, specifies a protocol peering with
   another router.  The value of a peer attribute has the following
   syntax:

     <protocol> <ipv4-address>      <options>
   | <protocol> <inet-rtr-name>     <options>
   | <protocol> <rtr-set-name>      <options>
   | <protocol> <peering-set-name>  <options>

   where <protocol> is a protocol name, <ipv4-address> is the IP address
   of the peer router, and <options> is a comma separated list of
   peering options for <protocol>.  Instead of the peer's IP address,
   its inet-rtr-name can be used.  Possible protocol names and
   attributes are defined in the dictionary (please see Section 7).  In
   the above example, the router has a BGP peering with the router
   192.87.45.195 in AS3334 and turns the flap damping on when importing
   routes from this router.

   Instead of a single peer, a group of peers can be specified by using
   the <rtr-set-name> and <peering-set-name> forms.  If <peering-set-
   name> form is being used only the peerings in the corresponding
   peering set that are with this router are included.  Figure 37 shows

   an example inet-rtr object with peering groups.

    rtr-set: rtrs-ibgp-peers
    members: 1.1.1.1, 2.2.2.2, 3.3.3.3

    peering-set: prng-ebgp-peers
    peering: AS3334 192.87.45.195
    peering: AS3335 192.87.45.196

    inet-rtr: Amsterdam.ripe.net
    alias:    amsterdam1.ripe.net
    local-as: AS3333
    ifaddr:   192.87.45.190 masklen 24
    ifaddr:   192.87.4.28   masklen 24
    ifaddr:   193.0.0.222   masklen 27
    ifaddr:   193.0.0.158   masklen 27
    peer:     BGP4 rtrs-ibgp-peers asno(AS3333), flap_damp()
    peer:     BGP4 prng-ebgp-peers asno(PeerAS), flap_damp()


                 Figure 37:  inet-rtr Object with peering groups

10 Extending RPSL

   Our experience with earlier routing policy languages and data formats
   (PRDB [2], RIPE-81 [8], and RIPE-181 [7]) taught us that RPSL had to
   be extensible.  As a result, extensibility was a primary design goal
   for RPSL.  New routing protocols or new features to existing routing
   protocols can be easily handled using RPSL's dictionary class.  New
   classes or new attributes to the existing classes can also be added.

   This section provides guidelines for extending RPSL. These guidelines
   are designed with an eye toward maintaining backward compatibility
   with existing tools and databases.  We next list the available
   options for extending RPSL from the most preferred to the least
   preferred order.

10.1 Extensions by changing the dictionary class

   The dictionary class is the primary mechanism provided to extend
   RPSL.  Dictionary objects define routing policy attributes, types,
   and routing protocols.

   We recommend updating the RPSL dictionary to include appropriate rp-
   attribute and protocol definitions as new path attributes or router
   features are introduced.  For example, in an earlier version of the
   RPSL document, it was only possible to specify that a router performs
   route flap damping on a peer, but it was not possible to specify the

   parameters of route flap damping.  Later the parameters were added by
   changing the dictionary.

   When changing the dictionary, full compatibility should be
   maintained.  For example, in our flap damping case, we made the
   parameter specification optional in case this level of detail was not
   desired by some ISPs.  This also achieved compatibility.  Any object
   registered without the parameters will continue to be valid.  Any
   tool based on RPSL is expected to do a default action on routing
   policy attributes that they do not understand (e.g. issue a warning
   and otherwise ignore).  Hence, old tools upon encountering a flap
   damping specification with parameters will ignore the parameters.

10.2 Extensions by adding new attributes to existing classes

   New attributes can be added to any class.  To ensure full
   compatibility, new attributes should not contradict the semantics of
   the objects they are attached to.  Any tool that uses the IRR should
   be designed so that it ignores attributes that it doesn't understand.
   Most existing tools adhere to this design principle.

   We recommend adding new attributes to existing classes when a new
   aspect of a class is discovered.  For example, RPSL route class
   extends its RIPE-181 predecessor by including several new attributes
   that enable aggregate and static route specification.

10.3 Extensions by adding new classes

   New classes can be added to RPSL to store new types of policy data.
   Providing full compatibility is straight forward as long as existing
   classes are still understood.  Since a tool should only query the IRR
   for the classes that it understand, full compatibility should not be
   a problem in this case.

   Before adding a new class, one should question if the information
   contained in the objects of the new class could have better belonged
   to some other class.  For example, if the geographic location of a
   router needs to be stored in IRR, it may be tempting to add a new
   class called, say router-location class.  However, the information
   better belongs to the inet-rtr class, perhaps in a new attribute
   called location.

10.4 Extensions by changing the syntax of existing RPSL attributes

   If all of the methods described above fail to provide the desired
   extension, it may be necessary to change the syntax of RPSL. Any
   change in RPSL syntax must provide backwards compatibility, and
   should be considered only as a last resort since full compatibility

   may not be achievable.  However, we require that the old syntax to be
   still valid.

11 Security Considerations

   This document describes RPSL, a language for expressing routing
   policies.  The language defines a maintainer (mntner class) object
   which is the entity which controls or "maintains" the objects stored
   in a database expressed by RPSL. Requests from maintainers can be
   authenticated with various techniques as defined by the "auth"
   attribute of the maintainer object.

   The exact protocols used by IRR's to communicate RPSL objects is
   beyond the scope of this document, but it is envisioned that several
   techniques may be used, ranging from interactive query/update
   protocols to store and forward protocols similar to or based on
   electronic mail (or even voice telephone calls).  Regardless of which
   protocols are used in a given situation, it is expected that
   appropriate security techniques such as IPSEC, TLS or PGP/MIME will
   be utilized.

12 Acknowledgements

   We would like to thank Jessica Yu, Randy Bush, Alan Barrett, Bill
   Manning, Sue Hares, Ramesh Govindan, Kannan Varadhan, Satish Kumar,
   Craig Labovitz, Rusty Eddy, David J. LeRoy, David Whipple, Jon
   Postel, Deborah Estrin, Elliot Schwartz, Joachim Schmitz, Mark Prior,
   Tony Przygienda, David Woodgate, Rob Coltun, Sanjay Wadhwa, Ardas
   Cilingiroglu, and the participants of the IETF RPS Working Group for
   various comments and suggestions.

References

   [1] Internet routing registry. procedures.
       http://www.ra.net/RADB.tools.docs/,
       http://www.ripe.net/db/doc.html.

   [2] Nsfnet policy routing database (prdb). Maintained by MERIT
       Network Inc., Ann Arbor, Michigan. Contents available from
       nic.merit.edu.:/nsfnet/announced.networks/nets.tag.now by
       anonymous ftp.

   [3] Alaettinouglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer,
       D., Terpstra, M. and C. Villamizer, "Routing Policy Specification
       Language (RPSL)", RFC 2280, January 1998.

   [4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of
       routing policy specification language (rpsl) on the internet.
       Work in Progress.

   [5] T. Bates. Specifying an `internet router' in the routing
       registry.  Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam,
       Netherlands, October 1994.

   [6] T. Bates, E. Gerich, L. Joncheray, J-M. Jouanigot, D. Karrenberg,
       M. Terpstra, and J. Yu. Representation of ip routing policies in
       a routing registry. Technical Report ripe-181, RIPE, RIPE NCC,
       Amsterdam, Netherlands, October 1994.

   [7] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
       Karrenberg, D., Terpstra, M. and J. Yu, " Representation of IP
       Routing Policies in a Routing Registry", RFC 1786, March 1995.

   [8] T. Bates, J-M. Jouanigot, D. Karrenberg, P. Lothberg, and M.
       Terpstra.  Representation of ip routing policies in the ripe
       database. Technical Report ripe-81, RIPE, RIPE NCC, Amsterdam,
       Netherlands, February 1993.

   [9] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute",
       RFC 1997, August 1996.

  [10] Crocker, D., "Standard for ARPA Internet Text Messages", STD 11,
       RFC 822, August 1982.

  [11] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
       Domain Routing (CIDR): an Address Assignment and Aggregation
       Strategy", RFC 1519, September 1993.

  [12] D. Karrenberg and T. Bates. Description of inter-as networks in
       the ripe routing registry. Technical Report RIPE-104, RIPE, RIPE
       NCC, Amsterdam, Netherlands, December 1993.

  [13] D. Karrenberg and M. Terpstra. Authorisation and notification of
       changes in the ripe database. Technical Report ripe-120, RIPE,
       RIPE NCC, Amsterdam, Netherlands, October 1994.

  [14] B. W. Kernighan and D. M. Ritchie. The C Programming Language.
       Prentice-Hall, 1978.

  [15] A. Lord and M. Terpstra. Ripe database template for networks and
       persons. Technical Report ripe-119, RIPE, RIPE NCC, Amsterdam,
       Netherlands, October 1994.

  [16] A. M. R. Magee. Ripe ncc database documentation. Technical Report
       RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.

  [17] Mockapetris, P., "Domain names - concepts and facilities", STD
       13, RFC 1034, November 1987.

  [18] Y. Rekhter. Inter-domain routing protocol (idrp). Journal of
       Internetworking Research and Experience, 4:61--80, 1993.

  [19] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
       1771, March 1995.

  [20] C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C.
       Orange.  Routing policy system security", Work in Progress.

  [21] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap
       Damping", RFC 2439, November 1998.

  [22] J. Zsako, "PGP authentication for ripe database updates", Work in
       Progress.

A Routing Registry Sites

   The set of routing registries as of November 1996 are RIPE, RADB,
   CANet, MCI and ANS. You may contact one of these registries to find
   out the current list of registries.

B Grammar Rules

   In this section we provide formal grammar rules for RPSL. Basic data
   types are defined in Section 2.  We do not provide formal grammar
   rules for attributes whose values are of basic types or list of basic
   types.  The rules are written using the input language of GNU Bison
   parser.  Hence, they can be cut and pasted to that program.

//**** Generic Attributes **********************************************

changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT

//**** aut-num class ***************************************************

//// as_expression /////////////////////////////////////////////////////

opt_as_expression:
| as_expression

as_expression: as_expression OP_OR as_expression_term
| as_expression_term

as_expression_term: as_expression_term OP_AND as_expression_factor
| as_expression_term KEYW_EXCEPT as_expression_factor
| as_expression_factor

as_expression_factor: '(' as_expression ')'
| as_expression_operand

as_expression_operand: TKN_ASNO
| TKN_ASNAME

//// router_expression /////////////////////////////////////////////////

opt_router_expression:
| router_expression

opt_router_expression_with_at:
| KEYW_AT router_expression

router_expression: router_expression OP_OR router_expression_term
| router_expression_term

router_expression_term: router_expression_term OP_AND
                        router_expression_factor
| router_expression_term KEYW_EXCEPT router_expression_factor
| router_expression_factor

router_expression_factor: '(' router_expression ')'
| router_expression_operand

router_expression_operand: TKN_IPV4
| TKN_DNS
| TKN_RTRSNAME

//// peering ///////////////////////////////////////////////////////////

peering: as_expression opt_router_expression opt_router_expression_with_at
| TKN_PRNGNAME

//// action ////////////////////////////////////////////////////////////

opt_action:
| KEYW_ACTION action

action: single_action
| action single_action
single_action: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')' ';'
| TKN_RP_ATTR TKN_OPERATOR list_item ';'
| TKN_RP_ATTR '(' generic_list ')' ';'
| TKN_RP_ATTR '[' generic_list ']' ';'
| ';'

//// filter ////////////////////////////////////////////////////////////

filter: filter OP_OR filter_term
| filter filter_term %prec OP_OR
| filter_term

filter_term : filter_term OP_AND filter_factor
| filter_factor

filter_factor :  OP_NOT filter_factor
| '(' filter ')'
| filter_operand

filter_operand: KEYW_ANY
| '<' filter_aspath '>'
| filter_rp_attribute
| TKN_FLTRNAME
| filter_prefix

filter_prefix: filter_prefix_operand OP_MS
|  filter_prefix_operand

filter_prefix_operand: TKN_ASNO
| KEYW_PEERAS
| TKN_ASNAME
| TKN_RSNAME
| '{' opt_filter_prefix_list '}'

opt_filter_prefix_list:
| filter_prefix_list

filter_prefix_list: filter_prefix_list_prefix
| filter_prefix_list ',' filter_prefix_list_prefix

filter_prefix_list_prefix: TKN_PRFXV4
| TKN_PRFXV4RNG

filter_aspath: filter_aspath '|' filter_aspath_term
| filter_aspath_term

filter_aspath_term: filter_aspath_term filter_aspath_closure
| filter_aspath_closure

filter_aspath_closure: filter_aspath_closure '*'
| filter_aspath_closure '?'
| filter_aspath_closure '+'
| filter_aspath_factor

filter_aspath_factor: '^'
| '$'
| '(' filter_aspath ')'
| filter_aspath_no

filter_aspath_no: TKN_ASNO
| KEYW_PEERAS
| TKN_ASNAME
| '.'
| '[' filter_aspath_range ']'
| '[' '^' filter_aspath_range ']'

filter_aspath_range:
| filter_aspath_range TKN_ASNO
| filter_aspath_range KEYW_PEERAS
| filter_aspath_range '.'
| filter_aspath_range TKN_ASNO '-' TKN_ASNO
| filter_aspath_range TKN_ASNAME

filter_rp_attribute: TKN_RP_ATTR '.' TKN_WORD '(' generic_list ')'
| TKN_RP_ATTR TKN_OPERATOR list_item
| TKN_RP_ATTR '(' generic_list ')'
| TKN_RP_ATTR '[' generic_list ']'

//// peering action pair ///////////////////////////////////////////////

import_peering_action_list: KEYW_FROM peering opt_action
| import_peering_action_list KEYW_FROM peering opt_action

export_peering_action_list: KEYW_TO peering opt_action
| export_peering_action_list KEYW_TO peering opt_action

//// import/export factor //////////////////////////////////////////////

import_factor: import_peering_action_list KEYW_ACCEPT filter

import_factor_list: import_factor ';'
| import_factor_list import_factor ';'

export_factor: export_peering_action_list KEYW_ANNOUNCE filter

export_factor_list: export_factor ';'
| export_factor_list export_factor ';'

//// import/export term ////////////////////////////////////////////////

import_term: import_factor ';'
| '{' import_factor_list '}'

export_term: export_factor ';'
| '{' export_factor_list '}'

//// import/export expression //////////////////////////////////////////

import_expression: import_term
| import_term KEYW_REFINE import_expression
| import_term KEYW_EXCEPT import_expression

export_expression: export_term
| export_term KEYW_REFINE export_expression
| export_term KEYW_EXCEPT export_expression

//// protocol ///////////////////////////////////////////////////////////

opt_protocol_from:
| KEYW_PROTOCOL tkn_word

opt_protocol_into:
| KEYW_INTO tkn_word

//**** import/export attributes ****************************************

import_attribute: ATTR_IMPORT
| ATTR_IMPORT opt_protocol_from opt_protocol_into import_factor

export_attribute: ATTR_EXPORT
| ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor

opt_default_filter:
| KEYW_NETWORKS filter

default_attribute: ATTR_DEFAULT KEYW_TO peering

filter_attribute: ATTR_FILTER filter

peering_attribute: ATTR_PEERING peering

//**** inet-rtr class **************************************************

ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action

//// peer attribute ////////////////////////////////////////////////////

opt_peer_options:
| peer_options

peer_options: peer_option
| peer_options ',' peer_option

peer_option: tkn_word '(' generic_list ')'

peer_id: TKN_IPV4
| TKN_DNS
| TKN_RTRSNAME
| TKN_PRNGNAME

peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options

//**** route class *****************************************************

aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression

aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND
| ATTR_AGGR_MTD KEYW_OUTBOUND opt_as_expression

//// inject attribute //////////////////////////////////////////////////

opt_inject_expression:
| KEYW_UPON inject_expression

inject_expression: inject_expression OP_OR inject_expression_term
| inject_expression_term

inject_expression_term: inject_expression_term OP_AND
                        inject_expression_factor
| inject_expression_factor

inject_expression_factor: '(' inject_expression ')'
| inject_expression_operand

inject_expression_operand: KEYW_STATIC
| KEYW_HAVE_COMPONENTS '{' opt_filter_prefix_list '}'
| KEYW_EXCLUDE '{' opt_filter_prefix_list '}'

inject_attribute: ATTR_INJECT opt_router_expression_with_at opt_action
                              opt_inject_expression

//// components attribute //////////////////////////////////////////////

opt_atomic:
| KEYW_ATOMIC

components_list:
| filter
| components_list KEYW_PROTOCOL tkn_word filter

components_attribute: ATTR_COMPONENTS opt_atomic components_list

//**** route-set *******************************************************

opt_rs_members_list: /* empty list */
| rs_members_list

rs_members_list: rs_member
| rs_members_list ',' rs_member

rs_member: TKN_ASNO
| TKN_ASNO OP_MS
| TKN_ASNAME
| TKN_ASNAME OP_MS
| TKN_RSNAME
| TKN_RSNAME OP_MS
| TKN_PRFXV4

| TKN_PRFXV4RNG

rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list

//**** dictionary ******************************************************

rpattr_attribute: ATTR_RP_ATTR TKN_WORD methods
| ATTR_RP_ATTR TKN_RP_ATTR methods

methods: method
| methods method

method: TKN_WORD '(' ')'
| TKN_WORD '(' typedef_type_list ')'
| TKN_WORD '(' typedef_type_list ',' TKN_3DOTS ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ')'
| KEYW_OPERATOR TKN_OPERATOR '(' typedef_type_list ',' TKN_3DOTS ')'

//// typedef attribute  ////////////////////////////////////////////////

typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type

typedef_type_list: typedef_type
| typedef_type_list ',' typedef_type

typedef_type: KEYW_UNION typedef_type_list
| KEYW_RANGE KEYW_OF typedef_type
| TKN_WORD
| TKN_WORD '[' TKN_INT ',' TKN_INT ']'
| TKN_WORD '[' TKN_REAL ',' TKN_REAL ']'
| TKN_WORD '[' enum_list ']'
| KEYW_LIST '[' TKN_INT ':' TKN_INT ']' KEYW_OF typedef_type
| KEYW_LIST KEYW_OF typedef_type

enum_list: tkn_word
| enum_list ',' tkn_word

//// protocol attribute ////////////////////////////////////////////////

protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options

protocol_options:
| protocol_options protocol_option

protocol_option: KEYW_MANDATORY method
| KEYW_OPTIONAL method

//**** Token Definitions ***********************************************

//// flex macros used in token definitions /////////////////////////////
INT            [[:digit:]]+
SINT           [+-]?{INT}
REAL           [+-]?{INT}?\.{INT}({WS}*E{WS}*[+-]?{INT})?
NAME           [[:alpha:]]([[:alnum:]_-]*[[:alnum:]])?
ASNO           AS{INT}
ASNAME         AS-[[:alnum:]_-]*[[:alnum:]]
RSNAME         RS-[[:alnum:]_-]*[[:alnum:]]
RTRSNAME       RTRS-[[:alnum:]_-]*[[:alnum:]]
PRNGNAME       PRNG-[[:alnum:]_-]*[[:alnum:]]
FLTRNAME       FLTR-[[:alnum:]_-]*[[:alnum:]]
IPV4           [0-9]+(\.[0-9]+){3,3}
PRFXV4         {IPV4}\/[0-9]+
PRFXV4RNG      {PRFXV4}("^+"|"^-"|"^"{INT}|"^"{INT}-{INT})
ENAMECHAR      [^()<>,;:\\\"\.[\] \t\r]
ENAME          ({ENAMECHAR}+(\.{ENAMECHAR}+)*\.?)|(\"[^\"@\\\r\n]+\")
DNAME          [[:alnum:]_-]+
//// Token Definitions ////////////////////////////////////////////////
TKN_INT         {SINT}
TKN_INT         {INT}:{INT}             if each {INT} is two octets
TKN_INT         {INT}.{INT}.{INT}.{INT} if each {INT} is one octet
TKN_REAL        {REAL}
TKN_STRING      Same as in programming language C
TKN_IPV4        {IPV4}
TKN_PRFXV4      {PRFXV4}
TKN_PRFXV4RNG   {PRFXV4RNG}
TKN_ASNO        {ASNO}
TKN_ASNAME      (({ASNO}|peeras|{ASNAME}):)*{ASNAME}\
                (:({ASNO}|peeras|{ASNAME}))*
TKN_RSNAME      (({ASNO}|peeras|{RSNAME}):)*{RSNAME}\
                (:({ASNO}|peeras|{RSNAME}))*
TKN_RTRSNAME    (({ASNO}|peeras|{RTRSNAME}):)*{RTRSNAME}\
                (:({ASNO}|peeras|{RTRSNAME}))*
TKN_PRNGNAME    (({ASNO}|peeras|{PRNGNAME}):)*{PRNGNAME}\
                (:({ASNO}|peeras|{PRNGNAME}))*
TKN_FLTRNAME    (({ASNO}|peeras|{FLTRNAME}):)*{FLTRNAME}\
                (:({ASNO}|peeras|{FLTRNAME}))*
TKN_BOOLEAN     true|false
TKN_RP_ATTR     {NAME} if defined in dictionary
TKN_WORD        {NAME}
TKN_DNS         {DNAME}("."{DNAME})+
TKN_EMAIL       {ENAME}@({DNAME}("."{DNAME})+|{IPV4})

C Changes from RFC 2280

   RFC 2280 [3] contains an earlier version of RPSL. This section
   summarizes the changes since then.  They are as follows:

  o  It is now possible to write integers as sequence of four 1-octet
     integers (e.g. 1.1.1.1) or as sequence of two 2-octet integers
     (e.g.  3561:70).  Please see Section 2.

  o  The definition of address prefix range is extended so that an
     address prefix is also an address prefix range.  Please see Section
     2.

  o  The semantics for a range operator applied to a set containing
     address prefix ranges is defined (e.g. {30.0.0.0/8^24-28}^27-30).
     Please see Section 2.

  o  All dates are now in UTC. Please see Section 2.

  o  Plus ('+') character is added to space and tab characters to split
     an attribute's value to multiple lines (i.e. by starting the
     following lines with a space, a tab or a plus ('+') character).
     Please see Section 2.

  o  The withdrawn attribute of route class is removed from the
     language.

  o  filter-set class is introduced.  Please see Section 5.4.

  o  rtr-set class is introduced.  Please see Section 5.5.

  o  peering-set class is introduced.  Please see Section 5.6.

  o  Filters can now refer to filter-set names.  Please see Section 5.4.

  o  Peerings can now refer to peering-set, rtr-set names.  Both local
     and peer routers can be specified using router expressions.  Please
     see Section 5.6.

  o  The peer attribute of the inet-rtr class can refer to peering-set,
     rtr-set names.  Please see Section 9.

  o  The syntax and semantics of union, and list types and typedef
     attribute have changed.  Please see Section 7.

  o  In the initial dictionary, the typedef attribute defining the
     community_elm, rp-attribute defining the community attribute has
     changed.  Please see Section 7.

  o  Guideliness for extending RPSL is added.  Please see Section 10.

  o  Formal grammar rules are added.  Please see Appendix B.

D Authors' Addresses

   Cengiz Alaettinoglu
   USC/Information Sciences Institute

   EMail: cengiz@isi.edu

   Curtis Villamizar
   Avici Systems

   EMail: curtis@avici.com

   Elise Gerich
   At Home Network

   EMail: epg@home.net

   David Kessens
   Qwest Communications

   EMail: David.Kessens@qwest.net

   David Meyer
   University of Oregon

   EMail: meyer@antc.uoregon.edu

   Tony Bates
   Cisco Systems, Inc.

   EMail: tbates@cisco.com

   Daniel Karrenberg
   RIPE NCC

   EMail: dfk@ripe.net

   Marten Terpstra
   c/o Bay Networks, Inc.

   EMail: marten@BayNetworks.com

Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights defined
   in the Internet Standards process must be followed, or as required to
   translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.