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

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 1 Mar 2022 10:14:32 +0100

See quickly below.

> On 28. Feb 2022, at 20:58, Brian E Carpenter <[email-masked]> wrote:
> 
> Responding to Eliot's direct question:
> 
> On 28-Feb-22 19:30, Eliot Lear wrote:
> 
> ...
> 
>>>> 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.
>> I think that's fair.  Others?
> 
> Yes, I think that's exactly right and it's a factual correction, not
> a change of intent.

The RSCE is indirectly mentioned as member of the RSAB. However, not real concerns to add this role here separately as well.

Mirja

> 
>   Brian
> 
> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2022 12:15:40 -0700

On 2/28/22 2:45 AM, Eliot Lear wrote:
> Hi Martin,
> 
> Thanks. Just to close the loop:
> 
> On 28.02.22 09:06, Martin J. Dürst wrote:
>> "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.
>>>>>
>>> The LLC role is described in detail below.  I don't think mention is 
>>> necessary here.
>>
>> 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.

I'm curious if Jay has any concerns about adding the IETF LLC to this 
sentence.

>>>>> " 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?"
>>>
>>> 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"?
> 
> draft-iab-rfcefdp-rfced-model.  Yes.

Martin's suggestion seems fine.

>>>>> 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.
>>>
>>> As you are aware, this was painfully negotiated text, and as you 
>>> point 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.
> 
> 
> Ok.

Well, we could tweak it as follows:

OLD

    *  Voting on approval of policy documents produced by the RSWG shall
       be delayed until the vacancy or vacancies have been filled, up to
       a maximum of 3 months.  If during this 3-month period a further
       vacancy arises, the delay should be extended by up to another 3
       months.  After the delay period expires, the RSAB should continue
       to process documents as described below.

NEW

    *  Voting on approval of policy documents produced by the RSWG shall
       be delayed until the vacancy or vacancies have been filled, up to
       a maximum of 3 months.  If during this or any subsequent delay
       period a further vacancy arises, the delay period should be
       extended by up to another 3 months.  After the delay period
       expires, the RSAB should continue to process documents as
       described below.

But this would introduce the possibility of an infinite delay period, 
which seems suboptimal even if highly unlikely.

>>>>> 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".
>>> 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.
>>
>> 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.
> 
> Ah ok.  Then I leave this to Peter as well, editorially.

I'd change "depositing" to "posting".

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2022 12:20:41 -0700

> The RSCE is indirectly mentioned as member of the RSAB. However, not real concerns to add this role here separately as well.

Agreed.

Peter

---

From: Eliot Lear <[email-masked]>
Date: Tue, 1 Mar 2022 20:24:20 +0100

Just on this point:

> which seems suboptimal even if highly unlikely. 

Unless there is a lot of support the other way, I would prefer the OLD 
to the NEW.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Mar 2022 08:37:18 +1300

On 02-Mar-22 08:15, Peter Saint-Andre wrote:
...
> which seems suboptimal even if highly unlikely.

Which iirc is exactly why we decided on the current text. I don't
agree with the proposed change.

    Brian

---

From: Jay Daley <[email-masked]>
Date: Wed, 2 Mar 2022 09:02:34 +1300

> On 2/03/2022, at 8:15 AM, Peter Saint-Andre <[email-masked]> wrote:
> 
>>> "In short:": What follows isn't really any much shorter than what preceded it,
>>>>>> 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
>>>> The LLC role is described in detail below.  I don't think mention is necessary here.
>>> 
>>> 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.
> 
> I'm curious if Jay has any concerns about adding the IETF LLC to this sentence.

My view remains as previously expressed - RFC 8711 is unequivocal on the requirement for the LLC to "follow accepted policies":

     "Responsiveness to the community.  The IETF LLC is expected to act
      consistently with the documented consensus of the IETF community,
      to be responsive to the community's needs, and to adapt its
      decisions in response to consensus-based community feedback."

