Network Working Group A. Farrel
Request for Comments: 5511 Old Dog Consulting
Category: Standards Track April 2009
Routing Backus-Naur Form (RBNF): A Syntax Used to Form
Encoding Rules in Various Routing Protocol Specifications
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
Several protocols have been specified in the Routing Area of the IETF using a common variant of the Backus-Naur Form (BNF) of representing message syntax. However, there is no formal definition of this version of BNF.
いくつかのプロトコルは、メッセージ構文を表すのバッカス記法（BNF）の共通のバリアントを使用してIETFのルーティング・エリアに指定されています。しかし、BNFのこのバージョンの正式な定義はありません。
There is value in using the same variant of BNF for the set of protocols that are commonly used together. This reduces confusion and simplifies implementation.
一般的に一緒に使用されるプロトコルのセットのためのBNFの同じバリアントを使用しての値があります。これは混乱を軽減し、実装を簡素化します。
Updating existing documents to use some other variant of BNF that is already formally documented would be a substantial piece of work.
すでに正式に文書化されているBNFの他のいくつかのバリアントを使用するように既存のドキュメントを更新すると、仕事のかなりの部分になります。
This document provides a formal definition of the variant of BNF that has been used (that we call Routing BNF) and makes it available for use by new protocols.
この文書では、使用（私たちはルーティングBNFを呼び出すこと）と新しいプロトコルで使用するために、それが利用できるようにされたBNFの変種の正式な定義を提供します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Existing Uses ..............................................3
1.3. Applicability Statement ....................................4
2. Formal Definitions ..............................................4
2.1. Rule Definitions ...........................................5
2.1.1. Rule Name Delimitation ..............................5
2.1.2. Objects .............................................5
2.1.3. Constructs ..........................................6
2.1.4. Messages ............................................6
2.2. Operators ..................................................6
2.2.1. Assignment ..........................................6
2.2.2. Concatenation .......................................7
2.2.3. Optional Presence ...................................7
2.2.4. Alternatives ........................................8
2.2.5. Repetition ..........................................9
2.2.6. Grouping ...........................................10
2.3. Editorial Conventions .....................................11
2.3.1. White Space ........................................11
2.3.2. Line Breaks ........................................11
2.3.3. Ordering ...........................................11
2.4. Precedence ................................................11
3. Automated Validation ...........................................13
4. Security Considerations ........................................13
5. Acknowledgments ................................................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................13
Backus-Naur Form (BNF) has been used to specify the message formats of several protocols within the Routing Area of the IETF. Unfortunately, these specifications are not based on any specific formal definition of BNF, and they differ slightly from the definitions provided in other places.
バッカスナウア記法（BNF）は、IETFのルーティング・エリア内のいくつかのプロトコルのメッセージ・フォーマットを指定するために使用されてきました。残念ながら、これらの仕様は、BNFの任意の特定の正式な定義に基づいていない、と彼らは他の場所で提供された定義とは若干異なります。
It is clearly valuable to have a formal definition of the syntax-defining language that is used. It would be possible to convert all existing specifications to use an established specification of BNF (for example, Augmented BNF or ABNF [RFC5234]); however, this would require a lot of work. It should be noted that in ABNF the terminals are integers (characters/bytes), while in the BNF form used to define message formats, the terminals are "objects" (some kind of message elements, but not individual bytes or characters) or entire "messages". This means that converting existing specifications to use an established BNF specification would also require extensions to that BNF specification.
使用されている構文定義言語の形式的な定義を持つことが明らかに価値があります。すべての既存の仕様は、BNF（例えば、増大しているBNFまたはABNF [RFC5234]）の確立された仕様を使用するように変換することも可能です。しかし、これは多くの作業が必要になります。メッセージ・フォーマットを定義するために使用されるBNF形で、端末は「オブジェクト」（メッセージ要素のいくつかの種類ではなく、個々のバイトまたは文字）または全体であるがABNFに端末が、整数（文字/バイト）であることに留意すべきです「メッセージ」。これは、確立されたBNFの仕様を使用するように既存の仕様を変換すると、また、そのBNF仕様の拡張が必要になることを意味します。
On the other hand, the variant of BNF used by the specifications in question (which is similar to a subset of Extended BNF [EBNF]) is consistent and has only a small number of constructs. It makes sense, therefore, to provide a definition of this variant of BNF to allow ease of interpretation of existing documents and to facilitate the development of new protocol specifications using the same variant of BNF. A specification will also facilitate automated verification of the formal definitions used in future documents.
一方、（拡張BNF [EBNF]のサブセットに類似している）問題の仕様で使用されるBNFの変異体は、一貫性があり、構築物のほんの数を有しています。したがって、既存の文書の解釈の容易さを可能にするためにBNFのこのバリアントの定義を提供し、BNFの同じバリアントを使用して、新しいプロトコル仕様の開発を容易にするため、理にかなっています。仕様は、将来の文書で使用される正式な定義の自動検証が容易になります。
This document provides such a specification and names the BNF variant Routing BNF (RBNF).
この文書は、本明細書および名前BNFバリアントルーティングBNF（RBNF）を提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The first notable use of the variant of BNF that concerns us is in the specification of the Resource Reservation Protocol (RSVP) [RFC2205]. RSVP has been extended for use in Multiprotocol Label Switching (MPLS) networks to provide signaling for Traffic Engineering (TE) [RFC3209], and this has been developed for use as the signaling protocol in Generalized MPLS (GMPLS) networks [RFC3473].
私たちに関係BNFの変異型の最初の顕著な使用はリソース予約プロトコル（RSVP）[RFC2205]の仕様です。 RSVPは、トラフィックエンジニアリング（TE）[RFC3209]のためのシグナリングを提供する（MPLS）ネットワークをマルチプロトコルラベルスイッチングに使用するために拡張されており、これは汎用MPLS（GMPLS）ネットワーク[RFC3473]でのシグナリングプロトコルとして使用するために開発されました。
Each of these three uses of RSVP has given rise to a large number of specifications of protocol extensions to provide additional features over and above those in the base documents. Each new feature is defined in its own document using the common variant of BNF.
RSVPこれら3つの用途は、それぞれの上に、ベース文書のもの上記の追加機能を提供するために、プロトコル拡張の仕様の大規模な数に上昇を与えています。各新機能は、BNFの共通の変異体を使用して、独自の文書で定義されています。
New protocols have also been specified using the same variant of BNF. This has arisen partly because the developers were familiar with the BNF used in [RFC2205], etc., but also because of the overlap between the protocols, especially with respect to the network objects controlled and operated.
新しいプロトコルもBNFの同じバリアントを使用して指定されています。これにより、開発者は、特に、ネットワーク・オブジェクトを制御及び作動に関して、[RFC2205]で使用されるBNFなどに精通していただけでなく、ためのプロトコルとの重なり部分的ため生じています。
Notable among these additional protocols are the Link Management Protocol (LMP) [RFC4204] and the Path Computation Element Protocol (PCEP) [RFC5440]. In both cases, further documents that specify protocol extensions also use the same variant of BNF.
これらの追加議定書の中で注目すべきは、リンク管理プロトコル（LMP）[RFC4204]とパス計算要素プロトコル（PCEP）[RFC5440]です。どちらの場合も、プロトコル拡張を指定し、さらに文書はまた、BNFの同じバリアントを使用します。
RBNF as defined in this document is primarily applicable for the protocols listed in the previous section. The specification may be used to facilitate the interpretation of the pre-existing RFCs that are referenced. It should also be used in the specification of extensions to those protocols.
この文書で定義されるようRBNFは、前のセクションに記載されているプロトコルの主に適用可能です。仕様は、参照される既存のRFCの解釈を容易にするために使用されてもよいです。また、これらのプロトコルの拡張機能の仕様で使用されるべきです。
RBNF could also be used for the specification of new protocols. This is most appropriate for the development of new protocols that are closely related to those that already use RBNF. For example, PCEP is closely related to RSVP-TE, and when it was developed, the PCE working group chose to use the same form of BNF as was already used in the RSVP-TE specifications.
RBNFはまた、新しいプロトコルの仕様を使用することができます。これは、すでにRBNFを使用するものに密接に関連して、新しいプロトコルの開発のために最も適切です。例えば、PCEP密接-TEをRSVPに関連して、それが開発されたとき、PCEワーキンググループは、既にRSVP-TEの仕様で使用されたようにBNFの同じフォームを使用することを選択しました。
If a wholly new protocol is being developed and is not related to a protocol that already uses RBNF, the working group should consider carefully whether to use RBNF or to use a more formally specified and broader form of BNF such as ABNF [RFC5234].
完全に新しいプロトコルが開発されており、すでにRBNFを使用するプロトコルに関連していない場合は、ワーキンググループはRBNFを使用するか、そのようなABNF [RFC5234]としてBNFのより正式に指定されており、より広範なフォームを使用するかどうかを慎重に検討すべきです。
The use of RBNF to specify extensions to protocols that do not already use RBNF (i.e., that use some other form of BNF) is not recommended.
RBNFの使用はすでにRBNFを使用していないプロトコルに拡張子を指定する（すなわち、BNFの他のいくつかのフォームを使用すること）は推奨されません。
The basic building blocks of BNF are rules and operators. At its simplest form, a rule in the context we are defining is a protocol object that is traditionally defined by a bit diagram in the protocol specification. Further and more complex rules are constructed by combining other rules using operators. The most complex rule is the message that is constructed from an organization of protocol objects as specified by the operators.
BNFの基本的なビルディングブロックはルールと演算子です。その最も単純な形で、我々は定義されているコンテキスト内のルールは、従来のプロトコル仕様のビット線図によって定義されたプロトコルのオブジェクトです。さらに、より複雑なルールは、演算子を使用して他のルールを組み合わせることによって構成されています。最も複雑な規則は、オペレータによって指定されたプロトコルオブジェクトの組織から構築されるメッセージです。
An RBNF specification consists of a sequence of rule definitions using the operators defined in Section 2.2. One rule may be constructed from a set of other rules using operators. The order of definition of rules does not matter. That is, the subordinate rules MAY be defined first and then used in subsequent definitions of further rules, or the top-level rules MAY be defined first followed by a set of definitions of the subordinate rules.
RBNF仕様はセクション2.2で定義された演算子を使用して、ルール定義の配列からなります。一つのルールは、演算子を使用して、他のルールのセットから構成されてもよいです。ルールの定義の順序は重要ではありません。すなわち、下位のルールは、最初に定義した後、定義された最初の従属ルールの定義のセットが続いてもよい更なるルール、または最上位のルールの後続の定義で用いてもよいです。
Rule definitions are read left-to-right on any line, and the lines are read top-to-bottom on the page. This becomes particularly important when considering sequences of rules and operators.
ルールの定義は、任意の行に左から右へ読み取られ、行がページに上から下へ読み込まれます。ルールと演算子の配列を考慮するとき、これは特に重要になります。
No semantics should be assumed from special characters used in rule names. For example, it would be wrong to assume that a rule carries a decimal number because the rule name begins or ends with the letter "d". However, individual specifications MAY choose to assign rule names in any way that makes the human interpretation of the rule easier.
いかなる意味は、ルール名に使用される特殊文字から想定されるべきではありません。例えば、ルール名が始まるか、文字「D」で終わるので、ルールは小数点数を運ぶことを想定して間違っているだろう。しかし、個々の仕様は、より簡単に、ルールの人間の解釈になりますどのような方法でルール名を割り当てるために選ぶかもしれません。
All rule names are enclosed by angle brackets ("<" and ">"). Rule names MAY include any printable characters, but MUST NOT include tabs or line feeds/breaks.
すべてのルール名は角括弧（「<」と「>」）で囲まれています。ルール名は、任意の印刷可能な文字を含んでもよいが、タブや改行/改行を含んではいけません。
Example: <Path Message>
例：<パスのメッセージ>
The most basic (indivisible) rule is termed an object. The definition of an object is derived from its context.
最も基本的な（不可分）ルールは、オブジェクトと呼ばれます。オブジェクトの定義は、そのコンテキストから導出されます。
Objects are typically named in uppercase. They do not usually use spaces within the name, favoring underbars ("_").
オブジェクトは通常、大文字で命名されています。彼らは通常、（「_」）下線を好む、名前の中にスペースを使用しないでください。
Example: <SENDER_TEMPLATE>
例：<SENDER_TEMPLATE>
Rules that are constructed from other rules using operators are termed constructs.
演算子を使用して他のルールから構成されているルールは、構造と呼ばれます。
Constructs are named in lowercase, although capitals are commonly used to indicate acronyms. Spaces and hyphens are used between words within names.
首都は一般頭文字を示すために使用されているが、構築物は、小文字で命名されています。スペースやハイフンは名前内の単語との間で使用されています。
Example: <sender descriptor>
例：<送信者の記述>
The final objective is the definition of messages. These are rules that are constructed from objects and constructs using operators. The only syntactic difference between a message and a construct is that no other rule is typically constructed from a message.
最終的な目的は、メッセージの定義です。これらは、演算子を使ってオブジェクトや構築物から構築されているルールです。メッセージと構築物との間の唯一の構文上の違いは、他のルールは、典型的には、メッセージから構成されていないことです。
Messages are typically named in title case.
メッセージは通常、タイトルケースで命名されています。
Example: <Path Message>
例：<パスのメッセージ>
Operators are used to build constructs and messages from objects and constructs.
演算子は、オブジェクトや構築物から構築物およびメッセージを構築するために使用されています。
Assignment is used to form constructs and messages.
割り当ては、構築物およびメッセージを形成するために使用されます。
Meaning: The named construct or message on the left-hand side is defined to be set equal to the right-hand side of the assignment.
意味：左側の名前の構築物またはメッセージは割当ての右辺と等しくなるように設定することと定義されます。
Encoding:
colon, colon, equal sign ("::=")
Example:
<WF flow descriptor> ::= <FLOWSPEC>
Note: The left-hand side of the assignment and the assignment operator MUST be present on the same line.
注：割り当てと代入演算子の左側が同一線上に存在しなければなりません。
Objects and constructs can be combined as a sequence to form a new construct or a message.
オブジェクトおよび構築物は、新たな構築物またはメッセージを形成するためのシーケンスとして組み合わせることができます。
Meaning: The objects or constructs MUST be present in the order specified. The order of reading RBNF is stated in Section 2.
意味：オブジェクトまたは構築物は、指定された順序で存在しなければなりません。 RBNFを読み取るためには、第2節に記載されています。
Encoding: A sequence of objects and constructs usually separated by spaces. The objects in a sequence MAY be separated by line breaks.
エンコード：通常、スペースで区切られたオブジェクトと構造体の配列です。シーケンス内のオブジェクトは、改行で分離することができます。
Example:
<SE flow descriptor> ::= <FLOWSPEC> <filter spec list>
Note: See Section 2.3.3 for further comments on the ordering of objects and constructs.
注：オブジェクトと構造の順序にさらなるコメントについては、セクション2.3.3を参照してください。
Objects and constructs can be marked as optionally present.
オブジェクトと構築物は任意に存在するとしてマークすることができます。
Meaning: The optional objects or constructs MAY be present or absent within the assignment. Unless indicated as optional, objects and constructs are mandatory and MUST be present. The optional operator can also be nested to give a hierarchical dependency of presence as shown in the example below.
意味：オプションのオブジェクトまたは構築物は、割当内に存在するか、存在しなくてもよいです。オプションとして示されていない限り、オブジェクトおよび構築物は必須であり、存在しなければなりません。任意のオペレーターは、以下の例に示すように、プレゼンスの階層的依存性を与えるように入れ子にすることができます。
Encoding: Contained in square brackets ("[" and "]").
エンコーディング：（「[」と「]」）角括弧内に含まれます。
Example:
<PathTear Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
[ <sender descriptor> ]
Example of nesting: The optional operator can be nested. For example,
ネスティングの例：オプションのオペレータはネストさせることができます。例えば、
<construct> ::= <MAND> [ <OPT_1> [ <OPT_2> ] ]
In this construction, the object OPT_2 can only be present if OPT_1 is also present.
OPT_1も存在している場合は、この構成では、オブジェクトOPT_2のみ存在することができます。
Note: The set of objects and constructs within the same pair of square brackets is treated as a unit (an unnamed construct). This means that when multiple objects and constructs are included within the same pair of square brackets, all MUST be included when one is included, unless nested square brackets are used as in the previous example.
注：角かっこの同じ組内のオブジェクトおよび構築物のセットは、単位（名前構築物）として扱われます。これは、複数のオブジェクト及び構築物は角括弧の同じペアに含まれる場合に一方が含まれているときにネスト角括弧は、前の例のように使用されていない限り、全てが含まれなければならないことを意味します。
Choices can be indicated within assignments.
選択肢が割り当て内に示すことができます。
Meaning: Either one rule or the other MUST be present.
意味：1つのルールまたは他のいずれかが存在しなければなりません。
Encoding: The pipe symbol ("|") is used between the objects or constructs that are alternatives.
エンコード：パイプ記号（「|」）の選択肢であるオブジェクトまたは構造の間で使用されています。
Example:
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
Notes: 1. Use of explicit grouping (Section 2.2.6) is RECOMMENDED to avoid confusion. Implicit grouping using line breaks (Section 2.3.2) is often used, but gives rise to potential misinterpretation and SHOULD be avoided in new definitions.
注：明示的なグループ化（2.2.6項）の1.は、混乱を避けることをお勧めします。改行を使用して暗黙のグループ化（2.3.2）がしばしば使用されるが、潜在的な誤解を生じさせ、新しい定義では避けるべきであるされています。
2. Multiple members of alternate sets can give rise to confusion. For example:
別のセットの2の複数のメンバーが混乱を生じさせることができます。例えば：
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
could be read to mean that an instance of <flow descriptor> must be present or that it is optional.
<フロー記述子>のインスタンスが存在するか、それがオプションであることをしなければならないことを意味すると読み取ることができます。
To avoid this type of issue, explicit grouping (see Section 2.2.6), or an intermediary MUST be used in all new documents (existing uses are not deprecated, and automatic parsers need to handle existing RFCs). See also Section 2.4 for a description of precedence rules.
この種の問題を回避するために、明示的なグループ化（2.2.6項を参照）、または仲介者は、すべての新しいドキュメントで使用されなければならない（既存の用途は廃止されていない、と自動パーサは、既存のRFCを処理する必要があります）。優先順位のルールの説明についても、2.4節を参照してください。
Thus:
したがって
<construct> ::= <ALT_A> <ALT_B> | <ALT_C> <ALT_D>
is not allowed in new documents and MUST be presented using grouping or using an intermediary construct. For example, and depending on intended meaning:
新しい文書で許可されておらず、グループ化を使用するか、または仲介構文を使用して提示しなければなりません。例えば、および意図された意味に応じて：
<construct> ::= ( <ALT_A> <ALT_B> ) | ( <ALT_C> <ALT_D> )
or
または
<construct> ::= <ALT_A> ( <ALT_B> | <ALT_C> ) <ALT_D>
or
または
<intermediary X> ::= <ALT_A> <ALT_B>
<intermediary Y> ::= <ALT_C> <ALT_D>
<construct> ::= <intermediary X> | <intermediary Y>
or
または
<intermediary Z> ::= <ALT_B> | <ALT_C>
<construct> ::= <ALT_A> <intermediary Z> <ALT_D>
It could be the case that a sequence of identical objects or constructs is required within an assignment.
これは、同じオブジェクトまたは構築物の配列が割り当て内で必要とされる場合であってもよいです。
Meaning: MAY repeat the preceding object, intermediate construct, or construct.
意味は：前のオブジェクト、中間構築を繰り返し、または構築することができます。
Encoding: Three dots ("...").
エンコード：3つのドット（ "..."）。
Example:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
Notes: 1. A set of zero or more objects or constructs can be achieved by combining with the Optional concept as shown in the example above.
注：1.ゼロ以上のオブジェクトまたは構築物のセットは、上記の例に示すように、オプションの概念と組み合わせることによって達成することができます。
2. Sequences can also be encoded by building a recursive construct using the Alternative operator. For example:
2.配列は、代替演算子を使用して再帰的な構築物を構築することによって符号化することができます。例えば：
<sequence> ::= <OBJECT> |
( <OBJECT> <sequence> )
3. Repetition can also be applied to a component of an assignment to indicate the optional repetition of that component. For example, the Notify message in [RFC3473] is defined as follows:
3.繰り返しはまた、その成分の任意の繰り返しを示すために割り当てのコンポーネントに適用することができます。たとえば、次のように定義されている[RFC3473]にメッセージを通知します：
<Notify message> ::=
<Common Header> [<INTEGRITY>]
[ [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>] ... ]
[ <MESSAGE_ID> ]
<ERROR_SPEC> <notify session list>
In this example, there is a sequence of zero or more instances of [<MESSAGE_ID_ACK> | <MESSAGE_ID_NACK>]. One could argue that the use of grouping (see Section 2.2.6) or a recursive construct (see Note 2, above) would be more clear.
|この例では、[<MESSAGE_ID_ACK>のゼロ以上のインスタンスの配列があります<MESSAGE_ID_NACK>]。一つは、グループ化の使用（セクション2.2.6を参照）または再帰的構築物（上記注2を参照）より明らかであろうと主張する可能性があります。
Meaning: A group of objects or constructs to be treated together. This notation is not mandatory but is RECOMMENDED for clarity. See Section 2.4 on Precedence.
意味：オブジェクトまたは構築物のグループが一緒に処理されます。この表記は必須ではありませんが、わかりやすくするために推奨されます。優先順位の2.4節を参照してください。
Encoding: Round brackets ("(" and ")") enclosing a set of objects, constructs, and operators.
エンコーディング：オブジェクト、構築、および演算子のセットを囲む丸括弧（「（」および「）」）。
Example:
<group> ::= ( <this> <that> )
Notes: 1. The precedence rule in Section 2.4 means that the use of grouping is not necessary for the formal interpretation of the BNF representation. However, grouping can make the BNF easier to parse unambiguously. Either grouping or an intermediate construct MUST be used for multi-alternates (Section 2.2.4).
注：1. 2.4節での優先ルールがグループ化の使用がBNF表記の正式な解釈のために必要ではないことを意味します。ただし、グループ化は明確に解析するBNFを容易にすることができます。グルーピングまたは中間構築物のいずれかは、マルチ交互に（セクション2.2.4）のために使用されなければなりません。
2. Line breaks (Section 2.3.2) are often used to clarify grouping as can be seen in the definition of <sequence> in Section 2.2.5, but these are open to misinterpretation, and explicit grouping is RECOMMENDED.
2.改行（セクション2.3.2）は、多くの場合、2.2.5項では、<列>の定義に見られるようにグループ分けを明確にするために使用されているが、これらは誤った解釈に開かれている、と明示的なグループ化が推奨されます。
3. A practical alternative to grouping is the definition of intermediate constructs as illustrated in Note 2 of Section 2.2.4.
第2.2.4項の注2に示すように3グループに実用的な代替案は、中間体構築物の定義です。
White space (that is space characters) between operators, objects, and constructs is ignored but SHOULD be used for readability.
ホワイトスペースは、演算子、オブジェクト間（つまり、スペース文字である）、および構築物は無視されますが、読みやすくするために使用されるべきです。
Line breaks within an assignment are ignored but SHOULD be used for readability.
割り当て内の改行は無視されますが、読みやすくするために使用されるべきです。
Line breaks are often used to imply grouping within the precedence rules set out in Section 2.4, but explicit grouping (Section 2.2.6) or intermediary constructs (Section 2.2.4) SHOULD be used in new definitions.
改行は、多くの場合、2.4節に定める優先順位規則内のグループ化を暗示するために使用されますが、明示的なグループ化（2.2.6項）または中間の構成要素（2.2.4項）は、新しい定義で使用されるべきです。
A line break MUST NOT be present between the left-hand side of an assignment and the assignment operator (see Section 2.2.1).
改行が割り当てと代入演算子の左側との間に存在してはならない（セクション2.2.1を参照）。
New assignments (i.e., new construct or message definitions) MUST begin on a new line.
新しい割り当て（すなわち、新たな構築物またはメッセージ定義）は、新しい行に開始する必要があります。
The ordering of objects and constructs in an assignment is explicit.
割り当て内のオブジェクトと構造の順序は、明示的です。
Protocol specifications MAY opt to state that ordering is only RECOMMENDED. In this case, elements of a list of objects and constructs MAY be received in any order.
プロトコル仕様は、順序が唯一推奨されていることを述べることを選ぶことができます。この場合、オブジェクトおよび構築物のリストの要素は、任意の順序で受信されてもよいです。
Precedence is the main opportunity for confusion in the use of this BNF. In particular, the use of alternatives mixed with concatenations can give rise to different interpretations of the BNF. Although precedence can be deduced from a "proper" reading of the BNF using the rules defined above and the precedence ordering shown below, authors are strongly RECOMMENDED to use grouping (Section 2.2.6) and ordering (Section 2.3.3) to avoid cases where the reader would otherwise be required to understand the precedence rules.
優先順位は、このBNFの使用における混乱のための主要な機会です。特に、の連結と混合選択肢の使用は、BNFの異なる解釈を生じさせることができます。優先順位が上で定義されたルールと、以下に示す優先順序付けを使用したBNFの「適切な」読書から推定することができますが、筆者は強くケースを避けるために、（2.2.6項）及び順序（2.3.3項）をグループ化し使用することをお勧めしますどこ読者は、そうでない場合は優先順位のルールを理解するために必要とされるであろう。
Automated readers are REQUIRED to parse rules correctly with or without this use of grouping.
自動化された読者が正しくまたはグループ化のこの使用せずにルールを解析するために必要とされています。
The various mechanisms described in the previous sections have the following precedence, from highest (binding tightest) at the top, to lowest (and loosest) at the bottom:
前のセクションで説明される様々なメカニズムは、底部で最も低い（そして最も緩い）に、上部に（密結合）最高から、次の優先順位を持っています。
objects, constructs repetition grouping, optional concatenation alternative
オブジェクト、繰り返しグループを構築し、オプションの連結代替
Note: Precedence is the main opportunity for confusion in the use of BNF. Authors are strongly RECOMMENDED to use grouping (Section 2.2.6) in all places where there is any scope for misinterpretation even when the meaning is obvious to the authors.
注意：優先順位は、BNFの使用における混乱のための主要な機会です。著者が強く意味が作者に明らかである場合でも、誤解のための任意の余地があるすべての場所でグループ化（セクション2.2.6）を使用することをお勧めします。
Example:
例：
An example of the confusion in precedence can be found in Section 3.1.4 of [RFC2205] and is mentioned in Section 2.2.4.
優先における混乱の例は、[RFC2205]のセクション3.1.4に見出すことができ、セクション2.2.4に記載されています。
<flow descriptor list> ::= <empty> |
<flow descriptor list> <flow descriptor>
The implementer MUST decide which of the following is intended:
実装者が意図して、以下のかを決定しなければなりません：
a. <flow descriptor list> ::= <empty> |
( <flow descriptor list> <flow descriptor> )
b. <flow descriptor list> ::= ( <empty> | <flow descriptor list> )
<flow descriptor>
The line break MAY be interpreted as implying grouping, but that is not an explicit rule. However, the precedence rules say that concatenation has higher precedence than the Alternative operator. Thus, the text in [RFC2205] SHOULD be interpreted as shown in formulation a.
改行は、グループ化を暗示するように解釈されるかもしれないが、それは明示的なルールではありません。ただし、優先順位のルールは、連結は代替演算子よりも優先順位が高いと言います。製剤Aに示すような、[RFC2205]のテキストは解釈されるべきです。
Similarly (from the same section of [RFC2205]):
同様に（[RFC2205]の同じセクションから）：
<flow descriptor list> ::=
<FLOWSPEC> <FILTER_SPEC> |
<flow descriptor list> <FF flow descriptor>
SHALL be interpreted as:
解釈されなければなりません。
<flow descriptor list> ::=
( <FLOWSPEC> <FILTER_SPEC> ) |
( <flow descriptor list> <FF flow descriptor> )
The use of explicit grouping or intermediary constructs is strongly RECOMMENDED in new text to avoid confusion.
明示的なグループ分けや仲介構築物の使用を強く混乱を避けるために、新しいテキストで推奨されています。
RBNF would be appropriate for verification using automated validation tools. Validation tools need to be able to check for close conformance to the rules expressed in this document to be useful for verifying new documents, but should also be able to parse RBNF as used in existing RFCs. No tools are known at this time.
RBNFは、自動検証ツールを使用して、検証のために適切であろう。検証ツールは、新しいドキュメントを検証するために有用であることが、この文書で表現のルールに近い適合性をチェックできるようにする必要がありますが、また、既存のRFCで使用されるようなRBNFを解析することができるはずです。工具はこの時点では知られていません。
This document does not define any network behavior and does not introduce or seek to solve any security issues.
このドキュメントは、任意のネットワーク動作を定義しないと、導入したり任意のセキュリティ問題を解決しようとしません。
It may be noted that clear and unambiguous protocol specifications reduce the likelihood of incompatible or defective implementations that might be exploited in security attacks.
明確で曖昧でないプロトコル仕様は、セキュリティ攻撃に悪用される可能性があります互換性がないか、欠陥のある実装の可能性を減らすことに留意されたいです。
Thanks to Magnus Westerlund, Nic Neate, Chris Newman, Alfred Hoenes, Lou Berger, Julien Meuric, Stuart Venters, Tom Petch, Sam Hartman, and Pasi Eronen for review and useful comments.
レビューと有益なコメントについてマグヌスウェスター、ニックNeate、クリス・ニューマン、アルフレッドHoenes、ルー・バーガー、ジュリアンMeuric、スチュアートVenters氏、トム・ペッチ、サム・ハートマン、およびパシEronenに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、エド、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"。、RFC 2205、9月1997。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、エド。、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204]ラング、J.、エド。、 "リンク管理プロトコル（LMP）"、RFC 4204、2005年10月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
[RFC5440] Vasseur、JP。、編、およびJL。ル・ルー、エド。、 "パス計算要素（PCE）通信プロトコル（PCEP）"、RFC 5440、2009年3月。
[EBNF] ISO/IEC 14977, "Information technology -- Syntactic metalanguage -- Extended BNF", 1996.
[EBNF] ISO / IEC 14977、 "情報技術 - 構文メタ言語 - BNF拡張"、1996。
Author's Address
著者のアドレス
Adrian Farrel Old Dog Consulting
エードリアンファレル古い犬のコンサルティング
EMail: adrian@olddog.co.uk
メールアドレス：adrian@olddog.co.uk