Subject: Re: Last Call: Instructions to Request for Comments (RFC) Authors to BCP

From: Geoff Huston <[email-masked]>
Date: Thu, 06 Mar 2003 09:36:21 +1100

>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by 2003-4-8.
>
>Files can be obtained via 
>http://www.ietf.org/internet-drafts/draft-rfc-editor-rfc2223bis-04.txt

I would like to make four comments on this document in response to this 
last call

1.  Section 2.4 reads:

    2.4 Publication Format(s)
  [...]
   If there is a Postscript and/or PDF version of the document (see Section 
2.4), the author should inform the RFC Editor at the time of submission of 
the ASCII version.

The self reference to section 2.4 from within 2.4 is cute in a recursive 
sense, but not strictly necessary or useful.

2. section 2.5

"When a .ps version is published, the RFC Editor will also publish a 
corresponding .pdf version by using the 'distill' utility."

I'm sure that the RFC Editor(s) would agree that all software is transient, 
and a reference to "the 'distill' utility" should be accompanied by a 
reference to its authoritative source so that readers may clearly 
understand what is being referred to here.

3. 3.2 PostScript Format Rules

Not all the world uses imperial measurement units. It would be reasonable 
to provide the metric equivalent when using "inches" to describe various 
dimensions.

4. 4.10 and 4.11

In both cases there are/will be  RFCs describing guidelines for security 
and IANA considerations,
and this document should reference them as informative references. I refer 
to draft-iab-sec-cons-03.txt and RFC 2434. Consideration should be given to 
publishing the draft-iab-sec-cons document concurrently with this document.

thanks,

    Geoff Huston

---

From: Keith Moore <[email-masked]>
Date: Wed, 5 Mar 2003 18:41:15 -0500

> understand what is being referred to here.

better yet, don't specify the distill utility part of the RFC.  let the rfc
editor choose whatever tool it wants to use at the time.  especially if adobe
changes distill so that the pdf versions it produces are not compatible with
free pdf readers (which isn't out of the question given their attempts to
promote DRM)

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 5 Mar 2003 17:08:54 -0800 (PST)

Hi,

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.
>

RFC 2026, section 10.4 (A) says "Standards track documents shall include
the following notice"; (B) says "... each standards document shall
include the following invitation."  This should be mentioned in 2223bis
in section 4 and in Appendix C (btw, the fourth subsection of App C is
labelled "B" instead of "D").

Finally, last para of sectin 4.5, "Mnemonics appearing in the Abstract"
and 'meaning of the mnemonics "IP" or "TCP" or "MIB"' -- you mean
acronym, not mnemonic.

Kireeti.

---

From: Scott Bradner <[email-masked]>
Date: Thu, 6 Mar 2003 09:59:50 -0500 (EST)

> labelled "B" instead of "D").

this may be changed in the work currently being done in teh ipr wg
specifically the currenty draft of the 2026 sec 10 replacement says
that the RFC ed will put on the IPR notice

Scott

---

From: Pekka Savola <[email-masked]>
Date: Sun, 16 Mar 2003 03:57:33 +0200 (EET)

Comments below.

> This has been reviewed in the IETF but is not the product of an IETF 

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

---

From: "C. M. Heard" <[email-masked]>
Date: Sun, 16 Mar 2003 08:32:55 -0800 (PST)

On Sun, 16 Mar 2003, Pekka Savola wrote:
>    [ ... ]

I believe that <draft-rfc-editor-rfc2223bis-04.txt> is just
reiterating what is required by RFC 2434.  The current policy
for I-Ds is, however, much as you suggest;  see
http://www.ietf.org/ID-nits.html and specifically this part:

     * IANA considerations

     * Required if IANA has to create a new registry or modify rules for
       an existing registry.
     * Required if the document requires IANA to assign or update values
       in an IANA registry before RFC publication. Note that for the
       assignment of just an OID for a MIB or PIB Module, no IANA
       Considerations section is required; it is sufficient to request
       such via a MIB/SMI or PIB/SPPI comment line,
       aka: ::= { mib-2 xxx } -- xxx to be assigned by IANA
     * See RFC 2434, and also RFC 2780 in some cases.