I’m opposed to any need to restate this in any RFC that does not update/replace 8711 because a) It is unnecessary - RFC 8711 says it all;  b) we then have make sure to add that language everywhere to ensure that we never imply by omission that there are circumstances under which the LLC can not follow accepted policies; c) we then have to start considering "should we also add the IESG, the IAB, the Trust?" etc.

The RSWG, RSAB, RSCE and RPC are the key subjects of this RFC and so this is the appropriate place for setting out how they are bound by policy, and we don’t need to go any further than them.

cheers
Jay

>>>>>>   (e.g., GitHub as specified in [RFC8874]), forms of communication, and
>>>>>> Should this read "as long as they are consistent with [RFC 2418] and this
>>>>>> 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"?
>>>>>> 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.
>>>> 
>>>> As you are aware, this was painfully negotiated text, and as you point 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.
>> Ok.
> 
> But this would introduce the possibility of an infinite delay period, which seems suboptimal even if highly unlikely.
> 
>>>>>> 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
>>>> 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.
>>> 
>>> My comment was that for the *first* bullet of point 17, "depositing" doesn't make much sense.

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2022 14:06:54 -0700

> agree with the proposed change.

Yeah I don't like it either - I just wanted to make it clear what the 
alternative was.

Peter

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 2 Mar 2022 08:35:11 +0900

Hello Jay, others,

> The RSWG, RSAB, RSCE and RPC are the key subjects of this RFC and so this is the appropriate place for setting out how they are bound by policy, and we don’t need to go any further than them.

Sorry for bringing this up again. If the above is our common 
understanding, then the text is fine as is.

