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

[Peter Saint-Andre <[e-mail]>]

Hi Martin,

Thanks for your careful review. Comments inline.

On 2/25/22 5:35 AM, Mirja Kuehlewind wrote:
> FYI
> 
>> Begin forwarded message:
>>
>> *From: *Martin Dürst via Datatracker <[e-mail] 
>> <mailto:[e-mail]>>
>> *Subject: **[IAB] I18ndir last call review of 
>> draft-iab-rfcefdp-rfced-model-11*
>> *Date: *25. February 2022 at 13:21:58 CET
>> *To: *<[e-mail] <mailto:[e-mail]>>
>> *Cc: *[e-mail] <mailto:[e-mail]>, [e-mail] 
>> <mailto:[e-mail]>, [e-mail] 
>> <mailto:[e-mail]>
>> *Reply-To: *Martin Dürst <[e-mail] 
>> <mailto:[e-mail]>>
>>
>> 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.

I suggest adding the following sentences to the Abstract:

    In addition, several responsibilities previously assigned to the "RFC
    Editor" or, more precisely, the "RFC Editor function" are now
    performed by the RSWG, RSAB, RPC, RFC Series Consulting Editor
    (RSCE), and IETF LLC (alone or in combination). Finally, this
    document establishes the Editorial Stream for publication of future
    policy definition documents produced through the processes defined
    herein.

>> 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;"

I agree that "packaging" is a slightly strange word, although I'll note 
that this text was copied directly from RFC 8728 / 6635 and from RFC 
5620 before that. Among potential synonyms such as "production", 
"collection", or "presentation", I think "production" is likely closest 
to our intent, but I might check with Olaf Kolkman (editor of RFC 5620) 
to see if he recalls why we chose this particular word.

>> 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 don't see the advantages of this proposed change.

>> 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.

While I acknowledge that the text looks a bit strange, I don't have an 
easy suggestion for making it less strange.

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

The "in short" is prospective, not retrospective, so I'll change it to:

    As described more fully in the remainder of this document, the core
    functions and responsibilities are as follows:

>> "*  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.

See reply later in this thread from Jay Daley.

>> 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 ..."

Sure, I'll break this into numbered bullets...

    Policies governing the RFC Series as a whole are defined through the
    following high-level process:

    1. Proposals must be submitted to, adopted by, and discussed within
       the RFC Series Working Group (RSWG).

    2. Proposals must pass a last call for comments in the working group
       and broader community (see {{cfc}}).

    3. Proposals must be approved by the RFC Series Approval Board
       (RSAB).

>> 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.

Agreed.

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

Noted.

>> " 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?"

WFM.

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

The current text sounds fine to my ear.

>> 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.

See discussion later in this thread.

>> 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.

Perhaps "omitted" is clearer - such topics would never be included in an 
archive in the first place (as opposed to included and then deleted).

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

Nothing comes immediately to mind, but I'll ponder it further.

>> 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.

I suggest:

    2. The RSWG may adopt the proposal as a draft proposal of the RSWG,
       if the chairs determine (by following working group procedures for
       rough consensus) that there is sufficient interest in the
       proposal; this is similar to the way a working group of the IETF
       would operate (see RFC2418).

>> 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.

Good catch. I suggest:

    Members of the RSAB are expected to participate as individuals in
    all discussions relating to RSWG proposals. This should help to
    ensure that they are fully aware of proposals early in the policy
    definition process. It should also help to ensure that RSAB members
    will raise any issues or concerns during the development of the
    proposal, and not wait until the RSAB review period.

>> 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]

Yes, that's better.

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

Agreed.

>> 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"?

Yes.

>> 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.

Yes, that's clearer.

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

+1

>> 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.

I think "Each relevant stream" should do 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.)

Agreed.

>> 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. 

I suggest that "Maintaining the RFC Editor website" should be #21 in the 
list of responsibilities (incrementing the subsequent items by one).

>> The word "depositing" then makes even less sense 
>> than it
>> does currently, I'd replace it with "publishing".

Later in this thread I suggested "posting".

>> 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.

That works.

>> 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.

Yes, that text is a bit of a muddle. I suggest:

    * If there is a conflict with a policy for a particular stream, to
      help achieve a resolution the RPC should consult with the relevant
      stream approving body (such as the IESG or IRSG) and other
      representatives of the relevant stream as appropriate.

>> 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.

In the source file it's one paragraph.

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

Sure, we can add text like this:

    Notwithstanding the status of "Informational", it should be
    understood that documents published in the Editorial Stream define
    policies for the RFC Series as a whole.

>> 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.

Yes, we discussed that later in the thread.

>> 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.

That seems slightly better.

Once again, thanks for the review.

Peter