Miscellaneous Issues

[john+rfc@…]

I've gone carefully through this document. I think it needs a
lot of work. Some of that work is "just" editorial in nature:
there are typographic mistakes, grammatical issues, some
sentences that just don't make sense, and a lot of confusion in
structural sections like Acknowledgments and change logs. One
can easily deduce the intent in most cases, but not in all of
them. There are also a number of redundancies and a few
apparent contradictions.

My apologies in advance for the length of this note. There are
a lot of issues, some quite significant. I did consider
posting 30+ separate per-issue notes, but decided that would be
even worse and more burdensome.

I have focused particularly on issues that may have
consequences vis-a-vis our ability to recruit an RSE,
especially from among people who will actually analyze the
description rather than knowing the community well enough to
decide what can be ignored in practice. (As you know, the IAB
has concluded, based on community input, that even levels of
community understanding much lower than needed to make that
determination should not be a requirement for the position.)
If nothing else, some of the issues identified below, even the
more editorial ones, will make it harder to fill the RSE
position because they make us look sloppy and disorganized
(unless we find a potential candidate who sees the RSE role as
a leverage point for "fixing" the IETF, another bad idea).
Worse, it is possible that they might create suspicions that
the documentation issues are hiding, however unintentionally,
additional disconnects about authority and responsibility,
reporting chains and the authority that goes with them, etc.

Note that a few of the issues raised below have been discussed
before and, I thought resolved, but that did not make it into
the text of the current draft of this document.

As with earlier drafts of "version 2" and with "version 1" the
document tries to strike a balance among a variety of
perspectives. In a number of cases, I don't think that is
succeeding. Let me give two examples, one (relatively) easily
resolved, the other not.

More specific issues (more or less in the order in which they
appear in the draft):

(B.8) Section 2.1.2 "Representation of the RFC Series" and
2.1.2.1 "Representation to the IETF"

This is confused and needs reorganizing. There is material in
the "to the IETF" section that is not related to the IETF at
all but to the broader community. The "community at large" for
the RFC Editor isn't the IETF or even the "IETF community".
There is no "history... of interaction between the RSE and the
IETF" because there has never been a permanent (or otherwise
without qualification as "interim", "transitional", or
"acting") RSE, especially not one appointed under this
procedure. If the text is intended to mean "RFC Editor", it
should say so.

(B.14) Other issues in Section 2.14 ("Development of the RFC
Series")

If "the technical specification series" is intended to identify
a subset, then it would be helpful to be explicit, e.g., "the
portion of the series that consists of technical
specifications". If that is not the intent, I'm not sure what
is being said and a reader without experience in the community
and with the series is likely to be considerably more confused.

I believe that section should include some mention of
standards-consumers, i.e., people who use parts of the RFC
Series as a basis for procurements, conformance evaluation, and
so on. While the IETF often skips over it, that has been an
intended, and significant, use of the series for many years
(the introductory material in RFC 1122 and 1123 is illustrative
in that regard). It is a very different audience from the
audience of implementers. We often forget that and it would be
unfortunate to build forgetting it into this document.

(B.31) Section 4.3, paragraph 2 ("If such a conclusion is not
possible through those informal processes,..." and paragraph 4
("If informal agreements cannot be reached,...") are largely
redundant, but describe slightly different (i.e.,
contradictory) processes. Let's choose one or the other and
drop the confusion.

(B.18) Sections 2.3 and 2.4

I haven't done a careful review of these sections. They seem
stable since version 1 and not in this month's critical path.
I assume that, once an RSE is hired, he or she may review these
sections and suggest tuning, possibly resulting in ...model-v3.
I do suggest that, in the interest of recruitment, that
assumption be made explicit, perhaps by adding ongoing review
of expectations for the Publisher and Production function as an
explicit RSE responsibility.

Thanks to everyone who has managed to read this far.

[jmh@…]

B.8 unchanged due to inability for the editor or IAB to craft improved text.
B.14, technical specification unchanged, parties added in working draft.
B.31 I hope that the rewording in the working draft addresses the inconsistency.
B.18 subject text left unchanged.