[要約] RFC 5511は、さまざまなルーティングプロトコル仕様で使用されるエンコーディングルールを形成するために使用される構文であるRouting Backus-Naur Form（RBNF）についての要約と目的を提供しています。
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
ルーティングBackus-Naurフォーム（RBNF）：さまざまなルーティングプロトコル仕様でエンコーディングルールを形成するために使用される構文
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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.
メッセージの構文を表す際のBackus-Naur形式（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.
Backus-Naurフォーム（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]）を使用することが可能です。ただし、これには多くの作業が必要です。ABNFでは、端子は整数（文字/バイト）であり、メッセージ形式を定義するために使用されるBNF形式では、端子は「オブジェクト」（何らかのメッセージ要素がありますが、個々のバイトまたは文字ではありません）または全体であることに注意してください。「メッセージ」。これは、既存の仕様を確立された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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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は、マルチプロトコルラベルスイッチング（MPLS）ネットワークで使用するために拡張され、トラフィックエンジニアリング（TE）[RFC3209]のシグナル伝達を提供し、これは一般化された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はRSVP-TEと密接に関連しており、開発された場合、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で定義されている演算子を使用した一連のルール定義で構成されています。1つのルールは、オペレーターを使用して他のルールのセットから構築できます。ルールの定義の順序は重要ではありません。つまり、下位のルールを最初に定義し、次にその後のさらなるルールの定義で使用する場合があります。または、最初にトップレベルのルールを定義し、その後、下位ルールの一連の定義が定義されます。
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>
例：<SenderDecriptor>
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.
意味：いずれかのルールが存在する必要があります。
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.
注：1。混乱を避けるために、明示的なグループ化（セクション2.2.6）の使用をお勧めします。ラインブレークを使用した暗黙のグループ化（セクション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.
<flow Decriptor>のインスタンスが存在する必要があるか、それがオプションであることを意味するように読むことができます。
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メッセージは次のように定義されています。
<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.
エンコーディング：丸いブラケット（ "（" and "）"）オブジェクト、コンストラクト、演算子のセットを囲みます。
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.2.5の<Sequence>の定義で見られるように、ラインブレーク（セクション2.3.2）を明確にするためによく使用されますが、これらは誤解に対して開かれており、明示的なグループ化が推奨されます。
3. A practical alternative to grouping is the definition of intermediate constructs as illustrated in Note 2 of Section 2.2.4.
3. グループ化の実用的な代替手段は、セクション2.2.4の注2に示すように、中間構造の定義です。
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.
ラインブレイクは、グループ化を暗示するものとして解釈される場合がありますが、それは明示的なルールではありません。ただし、優先順位の規則には、連結が代替演算子よりも優先順位が高いと述べています。したがって、[RFC2205]のテキストは、製剤aに示すように解釈する必要があります。
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.
マグナス・ウェスターランド、ニック・ニーテ、クリス・ニューマン、アルフレッド・ホーネス、ルー・ベルガー、ジュリエン・ムリック、スチュアート・ベンターズ、トム・ペティ、サム・ハートマン、パシ・エロネンにレビューと有用なコメントをしてくれたことに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Braden、R.、Ed。、Zhang、L.、Berson、S.、Herzog、S.、およびS. Jamin、「リソース予約プロトコル（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.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「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] Berger、L.、ed。、「一般化されたマルチプロトコルラベルスイッチング（GMPLS）シグナリングリソース予約プロトコルトラフィックエンジニアリング（RSVP-TE）拡張」、RFC 3473、2003年1月。
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, October 2005.
[RFC4204] Lang、J.、ed。、「Link Management Protocol（LMP）」、RFC 4204、2005年10月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、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。、ed。、およびJl。Le Roux、ed。、「パス計算要素（PCE）通信プロトコル（PCEP）」、RFC 5440、2009年3月。
[EBNF] ISO/IEC 14977, "Information technology -- Syntactic metalanguage -- Extended BNF", 1996.
[EBNF] ISO/IEC 14977、「情報技術 - 構文のMetalanguage-拡張BNF」、1996。
Author's Address
著者の連絡先
Adrian Farrel Old Dog Consulting
エイドリアンファレルオールドドッグコンサルティング
EMail: adrian@olddog.co.uk