idnits 2.17.1 draft-hoffman-rfc-author-guide-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 36. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 754. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 760. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 778 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 13, 2004) is 7166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC' is mentioned on line 303, but not defined ** Obsolete normative reference: RFC 3667 (ref. 'CONTR-RIGHTS') (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (ref. 'IPR-TECH') (Obsoleted by RFC 3979) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONS') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3330 (ref. 'IPV4-ADDR') (Obsoleted by RFC 5735) -- Obsolete informational reference (is this intentional?): RFC 3285 (ref. 'RFC-WORD') (Obsoleted by RFC 5385) -- Obsolete informational reference (is this intentional?): RFC 2629 (ref. 'RFC-XML') (Obsoleted by RFC 7749) Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Paul Hoffman, Editor 2 draft-hoffman-rfc-author-guide-01.txt VPN Consortium 3 Obsoletes: RFC 2223 4 Category: Informational September 13, 2004 5 Expires in six months 7 Instructions to Request for Comments (RFC) Authors 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable patent 12 or other IPR claims of which I am aware have been disclosed, or will be 13 disclosed, and any of which I become aware will be disclosed, in 14 accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than a "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/1id-abstracts.html 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 IPR Statement 33 By submitting this Internet-Draft, I certify that any applicable patent 34 or other IPR claims of which I am aware have been disclosed, or will be 35 disclosed, and any of which I become aware will be disclosed, in 36 accordance with RFC 3668. 38 Abstract 40 This document explains what authors who are writing Internet Drafts 41 which are intended to become Request for Comments (RFC) documents need 42 to do, and also gives suggestions for those documents. It explains the 43 process of RFC publication and lists the requirements for Internet 44 Drafts that will eventually become RFCs. 46 Table of Contents 48 1. Introduction 49 1.1 Acknowledgments 50 2. The Precursor to RFCs: Internet Drafts 51 2.1 Internet Draft preparation tools 52 2.2 Submissions from the IETF 53 2.3 Submissions from the IAB 54 2.4 Independent submissions 55 2.5 Submission from the IRTF 56 3. RFC Publication Process 57 4. General RFC Editorial Policies 58 4.1 Language and character set 59 4.2 Non-text files 60 4.3 Authors and editors listed on RFC 61 4.4 Relation to other RFCs 62 4.5 Abbreviations and acronyms in titles and abstracts 63 4.6 IANA considerations section 64 4.7 Security considerations section 65 4.8 References section 66 4.9 Author's address section 67 4.10 Titles for non-IETF RFCs 68 5. Formatting Requirements for RFCs 69 5.1 Line width 70 5.2 Page height 71 6. Suggestions for Input to the RFC Editor 72 6.1 Protocol data definitions 73 6.2 Examples 74 6.3 Pseudocode and formal languages in RFCs 75 6.4 The abstract and the introduction 76 6.5 The contributors and acknowledgements sections 77 6.6 Appendixes 78 6.7 General suggestions 79 7. Security Considerations 80 8. References 81 8.1 Normative references 82 8.2 Informative references 84 1. Introduction 86 This document provides information to authors who are writing Internet 87 Drafts which are intended to become Request for Comments (RFC) 88 documents. It includes requirements for and suggestions for the format 89 and content of the input to the RFC process. 91 Although this document describes all of the formatting and many of the 92 content requirements, it cannot be a complete discussion of the RFC 93 process because it relies on other documents, particularly other RFCs, 94 which may change or be obsoleted at different times. The reader must 95 also read all of the documents listed in the normative references 96 section. Note in particular that [CONTR-RIGHTS] and [IPR-TECH] specify 97 boilerplate text that must appear in all Internet Drafts and RFCs. 99 The RFC Editor maintains extensive information on the RFC process at its 100 web site, . The RFC Editor can be reached by 101 email at rfc-editor@rfc-editor.org. 103 1.1 Acknowledgments 105 This document is based on contributions collected over many years. 106 Major contributors include Jon Postel, Joyce Reynolds, Robert Braden, 107 Robert Shirley, and John Klensin. 109 2. The Precursor to RFCs: Internet Drafts 111 To be considered for publication as an RFC, a document must first be 112 submitted as an Internet-Draft (often called an "I-D") as described in 113 [STANDARDS-PROCESS]. This ensures an opportunity for feedback from 114 members of the Internet community and from the IESG. The Internet Draft 115 must include boilerplate text that allows RFC publication (see 116 "Guidelines to Authors of Internet-Drafts" [ID-AUTHORS]). 118 The submission and review procedures for RFCs depend upon the document's 119 source. RFC submissions may come from the IETF, from the IAB, from 120 individuals, or from the Internet Research Task Force (IRTF). 122 2.1 Internet Draft preparation tools 124 Authors have found various useful tools for preparing this text in the 125 format required by RFCs and Internet Drafts. More complete and 126 up-to-date information on such tools, including templates for some of 127 the tools, is available from the RFC Editor's web site. 129 The most popular tool for creating Internet Drafts is the XML DTD for 130 RFCs described in [RFC-XML] and a tool to format RFCs from XML source. 131 You can edit an XML file and either process it using the tool, or submit 132 the XML to a web site that will produce a text version and an HTML 133 version for you. There is also an XML-to-nroff translator suitable for 134 creating RFC text. More information on this tool is referenced from the 135 RFC Editor's web site. 137 Other tools include: 139 nroff, groff -- The nroff and groff programs are available on most 140 popular computer operating platforms. These programs use directives in 141 the text to control the formatting. The RFC Editor, in particular, uses 142 nroff for final RFC formatting. 144 Microsoft Word -- [RFC-WORD] describes in detail how to configure Word to 145 produce an ASCII text file in Internet Draft format. Note that the 146 template files are suitable only for fairly simple text formatting; they 147 may be incompatible with the more advanced features of Word. 149 LaTeX -- LaTeX is widely used for text preparation in many academic 150 environments. LaTeX in general does not produce plain ASCII text in the 151 RFC format, but there are tools that translate LaTeX to nroff. 153 2.2 Submissions from the IETF 155 RFCs originating in the IETF are submitted to the RFC Editor by the 156 IESG. The IESG considers them as described in [IESG-CHARTER]. These 157 IESG submissions are transmitted to the RFC Editor through official 158 "Protocol Action" messages, which are also recorded at the IETF web 159 site. Submissions from the IESG may be in any of the possible categories 160 for RFCs (Standards Track, Best Current Practice, Experimental, 161 Informational, or Historic.) 163 As described in [IESG-CHARTER], an Internet Draft intended for either 164 the Standards Track or Best Current Practice category must first be 165 submitted to the IESG for approval. If the IESG approves of the 166 document, it will submit the document to the RFC Editor. 168 If the IESG requests, the RFC Editor will add an "IESG Note" to a 169 published RFC, to provide clarification or guidance to readers, as 170 described in [IESG-CHARTER]. 172 Internet Drafts submitted from the IETF have some requirements that 173 allow RFC publication, described in [ID-AUTHORS]. These requirements are 174 beyond the minimum needed to get an Internet Draft published. 176 2.3 Submissions from the IAB 178 The IAB may submit documents directly to the RFC Editor for publication 179 as RFCs in the Informational or Experimental category, without IESG 180 approval or review. This is described at [IAB-SUBMISSION]. 182 2.4 Independent submissions 184 Individuals may submit documents directly to the RFC Editor for 185 publication as RFCs in the Experimental or Informational category. The 186 RFC Editor reviews each such "independent submission" for relevancy and 187 appropriateness. The RFC Editor may require updates to the Internet 188 Draft, at its discretion, sometimes through several iterations, until an 189 acceptable submission document is achieved. 191 To maintain the integrity of the RFC document series and to avoid 192 wasting scarce publication resources, the RFC Editor may reject an 193 independent submission because its content is uninteresting or 194 irrelevant, or because its editorial quality is unacceptable. The RFC 195 Editor will attempt to explain as clearly and completely as possible the 196 reasons for rejection. The RFC Editor may consult individuals expert in 197 the field. 199 After (and if) the RFC Editor has determined that an independent 200 submission is acceptable, the document is passed to the IESG for review 201 for conflict with work in progress in the IETF, as described in 202 [IESG-REVIEW]. 204 In general, the RFC Editor is charged with the final decision about 205 publication of an independent submission. 207 2.5 Submission from the IRTF 209 RFC submissions from IRTF members are normally treated as independent 210 submissions. 212 3. RFC Publication Process 214 The RFC Editor makes many editing and formatting changes to documents 215 before they become RFCs, based on the RFC Editor's policies. The goal 216 of these policies is to make the RFC series the most useful to the 217 Internet community. For example, the RFC Editor controls the content of 218 the header on the first page which describes the publication date, 219 status, and its relation to other RFCs. Another example is that the RFC 220 Editor will run every MIB through a MIB checker before publication. 222 The RFC Editor normally starts with just the Internet Draft. If the 223 authors of the draft also have the draft in a different format, that is 224 often useful to the RFC Editor and should be sent to them at the time 225 that the Internet Draft enters the RFC Editor queue. For example, if one 226 of the formatting tools described in section 7 is used, the input to 227 that tool may save the RFC Editor time in doing the final formatting. 229 An Internet Draft that is submitted to the RFC Editor enters the RFC 230 Editor's publication queue; the queue is viewable at the RFC Editor Web 231 site. The document remains in the publication queue until it is 232 published as an RFC, unless either the author withdraws it, the author 233 is very unresponsive in making requested updates, or the document is an 234 independent submission that is deemed unacceptable by the RFC Editor. 236 The RFC Editor ensures that the document follows the editorial rules 237 described later in this document. The RFC Editor may make editorial 238 changes to clarify readability and to provide a uniform style and format 239 consistent with other RFCs. For example, the RFC Editor will often 240 generate a table of contents for the document. If additional work is 241 required to satisfy to bring the RFC up to publication quality, the 242 document might be returned to the author or to the IESG for additional 243 work. 245 When editing of the document is complete, the RFC Editor sends email to 246 the authors suggesting that the authors review the revised document 247 carefully. This step is the last chance for the author to make sure 248 that the RFC Editor has not changed the technical meaning of the 249 document during the RFC Editor's processing. Each listed author or 250 editor must reply to the RFC Editor in email that he or she approves of 251 the formatting and editorial changes made by the RFC Editor. In some 252 cases, the RFC Editor needs to make further changes to the document, 253 such as making additional formatting changes or correcting some of the 254 content. All requests for changes and corrections are discussed with the 255 RFC Editor in email. (This step was historically called the "Authors' 256 48 Hours" period, although there is now no time limit on the step.) 258 In practice, the editorial process among the IESG, the RFC Editor, and 259 the author(s) can be lengthy and convoluted, and the time spent in the 260 RFC Editor's queue can vary greatly. Sometimes problems are found that 261 require document revisions by the authors. These revisions may require 262 the publication of another Internet-Draft, and the result must be re- 263 reviewed. Publication may be held up awaiting IANA assignments, or in 264 order to synchronize the publication of related RFCs. 266 RFC numbers are usually not assigned until very late in the editorial 267 process. Requests for early assignment of an RFC number are generally 268 denied unless they originate from the IAB or the IESG. 270 4. General RFC Editorial Policies 272 4.1 Language and character set 274 The IETF is an international organization with active participants from 275 dozens of countries, languages, and cultures, and it is very important 276 that all participants be able to read the standards that it produces. 277 Because of this, all RFCs must be written in the English language. 279 At the current time, all RFCs only use the US-ASCII character set, even 280 for such things as author's names and addresses. This also means that 281 all artwork in RFCs must be done in ASCII art. This topic gets 282 revisited in the IETF on a regular basis, usually with no new issues 283 being presented during the debate. 285 4.2 Non-text files 287 In a small number of cases, document authors provide secondary or 288 alternative versions in PostScript and/or PDF because of a need for 289 diagrams and graphs that cannot possibly be rendered in ASCII plain 290 text. RFCs published this way have often been not as useful as those 291 only in plain ASCII because many people do not know to retrieve the 292 alternate versions, and also because not all PostScript or PDF files 293 display well on all devices. Thus, most authors try very hard to get 294 their artwork to work as ASCII art. If you intend to publish an RFC 295 using a secondary version, contact the RFC Editor ahead of time about 296 their PostScript and PDF requirements. 298 4.3 Authors and editors listed on RFC 300 The copyright rules governing RFC publication [CONTR-RIGHTS] require 301 that an RFC must "[acknowledge] all major Contributors. A major 302 Contributor is any person who has materially or substantially 303 contributed to the [RFC]." The Contributors and Acknowledgment sections 304 of RFCs fulfill this objective. 306 The RFC Editor proposed, and the IESG ratified, a policy of limiting the 307 number of authors listed in the first page header of an RFC. That 308 policy is: 310 (1) A small set of author names, with affiliations, may appear on the 311 front page header. These should be the lead author(s) who are most 312 responsible for the actual text. When there are many contributors, the 313 best choice will be to list the person or (few) persons who acted as 314 document editor(s) (e.g.,"Tom Smith, Editor"). 316 There is no rigid limit on the size of this set, but there is likely to 317 be a discussion if the set exceeds five authors, in which case the right 318 answer is probably to list one editor. 320 The RFC Editor will hold all the people listed on the front page equally 321 responsible for the final form and content of the published RFC. In 322 particular, the "Author's 48 Hours" final approval period will require 323 sign-off from all listed authors. 325 (2) An RFC may include a Contributors section, listing those 326 contributors who deserve significant credit for the document contents. 327 The Contributors section is intended to provide a level of recognition 328 greater than an acknowledgment and nearly equal to listing on the front 329 page. The choice of either, both, or none of Contributor and 330 Acknowledgment sections in a particular RFC depends upon the 331 circumstance. 333 (3) The body of an RFC may include an Acknowledgements section, in 334 addition to or instead of a Contributors section. An Acknowledgments 335 section may be lengthy, and it may explain scope and nature of 336 contributions. It may also specify affiliations. 338 (4) The Author's Address section at the end of the RFC must include the 339 authors listed in the front page header. The purpose of this section is 340 to (1) unambiguously define author/contributor identity (e.g., the John 341 Smith who works for FooBar Systems) and to (2) provide contact 342 information for future readers who have questions or comments. 344 At the discretion of the author(s), contact addresses may also be 345 included in the Contributors section for those contributors whose 346 knowledge makes them useful future contacts for information about the 347 RFC. 349 (5) The RFC Editor may grant exceptions to these guidelines upon 350 specific IESG request or in other exceptional circumstances. 352 4.4 Relation to other RFCs 354 The RFC Editor may add an indication of the relation of a new RFC to 355 earlier RFCs. Sometimes an RFC adds information on a topic discussed in 356 a previous RFC or completely replaces an earlier RFC. Two terms are 357 used for these cases: "updates" and "obsoletes", respectively. 359 "Updates" specifies an earlier document whose contents are modified or 360 augmented by the new document. The new document cannot be used alone, 361 it can only be used in conjunction with the earlier document. 363 "Obsoletes" specifies an earlier document that is replaced by the new 364 document. The new document can be used alone as a replacement for the 365 obsoleted document. The new document may contain revised information or 366 all of the same information plus some new information, however extensive 367 or brief that new information may be. 369 4.5 Abbreviations and acronyms in titles and abstracts 371 The RFC Editor will often expand abbreviations and acronyms used in the 372 title and/or abstract of an RFC that is about to be published. The 373 exception is abbreviations that are so common that every participant in 374 the IETF can be expected to recognize them immediately; examples include 375 (but are not limited to) TCP, IP, SNMP, and FTP. Some cases are 376 marginal and the decision on expansion may depend upon the specific 377 title. 379 It is often helpful to follow the expansion with the parenthesized 380 abbreviation, such as "Encoding Rules for the Common Routing 381 Encapsulation Extension Protocol (CREEP)". 383 The RFC Editor will make the final judgment on abbreviation and acronym 384 expansion in titles and abstracts, weighing obscurity against 385 complexity. 387 4.6 IANA considerations section 389 Many RFCs define protocol specifications that require the assignment of 390 values to protocol parameters, and some define new parameter fields. 391 Assignment of these parameter values is often (and sometimes must be) 392 deferred until publication of the defining RFC. The IANA and the RFC 393 Editor collaborate closely to ensure that all required parameters are 394 assigned and entered into the final RFC text. The process for this is 395 described in [IANA-CONS]. 397 Even if the document has no IANA considerations, it is a good idea 398 to have a section that says so explicitly. The RFC Editor can decide 399 whether or not to remove this section at the time of publication. 401 4.7 Security considerations section 403 Most RFCs require a security considerations section that describes any 404 issues that affect security on the Internet. See [SEC-CONS] for more 405 information on creating a security consideration section. Even if 406 there are no security considerations for the Internet (such as in 407 this document), this section must be present. 409 4.8 References section 411 An RFC will generally contain bibliographic references to other 412 documents, and the body will contain citations to these references. If 413 there are both normative and informative references, they must be 414 clearly separated in sub-sections of the references section in the 415 document. 417 There are many styles for references, and the RFCs have one of their 418 own. Please follow the reference style used in recent RFCs; in 419 particular, see the Reference section of this RFC for an example. The 420 RFC Editor may change the style used in the references during the 421 editing phase. 423 There is no required format for a citation to a reference. It is common 424 to enclose citations in square brackets, as is exemplified in this 425 document. The naming scheme for citations is up to the authors. Some 426 authors prefer citations that name the documents (such as "RFC2119" and 427 "TCP-OPTIONS"), while others prefer citations that are by author and 428 year (such as "Pos92" and "IEEE97a"). Numbered citations are often 429 difficult for readers because the reference lists in RFCs are split into 430 normative and informative references. 432 Within an RFC, references to other documents fall into two general 433 categories: "normative" and "informative". Normative references specify 434 documents that must be read to understand or implement the technology in 435 the document, or whose technology must be present for the technology in 436 the new RFC to work. An informative reference provides additional, 437 non-essential information to the reader. For example, an informative 438 reference might provide background or historical information. Material 439 in an informative reference is not required to implement the technology 440 in the RFC. 442 The distinction between normative and informative references is often 443 important. The IETF standards process and the RFC Editor publication 444 process need to know whether a reference to a work in progress is 445 normative. A standards-track RFC cannot be published until all of the 446 documents that it lists as normative references have been published. In 447 practice, this often results in the simultaneous publication of a group 448 of interrelated RFCs. 450 The use of URLs as references in RFCs is discouraged except in cases 451 where the URL is widely believed to be stable for many years or decades, 452 and where there is no other useful reference. References to long-lived 453 files on ietf.org and rfc-editor.org are generally acceptable. 455 Informative references to Internet Drafts are allowed, but should 456 include the authors names, the title of the draft, the beginning part of 457 the Internet Draft file name, and the phrase "work in progress". For 458 instance, a reference might look like: 460 Smith, C., "The TLA Expansion Algorithm", draft-smith-tla-expansion, 461 work in progress 463 4.9 Author's address section 465 The author's address section, which is required for all RFCs, gives the 466 name(s) and some contact information for the author(s) who are listed in 467 the first-page header. Contact information must include at least a 468 postal address, a telephone number, and/or a long-lived email address 469 (only one of these is needed). The purpose of this section is to 470 unambiguously define the identity of the author(s) and/or 471 contributor(s), such as "the John Smith who works for FooBar Systems". 472 It also provides contact information for future readers who have 473 questions or comments. 475 4.10 Titles for non-IETF RFCs 477 RFCs that document a particular company's private protocol must bear a 478 title of the form "XYZZY's ... Protocol" (where XYZZY is the company's 479 name). This will clearly differentiate it from an IETF product. 481 5. Formatting Requirements for RFCs 483 The RFC Editor will use text formatting tools to change the Internet 484 Draft that is submitted to the RFC Editor into the final text RFC. 485 Because of this, the formatting of the document may change radically. 486 Most of these transformations are of no concern to the document author 487 and, in fact, are out of the author's control. A few of the changes, 488 however, are relevant to authors because it may affect the technical 489 content of the final RFC. This section covers those requirements. 491 5.1 Line width 493 Each line of the final RFC will be no more than 72 characters wide (plus 494 an end-of-line character). This means that all examples in the Internet 495 Draft from which the RFC Editor is working must have all lines 496 restricted to 72 characters with no exceptions. 498 5.2 Page height 500 RFC pages have a usable body size of 50 lines (the remaining lines on 501 the page are reserved for headers and footers). This means that 502 examples that are longer than 50 lines will be split across multiple 503 pages. 505 6. Suggestions for Input to the RFC Editor 507 6.1 Protocol data definitions 509 Many years ago, the RFC series adopted a pictorial approach to 510 representing data structures such as protocol headers. Furthermore, the 511 research community adopted a "big-endian" convention in which the bits 512 and bytes are shown in network byte order, byte zero is the first byte 513 shown, and bit zero is the most significant bit in a word or a field. 515 For example, RFC 791 contains the following definition of the IP header 516 format. 518 0 1 2 3 519 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |Version| IHL |Type of Service| Total Length | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Identification |Flags| Fragment Offset | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Time to Live | Protocol | Header Checksum | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Source Address | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Destination Address | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Options | Padding | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 6.2 Examples 536 DNS names that as used as generic examples in RFCs should use the 537 particular examples defined in [RESERVED-DNS]. IPv4 addresses in 538 generic examples should be from the range 192.0.2.0/24, as described in 539 [IPV4-ADDR]. IPv6 addresses in generic examples should be from the range 540 2001:DB8::/32, as described in [IPV6-ADDR]. 542 6.3 Pseudocode and formal languages in RFCs 544 The IESG has issued guidelines ([FORMAL-LANGS]) on using pseudocode and 545 formal languages such as ASN.1 and ABNF in RFCs. It covers topics such 546 how normative the pseudocode or formal language can be, and how to word 547 such references. 549 6.4 The abstract and the introduction 551 Every RFC must begin with an abstract. An abstract of more than 20 552 lines is generally not acceptable. The abstract should provide a 553 concise and comprehensive overview of the purpose and contents of the 554 entire document, to give a technically knowledgeable reader a general 555 overview of the function of the document. 557 A satisfactory abstract can often be constructed from a summary of some 558 of the material within the Introduction section. An abstract is not a 559 substitute for an introduction; the RFC should be self-contained as if 560 there were no Abstract section. 562 An abstract should be complete in itself; it should generally not 563 contain citations. Abbreviations appearing in the abstract should 564 generally be expanded in parentheses. 566 Each RFC should have an Introduction section that (among other things) 567 explains the motivation for the RFC. If appropriate, the introduction 568 should describe the applicability of the document, such as whether it 569 specifies a protocol, provides a discussion of some problem, is simply 570 of interest to the Internet community, or provides a status report on 571 some activity. The introduction must be the first numbered section. 573 6.5 The contributors and acknowledgements sections 575 The contributors section is an optional section lists those contributors 576 who deserve significant credit for the document. When a long author 577 list is replaced by a single editor in the front page header, the 578 displaced authors can be properly and fully acknowledged in the 579 contributors section. The contributors section may include brief 580 statements about the nature of particular contributions ("Sam 581 contributed section 3") and it may also include affiliations of listed 582 contributors. 584 An acknowledgements section may be used instead of, or in addition to, a 585 contributors section, when appropriate. 587 6.6 Appendixes 589 Many RFCs have appendices, some of which may be very extensive. Common 590 practice is to position appendixes at the very end of a document, after 591 the references. However, some RFCs have large and dense appendix 592 sections for technical details which are actually an integral part of 593 the document. In such documents, it can be difficult to locate the 594 references, and therefore it may be better to put the references after 595 the appendixes. 597 6.7 General suggestions 599 Use single-spaced text within a paragraph, and one blank line between 600 paragraphs. 602 When turning in an Internet Draft, do not fill the text with extra 603 spaces to provide a straight right margin, that is, do not right-justify 604 the text. 606 Do not use hyphenation at the right margin to split single words. 607 However, hyphenated word sequences (e.g., "Internet-Draft") may be split 608 at the hyphen across successive lines. 610 When a sentence ended by a period is immediately followed by another 611 sentence, there should be two blank spaces after the period. 613 Footnotes are strongly discouraged in RFCs. If such notes are 614 necessary, put them at the end of a section, or at the end of the 615 document. 617 Cross references within the body of the text must use section numbers 618 rather than page numbers because the RFC Editor generally adjusts 619 pagination during formatting. 621 7. Security Considerations 623 This RFC raises no new security issues. 625 8. References 627 8.1 Normative references 629 [CONTR-RIGHTS] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 630 3667, February 2004. 632 [ID-AUTHORS] IETF, "Guidelines to Authors of Internet Drafts", available 633 as 1id-guidelines.txt at http://www.ietf.org. 635 [IESG-CHARTER] Alvestrand, H., "An IESG Charter", RFC 3710, February 636 2004. 638 [IESG-REVIEW] Alvestrand, H., "The IESG and RFC Editor documents: 639 Procedures", draft-iesg-rfced-documents, work in progress. 641 [IPR-TECH] Bradner, S., "Intellectual Property Rights in IETF 642 Technology", BCP 79, RFC 3668, February 2004. 644 [STANDARDS-PROCESS] Bradner, S., "The Internet Standards Process -- 645 Revision 3", BCP 9, RFC 2026, October 1996. 647 8.2 Informative references 649 [FORMAL-LANGS] IESG, "Guidance for the use of formal languages in IETF 650 specifications", 651 http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-specs.txt, October 652 2001. 654 [IAB-SUBMISSION] IAB, "Process for Publication of IAB RFCs", 655 http://www.iab.org/documents/docs/iab-rfc-publication-process.html. 657 [IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an 658 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 660 [IPV4-ADDR] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 661 2002. 663 [IPV6-ADDR] Huston, G., et. al, "IPv6 Address Prefix Reserved for 664 Documentation", RFC 3849, July 2004. 666 [RESERVED-DNS] Eastlake, D. and E. Panitz, "Reserved Top Level DNS 667 Names", RFC 2606, June 1999. 669 [RFC-WORD] Gahrns, M. and T. Hain, "Using Microsoft Word to create 670 Internet Drafts and RFCs", RFC 3285, May 2002. 672 [RFC-XML] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 673 1999. 675 [SEC-CONS] Rescorla, E. and B. Korver., "Guidelines for Writing RFC Text 676 on Security Considerations", BCP 72, RFC 3552, July 2003. 678 Author's Address 680 Paul Hoffman 681 VPN Consortium 682 127 Segre Place 683 Santa Cruz, CA 95060 684 paul.hoffman@vpnc.org 686 Changes from -00 to -01 688 - Small editorial changes throughout based on comments from the 689 rfc-interest mailing list. 691 - Removed open questions throughout. 693 - 2.1: Moved the previous section 7 (RFC Tools) to section 2.1, and 694 expanded on xml2rfc. Renumbered the rest of section 2. 696 - 2.2: Added paragraph at the end about requirements above those for 697 turing in Internet Drafts. 699 - 2.3: Specified where the IAB submission rules are described. 701 - 4.3: Claified the origin of the number-of-names policy. 703 - 4.6: Added the second paragraph about empty IANA consideration 704 sections. 706 - 4.7: Added the last sentence about the security considerations section 707 being required even if trivial. 709 - 4.9: Clarified that only one piece of address information is required. 711 - 4.10: Added this section ("Titles for non-IETF RFCs"). 713 - 6.2: Updated this to point to the correct RFCs for example addresses 714 for IPv4 and IPv6. Also added those as references. 716 - 6.4: Shortened the description of citations in abstracts. 718 - 6.4: Added "The introduction must be the first numbered section.". 720 - References: Made all reference citations mneumonic. 722 - Author's address: fixed formatting. 724 Full Copyright Statement 726 Copyright (C) The Internet Society (2004). This document is subject to 727 the rights, licenses and restrictions contained in BCP 78, and except as 728 set forth therein, the authors retain all their rights. 730 This document and the information contained herein are provided on an 731 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 732 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 733 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 734 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 735 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 736 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 738 Intellectual Property 740 The IETF takes no position regarding the validity or scope of any 741 Intellectual Property Rights or other rights that might be claimed to 742 pertain to the implementation or use of the technology described in this 743 document or the extent to which any license under such rights might or 744 might not be available; nor does it represent that it has made any 745 independent effort to identify any such rights. Information on the 746 ISOC's procedures with respect to rights in ISOC Documents can be found 747 in BCP 78 and BCP 79. 749 Copies of IPR disclosures made to the IETF Secretariat and any 750 assurances of licenses to be made available, or the result of an attempt 751 made to obtain a general license or permission for the use of such 752 proprietary rights by implementers or users of this specification can be 753 obtained from the IETF on-line IPR repository at 754 http://www.ietf.org/ipr. 756 The IETF invites any interested party to bring to its attention any 757 copyrights, patents or patent applications, or other proprietary rights 758 that may cover technology that may be required to implement this 759 standard. Please address the information to the IETF at 760 ietf-ipr@ietf.org.