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

["Martin J. Dürst" <[e-mail]>]

Hello Peter,

On 2022-03-02 08:36, Peter Saint-Andre wrote:
> Hi Martin,
> 
> Thanks for your careful review. Comments inline.

Many thanks for your careful response.

[I have cut out parts where you agree with my comments.]

> On 2/25/22 5:35 AM, Mirja Kuehlewind wrote:
>> FYI
>>
>>> Begin forwarded message:
>>>
>>> *From: *Martin Dürst via Datatracker <[e-mail] 


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

Looks good!

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

Production would be fine by me. The others also sound a lot better than 
"packaging".

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

Let me try to explain a bit more. The section title says "Overview of 
the Model". So the reader expects to read about the (new!) model. But 
the section starts talking about the (no longer relevant) past. And that 
past will only become less relevant over time.

[It didn't help that in the copy I reviewed, printed from 
https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model-11, 
the first paragraph was at the bottom of one page, and the second at the 
top of the next page. But I don't think that was the main reason.]

So we currently have:

 >>>>
    Version 2 of the RFC Editor Model [RFC8728] defined a structure
    consisting of the RFC Series Editor, the RFC Production Center, and
    the RFC Publisher, with oversight provided by the RFC Series
    Oversight Committee (RSOC) on behalf of the Internet Architecture
    Board (IAB).

    By contrast, version 3 of the RFC Editor Model, specified here,
    provides a more consensus-oriented framework (similar in some
    respects to the structure of technical work within the IETF) that
    retains roles for specialized expertise in document editing and
    publication.
 >>>>

What I think would make more sense is something like:

 >>>>
    Version 3 of the RFC Editor Model, specified here,
    provides a consensus-oriented framework (similar in some
    respects to the structure of technical work within the IETF) that
    retains roles for specialized expertise in document editing and
    publication.

    By contrast, the predecessor, version 2 of the RFC Editor Model
    [RFC8728] defined a structure consisting of the RFC Series Editor,
    the RFC Production Center, and the RFC Publisher, with oversight
    provided by the RFC Series Oversight Committee (RSOC) on behalf
    of the Internet Architecture Board (IAB).
 >>>>

But then actually, it's even clearer that the discussion of the old 
structure doesn't contribute too much. And I may repeat myself, but over 
time, that contribution will get less and less.

[Of course, there's a bit of a chance that the new model might not work 
as well as we hope it will, and the old model will be discussed again, 
but I don't think we need to prepare for this now.]


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

Great!

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

Nice!


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

Good, but see additional comments on the list.

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

I tried several times, but it didn't sound well to me. I suggest we 
leave it to RPC editorial discretion.


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

Agreed.

>>> 3.2.  Process: This section may benefit from a bit of introductory text.
> 
> Nothing comes immediately to mind, but I'll ponder it further.

Thanks!

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

Nice.

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

Looks good.


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

Would that result in:

"Each relevant stream to which the boilerplate applies, which approves 
that the boilerplate meets its needs"

I'm really not sure that is an improvement. But maybe what about:

"Each stream to which the boilerplate applies, which approves that the
relevant boilerplate meets its needs"

(still not sure, just another idea)


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

Good idea.

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

Fine with me (I think I said so in a separate mail).


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

Looks good!

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

Great.


> Once again, thanks for the review.
> 
> Peter

Regards,   Martin.