1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
|
<pre>Network Working Group A. Farrel
Request for Comments: 5511 Old Dog Consulting
Category: Standards Track April 2009
<span class="h1">Routing Backus-Naur Form (RBNF): A Syntax Used to Form</span>
<span class="h1">Encoding Rules in Various Routing Protocol Specifications</span>
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.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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.
<span class="grey">Farrel Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
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.
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.
Updating existing documents to use some other variant of BNF that is
already formally documented would be a substantial piece of work.
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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology ................................................<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. Existing Uses ..............................................<a href="#page-3">3</a>
<a href="#section-1.3">1.3</a>. Applicability Statement ....................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Formal Definitions ..............................................<a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Rule Definitions ...........................................<a href="#page-5">5</a>
<a href="#section-2.1.1">2.1.1</a>. Rule Name Delimitation ..............................<a href="#page-5">5</a>
<a href="#section-2.1.2">2.1.2</a>. Objects .............................................<a href="#page-5">5</a>
<a href="#section-2.1.3">2.1.3</a>. Constructs ..........................................<a href="#page-6">6</a>
<a href="#section-2.1.4">2.1.4</a>. Messages ............................................<a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Operators ..................................................<a href="#page-6">6</a>
<a href="#section-2.2.1">2.2.1</a>. Assignment ..........................................<a href="#page-6">6</a>
<a href="#section-2.2.2">2.2.2</a>. Concatenation .......................................<a href="#page-7">7</a>
<a href="#section-2.2.3">2.2.3</a>. Optional Presence ...................................<a href="#page-7">7</a>
<a href="#section-2.2.4">2.2.4</a>. Alternatives ........................................<a href="#page-8">8</a>
<a href="#section-2.2.5">2.2.5</a>. Repetition ..........................................<a href="#page-9">9</a>
<a href="#section-2.2.6">2.2.6</a>. Grouping ...........................................<a href="#page-10">10</a>
<a href="#section-2.3">2.3</a>. Editorial Conventions .....................................<a href="#page-11">11</a>
<a href="#section-2.3.1">2.3.1</a>. White Space ........................................<a href="#page-11">11</a>
<a href="#section-2.3.2">2.3.2</a>. Line Breaks ........................................<a href="#page-11">11</a>
<a href="#section-2.3.3">2.3.3</a>. Ordering ...........................................<a href="#page-11">11</a>
<a href="#section-2.4">2.4</a>. Precedence ................................................<a href="#page-11">11</a>
<a href="#section-3">3</a>. Automated Validation ...........................................<a href="#page-13">13</a>
<a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-13">13</a>
<a href="#section-5">5</a>. Acknowledgments ................................................<a href="#page-13">13</a>
<a href="#section-6">6</a>. References .....................................................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Normative References ......................................<a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Informative References ....................................<a href="#page-13">13</a>
<span class="grey">Farrel Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
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.
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 [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]); 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.
On the other hand, the variant of BNF used by the specifications in
question (which is similar to a subset of Extended BNF [<a href="#ref-EBNF" title=""Information technology -- Syntactic metalanguage -- Extended BNF"">EBNF</a>]) 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.
This document provides such a specification and names the BNF variant
Routing BNF (RBNF).
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. Existing Uses</span>
The first notable use of the variant of BNF that concerns us is in
the specification of the Resource Reservation Protocol (RSVP)
[<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>]. RSVP has been extended for use in Multiprotocol Label
Switching (MPLS) networks to provide signaling for Traffic
Engineering (TE) [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], and this has been developed for use as
the signaling protocol in Generalized MPLS (GMPLS) networks
[<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>].
<span class="grey">Farrel Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
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.
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 [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>], etc., but also because of the overlap between
the protocols, especially with respect to the network objects
controlled and operated.
Notable among these additional protocols are the Link Management
Protocol (LMP) [<a href="./rfc4204" title=""Link Management Protocol (LMP)"">RFC4204</a>] and the Path Computation Element Protocol
(PCEP) [<a href="./rfc5440" title=""Path Computation Element (PCE) Communication Protocol (PCEP)"">RFC5440</a>]. In both cases, further documents that specify
protocol extensions also use the same variant of BNF.
<span class="h3"><a class="selflink" id="section-1.3" href="#section-1.3">1.3</a>. Applicability Statement</span>
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 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.
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 [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>].
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Formal Definitions</span>
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
<span class="grey">Farrel Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
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.
An RBNF specification consists of a sequence of rule definitions
using the operators defined in <a href="#section-2.2">Section 2.2</a>. 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.
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.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Rule Definitions</span>
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.
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Rule Name Delimitation</span>
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>
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Objects</span>
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>
<span class="grey">Farrel Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. Constructs</span>
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>
<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>. Messages</span>
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>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Operators</span>
Operators are used to build constructs and messages from objects and
constructs.
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Assignment</span>
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.
<span class="grey">Farrel Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Concatenation</span>
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 <a href="#section-2">Section 2</a>.
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 <a href="#section-2.3.3">Section 2.3.3</a> for further comments on the ordering of objects
and constructs.
<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>. Optional Presence</span>
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.
<span class="grey">Farrel Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
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.
<span class="h4"><a class="selflink" id="section-2.2.4" href="#section-2.2.4">2.2.4</a>. Alternatives</span>
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 (<a href="#section-2.2.6">Section 2.2.6</a>) is RECOMMENDED to avoid
confusion. Implicit grouping using line breaks (<a href="#section-2.3.2">Section 2.3.2</a>)
is often used, but gives rise to potential misinterpretation and
SHOULD be avoided in new definitions.
2. Multiple members of alternate sets can give rise to confusion.
For example:
<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 <a href="#section-2.2.6">Section</a>
<a href="#section-2.2.6">2.2.6</a>), 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 <a href="#section-2.4">Section 2.4</a> for a description
of precedence rules.
Thus:
<construct> ::= <ALT_A> <ALT_B> | <ALT_C> <ALT_D>
<span class="grey">Farrel Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
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>
<span class="h4"><a class="selflink" id="section-2.2.5" href="#section-2.2.5">2.2.5</a>. Repetition</span>
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 ("...").
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.
2. Sequences can also be encoded by building a recursive construct
using the Alternative operator. For example:
<span class="grey">Farrel Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
<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 [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>] is defined as follows:
<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 <a href="#section-2.2.6">Section 2.2.6</a>) or a recursive construct
(see Note 2, above) would be more clear.
<span class="h4"><a class="selflink" id="section-2.2.6" href="#section-2.2.6">2.2.6</a>. Grouping</span>
Meaning:
A group of objects or constructs to be treated together. This
notation is not mandatory but is RECOMMENDED for clarity. See
<a href="#section-2.4">Section 2.4</a> on Precedence.
Encoding:
Round brackets ("(" and ")") enclosing a set of objects,
constructs, and operators.
Example:
<group> ::= ( <this> <that> )
Notes:
1. The precedence rule in <a href="#section-2.4">Section 2.4</a> 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 (<a href="#section-2.2.4">Section 2.2.4</a>).
2. Line breaks (<a href="#section-2.3.2">Section 2.3.2</a>) are often used to clarify grouping
as can be seen in the definition of <sequence> in <a href="#section-2.2.5">Section 2.2.5</a>,
but these are open to misinterpretation, and explicit grouping
is RECOMMENDED.
3. A practical alternative to grouping is the definition of
intermediate constructs as illustrated in Note 2 of <a href="#section-2.2.4">Section</a>
<a href="#section-2.2.4">2.2.4</a>.
<span class="grey">Farrel Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Editorial Conventions</span>
<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>. White Space</span>
White space (that is space characters) between operators, objects,
and constructs is ignored but SHOULD be used for readability.
<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>. Line Breaks</span>
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 <a href="#section-2.4">Section 2.4</a>, but explicit grouping (<a href="#section-2.2.6">Section 2.2.6</a>)
or intermediary constructs (<a href="#section-2.2.4">Section 2.2.4</a>) SHOULD be used in new
definitions.
A line break MUST NOT be present between the left-hand side of an
assignment and the assignment operator (see <a href="#section-2.2.1">Section 2.2.1</a>).
New assignments (i.e., new construct or message definitions) MUST
begin on a new line.
<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>. Ordering</span>
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.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Precedence</span>
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 (<a href="#section-2.2.6">Section</a>
<a href="#section-2.2.6">2.2.6</a>) and ordering (<a href="#section-2.3.3">Section 2.3.3</a>) to avoid cases where the reader
would otherwise be required to understand the precedence rules.
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:
<span class="grey">Farrel Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
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 (<a href="#section-2.2.6">Section 2.2.6</a>) in
all places where there is any scope for misinterpretation even when
the meaning is obvious to the authors.
Example:
An example of the confusion in precedence can be found in <a href="./rfc2205#section-3.1.4">Section</a>
<a href="./rfc2205#section-3.1.4">3.1.4 of [RFC2205]</a> and is mentioned in <a href="#section-2.2.4">Section 2.2.4</a>.
<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 [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] SHOULD be interpreted as shown in
formulation a.
Similarly (from the same section of [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>]):
<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.
<span class="grey">Farrel Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Automated Validation</span>
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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC2205">RFC2205</a>] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", <a href="./rfc3473">RFC 3473</a>,
January 2003.
<span class="grey">Farrel Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5511">RFC 5511</a> Routing BNF April 2009</span>
[<a id="ref-RFC4204">RFC4204</a>] Lang, J., Ed., "Link Management Protocol (LMP)", <a href="./rfc4204">RFC 4204</a>,
October 2005.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January 2008.
[<a id="ref-RFC5440">RFC5440</a>] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", <a href="./rfc5440">RFC 5440</a>,
March 2009.
[<a id="ref-EBNF">EBNF</a>] ISO/IEC 14977, "Information technology -- Syntactic
metalanguage -- Extended BNF", 1996.
Author's Address
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk
Farrel Standards Track [Page 14]
</pre>
|
