Subject: [Rfced-future] Fwd: [Tsv-art] Tsvart last call review of draft-iab-rfcefdp-rfced-model-11

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 21 Feb 2022 17:33:36 +0100

FYI

> Begin forwarded message:
> 
> From: Wesley Eddy via Datatracker <[email-masked]>
> Subject: [Tsv-art] Tsvart last call review of draft-iab-rfcefdp-rfced-model-11
> Date: 21. February 2022 at 16:28:43 CET
> To: <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Reply-To: Wesley Eddy <[email-masked]>
> 
> Reviewer: Wesley Eddy
> Review result: Ready with Issues
> 
> This document has been reviewed as part of the transport area review team's
> ongoing effort to review key IETF documents. These comments were written
> primarily for the transport area directors, but are copied to the document's
> authors and WG to allow them to address any issues raised and also to the IETF
> discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC
> [email-masked] if you reply to or forward this review.
> 
> I don't have any major concern with this, just a handful of small comments that
> are maybe more than "nits", so I selected 'Ready with Issues'.
> 
> 1) Early the the document the concept of the RSWG is introduced and later
> described in detail in 3.1.1.  I wasn't sure at first if this was supposed to
> be an IETF working group (in the GEN area) or if it was intended to be
> "outside" of the IETF.  This seems more clear in section 3.1.1, but I would
> suggest thinking about if there's another term than "working group" that might
> fit, to distinguish it better.
> 
> 2) Section 3 says "that pass a last call for comments in the working group and
> broader community", but it doesn't provide any hint at what the "broader
> community" is supposed to include.
> 
> 3) The RSAB seems very complex and cumbersome for its simple role of basically
> confirming what the RSWG outputs.
> Since everyone on the RSAB is expected to be actively participating in the
> RSWG and would have weight in the RSWG consensus process, it isn't really
> clear to my why this is felt to be necessary (to have a separate organization
> with extra meetings, rules, etc.).  It seems like the RSAB shouldn't need to
> do much of anything separately if the RSWG is working properly, and RSAB is
> extra bureaucracy.  I'm just asking if it's certain this is really wanted and
> needed, since it would be harder to unwind later.  Maybe the reasoning why a
> separate board (beyond the chairs) is needed to approve the RSWG outputs could
> be described.
> 
> 4) Section 3.1.1.3 mentions that feedback on the RSWG chairs can go to the
> appointing bodies, but isn't clear how that would be collected (nomcom tools?).
> 
> 5) Is there any issue to be discussed of potential overlap between co-chairs of
> the RSWG, RSAB members, and other roles like being on the IESG, IAB, or IRSG,
> employees of the RPC, or other roles?  Can someone serve as RSWG co-chair while
> also on the IAB, for instance?  It seems to me like the people with willingness
> and bandwidth to do these things has always been a bit limited in number, so
> maybe worth considering.  Also, can both RSWG co-chairs work for the same
> company?
> 
> 6) In general, since this is adding extra things that didn't exist before, it
> would be nice if the introduction was more clear about what the problem that
> this is trying to solve is.  In other words, why is this formality needed now,
> when ~10k RFCs have been able to be published without it in the past.  What
> part isn't working well enough?  The introduction just talks about there having
> been meetings, and lists a lot of good properties that are desired, but doesn't
> seem clear which if any of these have been lacking or why these changes address
> that.
> 
> 
> 
> _______________________________________________
> Tsv-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tsv-art
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 Feb 2022 18:57:15 +0100

Hi Wes and thanks for your review.  Please see below.

On 21.02.22 17:33, Mirja Kuehlewind wrote:
> FYI
>
>> Begin forwarded message:
>>
>> *From: *Wesley Eddy via Datatracker <[email-masked]>
>> *Subject: **[Tsv-art] Tsvart last call review of 
>> draft-iab-rfcefdp-rfced-model-11*
>> *Date: *21. February 2022 at 16:28:43 CET
>> *To: *<[email-masked]>
>> *Cc: [email-masked], [email-masked], 
>> [email-masked]
>> *Reply-To: *Wesley Eddy <[email-masked]>
>>
>> Reviewer: Wesley Eddy

The program did discuss this and came to the conclusion that because the 
RSWG functions much like an IETF working group, "working group" was 
appropriate.  While we recognized that there might be a small amount of 
confusion, this could be easily rectified as people engage in the process.

>> community" is supposed to include.

This has been a point of discussion, and is covered in more detail in 
Section 3.2.3.  Perhaps a forward reference would help.

>> separate board (beyond the chairs) is needed to approve the RSWG 

The purpose of the RSWG is to allow an open forum to drive process.  The 
purpose of the RSAB is to allow a brake on that process if the process 
is going to break streams.  The reason RSAB members are expected to 
participate in the RSWG is so that when a CONCERN is raised, it is 
hopefully not a surprise.  If you have a way to simplify this 
explanation in the document, that could be very helpful.

>> appointing bodies, but isn't clear how that would be collected 

This is indeed left to the appointing bodies themselves to figure out.

>> maybe worth considering.  Also, can both RSWG co-chairs work for the same

This was not specifically discussed.  The group may wish to comment.

>> seem clear which if any of these have been lacking or why these 

