Skip to main content

Last Call Review of draft-iab-rfcefdp-rfced-model-11

Request Review of draft-iab-rfcefdp-rfced-model
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2022-02-25
Requested 2022-02-09
Requested by Mirja Kühlewind
Authors Peter Saint-Andre
I-D last updated 2022-02-21
Completed reviews Rtgdir Last Call review of -11 by Stig Venaas (diff)
Secdir Last Call review of -11 by Russ Mundy (diff)
Genart Last Call review of -11 by Christer Holmberg (diff)
Intdir Last Call review of -11 by Sheng Jiang (diff)
Opsdir Last Call review of -11 by Dan Romascanu (diff)
Tsvart Last Call review of -11 by Wesley Eddy (diff)
Artart Last Call review of -11 by Thomas Fossati (diff)
I18ndir Last Call review of -11 by Martin J. Dürst (diff)
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!
Assignment Reviewer Wesley Eddy
State Completed
Request Last Call review on draft-iab-rfcefdp-rfced-model by Transport Area Review Team Assigned
Posted at
Reviewed revision 11 (document currently at 13)
Result Ready w/issues
Completed 2022-02-21
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 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 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

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