idnits 2.17.1 draft-farrel-rtg-common-bnf-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 24, 2009) is 5506 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group A. Farrel 3 Internet-Draft Old Dog Consulting 4 Intended Status: Standards Track 5 Created: March 24, 2009 6 Expires: September 24, 2009 8 Routing Backus-Naur Form (RBNF) : A Syntax Used to Form 9 Encoding Rules in Various Routing Protocol Specifications 11 draft-farrel-rtg-common-bnf-09.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with 16 the provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Several protocols have been specified in the Routing Area of the IETF 37 using a common variant of the Backus-Naur Form (BNF) of representing 38 message syntax. However, there is no formal definition of this 39 version of BNF. 41 There is value in using the same variant of BNF for the set of 42 protocols that are commonly used together. This reduces confusion and 43 simplifies implementation. 45 Updating existing documents to use some other variant of BNF that is 46 already formally documented would be a substantial piece of work. 48 This document provides a formal definition of the variant of BNF that 49 has been used (that we call Routing BNF), and makes it available 50 for use by new protocols. 52 Table of Contents 54 1. Introduction ................................................... 2 55 1.1. Terminology .................................................. 3 56 1.2. Existing Uses ................................................ 3 57 1.3. Applicability Statement ...................................... 3 58 2. Formal Definitions ............................................. 4 59 2.1. Rule Definitions ............................................. 4 60 2.1.1. Rule Name Delimitation ..................................... 5 61 2.1.2. Objects .................................................... 5 62 2.1.3. Constructs ................................................. 5 63 2.1.4. Messages ................................................... 5 64 2.2. Operators .................................................... 5 65 2.2.1. Assignment ................................................. 6 66 2.2.2. Concatenation .............................................. 6 67 2.2.3. Optional Presence .......................................... 6 68 2.2.4. Alternatives ............................................... 7 69 2.2.5. Repetition ................................................. 8 70 2.2.6. Grouping ................................................... 9 71 2.3. Editorial Conventions ....................................... 10 72 2.3.1. White Space ............................................... 10 73 2.3.2. Line Breaks ............................................... 10 74 2.3.3. Ordering .................................................. 10 75 2.4. Precedence .................................................. 11 76 3. Automated Validation .......................................... 12 77 4. IANA Considerations ........................................... 12 78 5. Security Considerations ....................................... 12 79 6. Acknowledgments ............................................... 12 80 7. References ................................................... 13 81 7.1. Normative References ....................................... 13 82 7.2. Informative References ...................................... 13 84 1. Introduction 86 Backus-Naur Form (BNF) has been used to specify the message formats 87 of several protocols within the Routing Area of the IETF. 88 Unfortunately these specifications are not based on any specific 89 formal definition of BNF and differ slightly from the definitions 90 provided in other places. 92 It is clearly valuable to have a formal definition of the syntax- 93 defining language that is used. It would be possible to convert all 94 existing specifications to use an established specification of BNF 95 (for example, Augmented BNF or ABNF [RFC5234]), however this would 96 require a lot of work. It should be noted that in ABNF the terminals 97 are integers (characters/bytes), while in the BNF form used to 98 define message formats, the terminals are "objects" (some kind of 99 message elements, but not individual bytes or characters) or entire 100 "messages". This means that converting existing specifications to use 101 an established BNF specification would also require extensions to 102 that BNF specification. 104 On the other hand, the variant of BNF used by the specifications in 105 question (which is similar to a subset of Extended BNF [EBNF]) is 106 consistent and has only a small number of constructs. It makes sense, 107 therefore, to provide a definition of this variant of BNF to allow 108 ease of interpretation of existing documents and to facilitate the 109 development of new protocol specifications using the same variant of 110 BNF. A specification will also facilitate automated verification of 111 the formal definitions used in future documents. 113 This document provides such a specification and names the BNF variant 114 Routing BNF (RBNF). 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 1.2. Existing Uses 124 The first notable use of the variant of BNF that concerns us is in 125 the specification of the Resource Reservation Protocol (RSVP) 126 [RFC2205]. RSVP has been extended for use in Multiprotocol Label 127 Switching (MPLS) networks to provide signaling for Traffic 128 Engineering (TE) [RFC3209], and this has been developed for use as 129 the signaling protocol in Generalized MPLS (GMPLS) networks 130 [RFC3473]. 132 Each of these three uses of RSVP has given rise to a large number of 133 specifications of protocol extensions to provide additional features 134 over and above those in the base documents. Each new feature is 135 defined in its own document using the common variant of BNF. 137 New protocols have also been specified using the same variant of BNF. 138 This has arisen partly because the developers were familiar with the 139 BNF used in [RFC2205], etc., but also because of the overlap between 140 the protocols especially with respect to the network objects 141 controlled and operated. 143 Notable among these additional protocols are the Link Management 144 Protocol (LMP) [RFC4204] and the Path Computation Element Protocol 145 (PCEP) [RFC5440]. In both cases further documents that specify 146 protocol extensions also use the same variant of BNF. 148 1.3. Applicability Statement 150 RBNF as defined in this document is primarily applicable for the 151 protocols listed in the previous section. The specification may be 152 used to facilitate the interpretation of the pre-existing RFCs that 153 are referenced. It should also be used in the specification of 154 extensions to those protocols. 156 RBNF could also be used for the specification of new protocols. This 157 is most appropriate for the development of new protocols that are 158 closely related to those that already use RBNF. For example, PCEP is 159 closely related to RSVP-TE and when it was developed, the PCE working 160 gorup chose to use the same form of BNF as was already used in the 161 RSVP-TE specifications. 163 If a wholly new protocol is being developed and is not related to a 164 protocol that already uses RBNF, the working group should consider 165 carefully whether to use RBNF or to use a more formally specified and 166 broader form of BNF such as ABNF [RFC5234]. 168 The use of RBNF to specify extensions to protocols that do not 169 already use RBNF (i.e., that use some other form of BNF) is not 170 recommended. 172 2. Formal Definitions 174 The basic building blocks of BNF are rules and operators. At its 175 simplest form, a rule in the context we are defining is a protocol 176 object that is traditionally defined by a bit diagram in the protocol 177 specification. Further and more complex rules are constructed by 178 combining other rules using operators. The most complex rule is the 179 message that is constructed from an organization of protocol objects 180 as specified by the operators. 182 An RBNF specification consists of a sequence of rule definitions 183 using the operators defined in Section 2.2. One rule may be 184 constructed from a set of other rules using operators. The order of 185 definition of rules does not matter. That is, the sub-ordinate rules 186 MAY be defined first and then used in subsequent definitions of 187 further rules, or the top-level rules MAY be defined first followed 188 by a set of definitions of the sub-ordinate rules. 190 Rule definitions are read left-to-right on any line, and the lines 191 are read top-to-bottom on the page. This becomes particularly when 192 considering sequences of rules and operators. 194 2.1. Rule Definitions 196 No semantics should be assumed from special characters used in rule 197 names. For example, it would be wrong to assume that a rule carries a 198 decimal number because the rule name begins or ends with the letter 199 "d". However, individual specifications MAY choose to assign rule 200 names in any way that makes the human interpretation of the rule more 201 easy. 203 2.1.1. Rule Name Delimitation 205 All rule names are enclosed by angle brackets ("<" and ">"). Rule 206 names MAY include any printable characters, but MUST NOT include tabs 207 or line feeds/breaks. 209 Example: 210 212 2.1.2. Objects 214 The most basic (indivisible) rule is termed an object. The definition 215 of an object is derived from its context. 217 Objects are typically named in upper case. They do not usually use 218 spaces within the name, favoring underbars ("_"). 220 Example: 221 223 2.1.3. Constructs 225 Rules that are constructed from other rules using operators are 226 termed constructs. 228 Constructs are named in lower case, although capitals are commonly 229 used to indicate acronyms. Spaces and hyphens are used between words 230 within names. 232 Example: 233 235 2.1.4. Messages 237 The final objective is the definition of messages. These are rules 238 that are constructed from objects and constructs using operators. The 239 only syntactic difference between a message and a construct is that 240 no other rule is typically constructed from a message. 242 Messages are typically named in title case. 244 Example: 245 247 2.2. Operators 249 Operators are used to build constructs and messages from objects and 250 constructs. 252 2.2.1. Assignment 254 Assignment is used to form constructs and messages. 256 Meaning: 257 The named construct or message on the left-hand side is defined to 258 be set equal to the right-hand side of the assignment. 260 Encoding: 261 colon, colon, equal sign ("::=") 263 Example: 264 ::= 266 Note: 267 The left-hand side of the assignment and the assignment operator 268 MUST be present on the same line. 270 2.2.2. Concatenation 272 Objects and constructs can be combined as a sequence to form a new 273 construct or a message. 275 Meaning: 276 The objects or constructs MUST be present in the order specified. 277 The order of reading RBNF is stated in Section 2. 279 Encoding: 280 A sequence of objects and constructs usually separated by spaces. 281 The objects in a sequence MAY be separated by line breaks. 283 Example: 284 ::= 286 Note: 287 See Section 2.3.3 for further comments on ordering of objects and 288 constructs. 290 2.2.3. Optional Presence 292 Objects and constructs can be marked as optionally present. 294 Meaning: 295 The optional objects or constructs MAY be present or absent within 296 the assignment. Unless indicated as optional, objects and 297 constructs are mandatory and MUST be present. The optional operator 298 can also be nested to give a hierarchical dependency of presence as 299 shown in the example below. 301 Encoding: 302 Contained in square brackets ("[" and "]"). 304 Example: 305 ::= [ ] 306 307 [ ] 309 Example of nesting: 310 The optional operator can be nested. For example, 312 ::= [ [ ] ] 314 In this construction, the object OPT_2 can only be present if OPT_1 315 is also present. 317 Note: 318 The set of objects and constructs within the same pair of square 319 brackets is treated as a unit (an unnamed construct). This means 320 that when multiple objects and constructs are included within the 321 same pair of square brackets, all MUST be included when one is 322 included unless nested square brackets are used as in the previous 323 example. 325 2.2.4. Alternatives 327 Choices can be indicated within assignments. 329 Meaning: 330 Either one rule or the other MUST be present. 332 Encoding: 333 The pipe symbol ("|") is used between the objects or constructs 334 that are alternatives. 336 Example: 337 ::= 338 | 340 Notes: 341 1. Use of explicit grouping (Section 2.2.6) is RECOMMENDED to avoid 342 confusion. Implicit grouping using line breaks (Section 2.3.2) 343 is often used, but gives rise to potential misinterpretation and 344 SHOULD be avoided in new definitions. 346 2. Multiple members of alternate sets can give rise to confusion. 347 For example, 349 ::= | 350 352 could be read to mean that an instance of must 353 be present or that it is optional. 355 To avoid this type of issue, explicit grouping (see Section 356 2.2.6), or an intermediary MUST be used in all new documents 357 (existing uses are not deprecated, and automatic parsers need to 358 handle existing RFCs). See also Section 2.4 for a description of 359 precedence rules. 361 Thus: 363 ::= | 365 is not allowed in new documents and MUST be presented using 366 grouping or using an intermediary construct. For example, and 367 depending on intended meaning: 369 ::= ( ) | ( ) 371 or 373 ::= ( | ) 375 or 377 ::= 378 ::= 379 ::= | 381 or 383 ::= | 384 ::= 386 2.2.5. Repetition 388 It could be the case that a sequence of identical objects or 389 constructs is required within an assignment. 391 Meaning: 392 MAY repeat the preceding object, intermediate construct, or 393 construct. 395 Encoding: 396 Three dots ("..."). 398 Example: 399 ::= [ ] 400 401 402 [ ... ] 403 [ ] 405 Notes: 406 1. A set of zero or more objects or constructs can be achieved by 407 combining with the Optional concept as shown in the example 408 above. 410 2. Sequences can also be encoded by building a recursive construct 411 using the Alternative operator. For example: 413 ::= | 414 ( ) 416 3. Repetition can also be applied to a component of an assignment 417 to indicate the optional repetition of that component. For 418 example, the Notify message in [RFC3473] is defined as follows: 420 ::= 421 [] 422 [ [ | ] ... ] 423 [ ] 424 426 In this example, there is a sequence of zero or more instances 427 of [ | ]. One could argue that 428 the use of grouping (see Section 2.2.6) or a recursive construct 429 (see Note 2, above) would be more clear. 431 2.2.6. Grouping 433 Meaning: 434 A group of objects or constructs to be treated together. This 435 notation is not mandatory but is RECOMMENDED for clarity. See 436 Section 2.4 on Precedence. 438 Encoding: 439 Round brackets ("(" and ")") enclosing a set of objects, 440 constructs, and operators. 442 Example: 443 ::= ( ) 445 Notes: 446 1. The precedence rule in Section 2.4 means that the use of 447 grouping is not necessary for the formal interpretation of the 448 BNF representation. However, grouping can make the BNF easier to 449 parse unambiguously. Either grouping or an intermediate 450 construct MUST be used for multi-alternates (Section 2.2.4). 452 2. Line breaks (Section 2.3.2) are often used to clarify grouping 453 as can be seen in the definition of in Section 2.2.5, 454 but these are open to misinterpretation, and explicit grouping 455 is RECOMMENDED. 457 3. A practical alternative to grouping is the definition of 458 intermediate constructs as illustrated in Note 2 of Section 459 2.2.4. 461 2.3. Editorial Conventions 463 2.3.1. White Space 465 White space (that is space characters) between operators, objects, 466 and constructs is ignored, but SHOULD be used for readability. 468 2.3.2. Line Breaks 470 Line breaks within an assignment are ignored, but SHOULD be used for 471 readability. 473 Line breaks are often used to imply grouping within the precedence 474 rules set out in Section 2.4, but explicit grouping (Section 2.2.6) 475 or intermediary constructs (Section 2.2.4) SHOULD be used in new 476 definitions. 478 A line break MUST NOT be present between the left-hand side of an 479 assignment and the assignment operator (see Section 2.2.1). 481 New assignments (i.e., new construct or message definitions) MUST 482 begin on a new line. 484 2.3.3. Ordering 486 The ordering of objects and constructs in an assignment is explicit. 488 Protocol specifications MAY opt to state that ordering is only 489 RECOMMENDED. In this case, elements of a list of objects and 490 constructs MAY be received in any order. 492 2.4. Precedence 494 Precedence is the main opportunity for confusion in the use of this 495 BNF. In particular the use of alternatives mixed with concatenations 496 can give rise to different interpretations of the BNF. Although 497 precedence can be deduced from a "proper" reading of the BNF using 498 the rules defined above and the precedence ordering shown below, 499 authors are strongly RECOMMENDED to use grouping (Section 2.2.6) and 500 ordering (Section 2.3.3) to avoid cases where the reader would 501 otherwise be required to understand the precedence rules. 503 Automated readers are REQUIRED to parse rules correctly with or 504 without this use of grouping. 506 The various mechanisms described in the previous sections have the 507 following precedence, from highest (binding tightest) at the top, to 508 lowest and loosest at the bottom: 510 objects, constructs 511 repetition 512 grouping, optional 513 concatenation 514 alternative 516 Note: 517 Precedence is the main opportunity for confusion in the use of BNF. 518 Authors are strongly RECOMMENDED to use grouping (Section 2.2.6) in 519 all places where there is any scope for misinterpretation even when 520 the meaning is obvious to the authors. 522 Example: 523 An example of the confusion in precedence can be found in Section 524 3.1.4 of [RFC2205] and is mentioned in Section 2.2.4. 526 ::= | 527 529 The implementer MUST decide which of the following is intended. 531 a. ::= | 532 ( ) 534 b. ::= ( | ) 535 537 The line break MAY be interpreted as implying grouping, but that is 538 not an explicit rule. However, the precedence rules say that 539 Concatenation has higher precedence than the Alternative operator. 540 Thus, the text in [RFC2205] SHOULD be interpretted as shown in 541 formulation a. 543 Similarly (from the same section of [RFC2205]) 545 ::= 546 | 547 549 SHALL be interpretted as 551 ::= 552 ( ) | 553 ( ) 555 The use of explicit grouping or intermediary constructs is strongly 556 RECOMMENDED in new text to avoid confusion. 558 3. Automated Validation 560 RBNF would be appropriate for verification using automated validation 561 tools. Validation tools need to be able to check for close 562 conformance to the rules expressed in this document to be useful for 563 verifying new documents, but should also be able to parse RBNF as 564 used in existing RFCs. No tools are known at this time. 566 4. IANA Considerations 568 This document makes no requests for IANA action. 570 5. Security Considerations 572 This document does not define any network behavior and does not 573 introduce or seek to solve any security issues. 575 It may be noted that clear and unambiguous protocol specifications 576 reduce the likelihood of incompatible or defective implementations 577 that might be exploited in security attacks. 579 6. Acknowledgments 581 Thanks to Magnus Westerlund, Nic Neate, Chris Newman, Alfred Hoenes, 582 Lou Berger, Julien Meuric, Stuart Venters, Tom Petch, Sam Hartman, 583 and Pasi Eronen for review and useful comments. 585 7. References 587 7.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, March 1997. 592 7.2. Informative References 594 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S., and S. 595 Jamin, "Resource ReserVation Protocol -- Version 1 596 Functional Specification", RFC 2205, September 1997. 598 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 599 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 600 Tunnels", RFC 3209, December 2001. 602 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 603 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 604 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 606 [RFC4204] Lang, J., Ed., "The Link Management Protocol (LMP)", RFC 607 4204, September 2005. 609 [RFC5234] Crocker, D. (Ed.) and Overell, P., "Augmented BNF for 610 Syntax Specifications: ABNF", STD 68, RFC 5234, January 611 2008. 613 [RFC5440] Vasseur, J.P., and Le Roux, J.-L., "Path Computation 614 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 615 March 2009. 617 [EBNF] ISO/IEC 14977, "Information technology -- Syntactic 618 metalanguage -- Extended BNF", 1996 620 Author's Address 622 Adrian Farrel 623 Old Dog Consulting 625 Email: adrian@olddog.co.uk 627 Intellectual Property 629 The IETF Trust takes no position regarding the validity or scope of 630 any Intellectual Property Rights or other rights that might be 631 claimed to pertain to the implementation or use of the technology 632 described in any IETF Document or the extent to which any license 633 under such rights might or might not be available; nor does it 634 represent that it has made any independent effort to identify any 635 such rights. 637 Copies of Intellectual Property disclosures made to the IETF 638 Secretariat and any assurances of licenses to be made available, or 639 the result of an attempt made to obtain a general license or 640 permission for the use of such proprietary rights by implementers or 641 users of this specification can be obtained from the IETF on-line IPR 642 repository at http://www.ietf.org/ipr 644 The IETF invites any interested party to bring to its attention any 645 copyrights, patents or patent applications, or other proprietary 646 rights that may cover technology that may be required to implement 647 any standard or specification contained in an IETF Document. Please 648 address the information to the IETF at ietf-ipr@ietf.org. 650 The definitive version of an IETF Document is that published by, or 651 under the auspices of, the IETF. Versions of IETF Documents that are 652 published by third parties, including those that are translated into 653 other languages, should not be considered to be definitive versions 654 of IETF Documents. The definitive version of these Legal Provisions 655 is that published by, or under the auspices of, the IETF. Versions of 656 these Legal Provisions that are published by third parties, including 657 those that are translated into other languages, should not be 658 considered to be definitive versions of these Legal Provisions. 660 For the avoidance of doubt, each Contributor to the IETF Standards 661 Process licenses each Contribution that he or she makes as part of 662 the IETF Standards Process to the IETF Trust pursuant to the 663 provisions of RFC 5378. No language to the contrary, or terms, 664 conditions or rights that differ from or are inconsistent with the 665 rights and licenses granted under RFC 5378, shall have any effect and 666 shall be null and void, whether published or posted by such 667 Contributor, or included with or in such Contribution. 669 Disclaimer of Validity 671 All IETF Documents and the information contained therein are provided 672 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 673 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 674 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 675 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 676 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 677 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 678 FOR A PARTICULAR PURPOSE. 680 Full Copyright Statement 682 Copyright (c) 2009 IETF Trust and the persons identified as the 683 document authors. All rights reserved. 685 This document is subject to BCP 78 and the IETF Trust's Legal 686 Provisions Relating to IETF Documents in effect on the date of 687 publication of this document (http://trustee.ietf.org/license-info). 688 Please review these documents carefully, as they describe your 689 rights and restrictions with respect to this document. 691 This document may contain material from IETF Documents or IETF 692 Contributions published or made publicly available before November 693 10, 2008. The person(s) controlling the copyright in some of this 694 material may not have granted the IETF Trust the right to allow 695 modifications of such material outside the IETF Standards Process. 696 Without obtaining an adequate license from the person(s) 697 controlling the copyright in such materials, this document may not 698 be modified outside the IETF Standards Process, and derivative 699 works of it may not be created outside the IETF Standards Process, 700 except to format it for publication as an RFC or to translate it 701 into languages other than English.