Network Working Group C. Alaettinoglu
Request for Comments: 2622 USC/Information Sciences Institute
Obsoletes: 2280 C. Villamizar
Category: Standards Track Avici Systems
E. Gerich
At Home Network
D. Kessens
Qwest Communications
D. Meyer
University of Oregon
T. Bates
Cisco Systems
D. Karrenberg
RIPE NCC
M. Terpstra
Bay Networks
June 1999
Routing Policy Specification Language (RPSL)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
RPSLは、ネットワークオペレータは、インターネット階層の様々なレベルでのルーティングポリシーを指定できるようにすることを可能にします。自律システム（AS）レベルで、例えば。低レベルのルータの設定がそれらから生成することができるように、同時に、ポリシーがRPSLに十分詳細に指定することができます。 RPSLは拡張可能です。新しいルーティングプロトコルや新しいプロトコル機能は、任意の時点で導入することができます。
Table of Contents
目次
1 Introduction 3
2 RPSL Names, Reserved Words, and Representation 4
3 Contact Information 7
3.1 mntner Class . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 person Class . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 role Class . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 route Class 12
5 Set Classes 13
5.1 as-set Class . . . . . . . . . . . . . . . . . . . . . . . . 14
5.2 route-set Class. . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Predefined Set Objects . . . . . . . . . . . . . . . . . . . 17
5.4 Filters and filter-set Class . . . . . . . . . . . . . . . . 17
5.5 rtr-set Class. . . . . . . . . . . . . . . . . . . . . . . . 22
5.6 Peerings and peering-set Class . . . . . . . . . . . . . . . 24
6 aut-num Class 27
6.1 import Attribute: Import Policy Specification . . . . . . . 27
6.1.1 Action Specification . . . . . . . . . . . . . . . . . . 28
6.2 export Attribute: Export Policy Specification . . . . . . . 29
6.3 Other Routing Protocols, Multi-Protocol Routing Protocols,
and Injecting Routes Between Protocols . . . . . . . . . . . . 29
6.4 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . 31
6.5 default Attribute: Default Policy Specification . . . . . . 33
6.6 Structured Policy Specification. . . . . . . . . . . . . . . 33
7 dictionary Class 37
7.1 Initial RPSL Dictionary and Example Policy Actions and
Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8 Advanced route Class 45
8.1 Specifying Aggregate Routes. . . . . . . . . . . . . . . . . 45
8.1.1Interaction with policies in aut-num class. . . . . . . . 49
8.1.2Ambiguity resolution with overlapping aggregates. . . . . 50
8.2 Specifying Static Routes . . . . . . . . . . . . . . . . . . 52
9 inet-rtr Class 52
10 Extending RPSL 54
10.1 Extensions by changing the dictionary class . . . . . . . . 54
10.2 Extensions by adding new attributes to existing classes . . 55
10.3 Extensions by adding new classes . . . . . . . . . . . . . 55
10.4 Extensions by changing the syntax of existing RPSL
attributes. . . . . . . . . . . . . . . . . . . . . . . . . . 55
11 Security Considerations 56
12 Acknowledgements 56
References 56
A Routing Registry Sites 59
B Grammar Rules 59
C Changes from RFC 2280 67
D Authors' Addresses 68
Full Copyright Statement 69
1 Introduction
1はじめに
This memo is the reference document for the Routing Policy Specification Language (RPSL). RPSL allows a network operator to be able to specify routing policies at various levels in the Internet hierarchy; for example at the Autonomous System (AS) level. At the same time, policies can be specified with sufficient detail in RPSL so that low level router configurations can be generated from them. RPSL is extensible; new routing protocols and new protocol features can be introduced at any time.
このメモは、ルーティングポリシー仕様言語（RPSL）のための参考資料です。 RPSLは、ネットワークオペレータは、インターネット階層の様々なレベルでのルーティングポリシーを指定できるようにすることを可能にします。自律システム（AS）レベルで、例えば。低レベルのルータの設定がそれらから生成することができるように、同時に、ポリシーがRPSLに十分詳細に指定することができます。 RPSLは拡張可能です。新しいルーティングプロトコルや新しいプロトコル機能は、任意の時点で導入することができます。
RPSL is a replacement for the current Internet policy specification language known as RIPE-181 [6] or RFC-1786 [7]. RIPE-81 [8] was the first language deployed in the Internet for specifying routing policies. It was later replaced by RIPE-181 [6]. Through operational use of RIPE-181 it has become apparent that certain policies cannot be specified and a need for an enhanced and more generalized language is needed. RPSL addresses RIPE-181's limitations.
RPSL [7] [6]またはRFC-1786 RIPE-181としても知られている現在のインターネットポリシー仕様言語の代替です。 RIPE-81 [8]ルーティングポリシーを指定するためにインターネットにデプロイ最初の言語でした。それは、後に[6] RIPE-181により置き換えました。 RIPE-181の動作を使用することにより、それは、特定のポリシーを指定することができないことが明らかになったと強化され、より一般的な言語の必要性が必要とされています。 RPSLは、RIPE-181の制限に対処します。
RPSL was designed so that a view of the global routing policy can be contained in a single cooperatively maintained distributed database to improve the integrity of Internet's routing. RPSL is not designed to be a router configuration language. RPSL is designed so that router configurations can be generated from the description of the policy for one autonomous system (aut-num class) combined with the description of a router (inet-rtr class), mainly providing router ID, autonomous system number of the router, interfaces and peers of the router, and combined with a global database mappings from AS sets to ASes (as-set class), and from origin ASes and route sets to route prefixes (route and route-set classes). The accurate population of the RPSL database can help contribute toward such goals as router configurations that protect against accidental (or malicious) distribution of inaccurate routing information, verification of Internet's routing, and aggregation boundaries beyond a single AS.
グローバルルーティングポリシーのビューは、インターネットのルーティングの整合性を改善するために、単一の協同的に維持され、分散データベースに含まれていることができるように、RPSLを設計しました。 RPSLは、ルータの設定言語になるように設計されていません。そのルータの設定は、ルータ（INET-RTRクラス）の記述と組み合わさ1つの自律システム（AUT-NUMクラス）のポリシーの記述から生成することができるようにRPSLは、主に、自律システム番号ルータIDを提供し、設計されていますルータ、インターフェイス及びルーターのピア、および経路プレフィックス（ルートとルートセットクラス）へのAS（AS-セットクラス）のセットとして、原点からのASとルートセットからのグローバル・データベース・マッピングと組み合わせます。 RPSLデータベースの正確な人口は、単一のASを超えた偶発（あるいは悪意の）不正確なルーティング情報の配信、インターネットのルーティングの検証、および集約境界から保護ルータの設定などの目標に向かって貢献することができます。
RPSL is object oriented; that is, objects contain pieces of policy and administrative information. These objects are registered in the Internet Routing Registry (IRR) by the authorized organizations. The registration process is beyond the scope of this document. Please refer to [1, 17, 4] for more details on the IRR.
RPSLは、オブジェクト指向です。つまり、オブジェクトは、政策や行政の情報が含まれています。これらのオブジェクトは、認可機関によってインターネットルーティングレジストリ（IRR）に登録されています。登録プロセスは、このドキュメントの範囲を超えています。 IRRの詳細については[1、17、4]を参照して下さい。
In the following sections, we present the classes that are used to define various policy and administrative objects. The "mntner" class defines entities authorized to add, delete and modify a set of objects. The "person" and "role" classes describes technical and administrative contact personnel. Autonomous systems (ASes) are specified using the "aut-num" class. Routes are specified using the
次のセクションでは、我々は様々な政策や管理オブジェクトを定義するために使用されるクラスを提示します。 「のmntner」クラスは、追加、削除、およびオブジェクトのセットを変更する権限エンティティを定義します。 「人」と「役割」のクラスは、技術および管理接点人材を説明します。自律システム（ASの）は、「AUT-NUM」クラスを使用して指定されています。ルートは、使用して指定されています
"route" class. Sets of objects can be defined using the "as-set", "route-set", "filter-set", "peering-set", and "rtr-set" classes. The "dictionary" class provides the extensibility to the language. The "inet-rtr" class is used to specify routers. Many of these classes were originally defined in earlier documents [6, 13, 16, 12, 5] and have all been enhanced.
「ルート」クラス。オブジェクトのセットを用いて定義することができる「としてセット」、「ルート・セット」、「フィルタは設定」、「ピアリング・セット」、および「RTRセット」クラス。 「辞書」のクラスは、言語への拡張性を提供します。 「INET-RTR」クラスは、ルータを指定するために使用されます。これらのクラスの多くは、もともと以前の文書で定義された[6、13、16、12、5]およびすべての拡張されています。
This document is self-contained. However, the reader is encouraged to read RIPE-181 [7] and the associated documents [13, 16, 12, 5] as they provide significant background as to the motivation and underlying principles behind RIPE-181 and consequently, RPSL. For a tutorial on RPSL, the reader should read the RPSL applications document [4].
この文書では、自己完結型です。しかし、読者はRIPE-181を読み取ることが奨励されている[7]及び関連文書[13、16、12、5]それらはRIPE-181、その結果、RPSLの背後にある動機と下層の原理に関して有意なバックグラウンドを提供するように。 RPSLのチュートリアルについては、読者はRPSLアプリケーション文書を読む必要があり[4]。
2 RPSL Names, Reserved Words, and Representation
2 RPSL名、予約語、および表現
Each class has a set of attributes which store a piece of information about the objects of the class. Attributes can be mandatory or optional: A mandatory attribute has to be defined for all objects of the class; optional attributes can be skipped. Attributes can also be single or multiple valued. Each object is uniquely identified by a set of attributes, referred to as the class "key".
各クラスは、クラスのオブジェクトに関する情報の一部を格納する属性のセットを持っています。属性は、必須またはオプションとすることができます：必須の属性は、クラスのすべてのオブジェクトのために定義する必要があります。オプションの属性を省略することができます。属性はまた、単一の値または複数のことができます。各オブジェクトは、一意のクラス「キー」と呼ばれる属性のセットによって識別されます。
The value of an attribute has a type. The following types are most widely used. Note that RPSL is case insensitive and only the characters from the ASCII character set can be used.
属性の値は種類があります。以下のタイプが最も広く使用されています。そのRPSLは大文字と小文字が区別され、ASCII文字セットの文字のみを使用できます。
<object-name> Many objects in RPSL have a name. An <object-name> is made up of letters, digits, the character underscore "_", and the character hyphen "-"; the first character of a name must be a letter, and the last character of a name must be a letter or a digit. The following words are reserved by RPSL, and they can not be used as names:
<オブジェクト名> RPSLの多くのオブジェクトが名前を持っています。 <オブジェクト名>「_」文字、数字、文字、アンダースコアで構成され、文字、ハイフン「 - 」。名前の最初の文字は英字でなければならず、名前の最後の文字は、英字または数字でなければなりません。次の単語は、RPSLで予約されている、と彼らは名前として使用することはできません。
any as-any rs-any peeras
and or not
atomic from to at action accept announce except refine
networks into inbound outbound
Names starting with certain prefixes are reserved for certain object types. Names starting with "as-" are reserved for as set names. Names starting with "rs-" are reserved for route set names. Names starting with "rtrs-" are reserved for router set names. Names starting with "fltr-" are reserved for filter set names. Names starting with "prng-" are reserved for peering set names.
特定の接頭辞で始まる名前は、特定のオブジェクトタイプのために予約されています。セット名のために予約されている「AS-」で始まる名前。 「RS-」で始まる名前は、ルート・セット名のために予約されています。 「rtrs-」で始まる名前は、ルータ・セット名のために予約されています。 「fltr-」で始まる名前は、フィルタ・セット名のために予約されています。 「prng-」で始まる名前は、セットの名前をピアリング用に予約されています。
<as-number> An AS number x is represented as the string "ASx". That is, the AS 226 is represented as AS226.
<ように番号> AS番号Xは、文字列「ASX」として表されます。つまり、AS 226はAS226として表現されます。
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
<IPv4のアドレス> IPv4アドレスは、文字ドットで区切られた0から255の範囲の4つの整数のシーケンスとして表されます「」。例えば、128.9.128.5は有効なIPv4アドレスを表します。このドキュメントの残りの部分では、我々は、IPアドレスとしてIPv4アドレスを参照してもよいです。
<address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers.
<アドレスプレフィックス>アドレスプレフィックスが0から32の範囲は次の整数に続くキャラクタ、スラッシュ「/」に続いてIPv4アドレスとして表される有効なアドレスプレフィックスである：128.9.128.5/32、128.9.0.0 / 16、0.0.0.0/0。そして、次のアドレスのプレフィックスが無効です：0/0、128.9 / 0から16または128.9の4つの整数を含む文字列ではありません。
<address-prefix-range> An address prefix range is an address prefix followed by an optional range operator. The range operators are:
<アドレスプレフィックス範囲>アドレスプレフィックスの範囲は、オプションの範囲演算子に続くアドレスプレフィックスです。範囲演算子は以下のとおりです。
^- is the exclusive more specifics operator; it stands for the more specifics of the address prefix excluding the address prefix itself. For example, 128.9.0.0/16^- contains all the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16.
^ - 排他的な、より具体的演算子です。それは、アドレスプレフィックス自体を除いたアドレスプレフィックスのより詳細を表します。例えば、128.9.0.0/16^- 128.9.0.0/16は128.9.0.0/16を除くすべてのより多くの詳細を含みます。
^+ is the inclusive more specifics operator; it stands for the more specifics of the address prefix including the address prefix itself. For example, 5.0.0.0/8^+ contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8.
^ +を含め、より具体的演算子です。それは、アドレスプレフィックス自体を含むアドレスプレフィックスのより詳細を表します。例えば、5.0.0.0/8^+ 5.0.0.0/8 5.0.0.0/8を含め、すべてのより多くの詳細を含みます。
^n where n is an integer, stands for all the length n specifics of the address prefix. For example, 30.0.0.0/8^16 contains all the more specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16.
^ nは整数であり、アドレスプレフィックスの全長さNの仕様を表します。例えば、30.0.0.0/8^16は、長さ16など30.9.0.0/16である30.0.0.0/8のすべてより多くの詳細を含みます。
^n-m where n and m are integers, stands for all the length n to length m specifics of the address prefix. For example, 30.0.0.0/8^24-32 contains all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28.
^ nおよびmは整数であるN-Mは、アドレスプレフィックスの長さmの仕様にすべての長さnを表します。例えば、30.0.0.0/8^24-32 32例えば30.9.9.96/28ように長さが24である30.0.0.0/8のすべてより多くの詳細を含みます。
Range operators can also be applied to address prefix sets. In this case, they distribute over the members of the set. For example, for a route-set (defined later) rs-foo, rs-foo^+ contains all the inclusive more specifics of all the prefixes in rs-foo.
範囲演算子はまた、接頭辞セットに対処するために適用することができます。この場合、彼らはセットのメンバーを配布します。例えば、ルートセットに対してRS-FOO、RS-fooが^ + RS、fooの中のすべてのプレフィックスのすべての包括的なより詳細を含む（後に定義します）。
It is an error to follow a range operator with another one (e.g. 30.0.0.0/8^24-28^+ is an error). However, a range operator can be applied to an address prefix set that has address prefix ranges in it (e.g. {30.0.0.0/8^24-28}^27-30 is not an error). In this case, the outer operator ^n-m distributes over the inner operator ^k-l and becomes the operator ^max(n,k)-m if m is greater than or equal to max(n,k), or otherwise, the prefix is deleted from the set. Note that the operator ^n is equivalent to ^n-n; prefix/l^+ is equivalent to prefix/l^l-32; prefix/l^- is equivalent to prefix/l^(l+1)-32; {prefix/l^n-m}^+ is equivalent to {prefix/l^n-32}; and {prefix/l^n-m}^- is equivalent to {prefix/l^(n+1)-32}. For example,
それは別のものと範囲演算子を追従するエラー（例えば30.0.0.0/8^24-28^+はエラーです）。しかし、範囲演算子は、それのアドレスプレフィックスの範囲（例えば、{30.0.0.0/8^24-28}^27-30がエラーではない）を有しているアドレスプレフィックスの組に適用することができます。この場合、外側のオペレータ^ NMはKL内オペレータ^上に分配し、オペレータ^ maxの（N、K）となる-m mは以上MAX（N、K）に等しいか、またはそうでなければ、接頭辞である場合セットから削除。オペレータ^ nは^ N-Nと等価であることに留意されたいです。プレフィックス/ L ^ +接頭辞/ L ^ L-32と等価です。プレフィックス/ L ^ - 接頭辞/ L ^（L + 1）-32に相当します。 {接頭辞/ L ^ N-M} ^ + {接頭辞/ L ^ N-32}と等価です。そして{接頭辞/ L ^ N-mは} ^ - {接頭辞/ L ^（N + 1）-32}と等価です。例えば、
{128.9.0.0/16^+}^- == {128.9.0.0/16^-}
{128.9.0.0/16^-}^+ == {128.9.0.0/16^-}
{128.9.0.0/16^17}^24 == {128.9.0.0/16^24}
{128.9.0.0/16^20-24}^26-28 == {128.9.0.0/16^26-28}
{128.9.0.0/16^20-24}^22-28 == {128.9.0.0/16^22-28}
{128.9.0.0/16^20-24}^18-28 == {128.9.0.0/16^20-28}
{128.9.0.0/16^20-24}^18-22 == {128.9.0.0/16^20-22}
{128.9.0.0/16^20-24}^18-19 == {}
<date> A date is represented as an eight digit integer of the form YYYYMMDD where YYYY represents the year, MM represents the month of the year (01 through 12), and DD represents the day of the month (01 through 31). All dates are in UTC unless otherwise specified. For example, June 24, 1996 is represented as 19960624.
<日付>日付はYYYY年を表すフォームYYYYMMDDの8桁の整数として表され、MMは、年（01から12）の月を表し、そしてDDは月の日（01〜31）を表します。特に指定のない限り、すべての日付はUTCです。例えば、1996年6月24日は、19960624のように表されます。
<email-address>is as described in RFC-822 [10].
<電子メールアドレス> RFC-822に記載されているようである[10]。
<dns-name>is as described in RFC-1034 [17].
RFC-1034に記載されているように、<DNS名>である[17]。
<nic-handle> is a uniquely assigned identifier word used by routing, address allocation, and other registries to unambiguously refer to contact information. Person and role classes map NIC handles to actual person names, and contact information.
<NICハンドル>は明確連絡先情報を参照するために、ルーティング、アドレス割り当て、および他のレジストリによって使用される一意に割り当てられた識別子ワードです。人と役割のクラスは、NICは、実際の人物名にハンドルマップ、および連絡先情報。
<free-form>is a sequence of ASCII characters.
<自由形式>はASCII文字のシーケンスです。
<X-name> is a name of an object of type X. That is <mntner-name> is a name of a mntner object.
<X-名> <のmntner-名>のmntnerオブジェクトの名前であるタイプXのオブジェクトの名前です。
<registry-name> is a name of an IRR registry. The routing registries are listed in Appendix A.
<レジストリ名>は、IRRレジストリの名前です。ルーティングレジストリは、付録Aに記載されています
A value of an attribute may also be a list of one of these types. A list is represented by separating the list members by commas ",". For example, "AS1, AS2, AS3, AS4" is a list of AS numbers. Note that being list valued and being multiple valued are orthogonal. A multiple valued attribute has more than one value, each of which may or may not be a list. On the other hand a single valued attribute may have a list value.
属性の値は、これらのタイプのいずれかのリストであってもよいです。リストは、「」カンマでリストのメンバーを分離することによって表されます。たとえば、 "AS1、AS2、AS3、AS4は、" AS番号のリストです。リストが評価され、評価対象の複数が直交していることに注意してください。複数値の属性は、またはリストであってもなくてもよいそれぞれが複数の値を有します。一方、単一の値属性は、リスト値を有することができます。
An RPSL object is textually represented as a list of attribute-value 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.
RPSLオブジェクトはテキストで、属性と値のペアのリストとして表現されます。それぞれの属性と値のペアは、別の行に書かれています。 「：」属性名は文字が続く、列0から始まり、属性の値が続きます。オブジェクトのクラスと同じ名前を持つ属性は、最初に指定する必要があります。空白行が検出されたときに、オブジェクトの表現は終了します。属性の値は、スペース、タブまたはプラス（「+」）継続行の最初の文字として文字を持つことによって、複数行に分割することができます。行継続のための文字「+」は属性値が空白行を含めることができます。より多くのスペースは、必要に応じて可読性を高めるために、継続文字の後に使用することができます。属性と値のペアの順序は重要です。
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.
整数は、（1）Cプログラミング言語表記（例えば1、12345）を使用して指定することができます。 （2）文字のドットで区切られた（0から255の範囲の）4つの1オクテットの整数のシーケンスを「」 （例えば1.1.1.1、255.255.0.0）、この場合には4オクテットの整数が最下位ために最も重要で、これらの1オクテットの整数を連結することによって形成されます。 （3）文字のコロンで区切られた（0から65535の範囲の）2つの2オクテットの整数のシーケンス「：」（例えば、3561：70、3582：10）、この場合には4オクテットの整数を連結することによって形成されています最下位ために最も重要でこれらの2オクテットの整数。
3 Contact Information
3連絡先情報
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.
mntner、人と役割のクラスは、admin-C、ハイテクC、MNT-によっては、変更、およびすべてのクラスのソース属性は、連絡先情報を記述する。 mntnerクラスは、他のオブジェクトを作成、削除、および更新するために必要なauthenticaiton情報を指定します。これらのクラスは、ルーティングポリシーを指定しないと、各レジストリは、それらに異なるまたは追加の要件を有することができます。ここでは、RIPEデータベースの実装[16]である完全性についての共通分母を提示します。これらのクラスと属性の最新の仕様のためにあなたのルーティングレジストリを参照してください。 「ルーティングポリシーシステム・セキュリティ」ドキュメント[20]は、より詳細にauthenticaitonと承認モデルについて説明します。
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 attributes of the mntner class are shown in Figure 1. The mntner class was first described in [13].
mntnerクラスはRPSLオブジェクトを作成、削除、および更新するために必要な情報をauthenticaiton指定します。プロバイダは、彼/彼女はRPSLオブジェクトを作成する前に、最初のmntnerオブジェクトを作成する必要があります。 mntnerクラスの属性のmntnerクラスが最初の[13]で説明した図1に示されています。
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:
mntner属性は必須であり、クラスキーです。その値は、RPSL名です。認証属性は、このメンテナからの更新要求を識別し、認証するために使用されるスキームを指定します。構文は次のとおりです。
auth: <scheme-id> <auth-info>
AUTH：<スキーム-ID>の<auth-インフォメーション>
E.g. auth: NONE
例えば。 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
属性値のタイプのmntner <オブジェクト名>必須、単一値、クラスキーDESCR <自由形式>必須、テキストで説明を参照してくださいAUTHシングルは値必須、複数値<電子メールアドレス>必須、マルチUPD-へ大切MNT-NFY <電子メールアドレス>オプションの多値技術-C <NICハンドル>必須、複数の値を持つ管理者-C <NICハンドル>オプションの多値発言<フリーフォーム>オプション、マルチ通知大切<電子メールアドレス>オプションの多値MNT・バイ<のmntner-name>は必須、複数値は、<電子メールアドレス> <日時>必須、多値ソース<レジストリ名>必須、単一変更のリスト-valued
Figure 1: mntner Class Attributes
図1：のmntnerクラスの属性
auth: CRYPT-PW dhjsdfhruewf auth: MAIL-FROM .*@ripe\.net
AUTH：CRYPT-PW dhjsdfhruewf AUTH：MAIL-FROM * @熟し\ .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.
<スキーム-ID>の現在定義されている：NONE、-FROM MAIL PGP-KEYとCRYPT-PW。 <auth-情報>特定の方式に必要な追加情報です：MAIL-FROMの場合には、それが有効な電子メールアドレスに一致する正規表現です。 CRYPT-PWの場合には、それはUNIX crypt形式でパスワードです。およびPGP-KEYの場合には、ユーザのPGP公開鍵を含む鍵certif物[22]へのポインタです。複数の認証属性が指定されている場合、それらのいずれかを満たす更新要求がメンテナからのものであると認証されています。
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.
UPD-する属性は、電子メールアドレスです。このメンテナによって保持対象物の不正な更新の試みでは、電子メールメッセージは、このアドレスに送信されます。 MNT-NFY属性は、電子メールアドレスです。この保守によって維持オブジェクトは、追加、変更または削除されるたびに、通知メッセージは、このメールアドレスに転送されます。
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:
DESCR属性は、オブジェクトの短い、自由形式のテキスト記述です。ハイテクCの属性は、技術的な接触NICハンドルです。これは、このような設定ミスなどの技術的な問題のために連絡する人です。管理者-Cの属性は、管理者の連絡先NICハンドルです。発言属性は、フリーテキストの説明や明確化です。通知属性は、このオブジェクトへの変更の通知の送信先のメールアドレスです。 MNT-によって属性がのmntnerオブジェクト名のリストです。このオブジェクトへの変更の認可は、参照メンテナオブジェクトのいずれかによって支配されています。最後に、このオブジェクトを変更し、この変更が行われた時に変更された属性のドキュメント。その構文は次の形式があります。
changed: <email-address> <YYYYMMDD>
変更：<電子メールアドレス> <YYYYMMDD>
E.g. changed: johndoe@terabit-labs.nn 19900401
例えば。変更：johndoe@terabit-labs.nn 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.
<電子メールアドレス>は、最後の変更を行った人物を特定します。 <YYYYMMDD>変更の日付です。ソース属性は、オブジェクトが登録されているレジストリを指定します。図2は、例示のmntnerオブジェクトを示しています。例では、UNIX crypt形式のパスワード認証が使用されています。
mntner: RIPE-NCC-MNT descr: RIPE-NCC Maintainer admin-c: DK58 tech-c: OPS4-RIPE upd-to: ops@ripe.net mnt-nfy: ops-fyi@ripe.net auth: CRYPT-PW lz1A7/JnfkTtI mnt-by: RIPE-NCC-MNT changed: ripe-dbm@ripe.net 19970820 source: RIPE
mntner：RIPE-NCC-MNTのDESCR：RIPE-NCCメンテナ管理者-C：DK58ハイテク-C：OPS4-RIPE UPD-へ：ops@ripe.net MNT-NFY：ops-fyi@ripe.net AUTH：CRYPT-PW lz1A7 / JnfkTtI MNTバイ：RIPE-NCC-MNT変更：ripe-dbm@ripe.net 19970820ソース：RIPEを
Figure 2: An example mntner object.
図2の例では、オブジェクトのmntner。
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.
DESCR、ハイテクC、管理者-C、発言、通知、MNT-によっては、変更およびソースの属性は、すべてのRPSLクラスの属性です。その構文、意味論、および必須、オプションで、複数の値を持つ、または単一値のステータスは、すべてのRPSLクラスのために同じです。これに対する唯一の例外は、AUT-NUMクラスに必須である管理者-Cの属性です。私たちは、さらに他のセクションでそれらを議論していません。
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].
Personクラスは、ユーザーに関する情報を記述するために使用されます。それはルーティングポリシーについては説明しませんが、多くのポリシーオブジェクトが人物オブジェクトへの参照を作成するので、我々はまだここに簡単にそれを記述します。人クラスは、最初の[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:
Personクラスの属性は、人物属性は、人のフルネームである。図3に示されています。電話とファックス無属性の構文は次のとおりです。
phone: +<country-code> <city> <subscriber> [ext. <extension>]
電話：+ <国コード> <都市> <加入者> [EXT。 <拡張子>]
E.g.: phone: +31 20 12334676
例えば：電話：+31 20 12334676
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
値のタイプの人を属性<自由形式>必須、単一値のNIC-HDL <NICハンドル>必須、単一値、クラスキーアドレス<自由形式>必須、複数の値を持つ携帯電話は、マルチ、必須テキストで説明を参照してください。大切ファックス-noが電話オプション、複数の値を持つ電子メール<メールアドレス>と同じ必須多値ません
Figure 3: person Class Attributes
図3：Personクラスの属性
phone: +44 123 987654 ext. 4711
電話：+44 123 987654内線。 4711
Figure 4 shows an example person object.
図4は、例えば人物オブジェクトを示しています。
person: Daniel Karrenberg address: RIPE Network Coordination Centre (NCC) address: Singel 258 address: NL-1016 AB Amsterdam address: Netherlands phone: +31 20 535 4444 fax-no: +31 20 535 4445 e-mail: Daniel.Karrenberg@ripe.net nic-hdl: DK58 changed: Daniel.Karrenberg@ripe.net 19970616 source: RIPE
人：ダニエルKarrenbergアドレス：RIPEネットワークコーディネーションセンター（NCC）住所：シンゲル258住所：NL-1016 ABアムステルダムアドレス：オランダ電話：+31 20 535 4444ファックス番号：+31 20 535 4445 Eメール：Daniel.Karrenberg @ ripe.net NIC-HDL：DK58が変更：Daniel.Karrenberg@ripe.net 19970616ソース：RIPE
Figure 4: An example person object.
図4：例人物オブジェクト。
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.
役割のクラスは、personオブジェクトに似ています。しかし、代わりに人間を記述するのではなく、一つ以上の人間によって実行される役割について説明します。例としては、ロールオブジェクトが役割を行うことが多い人は変更することができるので、特に有用であるヘルプデスク、ネットワーク監視センター、システム管理者、等を含む、但し役割自体が残ります。
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.
役割クラスの属性は、人と役割のクラスのNIC-HDLの属性が同じ名前空間を共有し、図5に示されています。ロールオブジェクトのトラブル属性は、問題は、このロールオブジェクトを参照する任意のオブジェクトで発生したときに使用される追加の連絡先情報が含まれていてもよいです。図6は、例示的役割オブジェクトを示しています。
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
値タイプの役割を属性<自由形式>必須、単一値のNIC-HDL <NICハンドル>必須、単一値、クラスキートラブル<自由形式>オプションの多値アドレス<フリーフォーム>必須、マルチ電話必須テキスト必須多値ファックス・ノー電話オプション、複数の値を持つ電子メール<メールアドレス>と同じで説明を参照してください多値-valued
Figure 5: role Class Attributes
図5：役割クラス属性
role: RIPE NCC Operations trouble: address: Singel 258 address: 1016 AB Amsterdam address: The Netherlands phone: +31 20 535 4444 fax-no: +31 20 545 4445 e-mail: ops@ripe.net admin-c: CO19-RIPE tech-c: RW488-RIPE tech-c: JLSD1-RIPE nic-hdl: OPS4-RIPE notify: ops@ripe.net changed: roderik@ripe.net 19970926 source: RIPE
役割：RIPE NCCオペレーションのトラブル：住所：シンゲル258住所：1016 ABアムステルダムアドレス：オランダ電話：+31 20 535 4444ファックス番号：+31 20 545 4445電子メール：ops@ripe.net管理者-C：CO19 -RIPEハイテクC：RW488-RIPE技術-C：JLSD1-RIPE NIC-HDL：OPS4-RIPEが通知：ops@ripe.netが変更された：roderik@ripe.net 19970926ソース：RIPE
Figure 6: An example role object.
図6：例のロールオブジェクト。
4 route Class
4ルートクラス
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.
ASによって発信（また、ドメイン間ルートと呼ぶ）は、各インターアクセス経路は、ルートオブジェクトを使用して指定されます。ルートクラスの属性は図7に示されている経路属性は、ルートのアドレスプレフィックスとorigin属性は、システムのルーティングインターアクセスへのルートを発信ASのAS番号です。ルートと起源属性ペアは、クラスキーです。
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).
図8は、（私たちは、このような簡潔にするために管理者-C、ハイテク-Cと接触属性が含まれていません）4つのルートオブジェクトの例を示します。最後の2つのルートオブジェクトが同じアドレスプレフィックス、すなわち128.8.0.0/16を持っていることに注意してください。しかし、彼らは別のASによって発信されるので、異なるルートオブジェクトである（即ち、それらは異なるキーを有します）。
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
値のタイプルート<アドレスプレフィックス>必須、単一値、クラスキーの起源<として-数>必須、単一値、クラスキーメンバーの<ルート・セット名>のリストの任意の属性、複数の値を持つセクションを参照してください5第8オプション、多値成分は8オプション、単一値輸出コンプ、セクション8は、オプションセクション8オプション、単一値AGGR-BNDRYセクション8オプション、単一値AGGR-MTD参照セクション、単を見る注入-valued孔は多値、セクション8は、オプション参照します
Figure 7: route Class Attributes
図7：ルートクラス属性
route: 128.9.0.0/16 origin: AS226
ルート：128.9.0.0/16原産地：AS226
route: 128.99.0.0/16 origin: AS226
ルート：128.99.0.0/16原産地：AS226
route: 128.8.0.0/16 origin: AS1
ルート：128.8.0.0/16原産地：AS1
route: 128.8.0.0/16 origin: AS2
ルート：128.8.0.0/16原産地：AS2
Figure 8: Route Objects
図8：ルートオブジェクト
5 Set Classes
5セットクラス
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.
ポリシーを指定するには、オブジェクトのセットを定義しておくと便利です。この目的のために、我々はそのままセット、ルートセット、RTR-セット、フィルタセット、およびピアリング・セットのクラスを定義します。これらのクラスは、名前付きセットを定義します。これらのセットのメンバーが直接セットでそれらをリストすることによって名、または両方の方法の組み合わせの定義、または間接的にメンバーオブジェクトが集合を参照有することのいずれかで指定することができます。
A set's name is an rpsl word with the following restrictions: All as-set names start with prefix "as-". All route-set names start with prefix "rs-". All rtr-set names start with prefix "rtrs-". All filter-set names start with prefix "fltr-". All peering-set names start with prefix "prng-". For example, as-foo is a valid as-set name.
名前が接頭辞「れたまま」で始まるとセットのすべて：セットの名前は、以下の制限付きRPSLワードです。すべてのルートセット名は、接頭辞「RS-」で始まります。すべてのRTR-セット名は、接頭辞「rtrs-」で始まります。すべてのフィルタ・セット名は、接頭辞「fltr-」で始まります。すべてのピアリング・セット名は、接頭辞「prng-」で始まります。例えば、として-fooが有効なように、セットの名前です。
Set names can also be hierarchical. A hierarchical set name is a sequence of set names and AS numbers separated by colons ":". At least one component of such a name must be an actual set name (i.e. start with one of the prefixes above). All the set name components of an hierarchical name has to be of the same type. For example, the following names are valid: AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2, RS-EXCEPTIONS:RS-BOGUS.
SET NAMESは、階層することができます。階層的なセット名は、コロンで区切られたセット名およびAS番号のシーケンスです「：」。そのような名前の少なくとも一つの成分（すなわち、上記プレフィックスのいずれかで始まる）は、実際のセット名でなければなりません。階層名の全セット名のコンポーネントは、同じタイプである必要があります。たとえば、次の名前が有効です：AS1：AS-顧客、AS1：RS-EXPORT：AS2、RS-例外：RS-BOGUS。
The purpose of an hierarchical set name is to partition the set name space so that the maintainers of the set X1 controls the whole set name space underneath, i.e. X1:...:Xn-1. Thus, a set object with name X1:...:Xn-1:Xn can only be created by the maintainer of the object with name X1:...:Xn-1. That is, only the maintainer of AS1 can create a set with name AS1:AS-FOO; and only the maintainer of AS1:AS-FOO can create a set with name AS1:AS-FOO:AS-BAR. Please see RPS Security Document [20] for details.
階層的なセット名の目的セットX1の保守は、下にセット全体の名前空間を制御するように設定された名前空間を分割することであり、すなわち、X1：...：XN-1。このように、名前X1とセットオブジェクト：...：XN-1：Xnのは名前だけのX1を持つオブジェクトのメンテナーによって作成することができます：...：XN-1。それは唯一のAS1のメンテナが名前AS1とのセットを作成することができ、次のとおりです。AS-FOO;そして、AS1の唯一のメンテナ：AS-FOOは、名前AS1とのセットを作成することができます：AS-FOO：AS-BAR。詳細については、RPSセキュリティドキュメント[20]を参照してください。
The attributes of the as-set class are shown in Figure 9. The as-set attribute defines the name of the set. It is an RPSL name that starts with "as-". The members attribute lists the members of the set. The members attribute is a list of AS numbers, or other as-set names.
セットクラスの属性は、以下のように設定された属性図9.に示されているセットの名前を定義します。それは「れたまま」で始まるRPSL名です。メンバーはリストにセットのメンバーを属性。メンバーは、属性として番号、または他のAS-セット名のリストです。
Attribute Value Type as-set <object-name> mandatory, single-valued, class key members list of <as-numbers> or optional, multi-valued <as-set-names> mbrs-by-ref list of <mntner-names> optional, multi-valued
設定として、値型属性<オブジェクト名>の必須、単一値、クラスキーメンバーリストまたはオプションの多値<セットとして-名>はMBRバイ参照のリスト<<-番号など> mntner-名>オプションの多値
Figure 9: as-set Class Attributes
図9：設定されたクラスの属性
Figure 10 presents two as-set objects. The set as-foo contains two ASes, namely AS1 and AS2. The set as-bar contains the members of the set as-foo and AS3, that is it contains AS1, AS2, AS3. The set as-empty contains no members.
図10は、2つのように、セットのオブジェクトを提供します。 AS-fooのセットが2つのAS、すなわち、AS1とAS2が含まれています。バーセットは、それはそれはAS1、AS2、AS3が含まれている、として-fooとAS3セットのメンバーが含まれています。空のセットにはメンバーが含まれていません。
as-set: as-foo as-set: as-bar as-set: as-empty members: AS1, AS2 members: AS3, as-foo
AS-セットとしてバー：：AS-FOOとしてセット：セットのように空のメンバー：AS1、AS2のメンバー：AS3、として、FOO
Figure 10: as-set objects.
図10：としてセットオブジェクト。
The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. If this attribute is used, the AS set also includes ASes whose aut-num objects are registered by one of these maintainers and whose member-of attribute refers to the name of this AS set. If the value of a mbrs-by-ref attribute is ANY, any AS object referring to the AS set is a member of the set. If the mbrs-by-ref attribute is missing, only the ASes listed in the members attribute are members of the set.
MBRをバイrefの属性は、メンテナ名またはキーワードANYのリストです。この属性が使用される場合、ASも含むセットそのAUT-NUMオブジェクトこれら保守のいずれかによって登録され、その属性メンバーのASセット本の名前を指すのAS。 MBRをバイrefの属性の値がANYの場合、ASセットを参照するオブジェクトASいずれかがセットのメンバーです。 MBRをバイrefの属性が存在しない場合は、会員のみに記載されているのASは、属性セットのメンバーです。
as-set: as-foo members: AS1, AS2 mbrs-by-ref: MNTR-ME
セットとして：AS-FOOメンバー：AS1、AS2とのMBRバイREF：MNTR-ME
aut-num: AS3 aut-num: AS4 member-of: as-foo member-of: as-foo mnt-by: MNTR-ME mnt-by: MNTR-OTHER
AUT-NUM：AS3 AUT-NUM：AS4部材-の：AS-FOOメンバーの：AS-FOO MNTバイ：MNTR-MEは、MNT-によって：MNTR-OTHER
Figure 11: as-set objects.
図11のようなセットのオブジェクト。
Figure 11 presents an example as-set object that uses the mbrs-by-ref attribute. The set as-foo contains AS1, AS2 and AS3. AS4 is not a member of the set as-foo even though the aut-num object references as-foo. This is because MNTR-OTHER is not listed in the as-foo's mbrs-by-ref attribute.
図11は、AS-セットのMBRバイREF属性を使用するオブジェクトの例を示します。 AS-fooのセットは、AS1、AS2とAS3が含まれています。 AS4もAS-FOO AUT-NUMオブジェクト参照ものとして、FOOセットのメンバーではありません。 MNTR-、他方はAS-fooというのはMBR-によって-REF属性にリストされていないためです。
The attributes of the route-set class are shown in Figure 12. 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.
ルートセットクラスの属性は、ルート属性セットは、セットの名前を定義し、図12に示されています。これは、「RS-」で始まるRPSL名です。メンバーはリストにセットのメンバーを属性。メンバーは、アドレスプレフィックスまたは他のルートセット名のリストである属性。 、ルートセットのクラスは、ルートプレフィックスのではなく、RPSLルートオブジェクトの集合であることに留意されたいです。
Attribute Value Type route-set <object-name> mandatory, single-valued, class key members list of <address-prefix-range> or optional, multi-valued <route-set-name> or <route-set-name><range-operator> mbrs-by-ref list of <mntner-names> optional, multi-valued
属性値のタイプルート・セット<オブジェクト名> <アドレスプレフィックス範囲>またはオプションの多値<ルート・セット名>または<ルート・セット名>の必須、単一値、クラスキーメンバーリスト<のmntner-名>の<範囲オペレータ>のMBRバイREFリストオプション、多値
Figure 12: route-set Class Attributes
図12：ルート設定クラスの属性
Figure 13 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/24. The set rs-bar contains the members of the set rs-foo and the address prefix 128.7.0.0/16.
図13は、いくつかの例示的ルートセットオブジェクトを提示します。セットrs-fooが2つのアドレスのプレフィックス、すなわち128.9.0.0/16と128.9.0.0/24が含まれています。セットrs-バーがセットrs-fooとアドレスプレフィックス128.7.0.0/16のメンバーが含まれています。
An address prefix or a route-set name in a members attribute can be optionally followed by a range operator. For example, the following set:
メンバー属性のアドレスプレフィックスまたはルートセット名は、任意の範囲のオペレータが続くことができます。たとえば、次のように設定します。
route-set: rs-foo members: 128.9.0.0/16, 128.9.0.0/24
ルート設定：RS-fooのメンバー：128.9.0.0/16、128.9.0.0/24
route-set: rs-bar members: 128.7.0.0/16, rs-foo
ルート設定：RS-バー部材：128.7.0.0/16、RS-FOO
Figure 13: route-set Objects
図13：ルートセットオブジェクト
route-set: rs-bar members: 5.0.0.0/8^+, 30.0.0.0/8^24-32, rs-foo^+
ルート設定：RS-バー部材：5.0.0.0/8^+、30.0.0.0/8^24-32、RS-FOO ^ +
contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28, and all the more specifics of address prefixes in route set rs-foo.
5.0.0.0/8、例えば30.9.9.96/28として32を長さ24である30.0.0.0/8のすべてより詳細含む5.0.0.0/8の全てより詳細を含む、アドレスの全てより具体的ルートセットrs-fooの中に接頭辞。
The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. If this attribute is used, the route set also includes address prefixes whose route objects are registered by one of these maintainers and whose member-of attribute refers to the name of this route set. If the value of a mbrs-by-ref attribute is ANY, any route object referring to the route set name is a member. If the mbrs-by-ref attribute is missing, only the address prefixes listed in the members attribute are members of the set.
MBRをバイrefの属性は、メンテナ名またはキーワードANYのリストです。この属性が使用される場合、ルートセットはまた、そのルートオブジェクトこれら保守のいずれかによって登録され、その属性メンバーのこのルートセットの名前を指すアドレスプレフィックスを含みます。 MBRをバイrefの属性の値がANYの場合、ルートセット名を参照する任意の経路オブジェクトがメンバーです。 MBRをバイrefの属性が存在しない場合は、会員のみに記載されているアドレス接頭語が属性セットのメンバーです。
route-set: rs-foo mbrs-by-ref: MNTR-ME, MNTR-YOU
ルート設定：RS-fooというのMBRバイ参照：MNTR-ME、MNTR-YOUは、
route-set: rs-bar members: 128.7.0.0/16 mbrs-by-ref: MNTR-YOU
ルート設定：RS-バー部材：128.7.0.0/16のMBRバイ参照：MNTR-YOU
route: 128.9.0.0/16 origin: AS1 member-of: rs-foo mnt-by: MNTR-ME
ルート：128.9.0.0/16起源：AS1メンバーのRS-FOO MNTバイ：MNTR ME-
route: 128.8.0.0/16 origin: AS2 member-of: rs-foo, rs-bar mnt-by: MNTR-YOU
ルート：128.8.0.0/16原産地：AS2メンバーの：RS-FOO、RS-バーMNT-によって：MNTR-YOU
Figure 14: route-set objects.
図14：ルートセットオブジェクト。
Figure 14 presents example route-set objects that use the mbrs-by-ref attribute. The set rs-foo contains two address prefixes, namely 128.8.0.0/16 and 128.9.0.0/16 since the route objects for 128.8.0.0/16 and 128.9.0.0/16 refer to the set name rs-foo in their member-of attribute. The set rs-bar contains the address prefixes 128.7.0.0/16 and 128.8.0.0/16. The route 128.7.0.0/16 is explicitly listed in the members attribute of rs-bar, and the route object for 128.8.0.0/16 refer to the set name rs-bar in its member-of attribute.
図14は、のMBRバイREF属性を使用する例示的な経路設定オブジェクトを提示します。 128.8.0.0/16と128.9.0.0/16のルートオブジェクトはそれらmember-にセット名RS-FOOを参照するので、設定されたRS-fooが2つのアドレスプレフィックス、すなわち128.8.0.0/16と128.9.0.0/16が含ま属性の。セットrs-バーがアドレスプレフィックス128.7.0.0/16と128.8.0.0/16が含まれています。ルート128.7.0.0/16は、明示的にメンバーにリストされているRS-バーの属性、および128.8.0.0/16のルートオブジェクトは、その会員の属性にセット名RS-バーを参照してください。
Note that, if an address prefix is listed in a members attribute of a route set, it is a member of that route set. The route object corresponding to this address prefix does not need to contain a member-of attribute referring to this set name. The member-of attribute of the route class is an additional mechanism for specifying the members indirectly.
アドレスプレフィックスは、ルートセットのメンバー属性にリストされている場合、それはそのルートセットのメンバーである、ということに注意してください。このアドレスプレフィックスに対応するルートオブジェクトは、会員の属性セット名を参照を含める必要はありません。メンバーのルートクラスの属性は、間接的にメンバーを指定するための追加の機構です。
In a context that expects a route set (e.g. members attribute of the route-set class), an AS number ASx defines the set of routes that are originated by ASx; and an as-set AS-X defines the set of routes that are originated by the ASes in AS-X. A route p is said to be originated by ASx if there is a route object for p with ASx as the value of the origin attribute. For example, in Figure 15, the route set rs-special contains 128.9.0.0/16, routes of AS1 and AS2, and routes of the ASes in AS set AS-FOO.
ルートセット（ルートセットクラスのメンバー、例えば属性）を期待する文脈において、AS番号ASXはASXによって発信されたルートのセットを定義します。そして、として設定AS-Xは、AS-XでのASによって発信されたルートのセットを定義します。経路Pが原点属性の値として、ASXとpのルートオブジェクトがある場合ASXによって発信されると言われています。例えば、図15において、ルートセットRS-特別には128.9.0.0/16、AS1とAS2の経路、およびASセットAS-FOOでのASの経路を含んでいます。
route-set: rs-special members: 128.9.0.0/16, AS1, AS2, AS-FOO
ルート設定：RS-特別会員：128.9.0.0/16、AS1、AS2、AS-FOO
Figure 15: Use of AS numbers and AS sets in route sets.
図15：AS番号のとルートセットでのセットとして使用します。
The set rs-any contains all routes registered in IRR. The set as-any contains all ASes registered in IRR.
セットには、RS-任意のIRRに登録されたすべてのルートが含まれています。任意のセットは、IRRに登録されているすべてのASが含まれています。
The attributes of the filter-set class are shown in Figure 16. A filter-set object defines a set of routes that are matched by its filter. The filter-set attribute defines the name of the filter. It is an RPSL name that starts with "fltr-".
フィルタセットクラスの属性は、フィルタ設定の目的は、そのフィルタにマッチしているルートのセットを定義し、図16に示されています。フィルタ属性セットは、フィルタの名前を定義します。それは「fltr-」で始まるRPSL名です。
Attribute Value Type
filter-set <object-name> mandatory, single-valued, class key
filter <filter> mandatory, single-valued
Figure 16: filter Class Attributes
図16：フィルタクラス属性
filter-set: fltr-foo filter: { 5.0.0.0/8, 6.0.0.0/8 }
フィルタセット：FLTR-FOOフィルター：{5.0.0.0/8、6.0.0.0/8}
filter-set: fltr-bar filter: (AS1 or fltr-foo) and <AS2>
フィルタセット：FLTRバーフィルタ（AS1またはFLTR-FOO）と<AS2>
Figure 17: filter-set objects.
図17：フィルタセットオブジェクト。
The filter attribute defines the set's policy filter. A policy filter is a logical expression which when applied to a set of routes returns a subset of these routes. We say that the policy filter matches the subset returned. The policy filter can match routes using any BGP path attribute, such as the destination address prefix (or NLRI), AS-path, or community attributes.
フィルタ属性は、セットのポリシーフィルタを定義します。ポリシー・フィルタは、ルートのセットに適用した場合、これらの経路のサブセットを返す論理式です。私たちは、ポリシーフィルタが返されたサブセットと一致していることを言います。ポリシーフィルタは、ASパスを、宛先アドレスのプレフィックス（またはNLRI）などの任意のBGPパス属性を使用して、ルートを一致させることができ、またはコミュニティ属性。
The policy filters can be composite by using the operators AND, OR, and NOT. The following policy filters can be used to select a subset of routes:
ポリシーフィルタは、演算子AND、OR、NOTを使用して複合することができます。以下のポリシーフィルタは、ルートのサブセットを選択するために使用することができます。
ANY The keyword ANY matches all routes.
ANYキーワードはANYすべてのルートと一致します。
Address-Prefix Set This is an explicit list of address prefixes enclosed in braces '{' and '}'. The policy filter matches the set of routes whose destination address-prefix is in the set. For example:
アドレスプレフィックスは、これは、中括弧「{」と「}」で囲まれたアドレス接頭語の明示的なリストである設定してください。ポリシー・フィルタは、宛先アドレスプレフィックスセットにあるルートのセットに一致します。例えば：
{ 0.0.0.0/0 }
{ 128.9.0.0/16, 128.8.0.0/16, 128.7.128.0/17, 5.0.0.0/8 }
{ }
An address prefix can be optionally followed by a range operator (i.e.
アドレスプレフィックスは、任意の範囲のオペレータによって追跡することができる（すなわち、
{ 5.0.0.0/8^+, 128.9.0.0/16^-, 30.0.0.0/8^16, 30.0.0.0/8^24-32 }
｛ ５。０。０。０／８＾＋、 １２８。９。０。０／１６＾ー、 ３０。０。０。０／８＾１６、 ３０。０。０。０／８＾２４ー３２ ｝
contains all the more specifics of 5.0.0.0/8 including 5.0.0.0/8, all the more specifics of 128.9.0.0/16 excluding 128.9.0.0/16, all the more specifics of 30.0.0.0/8 which are of length 16 such as 30.9.0.0/16, and all the more specifics of 30.0.0.0/8 which are of length 24 to 32 such as 30.9.9.96/28.
128.9.0.0/16を除く5.0.0.0/8 5.0.0.0/8を含め、すべてのより具体的、128.9.0.0/16のすべてのより具体的、長さが16である30.0.0.0/8のすべてのより多くの詳細を含みます32例えば30.9.9.96/28ように長さが24である30.0.0.0/8のような30.9.0.0/16、およびすべてのより詳細。
Route Set Name A route set name matches the set of routes that are members of the set. A route set name may be a name of a route-set object, an AS number, or a name of an as-set object (AS numbers and as-set names implicitly define route sets; please see Section 5.3). For example:
ルートセット名は、ルートセット名は、セットのメンバーであるルートのセットと一致します。ルートセット名は、（AS番号とAS-セット名は、暗黙ルートセットを定義し、セクション5.3を参照）ルートセットオブジェクト、AS番号、又は、設定されたオブジェクトの名前の名前であってもよいです。例えば：
aut-num: AS1 import: from AS2 accept AS2 import: from AS2 accept AS-FOO import: from AS2 accept RS-FOO
AUT-NUM：AS1のインポート：AS2からAS2のインポートを受け入れる：AS2からAS-FOOのインポートを受け入れる：AS2からRS-FOOを受け入れます
The keyword PeerAS can be used instead of the AS number of the peer AS. PeerAS is particularly useful when the peering is specified using an AS expression. For example:
キーワードPeerASではなく、ASピアのAS番号を使用することができます。 PeerASピアリングは、式として使用して指定されている場合に特に便利です。例えば：
as-set: AS-FOO members: AS2, AS3
セットとして：AS-FOOメンバー：AS2、AS3
aut-num: AS1 import: from AS-FOO accept PeerAS
AUT-NUM：AS1のインポート：AS-FOOからPeerASを受け入れます
is same as:
同じです。
aut-num: AS1 import: from AS2 accept AS2 import: from AS3 accept AS3
AUT-NUM：AS1のインポート：AS2 AS2のインポートを受け入れるから：AS3からAS3を受け入れます
A route set name can also be followed by one of the operators '^-', '^+', example, { 5.0.0.0/8, 6.0.0.0/8 }^+ equals { 5.0.0.0/8^+, 6.0.0.0/8^+ }, and AS1^- equals all the exclusive more specifics of routes originated by AS1.
、、 '^ +'、例えば、{5.0.0.0/8、6.0.0.0/8} ^ +等号{5.0.0.0/8^+ - ルートセット名は、演算子 '^' のいずれかが続くことができます6.0.0.0/8^+}、及びAS1 ^ - AS1によって発信経路の全て排他的より具体的に等しいです。
AS Path Regular Expressions An AS-path regular expression can be used as a policy filter by enclosing the expression in `<' and `>'. An AS-path policy filter matches the set of routes which traverses a sequence of ASes matched by the AS-path regular expression. A router can check this using the AS_PATH attribute in the Border Gateway Protocol [19], or the RD_PATH attribute in the Inter-Domain Routing Protocol [18].
パス正規表現アンASパス正規表現は、 `<「と`>」で式を囲むことにより、ポリシーフィルタとして使用することができます。 ASパスポリシー・フィルタは、ASパス正規表現にマッチのASの配列を横断するルートのセットに一致します。ルータはボーダーゲートウェイプロトコル[19]、またはドメイン間ルーティングプロトコル[18]でRD_PATH属性にAS_PATH属性を使用して、これを確認することができます。
AS-path Regular Expressions are POSIX compliant regular expressions over the alphabet of AS numbers. The regular expression constructs are as follows:
ASパス正規表現はAS番号のアルファベットの上にPOSIX準拠の正規表現です。次のように正規表現の構文は以下のとおりです。
ASN where ASN is an AS number. ASN matches the AS-path that is of length 1 and contains the corresponding AS number (e.g. AS-path regular expression AS1 matches the AS-path "1").
ASNはAS番号であるASN。 ASNは、長さが1であり、番号、対応する（例えば、ASパス正規表現AS1は、ASパスを「1」と一致する）を含むASパスに一致します。
The keyword PeerAS can be used instead of the AS number of the peer AS.
キーワードPeerASではなく、ASピアのAS番号を使用することができます。
AS-set where AS-set is an AS set name. AS-set matches the AS-paths that is matched by one of the ASes in the AS-set.
AS-セットAS-セットはASセット名です。 AS-セットはAS-セット内のASのいずれかによって整合されるAS-パスと一致します。
. matches the AS-paths matched by any AS number.
。任意のAS番号にマッチしたAS-パスと一致します。
[...] is an AS number set. It matches the AS-paths matched by the AS numbers listed between the brackets. The AS numbers in the set are separated by white space characters. If a `-' is used between two AS numbers in this set, all AS numbers between the two AS numbers are included in the set. If an as-set name is listed, all AS numbers in the as-set are included.
[...] AS番号のセットです。これは、括弧の間で記載されているAS番号にマッチしたAS-パスと一致します。セットでのAS番号は空白文字で区切られます。 `場合 - 」はこのセットでAS番号2との間で使用され、AS番号2の間の数値ASすべてがセットに含まれています。設定された名前が表示されている場合は、AS-セット内のAS番号のすべてが含まれています。
[^...] is a complemented AS number set. It matches any AS-path which is not matched by the AS numbers in the set.
[^ ...]は、数セットとして補完されます。これは、セット中のAS番号にマッチしていない任意のASパスに一致します。
^ Matches the empty string at the beginning of an AS-path.
^ ASパスの先頭に空の文字列にマッチします。
$ Matches the empty string at the end of an AS-path.
$は、ASパスの最後に空の文字列にマッチします。
We next list the regular expression operators in the decreasing order of evaluation. These operators are left associative, i.e. performed left to right.
私たちは、次の評価の高い順に正規表現演算子を一覧表示します。これらの演算子は、左結合している、すなわち左から右に行います。
Unary postfix operators * + ? {m} {m,n} {m,} For a regular expression A, A* matches zero or more occurrences of A; A+ matches one or more occurrences of A; A? matches zero or one occurrence of A; A{m} matches m occurrence of A; A{m,n} matches m to n occurrence of A; A{m,} matches m or more occurrence of A. For example, [AS1 AS2]{2} matches AS1 AS1, AS1 AS2, AS2 AS1, and AS2 AS2.
単項後置演算子* +？ {M} {M、N} {mは}正規表現Aについては、A *はゼロまたはそれ以上の出現と一致し、 +は、の1回以上の繰り返しにマッチします。 ？マッチゼロ又はAの一方の出現。 {M}はAのm個の発生と一致します。 {M、N}はn個の発生にMと一致します。 {Mは、M}または、例えばA.より発生と一致する、[AS1とAS2] {2}は、AS1のAS1、AS1とAS2、AS2のAS1とAS2のAS2と一致します。
Unary postfix operators ~* ~+ ~{m} ~{m,n} ~{m,} These operators have similar functionality as the corresponding operators listed above, but all occurrences of the regular expression has to match the same pattern. For example, [AS1 AS2]~{2} matches AS1 AS1 and AS2 AS2, but it does not match AS1 AS2 and AS2 AS1.
単項後置演算子〜*〜+〜{M}〜{M、N}〜{M}これらの演算子は、上記対応する演算子と同様の機能を有するが、正規表現のすべてのオカレンスが、同じパターンに一致しなければなりません。例えば、[AS1とAS2は】〜{2} AS1のAS1とAS2のAS2と一致し、それは、AS1のAS2とAS2とAS1と一致していません。
Binary catenation operator This is an implicit operator and exists between two regular expressions A and B when no other explicit operator is specified. The resulting expression A B matches an AS-path if A matches some prefix of the AS-path and B matches the rest of the AS-path.
バイナリカテネーションオペレータこれは暗黙の演算子であり、他の明示的な演算子が指定されていないときに、2つの正規表現AとBの間に存在します。 Aは、ASパスの一部プレフィックスと一致し、Bは、ASパスの残りの部分に一致する場合、得られた式A Bは、ASパスに一致します。
Binary alternative (or) operator | For a regular expressions A and B, A | B matches any AS-path that is matched by A or B.
バイナリ代替（または）演算子|正規表現AとB、Aのために| BはAまたはBにマッチされている任意のASパスにマッチします
Parenthesis can be used to override the default order of evaluation. White spaces can be used to increase readability.
括弧は評価のデフォルトの順序を上書きするために使用することができます。ホワイトスペースは、可読性を高めるために使用することができます。
The following are examples of AS-path filters:
以下のASパスフィルタの例を示します。
<AS3> <^AS1> <AS2$> <^AS1 AS2 AS3$> <^AS1 .* AS2$>.
<AS3> <^ AS1> <AS2 $> <^ AS3のAS1のAS2 $> <^ AS1。* AS2の$>。
The first example matches any route whose AS-path contains AS3, the second matches routes whose AS-path starts with AS1, the third matches routes whose AS-path ends with AS2, the fourth matches routes whose AS-path is exactly "1 2 3", and the fifth matches routes whose AS-path starts with AS1 and ends in AS2 with any number of AS numbers in between.
最初の例は、そのASパスAS1始まる第二マッチルート、そのASパスAS2で終わる第一致ルート、そのASパス「正確に1 2であり、第四のマッチルート、そのASパスAS3を含む任意の経路に一致します3" 、およびそのASパスAS1始まるとの間でAS番号の任意の数のAS2で終わる第一致ルート。
Composite Policy Filters The following operators (in decreasing order of evaluation) can be used to form composite policy filters:
複合ポリシは、複合ポリシフィルタを形成するために使用することができる（評価の順に）次の演算子をフィルタリング：
NOT Given a policy filter x, NOT x matches the set of routes that are not matched by x. That is it is the negation of policy filter x.
ポリシーフィルタxを与えられていない、NOT xはxで一致していないルートのセットと一致します。つまり、ポリシーフィルタxの否定です。
AND Given two policy filters x and y, x AND y matches the intersection of the routes that are matched by x and that are matched by y.
そして、2つのポリシーフィルタのxとyを考えると、xとyは、xにマッチしていると、それはyで一致しているルートの交差点に一致します。
OR Given two policy filters x and y, x OR y matches the union of the routes that are matched by x and that are matched by y.
OR 2つのポリシーフィルタのxとyを考えると、xまたはyがxで一致していると、それはyで一致しているルートの労働組合に一致します。
Note that an OR operator can be implicit, that is `x y' is equivalent to `x OR y'.
OR演算子は暗黙的であってもよいことに留意されたい、それは `のx Y「xまたはy 'と等価である」です。
E.g. NOT {128.9.0.0/16, 128.8.0.0/16} AS226 AS227 OR AS228 AS226 AND NOT {128.9.0.0/16} AS226 AND {0.0.0.0/0^0-18}
例えば。 NOT {128.9.0.0/16、128.8.0.0/16} AS226はAS227 OR AS228はAS226 AND NOT {128.9.0.0/16} AS226と{} 0.0.0.0/0^0-18
The first example matches any route except 128.9.0.0/16 and 128.8.0.0/16. The second example matches the routes of AS226, AS227 and AS228. The third example matches the routes of AS226 except 128.9.0.0/16. The fourth example matches the routes of AS226 whose length are not longer than 18.
最初の例は、128.9.0.0/16と128.8.0.0/16除く任意の経路に一致します。第二の例では、AS226、AS227及びAS228の経路と一致しています。第3の例は128.9.0.0/16以外AS226のルートと一致します。第四の例は、長さ18よりも長くないAS226のルートと一致します。
Routing Policy Attributes Policy filters can also use the values of other attributes for comparison. The attributes whose values can be used in policy filters are specified in the RPSL dictionary. Please refer to Section 7 for details. An example using the the BGP community attribute is shown below:
ルーティングポリシーは、ポリシーフィルタはまた、比較のために他の属性の値を使用することができます属性。その値はポリシーフィルタで使用できる属性は、RPSL辞書に指定されています。詳細については、セクション7を参照してください。 BGPコミュニティ属性を使用した例を以下に示します。
aut-num: AS1 export: to AS2 announce AS1 AND NOT community(NO_EXPORT)
AUT-NUM：AS1エクスポート：AS2にAS1 AND NOTコミュニティ（NO_EXPORT）を発表
Filters using the routing policy attributes defined in the dictionary are evaluated before evaluating the operators AND, OR and NOT.
辞書に定義されたルーティングポリシーの属性を使用したフィルタは、演算子を評価する前に評価AND、ORおよびNOTされています。
Filter Set Name A filter set name matches the set of routes that are matched by its filter attribute. Note that the filter attribute of a filter set, can recursively refer to other filter set names. For example in Figure 17, fltr-foo matches { 5.0.0.0/8, 6.0.0.0/8 }, and fltr-bar matches AS1'S routes or { 5.0.0.0/8, 6.0.0.0/8 } if their as path contained AS2.
セット名をフィルタするフィルタセット名は、そのフィルタ属性で一致しているルートのセットと一致します。フィルタセットのフィルタ属性は、再帰的に他のフィルタセット名を参照できることに注意してください。図17の例では、FLTR-FOOマッチ{5.0.0.0/8、6.0.0.0/8}、およびFLTRバーは、AS1'Sルートに一致または{5.0.0.0/8、6.0.0.0/8}それらのパスが含まれるような場合AS2。
The attributes of the rtr-set class are shown in Figure 18. The rtr-set attribute defines the name of the set. It is an RPSL name that starts with "rtrs-". The members attribute lists the members of the set. The members attribute is a list of inet-rtr names, ipv4_addresses or other rtr-set names.
RTRセットクラスの属性は、RTR-属性セットは、セットの名前を定義し、図18に示されています。それは「rtrs-」で始まるRPSL名です。メンバーはリストにセットのメンバーを属性。メンバーは、INET-RTR名、ipv4_addressesまたは他のRTR-セット名のリストである属性。
Attribute Value Type rtr-set <object-name> mandatory, single-valued, class key members list of <inet-rtr-names> or optional, multi-valued <rtr-set-names> or <ipv4_addresses> mbrs-by-ref list of <mntner-names> optional, multi-valued
値のタイプRTR-セット<オブジェクト名>必須、単一値、クラスキーメンバー<INET-RTR-名>のリストやオプションの属性、複数値<RTR-セット名>または<ipv4_addresses> MBRをバイオプションの<のmntner-名>のrefリスト多値
Figure 18: rtr-set Class Attributes
図18：RTR-セットクラスの属性
Figure 19 presents two rtr-set objects. The set rtrs-foo contains two routers, namely rtr1.isp.net and rtr2.isp.net. The set rtrs-bar contains the members of the set rtrs-foo and rtr3.isp.net, that is it contains rtr1.isp.net, rtr2.isp.net, rtr3.isp.net.
図19は、2 RTR-セットオブジェクトを提供します。セットRTRS-fooが2つのルータ、すなわちrtr1.isp.netとrtr2.isp.netが含まれています。セットRTRSバーが設定RTRS-fooとrtr3.isp.netのメンバーが含まれている、それはそれはrtr1.isp.net、rtr2.isp.net、rtr3.isp.netが含まれています。
rtr-set: rtrs-foo rtr-set: rtrs-bar members: rtr1.isp.net, rtr2.isp.net members: rtr3.isp.net, rtrs-foo
RTR-セット：RTRS-fooというRTR-設定：RTRSバーメンバー：rtr1.isp.net、rtr2.isp.netメンバー：rtr3.isp.net、RTRS-FOO
Figure 19: rtr-set objects.
図19：RTR-設定オブジェクト。
The mbrs-by-ref attribute is a list of maintainer names or the keyword ANY. If this attribute is used, the router set also includes routers whose inet-rtr objects are registered by one of these maintainers and whose member-of attribute refers to the name of this router set. If the value of a mbrs-by-ref attribute is ANY, any inet-rtr object referring to the router set is a member of the set. If the mbrs-by-ref attribute is missing, only the routers listed in the members attribute are members of the set.
MBRをバイrefの属性は、メンテナ名またはキーワードANYのリストです。この属性が使用される場合、また、設定ルータは、そのINET-RTRオブジェクトこれら保守のいずれかによって登録され、その属性メンバーのこのルータ・セットの名前を意味するルータを含みます。 MBRをバイrefの属性の値がANYの場合は、ルータのセットを参照するすべてのINET-RTRオブジェクトは、セットのメンバーです。 MBRをバイrefの属性が存在しない場合は、会員のみに記載されているルータは、属性セットのメンバーです。
rtr-set: rtrs-foo
members: rtr1.isp.net, rtr2.isp.net
mbrs-by-ref: MNTR-ME
inet-rtr: rtr3.isp.net local-as: as1 ifaddr: 1.1.1.1 masklen 30 member-of: rtrs-foo mnt-by: MNTR-ME
INET-RTR：rtr3.isp.netローカル-AS：AS1用のifaddr：1.1.1.1 masklen 30メンバーの：RTRS-FOOのMNTバイ：MNTR-ME
Figure 20: rtr-set objects.
図20：RTRセットオブジェクト。
Figure 20 presents an example rtr-set object that uses the mbrs-by-ref attribute. The set rtrs-foo contains rtr1.isp.net, rtr2.isp.net and rtr3.isp.net.
図20は、のMBRバイREF属性を使用する例のRTRセットオブジェクトを提示します。セットRTRS-fooがrtr1.isp.net、rtr2.isp.netとrtr3.isp.netが含まれています。
The attributes of the peering-set class are shown in Figure 21. A peering-set object defines a set of peerings that are listed in its peering attributes. The peering-set attribute defines the name of the set. It is an RPSL name that starts with "prng-".
ピアリングセットクラスの属性は、ピア・セットオブジェクトは、そのピアリング属性に記載されているピアリングのセットを定義し、図21に示されています。ピアリング-属性セットは、セットの名前を定義します。それは「prng-」で始まるRPSL名です。
Attribute Value Type peering-set <object-name> mandatory, single-valued, class key peering <peering> mandatory, multi-valued
値のタイプは、ピアリング・セット<オブジェクト名>必須、単一値、クラスキーピアリング<ピアリング>必須属性多値
Figure 21: filter Class Attributes
図21：フィルタクラス属性
The peering attribute defines a peering that can be used for importing or
ピアリング属性は、インポートまたはのために使用することができるピアリングを定義します
---------------------- ----------------------
| 7.7.7.1 |-------| |-------| 7.7.7.2 |
| | ======== | |
| AS1 | EX1 |-------| 7.7.7.3 AS2 |
| | | |
| 9.9.9.1 |------ ------| 9.9.9.2 |
---------------------- | | ----------------------
===========
| EX2
---------------------- |
| 9.9.9.3 |---------
| |
| AS3 |
----------------------
Figure 22: Example topology consisting of three ASes, AS1, AS2, and AS3; two exchange points, EX1 and EX2; and six routers.
図22：3つのAS、AS1、AS2、AS3とからなる例トポロジ。 2つのExchange点、EX1とEX2。そして6つのルータ。
exporting routes. In describing peerings, we are going to use the topology of Figure 22. In this topology, there are three ASes, AS1, AS2, and AS3; two exchange points, EX1 and EX2; and six routers. Routers connected to the same exchange point peer with each other and exchange routing information. That is, 7.7.7.1, 7.7.7.2 and 7.7.7.3 peer with each other; 9.9.9.1, 9.9.9.2 and 9.9.9.3 peer with each other.
ルートをエクスポートします。ピアリングを説明する際に、我々は、3つのAS、AS1、AS2、およびAS3があります。このトポロジでは、図22のトポロジーを使用しようとしています。 2つのExchange点、EX1とEX2。そして6つのルータ。互いに同一の交換点ピアとルーティング情報を交換に接続されたルータ。すなわち、相互に、7.7.7.1、7.7.7.2と7.7.7.3ピアです。 9.9.9.1、9.9.9.2と9.9.9.3は、互いにピア。
The syntax of a peering specification is:
ピアリング仕様の構文は次のとおりです。
<as-expression> [<router-expression-1>] [at <router-expression-2>] | <peering-set-name>
<として発現> [<ルータ式1>] [<ルータ式2>で] | <ピアリング・セット名>
where <as-expression> is an expression over AS numbers and AS sets using operators AND, OR, and EXCEPT, and <router-expression-1> and <router-expression-2> are expressions over router IP addresses, inet-rtr names, and rtr-set names using operators AND, OR, and EXCEPT. The binary "EXCEPT" operator is the set subtraction operator and has the same precedence as the operator AND (it is semantically equivalent to "AND NOT" combination). That is "(AS1 OR AS2) EXCEPT AS2" equals "AS1".
ここで、<として-式> AS番号と演算子を使用してセットAS過剰発現AND、OR、およびEXCEPT、および<ルータ式1>と<ルータ式2>であるルータのIPアドレスを超える式で、INET-RTR名前、およびRTRセット名の演算子を使用してAND、OR、およびEXCEPT。演算子「以外の」バイナリセット減算演算子であり、オペレータと同じ優先順位を有し、（それが組み合わせ意味的に等価である「AND NOT」）。それは "AS1" に等しい "AS2は、EXCEPT（AS1 OR AS2）" です。
This form identifies all the peerings between any local router in <router-expression-2> to any of their peer routers in <router-expression-1> in the ASes in <as-expression>. If <router-expression-2> is not specified, it defaults to all routers of the local AS that peer with ASes in <as-expression>. If <router-expression-1> is not specified, it defaults to all routers of the peer ASes in <as-expression> that peer with the local AS.
この形式は、<ように、式>でのASの<ルータ式1>で、そのピアルータのいずれかに<ルータ式2>の任意のローカルルータの間のすべてのピアリングを識別する。 <AS-式>でのASとそのピアASローカルのすべてのルータに、<ルータ式2>が指定されていない場合、それがデフォルトになります。 <AS-式>でのピアのASのすべてのルータに、<ルータ式1>が指定されていない場合、それはデフォルトでローカルASとピアいます。
If a <peering-set-name> is used, the peerings are listed in the corresponding peering-set object. Note that the peering-set objects can be recursive.
<ピアリング・セット名>が使用される場合、ピアリングは、対応するピアリング・セットオブジェクトに記載されています。ピアリング・セットのオブジェクトを再帰的にできることに注意してください。
Many special forms of this general peering specification is possible. The following examples illustrate the most common cases, using the import attribute of the aut-num class. In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2.
この一般的なピアリング仕様の多くは特殊な形式が可能です。次の例では、AUT-NUMクラスのimport属性を使用して、最も一般的な例を示しています。次の例では7.7.7.2からの輸入128.9.0.0/16を7.7.7.1。
(1) aut-num: AS1 import: from AS2 7.7.7.2 at 7.7.7.1 accept { 128.9.0.0/16 }
（1）AUT-NUM：AS1インポート：7.7.7.1でAS2 7.7.7.2から{128.9.0.0/16}を受け入れます
In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3.
次の例では7.7.7.2と7.7.7.3からの輸入128.9.0.0/16を7.7.7.1。
(2) aut-num: AS1 import: from AS2 at 7.7.7.1 accept { 128.9.0.0/16 }
（2）AUT-NUM：AS1インポート：AS2から7.7.7.1には、{128.9.0.0/16}を受け入れます
In the following example 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3, and 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2.
次の例では9.9.9.2から7.7.7.2と7.7.7.3と9.9.9.1輸入128.9.0.0/16からの輸入128.9.0.0/16を7.7.7.1。
(3) aut-num: AS1 import: from AS2 accept { 128.9.0.0/16 }
（3）AUT-NUMを：AS1インポート：AS2からは{128.9.0.0/16}受け入れます
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3.
次の例では9.9.9.2と9.9.9.3からの輸入128.9.0.0/16を9.9.9.1。
(4) as-set: AS-FOO members: AS2, AS3
（4）としてセット：AS-FOOメンバー：AS2、AS3
aut-num: AS1
import: from AS-FOO at 9.9.9.1 accept { 128.9.0.0/16 }
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3, and 7.7.7.1 imports 128.9.0.0/16 from 7.7.7.2 and 7.7.7.3.
次の例では7.7.7.2と7.7.7.3から9.9.9.2と9.9.9.3と7.7.7.1輸入128.9.0.0/16からの輸入128.9.0.0/16を9.9.9.1。
(5) aut-num: AS1 import: from AS-FOO accept { 128.9.0.0/16 }
（5）AUT-NUM：AS1インポート：AS-FOOから{128.9.0.0/16}を受け入れます
In the following example AS1 imports 128.9.0.0/16 from AS3 at router 9.9.9.1
ルータ9.9.9.1でAS3から次の例ではAS1の輸入128.9.0.0/16
(6) aut-num: AS1 import: from AS-FOO and not AS2 at not 7.7.7.1 accept { 128.9.0.0/16 }
（6）AUT-NUM：AS1インポート：AS-FOOなく、AS2からではない7.7.7.1には、{128.9.0.0/16}を受け入れます
This is because "AS-FOO and not AS2" equals AS3 and "not 7.7.7.1" equals 9.9.9.1.
「AS-FOOなくAS2は」AS3に等しく、「ない7.7.7.1」9.9.9.1に等しいためです。
In the following example 9.9.9.1 imports 128.9.0.0/16 from 9.9.9.2 and 9.9.9.3.
次の例では9.9.9.2と9.9.9.3からの輸入128.9.0.0/16を9.9.9.1。
(7) peering-set: prng-bar peering: AS1 at 9.9.9.1
（7）ピアリングを設定：AS1と9.9.9.1：PRNGバーをピアリング
peering-set: prng-foo
peering: prng-bar
peering: AS2 at 9.9.9.1
aut-num: AS1 import: from prng-foo accept { 128.9.0.0/16 }
AUT-NUM：AS1インポート：PRNG-FOOから{128.9.0.0/16}受け入れます
6 aut-num Class
またはクラス6か
Routing policies are specified using the aut-num class. The attributes of the aut-num class are shown in Figure 23. The value of the aut-num attribute is the AS number of the AS described by this object. The as-name attribute is a symbolic name (in RPSL name syntax) of the AS. The import, export and default routing policies of the AS are specified using import, export and default attributes respectively.
ルーティングポリシーはAUT-NUMクラスを使用して指定されています。 AUT-NUMクラスの属性は、AUT-num属性の値は、このオブジェクトによって記載されたようにAS番号である図23に示されています。 AS-name属性は、ASの（RPSL名の構文で）シンボリック名です。 ASのインポート、エクスポート、およびデフォルトのルーティングポリシーは、それぞれのインポート、エクスポート、およびデフォルトの属性を使用して指定されています。
Attribute Value Type aut-num <as-number> mandatory, single-valued, class key as-name <object-name> mandatory, single-valued member-of list of <as-set-names> optional, multi-valued import see Section 6.1 optional, multi valued export see Section 6.2 optional, multi valued default see Section 6.5 optional, multi valued
<として-数>値のタイプAUT-NUMを属性として名必須、単一値、クラスキー<オブジェクト名>必須、単一値メンバーの<設定として-名>オプションで、複数の値を持つインポートのリスト多値、6.2節オプション、多値デフォルトは6.5節は、オプションの参照参照セクション6.1オプション、多値輸出を見ます
Figure 23: aut-num Class Attributes
図23：AUT-NUMクラス属性
In RPSL, an import policy is divided into import policy expressions. Each import policy expression is specified using an import attribute. The import attribute has the following syntax (we will extend this syntax later in Sections 6.3 and 6.6):
RPSLでは、輸入政策は、輸入政策表現に分かれています。各インポートポリシー表現は、import属性を使用して指定されています。 import属性は、次の構文を（私たちはセクション6.3と6.6の後半で、この構文を拡張します）があります。
import: from <peering-1> [action <action-1>] . . . from <peering-N> [action <action-N>] accept <filter>
インポート：から<ピアリング-1>アクション<アクション1>]。 。 。 <ピアリング-N>から[アクション<アクション-N>]受け入れる<フィルター>
The action specification is optional. The semantics of an import attribute is as follows: the set of routes that are matched by <filter> are imported from all the peers in <peerings>; while importing routes at <peering-M>, <action-M> is executed.
アクションの指定は任意です。次のようにインポート属性の意味は次のとおりです。<フィルタ>にマッチしているルートのセットは、<ピアリング>内のすべてのピアからインポートされます。 <ピアリング-M>にルートをインポートしながら、<アクションM>が実行されます。
E.g. aut-num: AS1 import: from AS2 action pref = 1; accept { 128.9.0.0/16 }
例えば。 AUT-NUM：AS1インポート：AS2アクション県から= 1。 {128.9.0.0/16}を受け入れます
This example states that the route 128.9.0.0/16 is accepted from AS2 with preference 1. We already presented how peerings (see Section 5.6) and filters (see Section 5.4) are specified. We next present how to specify actions.
この例では、ルート128.9.0.0/16は、我々はすでにピアリング（5.6節を参照）、フィルタは（セクション5.4を参照）を指定する方法を提示好み1とAS2から受け入れられていると述べています。私たちは、次のアクションを指定する方法を提示します。
Policy actions in RPSL either set or modify route attributes, such as assigning a preference to a route, adding a BGP community to the BGP community path attribute, or setting the MULTI-EXIT-DISCRIMINATOR attribute. Policy actions can also instruct routers to perform special operations, such as route flap damping.
RPSLのポリシーアクションのいずれかを設定あるいは、経路に優先度を割り当てるBGPコミュニティパス属性にBGPコミュニティを追加、またはマルチEXIT-識別子属性の設定などルート属性を変更します。ポリシー・アクションはまた、減衰経路のフラップのような特殊な操作を実行するようにルータに指示することができます。
The routing policy attributes whose values can be modified in policy actions are specified in the RPSL dictionary. Please refer to Section 7 for a list of these attributes. Each action in RPSL is terminated by the semicolon character (';'). It is possible to form composite policy actions by listing them one after the other. In a composite policy action, the actions are executed left to right. For example,
その値は、ポリシー・アクションに変更することができるRPSL辞書で指定されたルーティングポリシー属性。これらの属性のリストについては、セクション7を参照してください。 RPSLの各アクションは、セミコロン（「;」）で終了します。それらを1つずつリストすることによって複合政策行動を形成することが可能です。複合ポリシーアクションでは、アクションは左から右に実行されます。例えば、
aut-num: AS1 import: from AS2 action pref = 10; med = 0; community.append(10250, 3561:10); accept { 128.9.0.0/16 }
AUT-NUM：AS1インポート：AS2アクション県から= 10。 MED = 0; community.append（10250、3561：10）。 {128.9.0.0/16}を受け入れます
sets pref to 10, med to 0, and then appends 10250 and 3561:10 to the BGP community path attribute. The pref attribute is the inverse of the local-pref attribute (i.e. local-pref == 65535 - pref). A route with a local-pref attribute is always preferred over a route without one.
10に設定し県は、0にmedが、その後、10250と3561追加：BGPコミュニティパス属性に10。県属性は、ローカル県属性（ - 県すなわちローカル県== 65535）の逆数です。ローカル・県属性を持つルートは、常に1つずにルートよりも優先されます。
aut-num: AS1
import: from AS2 action pref = 1;
from AS3 action pref = 2;
accept AS4
The above example states that AS4's routes are accepted from AS2 with preference 1, and from AS3 with preference 2 (routes with lower integer preference values are preferred over routes with higher integer preference values).
上記の例では、AS4のルートが嗜好1とAS2から受け入れていることを述べ、及び嗜好2とAS3から（下の整数優先値を持つルートがより高い整数優先値とルートよりも好ましいです）。
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
from AS2 action pref = 2;
accept AS4
The above example states that AS4's routes are accepted from AS2 on peering 7.7.7.1-7.7.7.2 with preference 1, and on any other peering with AS2 with preference 2.
上記の例では、AS4のルートが嗜好1と7.7.7.1-7.7.7.2ピアリングに、そして好ましくは2とAS2とのピアリング他にAS2から受け入れていることを述べています。
Similarly, an export policy expression is specified using an export attribute. The export attribute has the following syntax:
同様に、輸出のポリシー表現は、エクスポート属性を使用して指定されています。エクスポート属性の構文は次のとおりです。
export: to <peering-1> [action <action-1>] . . . to <peering-N> [action <action-N>] announce <filter>
輸出：に<ピアリング-1> [アクション<アクション-1>]。 。 。 【アクション<アクション-N> <-Nピアリング>から<フィルター>アナウンス
The action specification is optional. The semantics of an export attribute is as follows: the set of routes that are matched by <filter> are exported to all the peers specified in <peerings>; while exporting routes at <peering-M>, <action-M> is executed.
アクションの指定は任意です。次のようにエクスポート属性の意味は次のとおりです。<フィルタ>にマッチしているルートのセットは、<ピアリング>で指定されたすべてのピアに輸出されています。 <ピアリング-M>にルートをエクスポート中、<アクションM>が実行されます。
E.g. aut-num: AS1 export: to AS2 action med = 5; community .= { 70 }; announce AS4
例えば。 AUT-NUM：AS1エクスポート：= 5 medがAS2アクションに。コミュニティ= {70}。 AS4を発表
In this example, AS4's routes are announced to AS2 with the med attribute's value set to 5 and community 70 added to the community list.
この例では、AS4のルートはmedの属性の値を5に設定し、コミュニティ70は、コミュニティリストに追加してAS2に発表しています。
Example:
例：
aut-num: AS1 export: to AS-FOO announce ANY
AUT-NUM：AS1エクスポート：AS-FOOにANYを発表
In this example, AS1 announces all of its routes to the ASes in the set AS-FOO.
この例では、AS1は、AS-FOOセットでのASへのルートのすべてを発表しました。
6.3 Other Routing Protocols, Multi-Protocol Routing Protocols, and Injecting Routes Between Protocols
6.3他のルーティングプロトコル、マルチプロトコルルーティングプロトコル、およびプロトコル間の注入ルート
The more complete syntax of the import and export attributes are as follows:
インポートおよびエクスポート属性のより完全な構文は次のとおりです。
import: [protocol <protocol-1>] [into <protocol-2>] from <peering-1> [action <action-1>] . . . from <peering-N> [action <action-N>] accept <filter> export: [protocol <protocol-1>] [into <protocol-2>] to <peering-1> [action <action-1>] . . . to <peering-N> [action <action-N>] announce <filter>
インポート：[プロトコル<プロトコル-1>] [<プロトコル-2>に<ピアリング-1>アクション<アクション1>]から。 。 。 [プロトコル<プロトコル-1>] [<プロトコル-2>に<ピアリング-1>〜[アクション<アクション1>]：<-Nピアリング>から[アクション<アクション-N> <フィルター>を受け入れる輸出。 。 。 【アクション<アクション-N> <-Nピアリング>から<フィルター>アナウンス
Where the optional protocol specifications can be used for specifying policies for other routing protocols, or for injecting routes of one protocol into another protocol, or for multi-protocol routing policies. The valid protocol names are defined in the dictionary. The <protocol-1> is the name of the protocol whose routes are being exchanged. The <protocol-2> is the name of the protocol which is receiving these routes. Both <protocol-1> and <protocol-2> default to the Internet Exterior Gateway Protocol, currently BGP.
オプションのプロトコル仕様は、他のルーティングプロトコルのためのポリシーを指定するため、または別のプロトコルへのプロトコルのルートを注入するため、またはマルチプロトコル・ルーティングポリシーのために使用することができる場合。有効なプロトコル名は辞書に定義されています。 <手順1>は、ルート交換されているプロトコルの名前です。 <手順2>は、これらのルートを受信しているプロトコルの名前です。どちらも<プロトコル-1>と<プロトコル-2>インターネットエクステリアゲートウェイプロトコル、現在BGPへのデフォルト。
In the following example, all interAS routes are injected into RIP.
以下の例では、すべてのインターアクセスルートは、RIPに注入されます。
aut-num: AS1 import: from AS2 accept AS2 export: protocol BGP4 into RIP to AS1 announce ANY
AUT-NUM：AS1のインポート：AS2からAS2エクスポートを受け入れる：AS1へのRIPへのプロトコルBGP4はANYを発表
In the following example, AS1 accepts AS2's routes including any more specifics of AS2's routes, but does not inject these extra more specific routes into OSPF.
次の例では、AS1はAS2の経路のいずれかより詳細など、AS2のルートを受け入れますが、OSPFにこれらの余分な、より具体的なルートを注入していません。
aut-num: AS1 import: from AS2 accept AS2^+ export: protocol BGP4 into OSPF to AS1 announce AS2
AUT-NUM：AS1のインポート：AS2はAS2 ^ +輸出受け入れるから：AS1にOSPFにプロトコルBGP4をAS2を発表
In the following example, AS1 injects its static routes (routes which are members of the set AS1:RS-STATIC-ROUTES) to the interAS routing protocol and appends AS1 twice to their AS paths.
インターアクセスルーティングプロトコルおよび経路としての2回AS1を追加次の例では、AS1は、静的ルート（RS-STATIC-ROUTESセットAS1のメンバーである経路）を注入します。
aut-num: AS1 import: protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1); accept AS1:RS-STATIC-ROUTES
AUT-NUM：AS1インポート：AS1アクションaspath.prepend（AS1、AS1）からBGP4にSTATICプロトコル。 RS-STATIC-ROUTES：AS1を受け入れます
In the following example, AS1 imports different set of unicast routes for multicast reverse path forwarding from AS2:
次の例では、AS1輸入AS2から転送マルチキャストリバースパスのユニキャスト経路の異なるセット。
aut-num: AS1 import: from AS2 accept AS2 import: protocol IDMR from AS2 accept AS2:RS-RPF-ROUTES
AUT-NUM：AS1のインポート：RS-RPF-ROUTES：AS2を受け入れるAS2からプロトコルIDMR：AS2 AS2のインポートを受け入れるから
It is possible that the same peering can be covered by more that one peering specification in a policy expression. For example:
同じピアリングは、ポリシー表現で、よりその1つのピアリング仕様でカバーされ得ることが可能です。例えば：
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1;
accept AS4
This is not an error, though definitely not desirable. To break the ambiguity, the action corresponding to the first peering specification is used. That is the routes are accepted with preference 2. We call this rule as the specification-order rule.
確かに望ましいことではないが、これは、エラーではありません。あいまいさを解除するには、最初のピアリング仕様に対応するアクションが使用されています。すなわち、ルートが我々は、仕様順序ルールとしてこのルールを呼び出す嗜好2で受け入れられています。
Consider the example:
例を考えてみます。
aut-num: AS1
import: from AS2 action pref = 2;
from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
accept AS4
where both peering specifications cover the peering 7.7.7.1-7.7.7.2, though the second one covers it more specifically. The specification order rule still applies, and only the action "pref = 2" is executed. In fact, the second peering-action pair has no use since the first peering-action pair always covers it. If the intended policy was to accept these routes with preference 1 on this particular peering and with preference 2 in all other peerings, the user should have specified:
二つ目は、より具体的には、それをカバーするのにここで両方のピアリング仕様は、ピアリング7.7.7.1-7.7.7.2を覆います。仕様順序ルールが適用され、唯一のアクション「県= 2」が実行されます。最初のピアリング・アクションのペアは、常にそれをカバーしているので実際には、第二ピアリング・アクションのペアで使用することは無意味です。意図されたポリシーは、この特定のピアリングに好ましい1とし、他のすべてのピアリングに優先2と、これらのルートを受け入れるようにした場合、ユーザが指定している必要があります。
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1 action pref = 1; dpa = 5;
from AS2 action pref = 2;
accept AS4
It is also possible that more than one policy expression can cover the same set of routes for the same peering. For example:
複数のポリシー式が同じピアリングのルートの同じセットをカバーできることも可能です。例えば：
aut-num: AS1 import: from AS2 action pref = 2; accept AS4 import: from AS2 action pref = 1; accept AS4
AUT-NUM：AS1インポート：AS2アクション県から= 2。 AS4のインポートを受け入れる：AS2アクション県= 1から; AS4を受け入れます
In this case, the specification-order rule is still used. That is, AS4's routes are accepted from AS2 with preference 2. If the filters were overlapping but not exactly the same:
この場合には、指定順序ルールがまだ使用されています。フィルタは、重複したが、まったく同じでない場合はそれは、AS4のルートは好み2でAS2から受け入れられています。
aut-num: AS1 import: from AS2 action pref = 2; accept AS4 import: from AS2 action pref = 1; accept AS4 OR AS5
AUT-NUM：AS1インポート：AS2アクション県から= 2。 AS4のインポートを受け入れる：AS2アクション県= 1から; AS4 OR AS5を受け入れます
the AS4's routes are accepted from AS2 with preference 2 and however AS5's routes are also accepted, but with preference 1.
AS4のルートは嗜好2とAS2から受け入れられ、ただしAS5のルートも受け入れられているが、好ましい1。
We next give the general specification order rule for the benefit of the RPSL implementors. Consider two policy expressions:
私たちは、次のRPSL実装者の利益のための一般的な仕様のオーダー規則を与えます。 2つのポリシーの表現を考えてみます。
aut-num: AS1 import: from peerings-1 action action-1 accept filter-1 import: from peerings-2 action action-2 accept filter-2
AUT-NUM：AS1インポート：ピアリング-1アクションアクション-1からは、フィルタ-1インポートを受け入れる：ピアリング-2アクションアクション-2からフィルタ2を受け入れます
The above policy expressions are equivalent to the following three expressions where there is no ambiguity:
上記のポリシー式は内容が不明確ではない場合、以下の3つの式と等価です。
aut-num: AS1 import: from peerings-1 action action-1 accept filter-1 import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1 import: from peerings-4 action action-2 accept filter-2
AUT-NUM：AS1インポート：ピアリング-1アクションアクション-1からは、フィルタ1を受け入れるインポート：ピアリング-3アクションアクション-2からは、フィルタ2およびNOTフィルタ-1をインポートを受け入れる：ピアリング-4アクションアクション-2からフィルターを受け入れます-2
where peerings-3 are those that are covered by both peerings-1 and peerings-2, and peerings-4 are those that are covered by peerings-2 but not by peerings-1 ("filter-2 AND NOT filter-1" matches the routes that are matched by filter-2 but not by filter-1).
ピアリング-3によって覆われているものである場合、両方のピアリング-1とピアリング-2、及びピアリング-4は、ピアリング-2によってではなくピアリング-1（「フィルタ-2およびNOTフィルタ-1」と一致することにより覆われているものですフィルタ2によってではなく、フィルタ1によって照合されるルート）。
Example:
例：
aut-num: AS1
import: from AS2 7.7.7.2 at 7.7.7.1
action pref = 2;
accept {128.9.0.0/16}
import: from AS2
action pref = 1;
accept {128.9.0.0/16, 75.0.0.0/8}
Lets consider two peerings with AS2, 7.7.7.1-7.7.7.2 and 9.9.9.1- 9.9.9.2. Both policy expressions cover 7.7.7.1-7.7.7.2. On this peering, the route 128.9.0.0/16 is accepted with preference 2, and the route 75.0.0.0/8 is accepted with preference 1. The peering 9.9.9.1-9.9.9.2 is only covered by the second policy expressions. Hence, both the route 128.9.0.0/16 and the route 75.0.0.0/8 are accepted with preference 1 on peering 9.9.9.1-9.9.9.2.
2つのAS2とのピアリング、7.7.7.1-7.7.7.2と9.9.9.1- 9.9.9.2を考えることができます。どちらのポリシー式は7.7.7.1-7.7.7.2をカバーしています。このピアに、ルート128.9.0.0/16は、優先2で受け入れられ、そして経路75.0.0.0/8のみ第2のポリシー表現で覆われている嗜好1ピアリング9.9.9.1-9.9.9.2で受け入れられています。したがって、ルート128.9.0.0/16と経路75.0.0.0/8両方が9.9.9.1-9.9.9.2ピアリングに嗜好1で受け入れられています。
Note that the same ambiguity resolution rules also apply to export and default policy expressions.
同じあいまいさ解決規則にも輸出して、デフォルトポリシーの表現に適用されることに注意してください。
Default routing policies are specified using the default attribute. The default attribute has the following syntax:
デフォルトのルーティングポリシーは、デフォルトの属性を使用して指定されています。デフォルト属性の構文は次のとおりです。
default: to <peering> [action <action>] [networks <filter>]
デフォルト：<ピアリング> [アクション<アクション>] [ネットワーク<フィルター>]へ
The <action> and <filter> specifications are optional. The semantics are as follows: The <peering> specification indicates the AS (and the router if present) is being defaulted to; the <action> specification, if present, indicates various attributes of defaulting, for example a relative preference if multiple defaults are specified; and the <filter> specifications, if present, is a policy filter. A router only uses the default policy if it received the routes matched by <filter> from this peer.
<アクション>と<フィルタ>仕様はオプションです。次のように意味は次のとおり<ピアリング>仕様は、AS（ルータ存在する場合は）にデフォルト設定されていることを示します。 <作用>仕様は、存在する場合、複数のデフォルト値が指定されている場合、例えば、相対的な優先度をデフォルト設定の様々な属性を示します。そして、<フィルタ>仕様は、存在する場合、ポリシーのフィルタです。それは、このピアから<フィルタ>にマッチしたルートを受け取った場合、ルータは、デフォルトのポリシーを使用しています。
In the following example, AS1 defaults to AS2 for routing.
次の例では、ルーティングのためのAS2にAS1デフォルト。
aut-num: AS1 default: to AS2
AUT-NUM：AS1デフォルト：AS2へ
In the following example, router 7.7.7.1 in AS1 defaults to router 7.7.7.2 in AS2.
次の例では、AS2で7.7.7.2をルーターにAS1のデフォルトのルータ7.7.7.1。
aut-num: AS1 default: to AS2 7.7.7.2 at 7.7.7.1
AUT-NUM：AS1デフォルト：AS2 7.7.7.2に7.7.7.1で
In the following example, AS1 defaults to AS2 and AS3, but prefers AS2 over AS3.
次の例では、AS2およびAS3へAS1のデフォルトが、AS3上AS2を好みます。
aut-num: AS1
default: to AS2 action pref = 1;
default: to AS3 action pref = 2;
In the following example, AS1 defaults to AS2 and uses 128.9.0.0/16 as the default network.
次の例では、AS2とAS1のデフォルトとデフォルトのネットワークとして128.9.0.0/16使用しています。
aut-num: AS1 default: to AS2 networks { 128.9.0.0/16 }
AUT-NUM：AS1デフォルト：AS2にネットワーク128.9.0.0/16 {}
The import and export policies can be structured. We only reccomend structured policies to advanced RPSL users. Please feel free to skip this section.
ポリシーのインポートおよびエクスポートを構成することができます。私たちは、高度なRPSLユーザーに構造化されたポリシーをreccomend。このセクションをスキップすること自由に感じなさい。
The syntax for a structured policy specification is the following:
構造化されたポリシー指定の構文は次のとおりであります：
<import-factor> ::= from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>;
<import-term> ::= <import-factor> |
LEFT-BRACE
<import-factor>
. . .
<import-factor>
RIGHT-BRACE
<import-expression> ::= <import-term> |
<import-term> EXCEPT <import-expression> |
<import-term> REFINE <import-expression>
import: [protocol <protocol1>] [into <protocol2>] <import-expression>
インポート：[プロトコル<プロトコル1>] [に<protocol2> <インポート式>
Please note the semicolon at the end of an <import-factor>. If the policy specification is not structured (as in all the examples in other sections), this semicolon is optional. The syntax and semantics for an <import-factor> is already defined in Section 6.1.
<輸入ファクター>の末尾にセミコロンに注意してください。ポリシー仕様は（他のセクションのすべての例のように）構成されていない場合、このセミコロンはオプションです。 <輸入ファクター>の構文と意味論は、すでに6.1節で定義されています。
An <import-term> is either a sequence of <import-factor>'s enclosed within matching braces (i.e. `{' and `}') or just a single <import-factor>. The semantics of an <import-term> is the union of <import-factor>'s using the specification order rule. An <import-expression> is either a single <import-term> or an <import-term> followed by one of the keywords "except" and "refine", followed by another <import-expression>. Note that our definition allows nested expressions. Hence there can be exceptions to exceptions, refinements to refinements, or even refinements to exceptions, and so on.
<インポート用語は、> <インポート因子>の一致括弧で囲まれ（すなわち、 '{'と '}'）または単に単一の<インポート因子>の配列のいずれかです。 <輸入用語>の意味は、指定順序のルールを使用しての<import-ファクター>さんの労働組合です。 <インポート式>単一の<インポート用語>または別の<インポート発現>続い<インポート用語>「以外」のキーワードのいずれかが続き、「絞り込み」、のいずれかです。私たちの定義は、ネストされた表現を可能にすることに注意してください。したがって、そうであった例外の例外、改良に改良、さらには改良の例外とすることができ、。
The semantics for the except operator is as follows: The result of an except operation is another <import-term>. The resulting policy set contains the policies of the right hand side but their filters are modified to only include the routes also matched by the left hand side. The policies of the left hand side are included afterwards and their filters are modified to exclude the routes matched by the right hand side. Please note that the filters are modified during this process but the actions are copied verbatim. When there are multiple levels of nesting, the operations (both except and refine) are performed right to left.
次のように除いてオペレータのためのセマンティクスは次のとおり操作以外の結果は、別の<インポート用語>です。結果のポリシーセットは、右側のポリシーが含まれていますが、そのフィルターはのみも左側にマッチしたルートを含むように変更されています。左側のポリシーがその後含まれており、そのフィルタが右側にマッチしたルートを除外するように変更されています。フィルタは、このプロセス中に変更されますが、アクションはそのままコピーされますのでご注意ください。ネストの複数のレベルがある場合、操作（除くと絞り込みの両方）は右から左に行われます。
Consider the following example:
次の例を考えてみます。
import: from AS1 action pref = 1; accept as-foo;
except {
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}
}
where the route 128.9.0.0/16 is originated by AS226, and AS226 is a member of the as set as-foo. In this example, the route 128.9.0.0/16 is accepted from AS3, any other route (not 128.9.0.0/16) originated by AS226 is accepted from AS2, and any other ASes' routes in as-foo is accepted from AS1.
ルート128.9.0.0/16はAS226によって発信された場合、およびAS226は、のように設定として、FOOの部材です。この例では、ルート128.9.0.0/16は、AS1から受け入れられ、AS3から（ない128.9.0.0/16）AS226によって発信がAS2から受け付けされる任意の他のルートを受け入れ、および他のASの経路として、FOOにされます。
We can come to the same conclusion using the algebra defined above. Consider the inner exception specification:
私たちは、上記で定義された代数を使用して、同じ結論に来ることができます。内部例外仕様を検討してください。
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}
is equivalent to
に相当します
{
from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
}
Hence, the original expression is equivalent to:
したがって、元の式は、と等価です。
import: from AS1 action pref = 1; accept as-foo;
except {
from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
}
which is equivalent to
に相当します
import: {
インポート：{
from AS3 action pref = 3;
accept as-foo AND AS226 AND {128.9.0.0/16};
from AS2 action pref = 2;
accept as-foo AND AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1;
accept as-foo AND NOT
(AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16});
}
Since AS226 is in as-foo and 128.9.0.0/16 is in AS226, it simplifies to:
AS226として、FOOであり、128.9.0.0/16はAS226にあるので、に簡素化：
import: {
from AS3 action pref = 3; accept {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1; accept as-foo AND NOT AS226;
}
In the case of the refine operator, the resulting set is constructed by taking the cartasian product of the two sides as follows: for each policy l in the left hand side and for each policy r in the right hand side, the peerings of the resulting policy are the peerings common to both r and l; the filter of the resulting policy is the intersection of l's filter and r's filter; and action of the resulting policy is l's action followed by r's action. If there are no common peerings, or if the intersection of filters is empty, a resulting policy is not generated.
各ポリシーlについて左側及び右側の各ポリシーRため、ピアリングを結果として生じる：絞り込み演算子の場合には、結果セットは、以下のように両側のcartasian積をとることによって構築されますポリシーはRとLの両方に共通ピアリングです。得られたポリシーのフィルタは、Lのフィルタと、Rのフィルタの交点です。そして得られた政策のアクションは、rのアクションが続くL'sのアクションです。共通のピアリングがない場合、またはフィルタの交差が空の場合、結果のポリシーが生成されません。
Consider the following example:
次の例を考えてみます。
import: { from AS-ANY action pref = 1; accept community(3560:10);
from AS-ANY action pref = 2; accept community(3560:20);
} refine {
from AS1 accept AS1;
from AS2 accept AS2;
from AS3 accept AS3;
}
Here, any route with community 3560:10 is assigned a preference of 1 and any route with community 3560:20 is assigned a preference of 2 regardless of whom they are imported from. However, only AS1's routes are imported from AS1, and only AS2's routes are imported from AS2, and only AS3's routes are imported form AS3, and no routes are imported from any other AS. We can reach the same conclusion using the above algebra. That is, our example is equivalent to:
ここで、コミュニティ3560と任意の経路10は、1の優先度を割り当てられ、コミュニティ3560と任意の経路20にかかわらず、それらがからインポートされた人の2の優先度を割り当てられます。しかし、唯一のAS1のルートがAS1から輸入されている、とだけAS2のルートはAS2から輸入されている、とだけAS3のルートは、フォームのAS3をインポートされ、そして何のルートは、他のASから輸入されていません。私たちは、上記の代数を使用して同じ結論に達することができます。それが私たちの例では、と等価である、次のとおりです。
import: {
from AS1 action pref = 1; accept community(3560:10) AND AS1;
from AS1 action pref = 2; accept community(3560:20) AND AS1;
from AS2 action pref = 1; accept community(3560:10) AND AS2;
from AS2 action pref = 2; accept community(3560:20) AND AS2;
from AS3 action pref = 1; accept community(3560:10) AND AS3;
from AS3 action pref = 2; accept community(3560:20) AND AS3;
}
Note that the common peerings between "from AS1" and "from AS-ANY" are those peerings in "from AS1". Even though we do not formally define "common peerings", it is straight forward to deduce the definition from the definitions of peerings (please see Section 5.6).
「AS1から」との間で共通ピアリングことに注意して、「AS-ANYから」「AS1から」でそれらのピアリングしています。我々は正式に「共通ピアリング」を定義していないにもかかわらず、（セクション5.6を参照してください）ピアリングの定義から定義を推定するために簡単です。
Consider the following example:
次の例を考えてみます。
import: {
from AS-ANY action med = 0; accept {0.0.0.0/0^0-18};
} refine {
from AS1 at 7.7.7.1 action pref = 1; accept AS1;
from AS1 action pref = 2; accept AS1;
}
where only routes of length 0 to 18 are accepted and med's value is set to 0 to disable med's effect for all peerings; In addition, from AS1 only AS1's routes are imported, and AS1's routes imported at 7.7.7.1 are preferred over other peerings. This is equivalent to:
18長さ0のルートだけがの受け入れとのmedされる値は、すべてのピアリングのためのmedの効果を無効にするために0に設定されています。また、AS1からのみAS1のルートがインポートされ、そして7.7.7.1にインポートAS1のルートが他のピアリングより好ましいです。これはと同等です。
import: {
from AS1 at 7.7.7.1 action med=0; pref=1; accept {0.0.0.0/0^0-
18} AND AS1;
from AS1 action med=0; pref=2; accept {0.0.0.0/0^0-
18} AND AS1;
}
The above syntax and semantics also apply equally to structured export policies with "from" replaced with "to" and "accept" is replaced with "announce".
上記の構文とセマンティクスも「発表」に置き換えられ、「受け入れる」「する」に置き換える「から」との構造輸出政策にも同様に適用されます。
7 dictionary Class
7辞書クラス
The dictionary class provides extensibility to RPSL. Dictionary objects define routing policy attributes, types, and routing protocols. Routing policy attributes, henceforth called rp-attributes, may correspond to actual protocol attributes, such as the BGP path attributes (e.g. community, dpa, and AS-path), or they may correspond to router features (e.g. BGP route flap damping). As new protocols, new protocol attributes, or new router features are introduced, the dictionary object is updated to include appropriate rp-attribute and protocol definitions.
辞書クラスはRPSLへの拡張性を提供します。辞書オブジェクトは、ルーティングポリシー属性、タイプ、およびルーティングプロトコルを定義します。以後RP-属性と呼ばれるポリシー属性を、ルーティング、実際そのようなBGPパス属性などのプロトコル属性、（例えば、コミュニティ、DPA、およびASパス）に対応してもよく、またはそれらは、機能（例えば、BGPルートフラップダンピング）をルータに対応することができます。新しいプロトコル、新しいプロトコル属性、または新しいルータ機能が導入されると、辞書オブジェクトは適切なRP-属性やプロトコルの定義を含むように更新されます。
An rp-attribute is an abstract class; that is a data representation is not available. Instead, they are accessed through access methods. For example, the rp-attribute for the BGP AS-path attribute is called aspath; and it has an access method called prepend which stuffs extra AS numbers to the AS-path attributes. Access methods can take arguments. Arguments are strongly typed. For example, the method prepend above takes AS numbers as arguments.
RP-属性は抽象クラスです。それは、データ表現が利用できないです。その代わりに、彼らはアクセスメソッドを介してアクセスされます。例えば、BGP ASパス属性のRP-属性はASPATHと呼ばれています。そして、それはASパスに数字が属性として余分に詰め込む前付加と呼ばれるアクセス方法があります。アクセス方法は、引数を取ることができます。引数は強く型付けされています。例えば、上記の先頭に追加する方法は、引数としてAS番号かかります。
Once an rp-attribute is defined in the dictionary, it can be used to describe policy filters and actions. Policy analysis tools are required to fetch the dictionary object and recognize newly defined rp-attributes, types, and protocols. The analysis tools may approximate policy analyses on rp-attributes that they do not understand: a filter method may always match, and an action method may always perform no-operation. Analysis tools may even download code to perform appropriate operations using mechanisms outside the scope of RPSL.
RP-属性が辞書に定義されると、ポリシーフィルタとアクションを記述するために使用することができます。政策分析ツールは、辞書オブジェクトを取得し、新たに定義されたRP-属性、タイプ、およびプロトコルを認識する必要があります。フィルタ法が常に一致すること、およびアクションメソッドは、常に無操作を実行しないことがあります。ポリシーを近似する解析ツールは、彼らが理解していないことをRP-属性を分析します。分析ツールもRPSLの範囲外の機構を使用して適切な動作を実行するためのコードをダウンロードすることができます。
We next describe the syntax and semantics of the dictionary class. This description is not essential for understanding dictionary objects (but it is essential for creating one). Please feel free to skip to the RPSL Initial Dictionary subsection (Section 7.1).
私たちは、次の辞書クラスの構文と意味を説明します。この説明は、辞書オブジェクトを理解するために必須ではない（が、それは1を作成するために不可欠です）。 RPSL初期辞書のサブセクション（7.1節）にスキップすること自由に感じてください。
The attributes of the dictionary class are shown in Figure 24. The dictionary attribute is the name of the dictionary object, obeying the RPSL naming rules. There can be many dictionary objects, however there is always one well-known dictionary object "RPSL". All tools use this dictionary by default.
辞書クラスの属性は、辞書の属性は、命名規則に従うRPSL、辞書オブジェクトの名前である図24に示されています。しかし、常に1つのよく知られた辞書オブジェクト「RPSL」があり、多くの辞書オブジェクトが存在する場合があります。すべてのツールは、デフォルトでは、この辞書を使用しています。
Attribute Value Type dictionary <object-name> mandatory, single-valued, class key rp-attribute see description in text optional, multi valued typedef see description in text optional, multi valued protocol see description in text optional, multi valued
値タイプ辞書を<オブジェクト名>は、単一値、クラスキーRP-属性はオプションのテキストでの説明を参照のtypedef大切テキストオプション、マルチでの説明を必須参照、多値プロトコルはテキストで、オプションの説明を参照してください属性、multiが大切
Figure 24: dictionary Class Attributes
図24：Dictionaryクラスの属性
The rp-attribute attribute has the following syntax:
RP-属性属性の構文は次のとおりです。
rp-attribute: <name> <method-1>(<type-1-1>, ..., <type-1-N1> [, "..."]) ... <method-M>(<type-M-1>, ..., <type-M-NM> [, "..."])
RP-属性：<名前> <方法1>（<タイプ1-1>、...、<タイプ1-N1> [、 "..."]）... <メソッドM>（ <型M-1>、...、<タイプM-NM> [、 "..."]）
where <name> is the name of the rp-attribute; and <method-i> is the name of an access method for the rp-attribute, taking Ni arguments where the j-th argument is of type <type-i-j>. A method name is either an RPSL name or one of the operators defined in Figure 25. The operator methods with the exception of operator() and operator[] can take only one argument.
ここで、<name>は、RP-属性の名前です。そして、<方法-I> j番目の引数はタイプ<タイプ-I-J>であるニッケルの引数を取るRP-属性に対するアクセス方法、の名前です。メソッド名はRPSL名またはオペレータを除くオペレータメソッド（）は、オペレータが[]だけ一つの引数を取ることができ、図25に定義された演算子のどれかです。
operator= operator== operator<<= operator< operator>>= operator> operator+= operator>= operator-= operator<= operator*= operator!= operator/= operator() operator.= operator[]
演算子=演算子==演算子<< =演算子<演算子>> =演算子>演算子+ =演算子> = operator- =演算子<=演算子* =演算子！=演算子/ =演算子（）演算子。=演算子[]
Figure 25: Operators
図25：演算子
An rp-attribute can have many methods defined for it. Some of the methods may even have the same name, in which case their arguments are of different types. If the argument list is followed by "...", the method takes a variable number of arguments. In this case, the actual arguments after the Nth argument are of type <type-N>.
RP-属性は、それのために定義された多くのメソッドを持つことができます。方法の一部では、その引数のタイプが異なる。その場合には、同じ名前を持つことがあります。引数リストは、「...」が続いている場合は、この方法は、可変数の引数を取ります。この場合、N番目の引数の後に実際の引数は<タイプ-N>型です。
Arguments are strongly typed. A <type> in RPSL is either a predefined type, a union type, a list type, or a dictionary defined type. The predefined types are listed in Figure 26.
引数は強く型付けされています。 RPSLで<type>は事前に定義されたタイプ、組合型、リスト型、または辞書定義された型のいずれかです。事前定義されたタイプが図26に記載されています。
integer[lower, upper] ipv4_address real[lower, upper] address_prefix enum[name, name, ...] address_prefix_range string dns_name boolean filter rpsl_word as_set_name free_text route_set_name email rtr_set_name as_number filter_set_name peering_set_name
整数[上下] ipv4_address [、上下]本物のaddress_prefix列挙[名、名前、...] address_prefix_range列DNS_NAMEブールフィルタrpsl_word as_set_name free_text route_set_nameメールrtr_set_name as_number filter_set_name peering_set_name
Figure 26: Predefined Types
図26：定義済みの型
The integer and the real predefined types can be followed by a lower and an upper bound to specify the set of valid values of the argument. The range specification is optional. We use the ANSI C language conventions for representing integer, real and string values. The enum type is followed by a list of RPSL names which are the valid values of the type. The boolean type can take the values true or false. as_number, ipv4_address, address_prefix and dns_name types are as in Section 2. filter type is a policy filter as in Section 6. The value of filter type is suggested to be enclosed in parenthesis.
整数と実数予め定義されたタイプは、引数の有効な値のセットを指定する下限と上限によって追跡することができます。範囲指定は任意です。私たちは、整数、実数、文字列の値を表現するためのANSI C言語の表記規則を使用します。列挙型は、タイプの有効な値ですRPSL名のリストが続いています。 boolean型は、真または偽の値を取ることができます。 as_number、ipv4_address、address_prefixおよびDNS_NAMEタイプは、セクション2フィルタタイプのようであるフィルタタイプの値を括弧で囲むことが示唆されている第6のようにポリシー・フィルタです。
The syntax of a union type is as follows:
次のようにユニオン型の構文は次のとおりです。
union <type-1>, ... , <type-N>
労働組合の<type-1>、...、<タイプ-N>
where <type-i> is an RPSL type. The union type is either of the types <type-1> through <type-N> (analogous to unions in C[14]).
ここで、<I型> RPSLタイプです。ユニオン型が<タイプ1> <タイプ-N>スルータイプのいずれかである（Cで組合に類似する[14]）。
The syntax of a list type is as follows:
次のようにリスト型の構文は次のとおりです。
list [<min_elems>:<max_elems>] of <type>
リスト[<min_elems>：<max_elems>]の<タイプ>
In this case, the list elements are of <type> and the list contains at least <min_elems> and at most <max_elems> elements. The size specification is optional. If it is not specified, there is no restriction in the number of list elements. A value of a list type is represented as a sequence of elements separated by the character "," and enclosed by the characters "{" and "}".
この場合、リストの要素は、<タイプ>のものであり、リストは、少なくとも<min_elems>と最も<max_elems>要素に含まれています。サイズ指定は任意です。それが指定されていない場合は、リスト要素の数の制限はありません。リスト・タイプの値は「」文字で区切られた要素のシーケンスとして表され、文字 『{』および 『}』で囲まれています。
The typedef attribute in the dictionary defines named types as follows:
次のように辞書でのtypedef属性は、名前付きの型を定義します。
typedef: <name> <type>
typedef：<名前> <タイプ>
where <name> is a name for type <type>. typedef attribute is paticularly useful when the type defined is not a predefined type (e.g. list of unions, list of lists, etc.).
ここで、<名前>はタイプ<タイプ>の名前です。定義されたタイプが所定のタイプ（組合の例えばリスト、リストのリスト、等）がない場合のtypedef属性はpaticularly有用です。
A protocol attribute of the dictionary class defines a protocol and a set of peering parameters for that protocol (which are used in inet-rtr class in Section 9). Its syntax is as follows:
辞書のクラスのプロトコル属性は、プロトコルと（セクション9にINET-RTRクラスで使用されている）、そのプロトコルのパラメータをピアリングのセットを定義します。構文は次のとおりです。
protocol: <name> MANDATORY | OPTIONAL <parameter-1>(<type-1-1>,..., <type-1-N1> [,"..."]) ... MANDATORY | OPTIONAL <parameter-M>(<type-M-1>,..., <type-M-NM> [,"..."])
プロトコル：<名前> MANDATORY |オプションの<パラメータ1>（<タイプ-1-1>、...、<タイプ-1-N1> [、 "..."]）... MANDATORY |オプションの<パラメータM>（<タイプM-1>、...、<タイプM-NM> [、 "..."]）
where <name> is the name of the protocol; MANDATORY and OPTIONAL are keywords; and <parameter-i> is a peering parameter for this protocol, taking Ni many arguments. The syntax and semantics of the arguments are as in the rp-attribute. If the keyword MANDATORY is used, the parameter is mandatory and needs to be specified for each peering of this protocol. If the keyword OPTIONAL is used, the parameter can be skipped.
ここで、<名前>は、プロトコルの名前です。必須およびオプションのキーワードです。そして、<パラメータ-I>ニッケル多くの引数を取って、このプロトコルのピアリングパラメータです。引数の構文とセマンティクスは、RP-属性のようにしています。 MANDATORYキーワードを使用する場合、パラメータは必須であり、このプロトコルの各ピアリングのために指定する必要があります。キーワードオプションを使用する場合は、パラメータを省略することができます。
dictionary: RPSL
rp-attribute: # preference, smaller values represent higher preferences
pref
operator=(integer[0, 65535])
rp-attribute: # BGP multi_exit_discriminator attribute
med
# to set med to 10: med = 10;
# to set med to the IGP metric: med = igp_cost;
operator=(union integer[0, 65535], enum[igp_cost])
rp-attribute: # BGP destination preference attribute (dpa)
dpa
operator=(integer[0, 65535])
rp-attribute: # BGP aspath attribute
aspath
# prepends AS numbers from last to first order
prepend(as_number, ...)
typedef: # a community value in RPSL is either
# - a 4 byte integer (ok to use 3561:70 notation)
# - internet, no_export, no_advertise (see RFC-1997)
community_elm union
integer[1, 4294967295],
enum[internet, no_export, no_advertise],
typedef: # list of community values { 40, no_export, 3561:70 }
community_list list of community_elm
rp-attribute: # BGP community attribute
community
# set to a list of communities
operator=(community_list)
# append community values
operator.=(community_list)
append(community_elm, ...)
# delete community values
delete(community_elm, ...)
# a filter: true if one of community values is contained
contains(community_elm, ...)
# shortcut to contains: community(no_export, 3561:70)
operator()(community_elm, ...)
# order independent equality comparison
operator==(community_list)
rp-attribute: # next hop router in a static route
next-hop
# to set to 7.7.7.7: next-hop = 7.7.7.7;
# to set to router's own address: next-hop = self; operator=(union ipv4_address, enum[self]) rp-attribute: # cost of a static route cost operator=(integer[0, 65535]) protocol: BGP4 # as number of the peer router MANDATORY asno(as_number) # enable flap damping OPTIONAL flap_damp() OPTIONAL flap_damp(integer[0,65535], # penalty per flap integer[0,65535], # penalty value for supression integer[0,65535], # penalty value for reuse integer[0,65535], # halflife in secs when up integer[0,65535], # halflife in secs when down integer[0,65535]) # maximum penalty protocol: OSPF protocol: RIP protocol: IGRP protocol: IS-IS protocol: STATIC protocol: RIPng protocol: DVMRP protocol: PIM-DM protocol: PIM-SM protocol: CBT protocol: MOSPF
ルータ自身のアドレスに設定する＃：ネクストホップ=自己;演算子=（ユニオンipv4_address、列挙[自己]）RP-属性：静的ルートコスト演算子=（整数[0、65535]）の＃コストプロトコル：BGP4位ピアルータ強制asno（as_number）＃の数がフラップを可能としてOPTIONAL flap_damp（）OPTIONAL flap_damp（整数[0から65535]、フラップ整数[0から65535]、抑圧整数[0から65535]のため＃ペナルティ値、再使用整数ため＃ペナルティ値[0から65535]あたり＃ペナルティ減衰、秒位半減期とき最大整数[0から65535]、ダウン整数[0から65535]）＃最大ペナルティプロトコル秒位の半減期：OSPFプロトコル：RIPプロトコル：IGRPプロトコル：プロトコルは、IS-IS：STATICプロトコル：RIPngプロトコル：DVMRPプロトコル：PIM-DMプロトコル：PIM-SMプロトコル：CBTプロトコル：MOSPF
Figure 27: RPSL Dictionary
図27：RPSL辞書
Figure 27 shows the initial RPSL dictionary. It has seven rp-
attributes: pref to assign local preference to the routes accepted;
med to assign a value to the MULTI_EXIT_DISCRIMINATOR BGP attribute;
dpa to assign a value to the DPA BGP attribute; aspath to prepend a
value to the AS_PATH BGP attribute; community to assign a value to or
to check the value of the community BGP attribute; next-hop to assign
next hop routers to static routes; and cost to assign a cost to
static routes. The dictionary defines two types: community_elm and
community_list. community_elm type is either a 4-byte unsigned
integer, or one of the keywords internet, no_export or no_advertise
(defined in [9]). An integer can be specified using two 2-byte
integers seperated by ":" to partition the community number space so that a provider can use its AS number as the first two bytes, and assigns a semantics of its choice to the last two bytes.
「：」で区切られた整数は、プロバイダが、最初の2つのバイトとしてのAS番号を使用できるようにコミュニティ番号空間を分割し、最後の2バイトにその選択肢の意味を割り当てます。
The initial dictionary (Figure 27) defines only options for the Border Gateway Protocol: asno and flap_damp. The mandatory asno option is the AS number of the peer router. The optional flap_damp option instructs the router to damp route flaps [21] when importing routes from the peer router.
asnoとflap_damp：初期辞書（図27）は、ボーダーゲートウェイプロトコルのための唯一のオプションを定義します。必須asnoオプションは、ピアルータのAS番号です。任意flap_dampオプションは、ピアルータからのルートをインポートするとき、ルートフラップ[21]を減衰するようにルータに指示します。
It can be specified with or without parameters. If parameters are missing, they default to:
これは、またはパラメータなしで指定することができます。パラメータが含まれていない場合、彼らはにデフォルト設定します：
flap_damp(1000, 2000, 750, 900, 900, 20000)
flap_damp（1000年、2000年、750、900、900、20000）
That is, a penalty of 1000 is assigned at each route flap, the route is suppressed when penalty reaches 2000. The penalty is reduced in half after 15 minutes (900 seconds) of stability regardless of whether the route is up or down. A supressed route is reused when the penalty falls below 750. The maximum penalty a route can be assigned is 20,000 (i.e. the maximum suppress time after a route becomes stable is about 75 minutes). These parameters are consistent with the default flap damping parameters in several routers.
すなわち、ペナルティがペナルティにかかわらず、ルートがアップまたはダウンしているか否かの安定性の15分（900秒）の後半分に低減され、2000年に達したときの経路が抑制され、1000のペナルティーは、各ルートフラップに割り当てられています。 supressed経路はペナルティが750を下回った場合に経路を割り当てることができる最大ペナルティ（すなわち、ルートが安定した後に最大抑制時間は約75分）20,000再利用されます。これらのパラメータは、デフォルトのフラップが、いくつかのルータでパラメータをダンピングと一致しています。
Policy Actions and Filters Using RP-Attributes
RP-属性を使用したポリシーアクションとフィルタ
The syntax of a policy action or a filter using an rp-attribute x is as follows:
次のようにRP-属性Xを使用して、ポリシーアクションまたはフィルタの構文は次のとおりです。
x.method(arguments) x "op" argument
x.method（引数）× "OP" の引数
where method is a method and "op" is an operator method of the rp-attribute x. If an operator method is used in specifying a composite policy filter, it evaluates earlier than the composite policy filter operators (i.e. AND, OR, NOT, and implicit or operator).
この方法は、方法であり、「OP」は、RP-属性xのオペレータ方法です。オペレータ法は複合ポリシフィルタを指定する際に使用される場合、それは（すなわちAND、OR、NOT、および暗黙的またはオペレータ）複合ポリシフィルタ演算子よりも前に評価します。
The pref rp-attribute can be assigned a positive integer as follows:
次のように県RP-属性は、正の整数を割り当てることができます。
pref = 10;
県= 10。
The med rp-attribute can be assigned either a positive integer or the word "igp_cost" as follows:
次のようにmedがRP-属性は、正の整数またはワード「igp_cost」のいずれかを割り当てることができます。
med = 0;
med = igp_cost;
The dpa rp-attribute can be assigned a positive integer as follows: dpa = 100;
次のようにDPAのRP-属性は、正の整数を割り当てることができる：DPA = 100。
The BGP community attribute is list-valued, that is it is a list of 4-byte integers each representing a "community". The following examples demonstrate how to add communities to this rp-attribute:
BGPコミュニティ属性がリスト値である、それはそれは4バイトの整数「コミュニティ」を表すそれぞれのリストです。次の例では、このRP-属性にコミュニティを追加する方法を示します。
community .= { 100 };
community .= { NO_EXPORT };
community .= { 3561:10 };
In the last case, a 4-byte integer is constructed where the more significant two bytes equal 3561 and the less significant two bytes equal 10. The following examples demonstrate how to delete communities from the community rp-attribute:
より上位2つのバイトが3561に等しいと下位2つのバイトが10以下の実施例は、コミュニティRP-属性からコミュニティを削除する方法を示し等しい場合、最後の場合には、4バイトの整数が構築されます。
community.delete(100, NO_EXPORT, 3561:10);
community.delete（100、NO_EXPORT、3561：10）。
Filters that use the community rp-attribute can be defined as demonstrated by the following examples:
コミュニティRP-属性を使用するフィルタは、次の例により実証されるように定義することができます。
community.contains(100, NO_EXPORT, 3561:10); community(100, NO_EXPORT, 3561:10); # shortcut
community.contains（100、NO_EXPORT、3561：10）。コミュニティ（100、NO_EXPORT、3561：10）。 ＃ショートカット
The community rp-attribute can be set to a list of communities as follows:
次のようにコミュニティRP-属性は、コミュニティのリストに設定することができます。
community = {100, NO_EXPORT, 3561:10, 200};
community = {};
In this first case, the community rp-attribute contains the communities 100, NO_EXPORT, 3561:10, and 200. In the latter case, the community rp-attribute is cleared. The community rp-attribute can be compared against a list of communities as follows:
この最初のケースでは、コミュニティRP-属性はコミュニティ100、NO_EXPORT、3561含まれています：10、後者の場合には200を、コミュニティRP-属性がクリアされます。次のようにコミュニティRP-属性は、コミュニティのリストと比較することができます。
community == {100, NO_EXPORT, 3561:10, 200}; # exact match
コミュニティ== {100、NO_EXPORT、3561：10、200}。 ＃ 完全に一致
To influence the route selection, the BGP as_path rp-attribute can be made longer by prepending AS numbers to it as follows:
ルート選択に影響を与えるために、BGPのASパスRP-属性は、次のようにAS番号を付加することで長くすることができます。
aspath.prepend(AS1);
aspath.prepend(AS1, AS1, AS1);
The following examples are invalid:
次の例は無効です。
med = -50; # -50 is not in the range med = igp; # igp is not one of the enum values med.assign(10); # method assign is not defined community.append(AS3561:20); # the first argument should be 3561
MED = -50; ＃-50範囲のmed = IGPではありません。 ＃のIGPはmed.assign enum値（10）のいずれでもありません。 ＃方法アサインはcommunity.append（AS3561：20）で定義されていません。 ＃最初の引数は3561でなければなりません
Figure 28 shows a more advanced example using the rp-attribute community. In this example, AS3561 bases its route selection preference on the community attribute. Other ASes may indirectly affect AS3561's route selection by including the appropriate communities in their route announcements.
図28は、RP-属性のコミュニティを使用して、より高度な例を示します。この例では、AS3561は、コミュニティ属性にその経路選択嗜好に基づか。他のASは、間接的にそのルートのアナウンスに適切なコミュニティを含めることにより、AS3561のルート選択に影響を与える可能性があります。
aut-num: AS1
export: to AS2 action community.={3561:90};
to AS3 action community.={3561:80};
announce AS1
as-set: AS3561:AS-PEERS members: AS2, AS3
セット：AS3561：ASピアメンバー：AS2、AS3
aut-num: AS3561
import: from AS3561:AS-PEERS
action pref = 10;
accept community(3561:90)
import: from AS3561:AS-PEERS
action pref = 20;
accept community(3561:80)
import: from AS3561:AS-PEERS
action pref = 20;
accept community(3561:70)
import: from AS3561:AS-PEERS
action pref = 0;
accept ANY
Figure 28: Policy example using the community rp-attribute.
図28：コミュニティRP-属性を使用してポリシーの例。
8 Advanced route Class
8つの高度なルートクラス
The components, aggr-bndry, aggr-mtd, export-comps, inject, and holes attributes are used for specifying aggregate routes [11]. A route object specifies an aggregate route if any of these attributes, with the exception of inject, is specified. The origin attribute for an aggregate route is the AS performing the aggregation, i.e. the aggregator AS. In this section, we used the term "aggregate" to refer to the route generated, the term "component" to refer to the routes used to generate the path attributes of the aggregate, and the term "more specifics" to refer to any route which is a more specific of the aggregate regardless of whether it was used to form the path attributes.
MTD AGGR-AGGR-BNDRY成分、輸出コンプ、注入、及び孔属性が[11]集約ルートを指定するために使用されます。ルートオブジェクトは、注入を除いて、指定された、これらの属性のいずれかの集約ルートを指定します。集約経路の起点属性は、ASすなわちアグリゲータ、アグリゲーションを行うようになります。このセクションでは、我々は、ルートを指すために用語「凝集体」を使用する、任意の経路を指すために、集約のパス属性を生成するために使用される経路、および用語「より詳細」を参照するように、用語「コンポーネント」を生成しましたこれにかかわらず、それはパス属性を形成するために使用されたかどうかの凝集体のより特異的です。
The components attribute defines what component routes are used to form the aggregate. Its syntax is as follows:
コンポーネントは、コンポーネントルートが凝集体を形成するために使用されるものを定義する属性。構文は次のとおりです。
components: [ATOMIC] [[<filter>] [protocol <protocol> <filter> ...]]
成分：[ATOMIC] [[<フィルター>] [プロトコル<プロトコル> <フィルター> ...]]
where <protocol> is a routing protocol name such as BGP4, OSPF or RIP (valid names are defined in the dictionary) and <filter> is a policy expression. The routes that match one of these filters and are learned from the corresponding protocol are used to form the aggregate. If <protocol> is omitted, it defaults to any protocol. <filter> implicitly contains an "AND" term with the more specifics of the aggregate so that only the component routes are selected. If the keyword ATOMIC is used, the aggregation is done atomically [11]. If a <filter> is not specified it defaults to more specifics. If the components attribute is missing, all more specifics without the ATOMIC keyword is used.
ここで、<プロトコル>は、このようなBGP4、OSPFまたはRIP（有効な名前が辞書に定義されている）と<フィルター>のようなルーティングプロトコル名ポリシー表現です。これらのフィルタのいずれかと一致し、対応するプロトコルから学習された経路は凝集体を形成するために使用されます。任意のプロトコルへの<プロトコル>が省略された場合、デフォルト。成分のみルートが選択されるように、<フィルター>は暗黙的に凝集体のより詳細と「AND」という用語を含んでいます。キーワードATOMICが使用される場合、凝集はアトミック[11]に行われます。 <フィルタ>場合は、より具体的にそれをデフォルトに指定されていません。コンポーネントが欠落している属性の場合は、ATOMICキーワードなしですべてのより多くの詳細が使用されています。
route: 128.8.0.0/15 origin: AS1 components: <^AS2>
ルート：128.8.0.0/15原産地：AS1コンポーネント：<^ AS2>
route: 128.8.0.0/15 origin: AS1 components: protocol BGP4 {128.8.0.0/16^+} protocol OSPF {128.9.0.0/16^+}
ルート：128.8.0.0/15起源：AS1成分：プロトコルBGP4 {128.8.0.0/16^+}プロトコルOSPF {128.9.0.0/16^+}
Figure 29: Two aggregate route objects.
図29：二つの集約ルートオブジェクト。
Figure 29 shows two route objects. In the first example, more specifics of 128.8.0.0/15 with AS paths starting with AS2 are aggregated. In the second example, some routes learned from BGP and some routes learned form OSPF are aggregated.
図29は、2つのルートオブジェクトを示しています。最初の例では、AS2始まるASパスと128.8.0.0/15のより詳細は、集約されます。第2の例では、いくつかのルートがBGPから学習し、いくつかのルートは、フォームOSPFが凝集している学びました。
The aggr-bndry attribute is an AS expression over AS numbers and sets (see Section 5.6). The result defines the set of ASes which form the aggregation boundary. If the aggr-bndry attribute is missing, the origin AS is the sole aggregation boundary. Outside the aggregation boundary, only the aggregate is exported and more specifics are suppressed. However, within the boundary, the more specifics are also exchanged.
AGGR-BNDRY属性がある数字とセット（5.6節を参照）AS過剰発現AS。結果は、集約境界を形成するのASのセットを定義します。 AGGR-BNDRY属性が欠落している場合は、AS起源は唯一の集約境界です。集約境界の外では、唯一の集合体が輸出され、より具体的には抑制されています。しかし、境界内に、より具体的には、も交換されます。
The aggr-mtd attribute specifies how the aggregate is generated. Its syntax is as follows:
AGGR-MTD属性は、集合体が生成される方法を指定します。構文は次のとおりです。
aggr-mtd: inbound | outbound [<as-expression>]
AGGR-MTD：インバウンド| [<AS-式>]アウトバウンド
where <as-expression> is an expression over AS numbers and sets (see Section 5.6). If <as-expression> is missing, it defaults to AS-ANY. If outbound aggregation is specified, the more specifics of the aggregate will be present within the AS and the aggregate will be formed at all inter-AS boundaries with ASes in <as-expression> before export, except for ASes that are within the aggregating boundary (i.e. aggr-bndry is enforced regardless of <as-expression>). If inbound aggregation is specified, the aggregate is formed at all inter-AS boundaries prior to importing routes into the aggregator AS. Note that <as-expression> can not be specified with inbound aggregation. If aggr-mtd attribute is missing, it defaults to "outbound AS-ANY".
ここで<として発現>番号とセットAS過剰発現（セクション5.6を参照）です。 <として-expression>は欠落している場合はAS-ANYがデフォルト。アウトバウンド集計が指定されている場合は、集約のより具体的には、AS内に存在することになると骨材が凝集境界内にあるのASを除き、輸出前に、<など-式>でのASを持つすべてのAS間の境界で形成されることになります（すなわちAGGR-BNDRYにかかわらず、<として表現>の強制されます）。インバウンド集合を指定した場合、凝集体は、ASアグリゲータにルートをインポートする前に、すべてのAS間の境界に形成されています。 <として表現>インバウンド凝集に指定することはできないことに注意してください。 「AS-ANYアウトバウンド」にAGGR-MTD属性が欠落している場合は、デフォルト。
route: 128.8.0.0/15 route: 128.8.0.0/15 origin: AS1 origin: AS2 components: {128.8.0.0/15^-} components: {128.8.0.0/15^-} aggr-bndry: AS1 OR AS2 aggr-bndry: AS1 OR AS2 aggr-mtd: outbound AS-ANY aggr-mtd: outbound AS-ANY
ルート：128.8.0.0/15経路：128.8.0.0/15起源：AS1起源：AS2コンポーネント：{128.8.0.0/15^-}コンポーネント：{128.8.0.0/15^-} AGGR-BNDRY：AS1 OR AS2 AGGR -bndry：AS1 OR AS2 AGGR-MTD：アウトバウンドAS-ANY AGGR-MTD：アウトバウンドAS-ANY
Figure 30: Outbound multi-AS aggregation example.
図30：アウトバウンドマルチAS集約例。
Figure 30 shows an example of an outbound aggregation. In this example, AS1 and AS2 are coordinating aggregation and announcing only the less specific 128.8.0.0/15 to outside world, but exchanging more specifics between each other. This form of aggregation is useful when some of the components are within AS1 and some are within AS2.
図30は、アウトバウンド集合の一例を示しています。この例では、AS1とAS2は、凝集を調整し、外の世界に128.8.0.0/15だけ少なく特定の発表が、互いの間でより多くの詳細を交換しています。構成要素のいくつかはAS1内にあり、いくつかは、AS2内にある場合、凝集のこの形式は、有用です。
When a set of routes are aggregated, the intent is to export only the aggregate route and suppress exporting of the more specifics outside the aggregation boundary. However, to satisfy certain policy and topology constraints (e.g. a multi-homed component), it is often required to export some of the components. The export-comps attribute equals an RPSL filter that matches the more specifics that need to be exported outside the aggregation boundary. If this attribute is missing, more specifics are not exported outside the aggregation boundary. Note that, the export-comps filter contains an implicit "AND" term with the more specifics of the aggregate.
ルートのセットが集約される場合、目的は、集約ルートをエクスポートし、集約境界の外側、より詳細の輸出抑制することです。しかし、特定のポリシーおよびトポロジの制約（例えばマルチホーム成分）を満足するためには、多くの場合、構成要素の一部をエクスポートする必要があります。輸出コンプ属性が集約境界の外に輸出する必要があり、より具体的に一致するRPSLフィルタに等しいです。この属性が欠落している場合は、より具体的には、集約境界の外に輸出されていません。なお、輸出コンプフィルタは、骨材のより具体的で、暗黙の「AND」という用語が含まれています。
Figure 31 shows an example of an outbound aggregation. In this example, the more specific 128.8.8.0/24 is exported outside AS1 in addition to the aggregate. This is useful, when 128.8.8.0/24 is multi-homed site to AS1 with some other AS.
図31は、アウトバウンド集合の一例を示しています。この例では、より具体的128.8.8.0/24を集計に加えて、AS1外に輸出されます。 128.8.8.0/24は、いくつかの他のASとAS1するマルチホームサイトがある場合に、便利です。
route: 128.8.0.0/15 origin: AS1 components: {128.8.0.0/15^-} aggr-mtd: outbound AS-ANY export-comps: {128.8.8.0/24}
ルート：128.8.0.0/15起源：AS1成分：{128.8.0.0/15^-} AGGR-MTD：AS-ANY輸出コンプアウトバウンド：{} 128.8.8.0/24
Figure 31: Outbound aggregation with export exception.
図31：輸出を除いて、アウトバウンド集約。
The inject attribute specifies which routers perform the aggregation and when they perform it. Its syntax is as follow:
ジェクト属性が、彼らはそれを実行したときに集計を実行しているルータを指定します。その構文は以下の通りです：
inject: [at <router-expression>] ... [action <action>] [upon <condition>]
ジェクト：[にて<ルータ-式>] ... [アクション<アクション>] [時に<条件>]
where <action> is an action specification (see Section 6.1.1), <condition> is a boolean expression described below, and <router-expression> is as described in Section 5.6.
5.6節で説明したようにここで（セクション6.1.1を参照）アクション仕様である<作用>は、<条件>以下に説明するブール式であり、そして<ルータ式>です。
All routers in <router-expression> and in the aggregator AS perform the aggregation. If a <router-expression> is not specified, all routers inside the aggregator AS perform the aggregation. The <action> specification may set path attributes of the aggregate, such as assign a preferences to the aggregate.
<ルータ-式>やアグリゲータでASのすべてのルータは、集約を行います。 <ルータ-式>が指定されていない場合は、アグリゲータ内のすべてのルータがAS集約を行います。 <作用>仕様は、このような凝集体に嗜好を割り当てるとして集約のパス属性を設定してもよいです。
The upon clause is a boolean condition. The aggregate is generated if and only if this condition is true. <condition> is a boolean expression using the logical operators AND and OR (i.e. operator NOT is not allowed) over:
句の際にブール条件です。この条件が真である場合にだけ、集約が生成されます。 <条件>は、論理演算子ANDとOR（すなわち、オペレータが許可されていないNOT）上を使用してブール式です：
HAVE-COMPONENTS { list of prefixes } EXCLUDE { list of prefixes } STATIC
HAVE-COMPONENTS {プレフィックスのリスト} STATIC {プレフィックスのリストを} EXCLUDE
The list of prefixes in HAVE-COMPONENTS can only be more specifics of the aggregate. It evaluates to true when all the prefixes listed are present in the routing table of the aggregating router. The list can also include prefix ranges (i.e. using operators ^-, ^+, ^n, and ^n-m). In this case, at least one prefix from each prefix range needs to be present in the routing table for the condition to be true. The list of prefixes in EXCLUDE can be arbitrary. It evaluates to true when none of the prefixes listed is present in the routing table. The list can also include prefix ranges, and no prefix in that range should be present in the routing table. The keyword static always evaluates to true. If no upon clause is specified the aggregate is generated if an only if there is a component in the routing table (i.e. a more specific that matches the filter in the components attribute).
HAVE-COMPONENTSにおけるプレフィックスのリストには、骨材のより具体的することができます。記載されているすべてのプレフィックスが集約ルータのルーティングテーブルに存在する場合には、真と評価します。リストはまた、（ - N、^ +、^、および^ N-M即ち^演算子を使用して）接頭辞の範囲を含むことができます。この場合、各プレフィックス範囲からの少なくとも一つの接頭辞は、条件が真であるために、ルーティングテーブル内に存在する必要があります。 EXCLUDEにおける接頭辞のリストは任意とすることができます。列挙されたプレフィックスのいずれも、ルーティングテーブルに存在しないときに真と評価します。リストには、プレフィックス範囲を含むことができ、その範囲には接頭辞は、ルーティングテーブル中に存在してはなりません。キーワード静的は常にtrueに評価されます。句には何が指定されている場合は、ルーティングテーブル内のコンポーネント（構成要素におけるフィルタ属性と一致する、すなわち、より具体的な）がある場合、集約は、場合にのみ生成されません。
route: 128.8.0.0/15
origin: AS1
components: {128.8.0.0/15^-}
aggr-mtd: outbound AS-ANY
inject: at 1.1.1.1 action dpa = 100;
inject: at 1.1.1.2 action dpa = 110;
route: 128.8.0.0/15 origin: AS1 components: {128.8.0.0/15^-} aggr-mtd: outbound AS-ANY inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16} holes: 128.8.8.0/24
ルート：128.8.0.0/15起源：AS1成分：{128.8.0.0/15^-} AGGR-MTD：アウトバウンドAS-ANY注入：HAVE-COMPONENTS {128.8.0.0/16、128.9.0.0/16}穴時： 128.8.8.0/24
Figure 32: Examples of inject.
図32：注入の例。
Figure 32 shows two examples. In the first case, the aggregate is injected at two routers each one setting the dpa path attribute differently. In the second case, the aggregate is generated only if both 128.8.0.0/16 and 128.9.0.0/16 are present in the routing table, as opposed to the first case where the presence of just one of them is sufficient for injection.
図32は、2つの例を示しています。最初のケースでは、凝集体は、二つのルータ異なるDPAパス属性を設定それぞれに注入されます。後者の場合、骨材は、単にそれらの一方の存在が注射のために十分である第一のケースとは対照的に128.8.0.0/16と128.9.0.0/16の両方が、ルーティングテーブルに存在する場合にのみ生成されます。
The holes attribute lists the component address prefixes which are not reachable through the aggregate route (perhaps that part of the address space is unallocated). The holes attribute is useful for diagnosis purposes. In Figure 32, the second example has a hole, namely 128.8.8.0/24. This may be due to a customer changing providers and taking this part of the address space with it.
穴は、リストに集約経路（おそらくアドレス空間の一部が割り当てられていない）を介して到達可能でない成分アドレスプレフィックス属性。穴は属性診断目的に有用です。図32において、第二の例では、ホール、すなわち128.8.8.0/24を有しています。これは、顧客のプロバイダを変更し、それをアドレス空間のこの部分を取るに起因する可能性があります。
An aggregate formed is announced to other ASes only if the export policies of the AS allows exporting the aggregate. When the aggregate is formed, the more specifics are suppressed from being exported except to the ASes in aggr-bndry and except the components in export-comps. For such exceptions to happen, the export policies of the AS should explicitly allow exporting of these exceptions.
ASの輸出政策は集計をエクスポートすることができます場合にのみ形成され、集約は、他のASに発表されます。凝集体が形成されると、より具体的にはAGGR-BNDRYおよび輸出コンプ中の成分以外のASを除いてエクスポートされることが抑制されます。そのような例外が発生するために、ASの輸出政策は、明示的にこれらの例外のエクスポートを許可する必要があります。
If an aggregate is not formed (due to the upon clause), then the more specifics of the aggregate can be exported to other ASes, but only if the export policies of the AS allows it. In other words, before a route (aggregate or more specific) is exported it is filtered twice, once based on the route objects, and once based on the export policies of the AS.
集計は、（原因に応じ句に）形成されていない場合は、集計のより具体的には、他のASにエクスポートすることができますが、ASの輸出政策は、それを許可されている場合のみ。言い換えれば、ルートの前に（集約または複数の特定の）一回のルートオブジェクトに基づいて、一度ASの輸出政策に基づいて、それが二回濾過されるエクスポートされます。
route: 128.8.0.0/16 origin: AS1
ルート：128.8.0.0/16原産地：AS1
route: 128.9.0.0/16 origin: AS1
ルート：128.9.0.0/16原産地：AS1
route: 128.8.0.0/15 origin: AS1 aggr-bndry: AS1 or AS2 or AS3 aggr-mtd: outbound AS3 or AS4 or AS5 components: {128.8.0.0/16, 128.9.0.0/16} inject: upon HAVE-COMPONENTS {128.9.0.0/16, 128.8.0.0/16}
ルート：128.8.0.0/15起源：AGGR-BNDRY AS1：AS1又はAS2またはAS3のAGGR-MTD：アウトバウンドAS3またはAS4またはAS5成分：{128.8.0.0/16、128.9.0.0/16}注入：HAVE-成分に{128.9.0.0/16、128.8.0.0/16}
aut-num: AS1 export: to AS2 announce AS1 export: to AS3 announce AS1 and not {128.9.0.0/16} export: to AS4 announce AS1 export: to AS5 announce AS1 export: to AS6 announce AS1
AS2 AS1エクスポートを発表する：AUT-NUM：AS1エクスポートAS3をAS1としない{128.9.0.0/16}エクスポートを発表：AS4 AS1エクスポートを発表する：AS5 AS1エクスポートを発表する：AS6はAS1を発表します
Figure 33: Interaction with policies in aut-num class.
図33：AUT-NUMクラスの政策との相互作用。
In Figure 33 shows an interaction example. By examining the route objects, the more specifics 128.8.0.0/16 and 128.9.0.0/16 should be exchanged between AS1, AS2 and AS3 (i.e. the aggregation boundary). Outbound aggregation is done to AS4 and AS5 and not to AS3, since AS3 is in the aggregation boundary. The aut-num object allows exporting both components to AS2, but only the component 128.8.0.0/16 to AS3. The aggregate can only be formed if both components are available. In this case, only the aggregate is announced to AS4 and AS5. However, if one of the components is not available the aggregate will not be formed, and any available component or more specific will be exported to AS4 and AS5. Regardless of aggregation is performed or not, only the more specifics will be exported to AS6 (it is not listed in the aggr-mtd attribute).
図33に、相互作用の例を示します。ルートオブジェクトを調べることによって、より具体的128.8.0.0/16と128.9.0.0/16はAS1、AS2およびAS3（すなわち凝集境界）との間で交換されるべきです。 AS3が集約境界であるため、アウトバウンドの集約は、AS3にAS4とAS5としないように行われます。 AUT-NUMオブジェクトはAS2の両方のコンポーネントをエクスポートできますが、AS3の成分のみ128.8.0.0/16。両方のコンポーネントが利用可能な場合、集約にのみ形成することができます。この場合、唯一の集合体は、AS4とAS5に発表されます。成分の一つが利用可能でない場合は、凝集体が形成されず、任意の利用可能なコンポーネントまたはより具体的には、AS4およびAS5にエクスポートされます。かかわらず、凝集が行われる、または、唯一より具体的には、（それがAGGR-MTD属性に記載されていない）AS6にエクスポートされません。
When doing an inbound aggregation, configuration generators may eliminating the aggregation statements on routers where import policy of the AS prohibits importing of any more specifics.
インバウンド集約を行う場合、コンフィギュレーション・ジェネレータは、ASの輸入政策はもはや仕様の輸入を禁止しているルータの集約文を排除することがあります。
When several aggregate routes are specified and they overlap, i.e. one is less specific of the other, they must be evaluated more specific to less specific order. When an outbound aggregation is performed for a peer, the aggregate and the components listed in the export-comps attribute for that peer are available for generating the next less specific aggregate. The components that are not specified in the export-comps attribute are not available. A route is exportable to an AS if it is the least specific aggregate exportable to that AS or it is listed in the export-comps attribute of an exportable route. Note that this is a recursive definition.
いくつかの集約ルートが指定され、それらは、すなわち、一方が他方のあまり特異的であり、重複している場合、それらは、以下の特定の順序に対してより特異的に評価されなければなりません。アウトバウンド凝集がピア、骨材とそのピアの輸出コンプ属性にリストされたコンポーネントに対して実行されたときに、次の以下の特定の骨材を生成するために利用可能です。輸出コンプ属性に指定されていない部品は使用できません。ルートは、ASとエクスポート少なくとも特定の集合体であるか、エクスポートルートの輸出コンプ属性にリストされているAS場合にエクスポート可能です。これは再帰的な定義であることに注意してください。
route: 128.8.0.0/15 origin: AS1 aggr-bndry: AS1 or AS2 aggr-mtd: outbound inject: upon HAVE-COMPONENTS {128.8.0.0/16, 128.9.0.0/16}
ルート：128.8.0.0/15起源：AGGR-BNDRY AS1：AS1又はAS2のAGGR-MTD：アウトバウンド注入：HAVE-COMPONENTS {128.8.0.0/16、128.9.0.0/16}時
route: 128.10.0.0/15 origin: AS1 aggr-bndry: AS1 or AS3 aggr-mtd: outbound inject: upon HAVE-COMPONENTS {128.10.0.0/16, 128.11.0.0/16} export-comps: {128.11.0.0/16}
ルート：128.10.0.0/15起源：AS1のAGGR-BNDRY：AS1又はAS3 AGGR-MTD：アウトバウンド注入：HAVE-COMPONENTS {128.10.0.0/16、128.11.0.0/16}輸出コンプ時：{128.11.0.0/ 16}
route: 128.8.0.0/14 origin: AS1 aggr-bndry: AS1 or AS2 or AS3 aggr-mtd: outbound inject: upon HAVE-COMPONENTS {128.8.0.0/15, 128.10.0.0/15} export-comps: {128.10.0.0/15}
ルート：128.8.0.0/14起源：AS1のAGGR-BNDRY：AS1又はAS2またはAS3 AGGR-MTD：アウトバウンド注入：HAVE-成分に{128.8.0.0/15、128.10.0.0/15}輸出コンプ：{128.10。 0.0 / 15}
Figure 34: Overlapping aggregations.
図34：重複集計。
In Figure 34, AS1 together with AS2 aggregates 128.8.0.0/16 and 128.9.0.0/16 into 128.8.0.0/15. Together with AS3, AS1 aggregates 128.10.0.0/16 and 128.11.0.0/16 into 128.10.0.0/15. But altogether they aggregate these four routes into 128.8.0.0/14. Assuming all four components are available, a router in AS1 for an outside AS, say AS4, will first generate 128.8.0.0/15 and 128.10.0.0/15. This will make 128.8.0.0/15, 128.10.0.0/15 and its exception 128.11.0.0/16 available for generating 128.8.0.0/14. The router will then generate 128.8.0.0/14 from these three routes. Hence for AS4, 128.8.0.0/14 and its exception 128.10.0.0/15 and its exception 128.11.0.0/16 will be exportable.
図34に、AS2と共にAS1は128.8.0.0/15に128.8.0.0/16と128.9.0.0/16を集約します。一緒にAS3で、AS1は128.10.0.0/15に128.10.0.0/16と128.11.0.0/16を集約します。しかし、完全に彼らは128.8.0.0/14にこれら四つのルートを集約します。 4つのすべてのコンポーネントが用意されてい仮定すると、AS外のためAS1内のルータは、最初に128.8.0.0/15と128.10.0.0/15を生成します、AS4と言います。これは128.8.0.0/14を生成するための128.8.0.0/15、128.10.0.0/15とその例外が128.11.0.0/16利用できるようになります。ルータは、これらの3つのルートから128.8.0.0/14を生成します。したがってAS4、128.8.0.0/14その例外128.10.0.0/15とその例外128.11.0.0/16のためにエクスポートされます。
For AS2, a router in AS1 will only generate 128.10.0.0/15. Hence, 128.10.0.0/15 and its exception 128.11.0.0/16 will be exportable. Note that 128.8.0.0/16 and 128.9.0.0/16 are also exportable since they did not participate in an aggregate exportable to AS2.
AS2の場合、AS1のルータは128.10.0.0/15を生成します。したがって、128.10.0.0/15とその例外128.11.0.0/16がエクスポートされます。彼らはAS2にエクスポート集計に参加しなかったので、128.8.0.0/16と128.9.0.0/16もエクスポート可能であることに注意してください。
Similarly, for AS3, a router in AS1 will only generate 128.8.0.0/15. In this case 128.8.0.0/15, 128.10.0.0/16, 128.11.0.0/16 are exportable.
同様に、AS3のため、AS1にあるルータは128.8.0.0/15を生成します。この場合は128.8.0.0/15、128.10.0.0/16、128.11.0.0/16はエクスポート可能です。
The inject attribute can be used to specify static routes by using "upon static" as the condition:
注入属性は、条件として「静的時」を使用して静的ルートを指定するために使用することができます。
inject: [at <router-expression>] ... [action <action>] upon static
ジェクト：静的な時に... [アクション<アクション>] [<ルータ-式>で]
In this case, the routers in <router-expression> executes the <action> and injects the route to the interAS routing system statically. <action> may set certain route attributes such as a next-hop router or a cost.
この場合、<ルータ式>のルータは<動作>を実行し、静的システムルーティングインターアクセスへのルートを注入します。 <作用>このようなネクストホップルータやコストなどの特定のルート属性を設定してもよいです。
In the following example, the router 7.7.7.1 injects the route 128.7.0.0/16. The next-hop routers (in this example, there are two next-hop routers) for this route are 7.7.7.2 and 7.7.7.3 and the route has a cost of 10 over 7.7.7.2 and 20 over 7.7.7.3.
次の例では、ルータ7.7.7.1は、ルート128.7.0.0/16を注入します。このルートのネクストホップルータ（この例では、2つのネクストホップルータが存在する）7.7.7.2及び7.7.7.3であり、経路は7.7.7.3上7.7.7.2及び20以上10のコストを有します。
route: 128.7.0.0/16 origin: AS1 inject: at 7.7.7.1 action next-hop = 7.7.7.2; cost = 10; upon static inject: at 7.7.7.1 action next-hop = 7.7.7.3; cost = 20; upon static
ルート：128.7.0.0/16起源：AS1の注入：7.7.7.1アクション次ホップ= 7.7.7.2で。コスト= 10;静的注入時：7.7.7.1アクションの次ホップ= 7.7.7.3。コスト= 20;静的な時に
9 inet-rtr Class
9 INET-RTRクラス
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.
ルータは、INET-RTRクラスを使用して指定されています。 INET-RTRクラスの属性は、INET-RTR属性が記述ルータの有効なDNS名であり、図35に示されています。各エイリアス属性が存在する場合、ルータのための正規のDNS名です。ローカル-などの属性は、/は、このルータを運営所有しているASのAS番号を指定します。
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
属性値のタイプINET-RTR <DNS名>必須、単一値、クラスキーのエイリアス<DNS名>オプションで、ローカルとして複数値<番号は次のように>必須、必須テキストで説明を参照のifaddr単一値、テキストにおける多値ピア参照記述オプション、多値メンバーの<RTR・セット名>のリストオプション、多値
Figure 35: inet-rtr Class Attributes
図35：INET-RTRクラスの属性
The value of an ifaddr attribute has the following syntax:
ifaddr属性の値の構文は次のとおりです。
<ipv4-address> masklen <integer> [action <action>]
<IPv4のアドレス> masklen <整数>アクション<作用>]
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.
IPアドレスとマスクの長さは、各インターフェイスのために必須です。必要に応じてアクションは、このインターフェイスの他のパラメータを設定するために指定することができます。
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.
図36は、例えば、INET-RTRオブジェクトを提示します。ルータの名前は「amsterdam.ripe.net」です。 「amsterdam1.ripe.netは、」ルータの正規名です。ルータは4つのネットワークに接続されています。それらのネットワークにおけるそのIPアドレスとマスク長は、のifaddr属性で指定されています。
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()
INET-RTR：Amsterdam.ripe.net別名：amsterdam1.ripe.netローカル-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ピアツーピア：BGP4の192.87.45.195のasno（AS3334）、flap_damp（）
Figure 36: inet-rtr Objects
図36：INET-RTRオブジェクト
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>
<プロトコル> <はIPv4アドレス> <オプション> | <プロトコル> <INET-RTR-名> <オプション> | <プロトコル> <RTR-セット名> <オプション> | <プロトコル> <ピアリング・セット名> <オプション>
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.
ここで、<プロトコル>はプロトコル名で、<IPv4のアドレス>はピアルータのIPアドレスで、<オプション> <プロトコル>のオプションをピアリングのカンマ区切りリストです。代わりに相手のIPアドレスで、そのINET-RTR-名を使用することができます。可能なプロトコルの名前と属性が辞書に定義されている（第7節を参照してください）。上記の例では、ルータは、AS3334のルータ192.87.45.195とBGPピアリングを有し、このルータからのルートをインポートするときに減衰フラップをオン。
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・セット名>を用いて<ピアリング・セット名>の形式で指定することができます。 <セット名をピアリング>場合は、フォームは、このルータであり、対応するピアリングのセットで唯一のピアリングが含まれて使用されています。図37は、ピアリング基を有する例えばINET-RTRオブジェクトを示しています。
rtr-set: rtrs-ibgp-peers members: 1.1.1.1, 2.2.2.2, 3.3.3.3
RTR-セット：RTRS-IBGPピアメンバー：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
ピアリングセット：PRNG-EBGPピアはピアリング：AS3334の192.87.45.195ピアリング：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()
INET-RTR：Amsterdam.ripe.net別名：amsterdam1.ripe.netローカル-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ピアツーピア：BGP4 RTRS-IBGPピアのasno（AS3333）、flap_damp（）ピア：BGP4 PRNG-EBGPピアのasno（PeerAS）、flap_damp（）
Figure 37: inet-rtr Object with peering groups
図37：ピアリング基とINET-RTRオブジェクト
10 Extending RPSL
10の拡張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.
以前のルーティングポリシー言語およびデータ形式と経験（PRDB [2]、RIPE-81 [8]、およびRIPE-181 [7]）はRPSLは、拡張しなければならなかった教えてくれました。その結果、拡張性がRPSLのための主要な設計目標でした。既存のルーティングプロトコルへの新しいルーティングプロトコルや新機能を簡単にRPSLの辞書クラスを使用して処理することができます。既存のクラスに新しいクラスや新しい属性を追加することもできます。
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.
このセクションでは、RPSLを拡張するためのガイドラインを提供します。これらのガイドラインは、既存のツールやデータベースとの下位互換性を維持に向けた目で設計されています。私たちは、次の最低優先順位に最も好ましいからRPSLを拡張するために利用可能なオプションの一覧を表示します。
The dictionary class is the primary mechanism provided to extend RPSL. Dictionary objects define routing policy attributes, types, and routing protocols.
辞書のクラスはRPSLを拡張するために設けられた主要なメカニズムです。辞書オブジェクトは、ルーティングポリシー属性、タイプ、およびルーティングプロトコルを定義します。
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.
私たちは、新しいパス属性またはルーター機能が導入されているように、適切なRP-属性やプロトコルの定義が含まれるようにRPSL辞書を更新することをおすすめします。例えば、RPSL文書の以前のバージョンでは、ルータがピアに減衰経路フラップを実行することを指定するためにのみ可能であったが、減衰経路フラップのパラメータを指定することができませんでした。その後のパラメータは、辞書を変更することで追加されました。
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.
辞書を変更する場合は、完全な互換性が維持されるべきです。例えば、我々のフラップダンピング場合には、我々は、このレベルの詳細は、いくつかのISPによって所望されなかった場合には、オプションのパラメータ指定を行いました。また、これは、互換性を実現しました。パラメータなしで登録された任意のオブジェクトは、有効であり続けるだろう。 RPSLに基づく任意のツールは、ルーティングポリシーのデフォルトのアクションを行うことが期待されている（例えば、警告を発行し、それ以外の場合は無視する）、彼らは理解していないことを属性。したがって、パラメータを使用してフラップダンピング仕様に遭遇した時に、古いツールはパラメータを無視します。
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.
新しい属性は、任意のクラスに追加することができます。完全な互換性を確保するために、新しい属性は、それらが接続されているオブジェクトの意味論と矛盾してはなりません。それはそれは理解していない属性を無視するようにIRRを使用するすべてのツールを設計する必要があります。ほとんどの既存のツールでは、この設計原理に従います。
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.
クラスの新たな一面が発見されたときに我々は、既存のクラスに新しい属性を追加することをお勧めします。例えば、RPSLルートクラスは、集約および静的ルートの指定を有効にいくつかの新しい属性を含むことにより、そのRIPE-181前身を拡張します。
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.
新しいクラスは、ポリシー新しいタイプのデータを保存するためにRPSLに追加することができます。完全な互換性を提供することは限り既存のクラスがまだ理解されているようにまっすぐ進むです。ツールは唯一、それは理解したクラスのIRRを照会する必要がありますので、完全な互換性は、この場合に問題になることはありません。
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.
新しいクラスのオブジェクトに含まれる情報は、より良い持っているいくつかの他のクラスに属していることができれば、新しいクラスを追加する前に、人は質問すべきです。ルータの地理的位置は、IRRに格納する必要がある場合たとえば、それはと呼ばれる新しいクラスを追加するために魅力的であってもよいし、ルータの場所クラスは言います。しかし、より良い情報は、おそらく場所と呼ばれる新しい属性で、INET-RTRクラスに属します。
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.
上記の方法の全ては、所望の拡張を提供するために失敗した場合、RPSLの構文を変更する必要があるかもしれません。 RPSL構文の変更は下位互換性を提供しなければならない、との完全な互換性が達成できない場合がありますので、最後の手段としてのみ考慮されるべきです。しかし、我々は古い構文がまだ有効であることをする必要があります。
11 Security Considerations
11のセキュリティの考慮事項
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.
この文書では、RPSL、ルーティングポリシーを表現するための言語を記述しています。言語は、コントロールまたはRPSLで表さデータベースに格納されたオブジェクトを「維持」エンティティである保守（のmntnerクラス）のオブジェクトを定義します。メンテナオブジェクトの「認証」属性で定義されているメンテナからの要求は、様々な技術を用いて認証することができます。
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.
RPSLオブジェクトを通信するIRRのによって使用される正確なプロトコルは、この文書の範囲外であるが、類似または電子メールに基づいて格納するためのインタラクティブクエリ/更新プロトコルと前方プロトコルに至るまで、いくつかの技術が使用され得ることが想定（又はされでも）電話、音声通話。かかわらず、所与の状況で使用されるプロトコルの、そのようなIPSEC、TLSまたはPGP / MIMEなどの適切なセキュリティ技術が利用されることが期待されます。
12 Acknowledgements
12の謝辞
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.
私たちは、ジェシカ・ユー、ランディブッシュ、アラン・バレット、ビル・マニング、スーノウサギ、ラメシュ・ガバインダン、Kannan Varadhan、サティシュ・クマール、クレイグLabovitz、ラスティエディ、デビッドJ.リロイ、デビッド・ウィップル、ジョン・ポステル、デボラ・エストリン、エリオットに感謝したいと思いますシュワルツ、ヨアヒム・シュミッツ、マーク・プライアー、トニーPrzygienda、デビッド・ウッドゲート、ロブColtun、サンジャイWadhwa、Ardas Cilingiroglu、および様々な意見や提案のためのIETF RPSワーキンググループの参加者。
References
リファレンス
[1] Internet routing registry. procedures. http://www.ra.net/RADB.tools.docs/, http://www.ripe.net/db/doc.html.
[1]インターネット・ルーティング・レジストリ。手順。 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.
[2] NSFNETポリシールーティングデータベース（PRDB）。 MERITネットワーク株式会社、アナーバー、ミシガン州によって維持。匿名ftpでnic.merit.edu.:/nsfnet/announced.networks/nets.tag.nowから入手できる内容。
[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.
[3] Alaettinouglu、C.、ベイツ、T.、Gerich、E.、Karrenberg、D.、マイヤー、D.、テルプストラ、M.とC. Villamizer、 "ルーティングポリシー仕様言語（RPSL）"、RFC 2280、 1998年1月。
[4] C. Alaettinouglu, D. Meyer, and J. Schmitz. Application of routing policy specification language (rpsl) on the internet. Work in Progress.
[4] C. Alaettinouglu、D.マイヤー、及びJ.シュミッツ。インターネット上のポリシー仕様言語（RPSL）をルーティングの適用。進行中の作業。
[5] T. Bates. Specifying an `internet router' in the routing registry. Technical Report RIPE-122, RIPE, RIPE NCC, Amsterdam, Netherlands, October 1994.
[5] T.ベイツ。ルーティングレジストリ内の `インターネットルータ」を指定します。テクニカルレポートRIPE-122、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月。
[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.
[6] T.ベイツ、E. Gerich、L. Joncheray、J-M。 Jouanigot、D. Karrenberg、M.テルプストラ、及びJ.ゆいます。ルーティングレジストリ内のIPルーティングポリシーの表現。テクニカルレポート熟し-181、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月。
[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.
[7]ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、JM。、Karrenberg、D.、テルプストラ、M.及びJ.優、 "ルーティングレジストリにIPルーティングポリシーの表現"、RFC 1786年、1995年3月。
[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.
[8] T.ベイツ、J-M。 Jouanigot、D. Karrenberg、P. Lothberg、およびM.テルプストラ。熟したデータベース内のIPルーティングポリシーの表現。熟した-81テクニカルレポート、RIPE、RIPE NCC、アムステルダム、オランダ、1993年2月。
[9] Chandra, R., Traina, P. and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
[9]チャンドラ、R.、Trainaの、P.およびT.李、 "BGPコミュニティ属性"、RFC 1997、1996年8月。
[10] Crocker, D., "Standard for ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10]クロッカー、D.、 "標準ARPAのためのインターネットテキストメッセージ"、STD 11、RFC 822、1982年8月。
[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.
[11]フラー、V.、李、T.、ゆう、J.及びK. Varadhan、 "クラスレスドメイン間ルーティング（CIDR）：アドレス割り当ておよび集約戦略"、RFC 1519、1993年9月。
[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.
[12] D. Karrenberg及びT.ベイツ。熟したルーティングレジストリの間などのネットワークの説明。テクニカルレポートRIPE-104、RIPE、RIPE NCC、アムステルダム、オランダ、1993年12月。
[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.
[13] D. Karrenberg及びM.テルプストラ。熟したデータベースの変更の承認と通知。テクニカルレポート熟し-120、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月。
[14] B. W. Kernighan and D. M. Ritchie. The C Programming Language. Prentice-Hall, 1978.
[14] B. W.カーニハンとD. M.リッチー。 Cプログラミング言語。プレンティス・ホール、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.
[15] A.主及びM.テルプストラ。ネットワークや人のために熟したデータベーステンプレート。テクニカルレポート熟し-119、RIPE、RIPE NCC、アムステルダム、オランダ、1994年10月。
[16] A. M. R. Magee. Ripe ncc database documentation. Technical Report RIPE-157, RIPE, RIPE NCC, Amsterdam, Netherlands, May 1997.
[16] A. M. R.マギー。 RIPE NCCデータベースのマニュアルを参照してください。テクニカルレポートRIPE-157、RIPE、RIPE NCC、アムステルダム、オランダ、1997年5月。
[17] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[17] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[18] Y. Rekhter. Inter-domain routing protocol (idrp). Journal of Internetworking Research and Experience, 4:61--80, 1993.
[18] Y. Rekhter。ドメイン間ルーティングプロトコル（IDRP）。インターネットワーキングの研究と経験のジャーナル、4：61--80、1993。
[19] Rekhter Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[19] Y. RekhterおよびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[20] C. Villamizar, C. Alaettinouglu, D. Meyer, S. Murphy, and C. Orange. Routing policy system security", Work in Progress.
[20] C. Villamizar、C. Alaettinouglu、D.マイヤー、S.マーフィー、およびC.オレンジ。ルーティングポリシーシステムのセキュリティ」が進行中で働いています。
[21] Villamizar, C., Chandra, R. and R. Govindan, "BGP Route Flap Damping", RFC 2439, November 1998.
[21] Villamizar、C.、チャンドラ、R.及びR.ゴヴィンダン、 "BGPルートフラップダンピング"、RFC 2439、1998年11月。
[22] J. Zsako, "PGP authentication for ripe database updates", Work in Progress.
[22] J. Zsako、 "熟したデータベースの更新のためのPGP認証"、進行中の作業。
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.
1996年11月のようなルーティングレジストリのセットは、RADB、カネ、MCIとANS RIPEです。あなたは、レジストリの現在のリストを見つけるためにこれらのレジストリの1に接触してもよいです。
B Grammar Rules
B文法規則
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.
このセクションでは、RPSLの正式な文法規則を提供します。基本データ型は、我々は値基本タイプまたは基本タイプのリストである属性の正式な文法規則を提供していない第2節で定義されています。ルールは、GNU Bison構文解析器の入力言語を使用して書かれています。したがって、彼らはカットし、そのプログラムに貼り付けることができます。
//**** Generic Attributes **********************************************
changed_attribute: ATTR_CHANGED TKN_EMAIL TKN_INT
changed_attribute：ATTR_CHANGED TKN_EMAIL TKN_INT
//**** aut-num class ***************************************************
//// as_expression /////////////////////////////////////////////////////
//// as_expression ///////////////////////////////////////////// ////////
opt_as_expression: | as_expression
opt_as_expression：| as_expression
as_expression: as_expression OP_OR as_expression_term | as_expression_term
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_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_factor： '（' as_expression '）' | as_expression_operand
as_expression_operand: TKN_ASNO | TKN_ASNAME
as_expression_operand：TKN_ASNO | TKN_ASNAME
//// router_expression /////////////////////////////////////////////////
//// router_expression ///////////////////////////////////////////// ////
opt_router_expression: | router_expression
opt_router_expression：| router_expression
opt_router_expression_with_at: | KEYW_AT 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：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_factor： '（' router_expression '）' | router_expression_operand
router_expression_operand: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME
router_expression_operand：TKN_IPV4 | TKN_DNS | TKN_RTRSNAME
//// peering ///////////////////////////////////////////////////////////
//// /////////////////////////////////////////////ピアリング//////////////
peering: as_expression opt_router_expression opt_router_expression_with_at | TKN_PRNGNAME
ピアリング：as_expressionのopt_router_expressionのopt_router_expression_with_at | TKN_PRNGNAME
//// action ////////////////////////////////////////////////////////////
////アクション///////////////////////////////////////////// ///////////////
opt_action: | KEYW_ACTION action
opt_action：| KEYW_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 ']' ';' | ';'
アクション：single_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
フィルタ：フィルタOP_OR FILTER_TERM |フィルタFILTER_TERM％のPRECのOP_OR | FILTER_TERM
filter_term : filter_term OP_AND filter_factor | filter_factor
filter_term：filter_term OP_AND FILTER_FACTOR | FILTER_FACTOR
filter_factor : OP_NOT filter_factor | '(' filter ')' | filter_operand
FILTER_FACTOR：OP_NOTのFILTER_FACTOR | （ 'フィルター'）| 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_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 '}'
filter_prefix_operand：TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | TKN_RSNAME | '{' opt_filter_prefix_list '}'
opt_filter_prefix_list: | 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：filter_prefix_list_prefix | filter_prefix_list '' filter_prefix_list_prefix
filter_prefix_list_prefix: TKN_PRFXV4 | TKN_PRFXV4RNG
filter_prefix_list_prefix：TKN_PRFXV4 | TKN_PRFXV4RNG
filter_aspath: filter_aspath '|' filter_aspath_term | filter_aspath_term
filter_aspath：filter_aspath '|' filter_aspath_term | filter_aspath_term
filter_aspath_term: filter_aspath_term filter_aspath_closure | filter_aspath_closure
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_closure：filter_aspath_closure '*' | filter_aspath_closure '？' | filter_aspath_closure '+' | filter_aspath_factor
filter_aspath_factor: '^' | '$' | '(' filter_aspath ')' | filter_aspath_no
filter_aspath_factor： '^' | '$' | '（' filter_aspath '）' | filter_aspath_no
filter_aspath_no: TKN_ASNO | KEYW_PEERAS | TKN_ASNAME | '.' | '[' filter_aspath_range ']' | '[' '^' filter_aspath_range ']'
Philtaraaspathano：taknaeno | Keyvpirasa | Taknaasanamem | '' | '[' Philtaraaspatharange ']' | '[' ^ 'Philtaraaspatharange']」
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 ']'
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
import_peering_action_list：KEYW_FROMピアリングopt_action | import_peering_action_list KEYW_FROMピアリングopt_action
export_peering_action_list: KEYW_TO peering opt_action | export_peering_action_list KEYW_TO peering opt_action
export_peering_action_list：KEYW_TOはopt_actionをピアリング| export_peering_action_list KEYW_TOピアリングopt_action
//// import/export factor //////////////////////////////////////////////
////インポート/エクスポート要因////////////////////////////////////////// ////
import_factor: import_peering_action_list KEYW_ACCEPT filter
import_factor：import_peering_action_list KEYW_ACCEPTフィルタ
import_factor_list: import_factor ';' | import_factor_list import_factor ';'
import_factor_list：import_factor ';' | import_factor_list import_factor ';'
export_factor: export_peering_action_list KEYW_ANNOUNCE filter
export_factor：export_peering_action_list KEYW_ANNOUNCEフィルタ
export_factor_list: export_factor ';' | export_factor_list export_factor ';'
export_factor_list：export_factor ';' | export_factor_list export_factor ';'
//// import/export term ////////////////////////////////////////////////
////インポート/エクスポート用語////////////////////////////////////////// //////
import_term: import_factor ';' | '{' import_factor_list '}'
import_term：import_factor ';' | '{' import_factor_list '}'
export_term: export_factor ';' | '{' export_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
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
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
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
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
export_attribute：ATTR_EXPORT | ATTR_EXPORT opt_protocol_from opt_protocol_into export_factor
opt_default_filter: | KEYW_NETWORKS filter
opt_default_filter：| KEYW_NETWORKSフィルタ
default_attribute: ATTR_DEFAULT KEYW_TO peering
default_attribute：ATTR_DEFAULT KEYW_TOピアリング
filter_attribute: ATTR_FILTER filter
filter_attribute：ATTR_FILTERフィルタ
peering_attribute: ATTR_PEERING peering
peering_attribute：ピアリングATTR_PEERING
//**** inet-rtr class **************************************************
ifaddr_attribute: ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action
ifaddr_attribute：ATTR_IFADDR TKN_IPV4 KEYW_MASKLEN TKN_INT opt_action
//// peer attribute ////////////////////////////////////////////////////
////ピア属性//////////////////////////////////////////// ////////
opt_peer_options: | peer_options
opt_peer_options：| peer_options
peer_options: peer_option | peer_options ',' peer_option
peer_options：peer_option | peer_options '' peer_option
peer_option: tkn_word '(' generic_list ')'
peer_option：tkn_word '（' generic_list '）'
peer_id: TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME
peer_id：TKN_IPV4 | TKN_DNS | TKN_RTRSNAME | TKN_PRNGNAME
peer_attribute: ATTR_PEER tkn_word peer_id opt_peer_options
peer_attribute：ATTR_PEER tkn_word peer_id opt_peer_options
//**** route class *****************************************************
aggr_bndry_attribute: ATTR_AGGR_BNDRY as_expression
aggr_bndry_attribute：ATTR_AGGR_BNDRY as_expression
aggr_mtd_attribute: ATTR_AGGR_MTD KEYW_INBOUND | ATTR_AGGR_MTD KEYW_OUTBOUND opt_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
opt_inject_expression：| KEYW_UPONのinject_expression
inject_expression: inject_expression OP_OR inject_expression_term | inject_expression_term
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_term：inject_expression_term OP_AND inject_expression_factor | inject_expression_factor
inject_expression_factor: '(' inject_expression ')' | inject_expression_operand
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_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
inject_attribute：ATTR_INJECT opt_router_expression_with_at opt_action opt_inject_expression
//// components attribute //////////////////////////////////////////////
////コンポーネントは、属性//////////////////////////////////////////// //
opt_atomic: | KEYW_ATOMIC
opt_atomic：| KEYW_ATOMIC
components_list: | filter | components_list KEYW_PROTOCOL tkn_word filter
components_list：|フィルタ| components_list KEYW_PROTOCOLのtkn_wordフィルタ
components_attribute: ATTR_COMPONENTS opt_atomic components_list
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_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
rs_member：TKN_ASNO | TKN_ASNO OP_MS | TKN_ASNAME | TKN_ASNAME OP_MS | TKN_RSNAME | TKN_RSNAME OP_MS | TKN_PRFXV4
| TKN_PRFXV4RNG
| TKN_PRFXV4RNG
rs_members_attribute: ATTR_RS_MEMBERS opt_rs_members_list
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
rpattr_attribute：ATTR_RP_ATTRのTKN_WORD方法| ATTR_RP_ATTR TKN_RP_ATTR方法
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 ')'
方法：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の属性//////////////////////////////////////////// ////
typedef_attribute: ATTR_TYPEDEF TKN_WORD typedef_type
typedef_attribute：ATTR_TYPEDEF TKN_WORD typedef_type
typedef_type_list: typedef_type | typedef_type_list ',' 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
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
enum_list：tkn_word | enum_list '' tkn_word
//// protocol attribute ////////////////////////////////////////////////
////プロトコル属性//////////////////////////////////////////// ////
protocol_attribute: ATTR_PROTOCOL tkn_word protocol_options
protocol_attribute：ATTR_PROTOCOLのtkn_wordのprotocol_options
protocol_options: | protocol_options protocol_option
protocol_options：| protocol_optionsのprotocol_option
protocol_option: KEYW_MANDATORY method | KEYW_OPTIONAL method
protocol_option：KEYW_MANDATORY方法| KEYW_OPTIONAL方法
//**** 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})
トークンの定義に使用////フレックスマクロ///////////////////////////// INT [[：桁：]] + SINT [ + - ] {INT} REAL [+ - ？？？] {INT} \ {INT}（{WS} * E {WS} * [+ - ] {INT}？）？ NAME [[：アルファ：]]（[[：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：] _-]。？+ ////トークンの定義//////////////////////////////////////////////// TKN_INT {SINT} TKN_INT {INT}：{INT}各{INT}は2つのオクテットのTKN_INT {INT} {INT} {INT} {INT}各{INT}がある場合、1オクテットのTKN_REAL {REAL} TKN_STRING同じである場合* {ASNAME} \（：プログラミング言語C TKN_IPV4 {IPV4} TKN_PRFXV4 {PRFXV4} TKN_PRFXV4RNG {PRFXV4RNG} TKN_ASNO {ASNO} TKN_ASNAME（| | peeras {ASNAME}）（{ASNO}）のように（{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真|辞書TKN_WORD {NAME} TKN_DNS {DNAME}で定義されている場合はfalse TKN_RP_ATTR {NAME}（ "" {DNAME}）+ TKN_EMAIL {ENAME} @（{DNAME}（{DNAME}）+ "" | {IPV4}）
C Changes from RFC 2280
RFC 2280からの変更点C
RFC 2280 [3] contains an earlier version of RPSL. This section summarizes the changes since then. They are as follows:
RFC 2280 [3] RPSLの以前のバージョンを含んでいます。このセクションでは、それ以来、変更内容をまとめたもの。それらは次の通りです：
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 4つの1オクテットの整数（例えば、1.1.1.1）の配列として、または2つの2オクテットの整数（70例えば3561）のシーケンスとして整数を書き込みできるようになりました。第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アドレスプレフィックス範囲の定義が拡張されます。第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（例えば{30.0.0.0/8^24-28}^27-30）が定義されています。第2節を参照してください。
o All dates are now in UTC. Please see Section 2.
Oすべての日付はUTCになりました。第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プラス（「+」）文字は複数行に属性の値を分割するスペースとタブ文字に追加された（すなわちスペース、タブまたはプラス（「+」）文字で次の行を開始することにより）。第2節を参照してください。
o The withdrawn attribute of route class is removed from the language.
Oルートクラスの撤回属性が言語から削除されます。
o filter-set class is introduced. Please see Section 5.4.
Oフィルタ設定クラスが導入されます。 5.4節を参照してください。
o rtr-set class is introduced. Please see Section 5.5.
O RTR-設定クラスが導入されます。セクション5.5を参照してください。
o peering-set class is introduced. Please see Section 5.6.
Oピアリング・セットのクラスが導入されます。 5.6節を参照してください。
o Filters can now refer to filter-set names. Please see Section 5.4.
Oフィルタは現在の名前セットをフィルタリングするために参照することができます。 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ピアリングは今ピアリングセット、RTR-セット名を参照することができます。ローカルおよびピアルータは、ルータ式を使用して指定することができます。 5.6節を参照してください。
o The peer attribute of the inet-rtr class can refer to peering-set, rtr-set names. Please see Section 9.
O INET-RTRクラスのピア属性は、ピアリングセット、RTR-セット名を参照することができます。第9章を参照してください。
o The syntax and semantics of union, and list types and typedef attribute have changed. Please see Section 7.
O構文と労働組合の意味論、およびリストの種類とtypedefの属性が変更されました。セクション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初期辞書では、community_elmを定義typedefの属性は、コミュニティの属性を定義するRP-属性が変更されました。セクション7を参照してください。
o Guideliness for extending RPSL is added. Please see Section 10.
RPSLを拡張するためのOのガイドラインが追加されます。セクション10を参照してください。
o Formal grammar rules are added. Please see Appendix B.
O正式な文法規則が追加されます。付録Bを参照してください。
D Authors' Addresses
D著者のアドレス
Cengiz Alaettinoglu USC/Information Sciences Institute
チンギスAlaettinogl USC /情報科学研究所
EMail: cengiz@isi.edu
メールアドレス：cengiz@isi.edu
Curtis Villamizar Avici Systems
カーティスVillamizar Aviciシステム
EMail: curtis@avici.com
メールアドレス：curtis@avici.com
Elise Gerich At Home Network
ホームネットワークではエリーゼGerich
EMail: epg@home.net
メールアドレス：epg@home.net
David Kessens Qwest Communications
デビッド枕、クエスト・コミュニケーションズ
EMail: David.Kessens@qwest.net
メールアドレス：David.Kessens@qwest.net
David Meyer University of Oregon
オレゴン州のデビッド・マイヤー大学
EMail: meyer@antc.uoregon.edu
メールアドレス：meyer@antc.uoregon.edu
Tony Bates Cisco Systems, Inc.
トニー・ベイツシスコシステムズ株式会社
EMail: tbates@cisco.com
メールアドレス：tbates@cisco.com
Daniel Karrenberg RIPE NCC
ダニエルKarrenberg RIPE NCC
EMail: dfk@ripe.net
メールアドレス：dfk@ripe.net
Marten Terpstra c/o Bay Networks, Inc.
/ Oベイネットワーク株式会社Cマーテンテルプストラ
EMail: marten@BayNetworks.com
メールアドレス：marten@BayNetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、そのimplmentationを支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。