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

FYI

> Begin forwarded message:
> 
> From: Wesley Eddy via Datatracker <noreply@ietf.org>
> Subject: [Tsv-art] Tsvart last call review of draft-iab-rfcefdp-rfced-model-11
> Date: 21. February 2022 at 16:28:43 CET
> To: <tsv-art@ietf.org>
> Cc: last-call@ietf.org, iab@iab.org, draft-iab-rfcefdp-rfced-model.all@ietf.org
> Reply-To: Wesley Eddy <wes@mti-systems.com>
> 
> 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
> tsv-art@ietf.org 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
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art
>