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)", RFC2280, 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", RFC1786, 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",
RFC1997, August 1996.
[10] Crocker, D., "Standard for ARPA Internet Text Messages", STD 11,
RFC822, August 1982.
[11] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-
Domain Routing (CIDR): an Address Assignment and Aggregation
Strategy", RFC1519, 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, RFC1034, 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", RFC2439, 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 RFC2280
RFC2280 [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 RFCEditor function is currently provided by the
Internet Society.