If this policy is to be captured in the "Instructions to Request for
Comments (RFC) Authors" document [do we really need to have _that_
acronym expanded? :) ] it should be noted that the wording that goes
in the RFC should not discuss a request for an assignment (as an I-D
usually does) but an should instead discuss the actual assignment.  This
has been done in recently-published RFCs, but inappropriate language has
slipped through in the past (see RFC 2493 for an example).

//cmh

---

From: Pekka Savola <[email-masked]>
Date: Mon, 17 Mar 2003 17:13:19 +0200 (EET)

> a very important thing to note

After getting a few private clarifying remarks (thanks!), I'd like to 
expand this a bit.

It seems this reference model is a "tradition" of a kind.

However, now that the RFC-ed policies are being re-reviewed, it should be 
excellent time to fix problems, with all due respect.

Unless, of course, there was some particular point to always writing the 
_last_ author (and that only) wrong (in the case that author-count > 1).

---

From: John C Klensin <[email-masked]>
Date: Mon, 17 Mar 2003 13:22:45 -0500

--On Monday, 17 March, 2003 17:13 +0200 Pekka Savola
<[email-masked]> 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.
>> 
>>    [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.)
> 
> After getting a few private clarifying remarks (thanks!),
> I'd like to  expand this a bit.
> 
> However, now that the RFC-ed policies are being re-reviewed,
> it should be  excellent time to fix problems, with all due
> respect.
> 
> Unless, of course, there was some particular point to always
> writing the  _last_ author (and that only) wrong (in the
> case that author-count > 1).

Pekka,

This is not just "a tradition", it is an approved form in some
style manuals.  It is most often used along with
[AUTHyyS]-type references, where "AUTH" is two or four letters
from the first author's name, yy are a two-digit year, and S
is "a"..."z" if there are more than one reference for the same
author, or for an author with the same (last) name.  One of
the controversies about the method (controversy == different
sources make different recommendations) is whether, say two
articles, one each by Joe Jones and Fred Jones, should be
cited as [JONE03a] and [JONE03b] or whether they should
preferentially appear as [JONJ03] and [JONF03].  

   LastName1, initials1, initials2 LastName2, ...
form is preferred to
    initials1 LastName1, initials2 LastName2, ...
because it is easier for the reader to identify the author
name and match it to the above referencing variants.   And
those manuals tend to prefer "Initials Lastname" (more
generally, having names appear in their natural order) in the
absence of other considerations because it is really nice to
not have ambiguity about what people are really called (those
Asian names that are normally written with the family name
first appear in natural order in that scheme, without the key
commas).

The RFC Editor's real "tradition", as I understand it, has
been to permit any reasonable reference form to be used, as
long as it is applied consistently.   I am personally
sympathetic to that tradition; I think an argument for forcing
a single format should focus clearly on the method to be
chosen and why it represents an improvement.  And, in doing
so, please remember those Asian and Spanish-style names.

     john

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 Mar 2003 00:06:37 +0200 (EET)

> so, please remember those Asian and Spanish-style names.

It seems I was not clear enough and you misinterpreted my point.  Let try 
to clarify,

> >> s/E. Panitz/Panitz, E./, right?

I have a problem of writing the author list as "Eastlake, D., and E.  
Panitz", rather than "Eastlake, D., and Panitz, E."

---

From: John C Klensin <[email-masked]>
Date: Thu, 20 Mar 2003 19:18:56 -0500

--On Tuesday, 18 March, 2003 00:06 +0200 Pekka Savola
<[email-masked]> wrote:

>> >>    [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?
> 
> I have a problem of writing the author list as "Eastlake,
> D., and E.   Panitz", rather than "Eastlake, D., and Panitz,
> E."

Nope, I understood that was your concern.  It is a valid form
according to several style manuals.  The rest of my note was
an attempt to explain why.

    john

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Mar 2003 09:01:54 +0200 (EET)

> an attempt to explain why.

Sorry, I didn't get that.

Ok -- the current format is fine as long as people aren't bound to 
miswriting the last author.

However, I'd strongly suggest adding some small amount of text to 
rationalize the editorial style, to avoid a thread like this occurring 
when people wonder whether the style is correct or not.

---

From: [email-masked]
Date: Fri, 21 Mar 2003 08:45:30 -0500

> when people wonder whether the style is correct or not.

Would a "We prefer to follow style manual XYZ" notation in the next
'guide to authors' document suffice?  Or would you want "We do this,
consult XYZ for the details" expository text?