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

[Mirja Kuehlewind <[e-mail]>]

FYI

> Begin forwarded message:
> 
> From: Martin Dürst via Datatracker <[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]>
> Cc: [e-mail], [e-mail], [e-mail]
> Reply-To: Martin Dürst <[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.
> 
> 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.
> 
> 
> 
>