Subject: [Rfced-future] Fwd: [IAB] I18ndir last call review of draft-iab-rfcefdp-rfced-model-11

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 25 Feb 2022 13:35:41 +0100

FYI

> Begin forwarded message:
> 
> From: Martin Dürst via Datatracker <[email-masked]>
> Subject: [IAB] I18ndir last call review of draft-iab-rfcefdp-rfced-model-11
> Date: 25. February 2022 at 13:21:58 CET
> To: <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Reply-To: Martin Dürst <[email-masked]>
> 
> Reviewer: Martin Dürst
> Review result: Almost Ready
> 
> [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.
> 
> 
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Feb 2022 07:30:59 +0100

Hi Martin,

Thanks for your review.  On the whole, most of your comments are 
editorial, and Peter should review.  There are a handful that are not, 
and I will comment on them here:

On 25.02.22 13:35, Mirja Kuehlewind wrote:
>> where April Fool RFCs go?

April Fools RFCs are sent to and considered by the ISE in consultation 
with the RPC.

>> also has to follow this policy.
The LLC role is described in detail below.  I don't think mention is 
necessary here.

>> Should this read "as long as they are consistent with [RFC 2418] and this

Do we say anything else in that document?

>> these things happening are very low, but in the whole new process, 

As you are aware, this was painfully negotiated text, and as you point 
out, this is a corner case.

>> does currently, I'd replace it with "publishing".
Adding the website responsibility seems reasonable.  The word 
"depositing" matters in as much as other repositories are involved, such 
as the U.S. Library of Congress or the like.

>> also had consulting/advisory roles, and these are now held by the RSCE.

I think that's fair.  Others?

Eliot

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 28 Feb 2022 17:06:23 +0900

Hello Eliot,

> and I will comment on them here:

Many thanks for your comments.

> April Fools RFCs are sent to and considered by the ISE in consultation 

Ok, so this should be in good hands :-).

> The LLC role is described in detail below.  I don't think mention is 

Well, things will probably work out either way. But in my view, it would 
be better if it were clear here that the LLC has to follow accepted 
policies, too.

> Do we say anything else in that document?

By "this document", I mean draft-iab-rfcefdp-rfced-model and the RFC 
that it will (hopefully soon) become. Which document do you mean by 
"that document"?

> out, this is a corner case.

I'm definitely aware of all the background, but in my role as a 
reviewer, I wanted to make sure others are, too.

> as the U.S. Library of Congress or the like.

Yes, but that's covered by the *second* bullet of point 17, reading
*  depositing copies with external archives
There, as you say, "depositing" is a very good choice.

My comment was that for the *first* bullet of point 17, "depositing" 
doesn't make much sense.

> I think that's fair.  Others?

Regards,   Martin.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 28 Feb 2022 10:45:45 +0100

Hi Martin,

Thanks. Just to close the loop:

On 28.02.22 09:06, Martin J. Dürst wrote:
> Well, things will probably work out either way. But in my view, it 
> would be better if it were clear here that the LLC has to follow 
> accepted policies, too.

We are very careful in the draft *not* to be prescriptive to the LLC as 
a whole.  The board in particular cannot be bound to this document, 
though they can be guided.

> that it will (hopefully soon) become. Which document do you mean by 

draft-iab-rfcefdp-rfced-model.  Yes.

>> As you are aware, this was painfully negotiated text, and as you 
>> point out, this is a corner case.
>

Ok.

>> "depositing" matters in as much as other repositories are involved, 
>> such as the U.S. Library of Congress or the like.
>

Ah ok.  Then I leave this to Peter as well, editorially.

Regards,

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Mar 2022 08:58:15 +1300

Responding to Eliot's direct question:

On 28-Feb-22 19:30, Eliot Lear wrote:

...

> I think that's fair.  Others?

Yes, I think that's exactly right and it's a factual correction, not
a change of intent.

    Brian