Last Call Review of draft-iab-rfcefdp-rfced-model-11
review-iab-rfcefdp-rfced-model-11-i18ndir-lc-duerst-2022-02-25-00

[Preliminary comments on this review:
I have contributed to the IAB's RFC Editor Future Development Program (sorry,
that's the official title) and therefore to this document. I'm not sure why
Pete Resnik picked me as the reviewer, but anyway, I agreed to do it because I
hadn't done a full read-through of the document yet.

The review was requested by Mirja Kühlewind with the following words:
"We're aiming to maximize the reviews for all documents associated with the
change in the RFC Editor model. This document is the main deliverable from the
RFC future editor model program and describes the new RFC editor model. The
more eyes we get on this, the better!"]

This review was requested from the I18N Directorate. So here first my comments
re. internationalization, as far as there are some:

Progress on internationalization of RFCs has been made in the past (RFC 7997).
Some more progress in that direction seems highly desirable. In my opinion, the
new process proposed in the current document shouldn't make it more difficult
to make such progress, but on the other hand probably also won't make it much
easier. Process changes and internationalization are mostly independent of each
other. [There's also a small personal issue in the Acknowledgments section,
which mentions "Martin Duerst (note: replace "ue" with U+00FC before
publication)". I'm confident that Peter Saint-Andre and the RPC can figure how
to actually change this to "Martin Dürst".]

What follows are general comments, unrelated to internationalization. I decided
to include everything that caught my eyes, so it ended up to be quite a lot.

Abstract: It may be worth mentioning the RSCE and the Editorial Stream here,
because they are also important and new.

1. Introduction: "The RFC Editor function
   is responsible for the packaging and distribution of all RFCs;"
"packaging" sounds a bit strange; it might be better to say something like "The
RFC Editor function
   is responsible for the editing and distribution of all RFCs;"

2. Overview

It would be great if the first two paragraphs could be exchanged so that the
actual new model comes first. But this may need too much editing.

I think I might have asked that question somewhere already, but is it clear
where April Fool RFCs go? The most recently published April fool RFC　(RFC 8962)
says: "This is a contribution to the RFC Series, independently of any other RFC
stream.  The RFC Editor has chosen to publish this document at its discretion
and makes no statement about its value for implementation or deployment."
Looking around a bit, this seems to be part of the template of the Independent
Stream. Will it be in the RPC's discrecion to publish such RFCs in the future?
Essentially, the "RFC Editor" is now mostly just the RPC, and in this case, the
text looks a bit strange, not only for April fool RFCs.

"In short:": What follows isn't really any much shorter than what preceded it,
so the "in short" seems a bit misplaced.

"*  If approved, such proposals are published as RFCs in the Editorial
      Stream and thus define the policies to be followed by the RSWG,
      RSAB, RSCE, and RPC."
Shouldn't the IETF LLC also be mentioned here? My understanding is that the LLC
can say that something won't work because there's no money for it, but that
once it has accepted that a policy is implementable with reasonable means, it
also has to follow this policy.

3. Policy Definition

The first paragraph is quite long and convoluted. Something like
"Policies governing the RFC Series as a whole are defined via a three-step open
process: First ..."

3.1.1.4 Mode of Operation: The paragraph starting "When the RSWG is formed"
should be moved one paragraph down to just before the paragraph starting "The
RSWG may decide by rough consensus" (or probably better the later should be
moved up) to make people help understand what the "when ... is formed" part is
all about.

"for those unable to to attend" -> "for those unable to attend"

" The RSWG may decide by rough consensus to use additional tooling
   (e.g., GitHub as specified in [RFC8874]), forms of communication, and
   working methods (e.g., design teams) as long as they are consistent
   with [RFC2418]."
Should this read "as long as they are consistent with [RFC 2418] and this
document?"

3.1.2.2.  Members

"As the stream representative for the IETF stream, an IESG member
      or other person appointed by the IESG" ->
"As the stream representative for the IETF stream, an IESG member
      or another person appointed by the IESG"
(And same for the next three bullets; it feels unnatural to have the "an" apply
over an "or", and it feels even less natural to have to imagine an "an" for the
later two bullets where the preceding options take the definitive article.)

3.1.2.4.  Vacancies
This is the part that I'm really still not sure about. First, there's a problem
with what the text means. Imagine a first 3-month period, during which a second
3-month period starts. So far, the text is clear. But let's say then there's a
third 3-month period, which overlaps with the second one. Does that extend the
delay again? Or is there only one delay, because the text mentions only one
delay? This should be clarified. On a higher level, I think the probability of
these things happening are very low, but in the whole new process, this is one
of the weakest points.

3.1.2.6.  Mode of Operation
"although topics that require confidentiality (e.g., personnel
matters) may be elided from such archives or discussed in private."
The "elided" part is wishful thinking. If something is published once, it's
out. "eliding" doesn't really help. So I wouldn't mention this.

3.2.  Process: This section may benefit from a bit of introductory text.