Rather than “what was the problem”, which we did investigate from time 
to time, we spent more time on what people thought Good looks like, and 
how they might reconcile their different visions. That's what you're 
reading.

Thanks again for your review.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Feb 2022 09:06:21 +1300

I think Wes is showing how people who have not been closely involved
might be puzzled by the appearance of this model "out of the blue",
and I think a few light editorial touches could fix this. In line...

On 22-Feb-22 06:57, Eliot Lear wrote:
>>> *Subject: **[Tsv-art] Tsvart last call review of draft-iab-rfcefdp-rfced-model-11*
>>> *Cc: [email-masked], [email-masked], [email-masked]
> The program did discuss this and came to the conclusion that because the RSWG functions much like an IETF working group, "working group" was appropriate.  While we recognized that there might be a small amount of 

Exactly right. I suggest that where the text first uses the phrase
"working group" we should qualify it:

OLD:
1. Policy definition governing the Series as a whole. This is the joint responsibility of the RFC Series Working Group (RSWG), an open working group that produces policy proposals,...

NEW:
1. Policy definition governing the Series as a whole. This is the joint responsibility of the RFC Series Working Group (RSWG), an open working group independent of the IETF that produces policy proposals,...
  
> This has been a point of discussion, and is covered in more detail in Section 3.2.3.  Perhaps a forward reference would help.

Yes.

> The purpose of the RSWG is to allow an open forum to drive process.  
The purpose of the RSAB is to allow a brake on that process if the process is going to break streams.  The reason RSAB members are expected to participate in the RSWG is so that when a CONCERN is raised, it is hopefully not a surprise.  If you have a way to simplify this explanation in the document, that could be very helpful.

Maybe add a note about "checks and balances" in 3.1.2.1. Purpose.

> This is indeed left to the appointing bodies themselves to figure out.

So the text should say that.

> This was not specifically discussed.  The group may wish to comment.

It's valid point. I don't see what we can do except add a general
recommendation that the appointing bodies should consider potential
conflicts of interest.

> Rather than “what was the problem”, which we did investigate from time to time, we spent more time on what people thought Good looks like, and how they might reconcile their different visions. That's what you're reading.

Right, but an outsider might well have the same question as Wes. I wonder
if we should tweak the motivation in the Introduction. Something like:

OLD:
This document reflects experience gained with version 1 and version 2 of the Model, and therefore describes version 3 of the Model while remaining 
consistent with [RFC8729].

NEW:
This document reflects experience gained and problems experienced with version 1 and version 2 of the Model, and therefore describes version 3 of the Model while remaining consistent with [RFC8729].

The next paragraph does in fact summarise the problem statement,
but a little obliquely. Personally I wouldn't change it, but if we
made it more direct, the problems we tackled were

- lack of transparency and community input for policies
- unclear lines of authority and responsibility

     Brian

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 21 Feb 2022 15:33:21 -0500

> and I think a few light editorial touches could fix this. In line...

That's exactly right ... I paid no attention to it, until now! :)

The changes you suggest are small, but work well for me; thanks.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 21 Feb 2022 14:54:17 -0700

On 2/21/22 1:06 PM, Brian E Carpenter wrote:
>> The program did discuss this and came to the conclusion that because 
>> the RSWG functions much like an IETF working group, "working group" 
>> was appropriate.  While we recognized that there might be a small 
>> amount of 
> 1. Policy definition governing the Series as a whole. This is the joint 
> responsibility of the RFC Series Working Group (RSWG), an open working 
> group that produces policy proposals,...
> 
> NEW:
> 1. Policy definition governing the Series as a whole. This is the joint 
> responsibility of the RFC Series Working Group (RSWG), an open working 
> group independent of the IETF that produces policy proposals,...

WFM.

>> Section 3.2.3.  Perhaps a forward reference would help.

Agreed.

> The purpose of the RSAB is to allow a brake on that process if the 
> process is going to break streams.  The reason RSAB members are expected 
> to participate in the RSWG is so that when a CONCERN is raised, it is 

Yes. To amplify on what Brian said: because we don't want to make it 
especially easy for the RSWG to do something that could cause 
significant harm to the RFC Series or to one of the streams, 
representatives of all of the streams need to sign off on proposals 
approved by the RSWG. So this is a case of cumbersome by design, if you 
will.

> So the text should say that.

Sure, I can add a few words to that effect.

> recommendation that the appointing bodies should consider potential

Without my editor's hat on, I'd be somewhat concerned about limiting our 
pool of candidates for the RSWG chair positions or causing perhaps 
unnecessary churn (e.g., one of the current chairs is subsequently named 
to the IRSG and therefore needs to be replaced). A statement about 
considering potential conflicts of interest seems fine, even if not very 
directive.

>> to time, we spent more time on what people thought Good looks like, 
>> and how they might reconcile their different visions. That's what 
>> you're reading.
> 
> This document reflects experience gained with version 1 and version 2 of 
> the Model, and therefore describes version 3 of the Model while 
> remaining consistent with [RFC8729].
> 
> NEW:
> This document reflects experience gained and problems experienced with 
> version 1 and version 2 of the Model, and therefore describes version 3 
> of the Model while remaining consistent with [RFC8729].
> 

I'll do some wordsmithing along these lines in the next version.

Peter