Regards,   Martin.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 1 Mar 2022 16:36:20 -0700

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 <[email-masked] 
>> <mailto:[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] <mailto:[email-masked]>>
>> *Cc: [email-masked] <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>, [email-masked] 
>> <mailto:[email-masked]>
>> *Reply-To: *Martin Dürst <[email-masked] 
>> <mailto:[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.

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.

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

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

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

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.

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

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.

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

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
>>   shared among the RSWG, RSAB, RPC, and IETF LLC (alone or in
>>   combination).

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

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 2 Mar 2022 08:39:12 +0900

Hello everybody,

> agree with the proposed change.

I definitely prefer the old text to this new text. The fact that this 
new text was introduced here also seems to confirm that the 
interpretation of the old text is that the maximum delay is 6 months.

As I said in another mail, the main purpose of commenting on this was to 
make sure that even people not involved in the original discussions were 
aware of this issue.

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 2 Mar 2022 13:51:21 +1300

On 02-Mar-22 12:36, Peter Saint-Andre wrote:
...
> easy suggestion for making it less strange.

Shouldn't the Independent Stream boilerplate actually say:

"The Independent Submissions Editor has chosen to publish this document at their discretion..."?

But that's a fix to RFC7841 that seems out of place in *this* document.

     Brian

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 2 Mar 2022 09:54:08 +0900

Hello Brian, others,

Please see below.

> But that's a fix to RFC7841 that seems out of place in *this* document.

Agreed on both points.   Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Mar 2022 23:35:49 -0500

--On Tuesday, March 1, 2022 16:36 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>...
>>> Abstract: It may be worth mentioning the RSCE and the
>>> Editorial Stream  here,

Peter, probably a good idea for the reason Martin pointed out,
but this (and the first sentence of 8.1) seem to retire the "RFC
Editor Function" terminology although it is used in other parts
of the document (such as the first paragraph).  While I don't
have a big problem obsoleting the term is that was the intent
(or won't once I get used to it), there does need to be a
comprehensive term that covers the whole shebang in operation
(not the model).  While the details of the RFC Editor Function
are changing with this model -- including a new collection of
alphabet soup-- it is still a plausible term for the collection
of things whose ultimate goal is at least nearly the same as it
has always been.  For that reason, I think I prefer "RFC Editor
Function" to "RFC Whole Shebang", but you or others may have
better ideas than either.

If you want to retain "RFC Editor Function" (I think "function"
in Section 1, first paragraph, is a typo),  then "previously
assigned" is not quite right.

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

Try "...with this document, [RFC2418] and its successors."  You
really do not want to force an update to this document if 2418
is obsoleted.

  best,
    john

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 2 Mar 2022 17:53:49 +0900

Hello Peter,

> Thanks for your careful review. Comments inline.

Many thanks for your careful response.

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

>>> Abstract: It may be worth mentioning the RSCE and the Editorial 
>>> Stream here,

Looks good!

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

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

>     functions and responsibilities are as follows:

Great!

>     3. Proposals must be approved by the RFC Series Approval Board

Nice!

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

Good, but see additional comments on the list.

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

>>> The "elided" part is wishful thinking. If something is published 
>>> once, it's

Agreed.

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

Thanks!

>        would operate (see RFC2418).

Nice.

>>> This sentence is simply too long, in particular because after the 
>>> last comma,

Looks good.

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

> list of responsibilities (incrementing the subsequent items by one).

Good idea.

>>> The word "depositing" then makes even less sense than it

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

>>> the intent was that these should be different, then the text has to 
>>> be written

Looks good!

>>> I think there should be an additional sentence saying that despite 
>>> the name of

Great.

Regards,   Martin.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Mar 2022 08:57:29 +1300

"RFC Editor Function" is used in other drafts too. I think that dropping this phrase would have many repercussions and we should just keep it.

Regards
    Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2022 14:02:18 -0700

> assigned" is not quite right.

That text was intended to be about the responsibilities, not the name.

Do we feel that we need to (re-)define "RFC Editor Function" in this 
document? (Brian mentions "various documents" but where was it defined 
before?)

If so, is it the collective combination of the RSWG, RSAB, RPC, RSCE, 
and IETF LLC when dispatching the responsibilities specified in this 
document?

> really do not want to force an update to this document if 2418

Good catch.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 2 Mar 2022 14:32:32 -0700

> Many thanks for your careful response.

Many thanks for your careful consideration of my careful response to 
your careful review. ;-)

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

Likewise.

>>>> *From: *Martin Dürst via Datatracker <[email-masked] 

<snip/>

>>>> "packaging" sounds a bit strange; it might be better to say 
>>>> something like "The
>>>> RFC Editor function
>> 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.
> 

I've pinged Olaf about this. In the meantime, I would prefer "production".

> past will only become less relevant over time.

I see your point now. This seems slightly better.

> time, that contribution will get less and less.

Sure, I think we could remove this paragraph from the Overview section 
without loss.

Good idea.

> that the boilerplate meets its needs"

Sorry to have been so terse. I'm suggesting:

###

As part of the RFC Style Guide (see {{RFC7322}} and {{STYLEGUIDE}}),
new or modified RFC boilerplates (see {{RFC7841}}) considered under
version 3 of the RFC Editor Model must be approved by the following
parties, each of which has a separate area of responsibility with
respect to boilerplates:

* Each relevant stream, which approves that the boilerplate meets its needs

###

Here "relevant" (or perhaps "applicable") is shorthand for "to which the 
boilerplate applies"; on reflection, I prefer "applicable stream".

Peter

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Mar 2022 17:04:39 -0500

--On Wednesday, March 2, 2022 14:02 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> If you want to retain "RFC Editor Function" (I think
>> "function" in Section 1, first paragraph, is a typo),  then
>> "previously assigned" is not quite right.
> 

That makes good sense, but I read it as definitional.  See below.

> Do we feel that we need to (re-)define "RFC Editor Function"
> in this document? (Brian mentions "various documents" but
> where was it defined before?)

I'm not going to spend time looking in other places, but the
Abstract of RFC 4844 (copied, AFAICT, into RFC 8729) does use
the term.  They use lower case as "RFC Editor function", perhaps
because at the time 4844 was written, we had not even separated
things into Streams, much less created a whole cluster of
relevant entities.

Unless we want to invite "RFC Editor [Whole] Shebang", "RFC
Editor [Three-Ring] Circus", or, for the negative among us "RFC
Editor Mess", I think it would be very helpful if, early on, you
said something like 'the entire collection of organizations and
functions that bear on this model and getting RFCs produced is
known as the "RFC Editor Function"'.  I have no opinion about
whether we need get another abbreviation (RFCF? RFCEF?) there or
what it should be.
 
> If so, is it the collective combination of the RSWG, RSAB,
> RPC, RSCE, and IETF LLC when dispatching the responsibilities
> specified in this document?

Yes, I think so but, if you were listing them, I'd say
"including" so as the make the term (and the document) a bit
more future-proof.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Mar 2022 14:38:47 +1300

> things into Streams, much less created a whole cluster of

I was specifically thinking about draft-carpenter-rfced-iab-charter,
which could of course be wordsmithed if necessary, but I imagine
that such a generic phrase is used in various places.

Wait, there's this thing called 'grep'...

Yes, the phrase is used in literally thousands of RFCs; notably
3716, 4844, 4846, 6220, 6548, 6635, etc. but also all those containing
"Funding for the RFC Editor function is currently provided by the
Internet Society." or
"Funding for the RFC Editor function is provided by the IETF."

I don't see any particular argument for changing the usage now.

    Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Mar 2022 22:06:23 -0500

--On Thursday, March 3, 2022 08:57 +1300 Brian E Carpenter
<[email-masked]> wrote:

> "RFC Editor Function" is used in other drafts too. I think
> that dropping this phrase would have many repercussions and we
> should just keep it.

In case it was not clear, I agree.  I just think that a
definition --probably a deliberately vague one-- in the model
document might be helpful.

    john

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 Mar 2022 08:52:46 -0700

> document might be helpful.

Perhaps something like this:

###

The overall framework for the RFC Series and the RFC Editor
Function is described in {{RFC8729}} and is updated by this
document. Under version 3 of the RFC Editor Model, various
responsibilities of the RFC Editor Function are now performed
alone or in combination by the RSWG, RSAB, RPC, RFC Series
Consulting Editor (RSCE), and IETF LLC, which collectively
comprise the essence of the RFC Editor Function.

###

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 4 Mar 2022 08:41:42 +1300

> comprise the essence of the RFC Editor Function.

Looks good to me.

    Brian

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 4 Mar 2022 08:14:06 +0900

> comprise the essence of the RFC Editor Function.

Very good, as usual. However, I'd cut out "the essence". There may be 
some other little splinters somewhere, but I couldn't name them.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2022 18:17:40 -0500

--On Friday, March 4, 2022 08:41 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>>> that dropping this phrase would have many repercussions and
>>>> we should just keep it.
>>> 

Me too.  Thanks.
   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 3 Mar 2022 17:21:33 -0700

> some other little splinters somewhere, but I couldn't name them.

Yes, I said "the essence" to forestall the objection that there are 
little splinters somewhere. But I'm happy to remove those words.

Peter

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2022 21:17:04 -0500

> comprise the essence of the RFC Editor Function.

Not quite what I had in mind, but probably more than good
enough.  Wfm.

   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Mar 2022 21:25:15 -0500

--On Thursday, March 3, 2022 17:21 -0700 Peter Saint-Andre
<[email-masked]> wrote:

>> Very good, as usual. However, I'd cut out "the essence".
>> There may be  some other little splinters somewhere, but I
>> couldn't name them.
> 
> Yes, I said "the essence" to forestall the objection that
> there are little splinters somewhere. But I'm happy to remove
> those words.

Or you could replace "essence" with "core components", "range",
"core bodies that make up" (maybe without "core"), or something
similar.  My concern about future-proofing again suggests avoid
close-ended lists where possible and, while I share your
concerns about "splinters" I'm more concerned about future
changes and things that might look like splinters initially but
turn out to be the pointy end of spears.

But I can live with any of those choices, including dropping
"the essence".

   john