Comments below. On Tue, 4 Mar 2003, The IESG wrote: > The IESG has received a request to consider Instructions to Request for > Comments (RFC) Authors <draft-rfc-editor-rfc2223bis-04.txt> as a BCP. > This has been reviewed in the IETF but is not the product of an IETF > Working Group. a very important thing to note ------------------------------ [10] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999. ==> hopefully this isn't the reference practise, should be s/E. Panitz/Panitz, E./, right? This seems to be happening with almost all the drafts, with the last of multiauthor lists, so I'm fearing a bug in the tools? (of course, tools aren't the problem of IESG, RFC-ED etc. as such, but should be noted and corrected ASAP.) non-editorial: -------------- This Request for Comments (RFC) document provides instructions for authors regarding the preparation of RFCs and describes RFC publication policies. For the latest version of this document, see ==> Is this intentional? Would it be more useful to just document the rfc editorial policies, and leave the politics (which could change one way or the other) out? (I'm ok with both approaches) ==> "publication policies"? Abstract says "editorial policies", btw. Abbreviations (e.g., acronyms) in a title should generally be expanded; the exception is abbreviations that are so common (like TCP, IP, SNMP, FTP, etc.) that every member of the IETF can be expected to recognize them immediately. It is often helpful to ==> would it be the time to start recognizing IPv6 under this category..? It has been over 10 years... :-) 2.10 IANA Considerations Many RFCs define protocol specifications that require the assignment of values to protocol parameters, and some define new parameter fields. Assignment of these parameter values is often (and sometimes must be) deferred until publication of the defining RFC. The IANA and the RFC Editor collaborate closely to ensure that all required parameters are assigned and entered into the final RFC text. Any RFC that defines a new "namespace" [9] of assigned numbers should include an IANA Considerations section specifying how that space should be administered. See "Guidelines for Writing an IANA Considerations Section in RFCs" [9] for a detailed discussion of the issues to be considered and the contents of this section. ==> so, IANA considerations is not needed if you're just requesting a few values from existing namespaces? It would seem to make sense to have a section anyway (at least in the I-D's if not necessarily RFC's). In some namespaces, there are some subsets of a namespace (example: different option values in IPv6 hop-by-hop/destination options header), so specifying the requested values somewhere might be useful. ==> same in 4.11 Obsoletes Specifies an earlier document that is replaced by the new document. The new document can be used alone as a replacement for the obsoleted document. The new document may contain revised information or all of the same information plus some new information, however extensive or brief that new information may be. ==> for clarification: I've sometimes seen text like "XXX obsoletes RFC YYY. RFC YYY will become Historic". I assume there is no connection between Obsoleted and Historic, and the above text is just heretic & unclear for not separating the actions properly? Many RFC documents have appendices, some of which may be very extensive. It is often customary in academic publications to place appendices at the very end, after references. This is permissible in an RFC, but we recommend that an author place any appendices at the end of the body of the text and before the references. This is appropriate because the references of an RFC may be normative and should therefore be clearly accessible at the very end of the document. ==> is this really the recommendation? The intent of appendices, IMO, is to separate stuff should considered separate from the RFC, and putting it in after the references (at least) seems like a much better idea mostly editorial: ----------------- document [2]. The IESG may also specify that a document is to become part of the STD or TYI sub-series (Best Common ==> s/TYI/FYI/ not listed, please send e-mail to the authors of the document, and CC: the RFC Editor (Section 5.) 2.2 Not all RFCs are Standards ==> perhaps use a more formal wording for "CC:" ==> s/all/All/ Some standards track document use certain capitalized words ==> s/track/-track/ ==> s/document/documents/ (4) The Authors' Address section at the end of the RFC must ==> s/s'/'s/ or s/Address/Addresses/ ? 7. Body of memo ==> s/of/of the/ 13. Authors' Address ==> see above An Abstract will typically be 5-10 lines, but an Abstract of more than 20 lines is generally not acceptable. ==> is there a missing s/be/be at least/, otherwise "but" is awkward and rewording is needed. No specific format is required, but the following example illustrates a useful format: 1. INTRODUCTION ............................................... 5 1.1 The Internet Architecture .............................. 6 ==> Make that s/INTRODUCTION/Introduction/ :-) 4.7 Body of Memo ==> s/of/of the/ See [15} for IESG guidance on the use of formal languages in RFCs. ==> s/}/]/ 3. Abstract | 4.5 > Unnumbered section | ==> note that a lot of other sections are also unnumbered. Normative References [2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ==> any guidance on the ordering? Personally I like the approach where the refs are sorted by the number here, or references in the format of [KEYWORDS] is used. [10] Eastlake, D. and E. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999. ==> hopefully this isn't the reference practise, should be s/E. Panitz/Panitz, E./, right? This seems to be happening a lot with the last of multiauthor lists, so I'm fearing a bug in the tools. ==> same also applies to a few other refs -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings