Instructions to Request for Comments (RFC) Authors
draft-rfc-editor-rfc2223bis-08

Section 1.2.1 indicates that individual submissions are
reviewed by the RFC editor for various things (relevancy,
apporpriateness, compliance...), but it does not indicate
that the RFC editor reviews submissions that come through
the IESG or IAB.

This seems misleading, as I know that the RFC editor
does review (and sometimes modifies) IESG and IAB
submissions, particularly for editorial nits, and
perhaps for clarity.

Appendix B refers to document (example: 2-nroff.template),
without indicating where those documents can be found.

[Ballot comment]
Section 1.2.1 indicates that individual submissions are
reviewed by the RFC editor for various things (relevancy,
apporpriateness, compliance...), but it does not indicate
that the RFC editor reviews submissions that come through
the IESG or IAB.

This seems misleading, as I know that the RFC editor
does review (and sometimes modifies) IESG and IAB
submissions, particularly for editorial nits, and
perhaps for clarity.

Appendix B refers to document (example: 2-nroff.template),
without indicating where those documents can be found.

The RFC Editor has decided that it would be best to emit this document as an Informational RFC, and intends to publish "soon". The RFC Editor intends to send a message to the IETF-announce list announcing that this change in intended status has taken place.

The RFC Editor has decided that it would be best to emit this document as an Informational RFC, and intends to publish "soon". The RFC Editor intends to send a message to the IETF-announce list announcing that this change in intended status has taken place.

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)

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)

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)

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)

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)

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 :-)

Comments from the IAB that the document describes the RFC publication process in a way that is not entirely consistent with other documents. It needs to be either consistent or omitted.
Comments from John Klensin on a number of topics.