Last Call on rfc2223bis-04.

[Bob Braden <braden@ISI.EDU>]

  *> 
  *> Hello,
  *> I have reviewed the Last Call comments on the Last Call for BCP status on 
  *> this document.
  *> 
  *> There seems to be a number of different concerns at various levels:
  *> 
  *> 1 - The document seems to specify the rules for RFC publication in some 
  *> detail, without being clear about whether it is claiming authority or it is 
  *> reproducing other documents' rules. In some cases, it seems in conflict 
  *> with other documents. This needs to be clear and consistent; RFC 2223 is 
  *> claimed to not have described the publication process.
  *> The suggestion has been made that the policy issues need to be separated 
  *> out in its own document - perhaps an "RFC Editor charter"? (IAB, Atkinson, 
  *> others)
  *> 

Harald,

The first sentence of section 1.3 seems to make this clear, but we can
add a statement that in case of any apparent conflict, RFC 2026 takes
precedence.

We do not accept the idea that this document should be split into
two documents, but we will endeavor to clarify any apparent confusions
or contradictions in the introduction.

  *> 2 - The document is somewhat over-specific at some points, such as 
  *> specifying which utility the RFC Editor uses to produce PDF from text. This 
  *> is probably inappropriate. (Huston, Moore)

Accepted.

  *> 
  *> 3 - There are references to other specs, such as the IESG "ID-nits", whose 
  *> stability is less than that of a BCP RFC. The form of these references 
  *> needs to be carefully considered. (Klensin)

Accepted.

  *> 
  *> 4 - Some considerations (security considerations, IANA considerations) 
  *> already have, or will have, specific RFCs talking about them. Referencing 
  *> these is preferable to reproducing a revised version of their content. 
  *> (Huston, others; IANA had specific text suggestions)
  *> 

We believe that this document should have brief statements of the
purpose and contents of these sections, with references to the full
RFCs for elaboration.

  *> 5 - The style of references preferred by the RFC Editor needs to be clear; 
  *> either the author always gets to choose, or there is one documented style, 
  *> with justification. (Hoffman, others)
  *> 

We believe this is a confusion that we have accidentally allowed to
arise, about the distinction between a reference and a citation.  We
DO have a standard form for a reference, but NOT for a citation.
(e.g., see RFC 1122).  We will certainly clarify this in the next revision.

  *> I believe that point 1, 3 and 4 HAVE to be addressed before publication - 
  *> and that the implications of doing so may be wide enough that I'm holding 
  *> back on spending significant time on finding smaller nits at this time.
  *> 
  *> However, this AD thinks that the difference between an acronym and an 
  *> abbreviation is irrelevant to the content of the document :-)
  *> 
  *> These comments have been entered into the ID-tracker, and the state changed 
  *> to "new ID needed". If appropriate, I and several others are available at 
  *> the IESG retreat for more discussion of the document.


We will now prepare a new version to erase the many red marks that we
have on our copy of -04!

Thanks,

RFC Editor/bb


  *> 
  *> Thank you!
  *> 
  *>              Harald Alvestrand, responsible AD for this document
  *>