[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5511

Networking Working Group                                       A. Farrel
Internet-Draft                                        Old Dog Consulting
Intended Status: Standards Track
Created: September 12, 2008
Expires: March 12, 2009

                  Reduced Backus-Naur Form (RBNF)
          A Syntax Used in Various Protocol Specifications


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   Several protocols have been specified 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 Reduced BNF), and makes it available for
   use by new protocols.

Farrel                   Expires March 12, 2009                 [Page 1]

Internet-Draft                 Reduced BNF                September 2008

1. Introduction

   Backus-Naur Form (BNF) has been used to specify the message formats
   of several protocols within the IETF. Unfortunately these
   specifications are not based on any specific formal definition of BNF
   and 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 [RFC5234]), however this would
   require a lot of work.

   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

   This document provides such a specification and names the BNF variant
   Reduced BNF (RBNF).

1.1. Existing Uses

   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 gone on to be used 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

   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 form 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 [RFC2205], 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) [RFC4204] and the Path Computation Element Protocol
   (PCEP) [PCEP]. Both of these protocols have also given rise to a
   large number of protocol extensions that also use the same variant of

Farrel                   Expires March 12, 2009                 [Page 2]

Internet-Draft                 Reduced BNF                September 2008

2. Formal Definitions

   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.

   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 sub-ordinate 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 sub-ordinate rules.

2.1. Rule Definitions

   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 more

2.1.1. Rule Name Delimitation.

   All rule names are enclosed by angle brackets ("<" and ">"). Rules
   names may include any printable characters, but not tabs or line

     <Path Message>

2.1.2. Objects

   The most basic (indivisible) rule is termed an object. The definition
   of an object is derived from its context.

   Objects are typically named in upper case. They do not usually use
   spaces within the name, favoring underbars ("_").


Farrel                   Expires March 12, 2009                 [Page 3]

Internet-Draft                 Reduced BNF                September 2008

2.1.3. Constructs

   Rules that are constructed from other rules using operators are
   termed constructs.

   Constructs are named in lower case, although capitals are commonly
   used to indicate acronyms. Spaces and hyphens are used between words
   within names.

     <sender descriptor>

2.1.4. Messages

   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.

     <Path Message>

2.2. Operators

   Operators are used to build constructs and messages from objects and

2.2.1. Assignment

   Assignment is used to form constructs and messages.

     The named construct or message on the left-hand side is defined to
     be equivalent to the right-hand side of the assignment.

     colon, colon, equal sign ("::=")

     <WF flow descriptor> ::= <FLOWSPEC>

     The left-hand side of the assignment and the assignment operator
     must be present on the same line.

Farrel                   Expires March 12, 2009                 [Page 4]

Internet-Draft                 Reduced BNF                September 2008

2.2.2. Concatenation

   Objects and constructs may be combined as a sequence to form a new
   construct or message.

     The objects or constructs must be present in the order specified.

     A sequence of objects and constructs usually separated by spaces.
     May also be separated by line breaks.

     <SE flow descriptor> ::= <FLOWSPEC> <filter spec list>

     See Section 2.3.3 for further comments on ordering of objects and

2.2.3. Optional Presence

   Objects and constructs may be marked as optionally present.

     The optional objects or constructs may be present or absent within
     the assignment. Unless indicated as optional, objects and
     constructs are mandatory.

     Contained in square brackets ("[" and "]").

     <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.

     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

Farrel                   Expires March 12, 2009                 [Page 5]

Internet-Draft                 Reduced BNF                September 2008


2.2.4. Alternatives

   Choices may be indicated within assignments.

     Either one rule or the other must be present.

     The pipe symbol ("|") is used between the objects or constructs
     that are alternatives.

     <flow descriptor list> ::= <FF flow descriptor list>
                                | <SE flow descriptor>

     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. Multi-way alternates are not common. To avoid confusion,
        explicit grouping (see Section 2.2.6), or an intermediary must
        be used. Thus:

          <construct> ::= <ALT_ONE> | <ALT_TWO> | <ALT_THREE>

        is not allowed and must be presented as

          <construct> ::= ( <ALT_ONE> | <ALT_TWO> ) | <ALT_THREE>

        or as

          <intermediary construct> ::= <ALT_TWO> | <ALT_THREE>
          <construct> ::= <ALT_ONE> | <intermediary construct>

2.2.5. Repetition

   It may be the case that a sequence of identical objects or constructs
   is required within an assignment.

     One or more objects or constructs may be present.

     Three dots ("...").

