Networking Working Group A. Farrel Internet-Draft Old Dog Consulting Intended Status: Standards Track Created: September 10, 2008 Expires: March 10, 2009 Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications draft-farrel-rtg-common-bnf-04.txt 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- Drafts. 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 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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 10, 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 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. 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 [RFC3473]. Each of these three uses of RSVP has given rise to a considerable 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 number of protocol extensions that also use the same variant of BNF. Farrel Expires March 10, 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 protocol 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 easy. 2.1.1. Rule Name Delimitation. All rule names are enclosed by angle brackets ("<" and ">"). Example: 2.1.2. Data Objects The most basic (indivisible) rule is termed a data object. Data objects are named in upper case. They do not usually use spaces within the name, favoring hyphens ("-") or underbars ("_"). Example: 2.1.3. Data Constructs Rules that are constructed from other rules using operators are termed data constructs. Data constructs are named in lower case, although capitals may be Farrel Expires March 10, 2009 [Page 3] Internet-Draft Reduced BNF September 2008 used to indicate acronyms. Example: 2.1.4. Protocol Messages The final objective is the definition of protocol messages. These are constructed from data objects and data constructs using operators. Data constructs are named in title case. Example: 2.2. Operators Operators are used to build data constructs and protocol messages from data objects, and from other data constructs. 2.2.1. Assignment Assignment is used to form data constructs and protocol messages. Meaning: The named data construct or protocol message on the left-hand side is defined to be equivalent to the right-hand side of the assignment. Encoding: colon, colon, equal sign Example: ::= Note: The left-hand side of the assignment and the assignment operator must be present on the same line. 2.2.2. Sequential Combination Data objects and data constructs may be combined as a sequence to form a new data construct or protocol message. Meaning: The data objects or data constructs must be present in the order specified. Farrel Expires March 10, 2009 [Page 4] Internet-Draft Reduced BNF September 2008 Encoding: A sequence of data objects and data constructs usually separated by spaces. May also be separated by line breaks. Example: ::= Note: See Section 2.3.3 for comments on ordering of data objects and data constructs. 2.2.3. Optional Presence Data objects and data constructs may be marked as optionally present. Meaning: The optional data objects or data constructs may be present or absent within the assignment. Unless indicated as optional, data objects and data constructs are mandatory. Encoding: Contained in square brackets ("[" and "]"). Example: ::= [ ] [ ] Note: The optional operator can be nested. For example, ::= [ [ ] ] In this construction, the data object OPT_2 can only be present if OPT_1 is also present. 2.2.4. Alternatives Choices may be indicated within assignments. Meaning: Either one thing or the other must be present. Encoding: The pipe symbol ("|") is used between the data objects or data constructs that are alternatives. Example: ::= | Farrel Expires March 10, 2009 [Page 5] Internet-Draft Reduced BNF September 2008 Note: Multi-way alternates are not currently common. To avoid confusion, grouping should be used (see Section 2.2.6), or an intermediary data construct may be created. Thus: ::= | | is better presented as ::= ( | ) | or as ::= | ::= | 2.2.5. Repetition It may be the case that a sequence of identical data objects or data constructs is required within an assignment. Meaning: One or more objects or constructs may be present. Encoding: Three dots ("..."). Example: ::= [ ] [ ... ] [ ] Notes: 1. A set of zero or more objects or constructs may be achieved by combining with the Optional concept as shown in the example above. 2. Sequences may also be encoded by building a recursive data construct using the Alternative operator. For example: ::= | 3. Repetition may also be applied to a component of an assignment to indicate the optional repetition of that component. For example: Farrel Expires March 10, 2009 [Page 6] Internet-Draft Reduced BNF September 2008 ::= [] [ [ | ] ... ] [ ] In this example, there is a sequence of zero or more instances of [ | ]. One could argue that the use of grouping (see Section 2.2.6) or a recursive data construct (see note 2, above) would be more clear. 2.2.6. Grouping 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. Encoding: Round brackets ("(" and ")") enclosing a set of data objects, data constructs, and operators. Example: ::= ( ) Note: 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 may make the BNF easier to parse unambiguously. Line breaks (Section 2.3.2) are often used to clarify grouping as can be seen in the definition of in Section 2.2.5. 2.3. Editorial Conventions 2.3.1. White Space White space (that is space characters) 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 readability. They can be used to enhance readability when the precedence rules imply grouping as described in Section 2.2.6 and Section 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). Farrel Expires March 10, 2009 [Page 7] Internet-Draft Reduced BNF September 2008 New assignments (i.e., new data construct or protocol message definitions) must begin on a new line. 2.3.3. Ordering The ordering of data objects and data 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 data objects and data 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, from highest (binding tightest) at the top, to lowest and loosest at the bottom: data objects, data 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. Example: An example of the confusion in precedence can be found in Section 3.1.4 of [RFC2205]. ::= | The implementer must decide which of the following is intended. a. ::= | ( ) b. ::= ( | ) The line break may be interpreted as implying grouping, but that is not an explicit rule. However, the precedence rules say that Farrel Expires March 10, 2009 [Page 8] Internet-Draft Reduced BNF September 2008 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 ::= | as ::= ( ) | ( ) 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, and Alfred Hoenes for review and useful comments. 7. References 7.1. Normative References None 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. Farrel Expires March 10, 2009 [Page 9] Internet-Draft Reduced BNF September 2008 [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 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. 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 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 Farrel Expires March 10, 2009 [Page 10] Internet-Draft Reduced BNF September 2008 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 http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Farrel Expires March 10, 2009 [Page 11]