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