Farrel                   Expires March 12, 2009                 [Page 6]

Internet-Draft                 Reduced BNF                September 2008

     <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                        <SESSION> <RSVP_HOP>
                        [ <POLICY_DATA> ... ]
                        [ <sender descriptor> ]

     1. A set of zero or more objects or constructs may be achieved by
        combining with the Optional concept as shown in the example

     2. Sequences may also be encoded by building a recursive construct
        using the Alternative operator. For example:

          <sequence> ::= <OBJECT> |
                         <OBJECT> <sequence>

     3. Repetition may also be applied to a component of an assignment
        to indicate the optional repetition of that component. For

         <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.

2.2.6. Grouping

     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.

     Round brackets ("(" and ")") enclosing a set of objects,
     constructs, and operators.

     <group> ::= ( <this> <that> )

     1. The precedence rule in Section 2.4 means that the use of
        grouping is not necessary for the formal interpretation of the

Farrel                   Expires March 12, 2009                 [Page 7]

Internet-Draft                 Reduced BNF                September 2008

        BNF representation. However, grouping may make the BNF easier to
        parse unambiguously and is recommended as a solution for multi-
        alternates (Section 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 grouping is

     3. A practical alternative to grouping is he definition of
        intermediate constructs as illustrated in Note 2 of Section

2.3. Editorial Conventions

2.3.1. White Space

   White space (that is space characters) between operators, objects,
   and constructs is ignored, but should be used for readability.

2.3.2. Line Breaks

   Line breaks within an assignment are ignored, but should be used for

   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

   A line break must not be present between the left-hand side of an
   assignment and the assignment operator (see Section 2.2.1).

   New assignments (i.e., new construct or message definitions) must
   begin on a new line.

2.3.3. Ordering

   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.

2.4. Precedence

   Precedence may be deduced from a "proper" reading of the BNF using
   these rules. Grouping and ordering are recommended for clarity.

   The various mechanisms described above have the following precedence,

Farrel                   Expires March 12, 2009                 [Page 8]

Internet-Draft                 Reduced BNF                September 2008

   from highest (binding tightest) at the top, to lowest and loosest at
   the bottom:

      objects, constructs
      grouping, optional

     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.

     An example of the confusion in precedence can be found in Section
     3.1.4 of [RFC2205].

           <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 operators.
     Thus, we should interpret (correctly) the text in [RFC2205] as
     shown in formulation a.

     Similarly (from the same section of [RFC2205]) we should interpret

           <flow descriptor list> ::=
                            <FLOWSPEC>  <FILTER_SPEC>  |
                            <flow descriptor list> <FF flow descriptor>


           <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.

Farrel                   Expires March 12, 2009                 [Page 9]

Internet-Draft                 Reduced BNF                September 2008

3. Automated Validation

   RBNF would be appropriate for verification using automated validation
   tools. No tools are known at this time.

4. IANA Considerations

   This document makes no requests for IANA action.

5. Security Considerations

   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 defective or incompatible implementations
   that might be exploited in security attacks.

6. Acknowledgments

   Thanks to Magnus Westerlund, Nic Neate, Chris Newman, Alfred Hoenes,
   and Lou Berger for review and useful comments.

7.  References

7.1.  Normative References


7.2.  Informative References

   [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S., and S.
             Jamin, "Resource ReserVation Protocol -- Version 1
             Functional Specification", RFC 2205, September 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.

   [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
             (GMPLS) Signaling Resource ReserVation Protocol-Traffic
             Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC
             4204, September 2005.

   [RFC5234] Crocker, D. (Ed.) and Overell, P., "Augmented BNF for
             Syntax Specifications: ABNF", STD 68, RFC 5234, January

Farrel                   Expires March 12, 2009                [Page 10]

Internet-Draft                 Reduced BNF                September 2008

   [PCEP]    Vasseur, J.P., and Le Roux, J.-L., "Path Computation
             Element (PCE) Communication Protocol (PCEP) - Version 1",
             draft-ietf-pce-pcep, work in progress.

   [EBNF]    ISO/IEC 14977, "Information technology -- Syntactic
             metalanguage -- Extended BNF", 1996

Author's Address

   Adrian Farrel
   Old Dog Consulting

   Email: adrian@olddog.co.uk

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary

Farrel                   Expires March 12, 2009                [Page 11]

Internet-Draft                 Reduced BNF                September 2008

   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Farrel                   Expires March 12, 2009                [Page 12]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/