3.2.2.  Workflow, point 2:
"If by following working group procedures for rough consensus the
chairs determine that there is sufficient interest in the
proposal, the RSWG may adopt the proposal as a draft proposal of
the RSWG...": The "may" here 'may' be correct logically, but because it turns
up so late in the sentence, it's difficult to read this other than "even if the
chairs determine that there is sufficient interest, it's still just a 'may'". I
think this would be wrong. Reordering the sentence to have the 'if' part after
the 'may' part should solve this.

point 3:
"Members of the RSAB are expected to participate as
individuals in all discussions relating to RSWG proposals so
that they are fully aware of proposals early in the policy
definition process, and so that any issues or concerns that they
have will be raised during the development of the proposal, not
left until the RSAB review period."
This sentence is simply too long, in particular because after the last comma,
it would make sense replace "not" by "and will not be". So please split this
sentence into smaller ones.

point 4: "call for comment": from a quick search, it seems that "call for
comments" is much more widely used, and I suggest to follow that throughout
this document. I feel it's also more encouraging, asking for as many as there
might be rather than pretending it might be only one or, if there is more, just
treating it as an amorphous mass. Also, at least according to Wikipedia, RFC
itself stands for "Request for Comments", not for "Request for Comment". [this
applies thoughout the document, to quite a few instances]

point 7:
"If the scope of the revisions made in the previous step is large":
It might be better to change "large" to "substantial", because that might
better express that it's not only about the volume of changes, but also about
their impact (at least I hope so).

point 9:
"the RSAB will then poll among its members regarding the proposal":
Does this need to be so indirect? Why not just something like "poll its members
for positions on the proposal"?

point 15:
"unless the IETF LLC objects pending resolution of resource or contract
issues": "objects pending" is a bit obscure. "unless they are delayed while the
IETF LLC resolves pending resource or contract issues". This would make it
clearer that the IETF LLC cannot object to the policies themselves at this
point.

3.2.3.  Community Calls for Comment
"A URL to the Internet-Draft that defines the proposal" ->
"A URL pointing to the Internet-Draft that defines the proposal"

"Any commentary or questions for the community that the RSAB deems
necessary (using their usual decision-making procedures)"
"Any commentary" -> "Any explanations" (commentary sounds just a bit too
academic)

3.2.6.  RFC Boilerplates
"Each stream to which the boilerplate applies, which approves that the
boilerplate meets its needs": This can be read as the boilerplate approving the
boilerplate. Not sure how to fix this, but if somebody has a good idea, please
apply it.

4.  Policy Implementation

4.1.  Roles and Processes
"by legacy RFCs which apply to the RPC and which have not yet been superseded
by Editorial Stream RFCs": "legacy" -> "existing" (Legacy can mean leftover,
outdated, old, but my understanding is that these RFCs are perfectly fine, no
rush and no need to update them. Caution: the word 'legacy' turns up again
later and should be fixed there, too.)

4.3.  RPC Responsibilities
point 17: "depositing copies on the RFC Editor site both individually and in
collections": As far as I understand, maintaining the RFC Editor website will
also be the responsibility of the RPC, but this isn't listed in these points.
This should be added. The word "depositing" then makes even less sense than it
does currently, I'd replace it with "publishing".

point 22: "Providing storage and preservation of records.": I (mis)read this as
"Providing storage, and preservation of records". Maybe "Providing for the
storage and preservation of records" would avoid such misreading.

4.4.  Resolution of Disagreements between Authors and the RPC
"If there is a conflict with a policy for a particular stream, the
RPC should consult with the relevant stream approving body and
other representatives of the relevant streams to help achieve a
resolution, if needed also conferring with a per-stream body such
as the IESG or IRSG."
This looks like a mess. We have
- the relevant stream approving body
- other representatives of the relevant streams
- a per-stream body
To me, these seem to be one and the same thing three times. If they are
supposed to be the same, then we shouldn't need to mention them three times. If
the intent was that these should be different, then the text has to be written
so that the difference is much clearer.

5.4.  Conflict of Interest
Unclear whether the following is one or two paragraphs:
>>>>
   The RPC service provider may contract services from the RSCE service
   provider, and vice versa including for services provided to the IETF
   LLC.  All contracts between the two must be disclosed to the IETF
   LLC.
   Where those services are related to services provided to the IETF
   LLC, IETF LLC policies shall apply, including publication of relevant
   parts of the contract.
>>>>
Also unclear how that's being generate. Also, there are other, similar
instances.

6.  Editorial Stream
   All documents produced by the RSWG and approved by the RSAB shall be
   published as RFCs in the Editorial Stream with a status of
   Informational.
I think there should be an additional sentence saying that despite the name of
the status, these documents nevertheless define policy. (in the long term, a
better name for the status may be desirable, such as "RFC Policy" or something
similar)

8.2.  RFC Series Editor
   Implied by the changes outlined in the previous section, the
   responsibilities of the RFC Series Editor (RSE) as a person or role
   (contrasted with the overall "RFC Editor function") are now split or
   shared among the RSWG, RSAB, RPC, and IETF LLC (alone or in
   combination).
In this list, the RSCE should also be mentioned, because the RFC Series Editor
also had consulting/advisory roles, and these are now held by the RSCE.

9.  Updates to This Document
I think this section should be before section 8, because it's material for the
future, whereas Section 8 is just documentary about the past.