[Rats] Re: RATS Multi Verifier Design Team Meeting

[Nathanael Ritz <[e-mail]>]

Hi Thomas,

Thanks for the additional insight. Your conclusions make sense to me.

I would add that under §6.3 of RFC 2418, the circumstances of what defines
a "design team" is broad, starting with something as minimal as "an
informal chat between people in a hallway"!

And when the member list would be equivalent to the WG membership as a
whole regardless, the need for a formal process associated with a DT
appears, as you say, absent.

Cheers,

Nathanael

On Sun, 10 May 2026 at 22:54, Thomas Fossati <[e-mail]>
wrote:

> Hi Nathanael,
>
> On Mon, 11 May 2026 at 02:10, Nathanael Ritz <[e-mail]> wrote:
> >
> > Hello!
> >
> > Thanks Yogesh for sharing this update and for the availability survey.
> >
> > Another WG member raised some questions regarding the process for how
> working group design teams are to be operated [0], and as a recent active
> participant with the IETF, I took a special interest in the topic. As such,
> I am sharing my understanding for the WG's consideration below [NLR].
> >
> > > On Sun, 10 May 2026 at 14:51, Muhammad Usama Sardar [
> [e-mail]]() wrote: [0]
> > > > On 10.05.26 22:08, Yogesh Deshpande wrote:
> > > > I am referring to [
> https://www.rfc-editor.org/rfc/rfc2418#section-6.5](https://www.rfc-editor.org/rfc/rfc2418#section-6.5)
> [1]
> >
> > > Thanks for the clarification. [...] "any one" and "purely optional"
> does not seem appropriate for [2]. IIUC, 'Design Team' members have a clear
> terse mission statement and they require committed members to deliver
> specific output. Unless you are recruiting specific members to the 'Design
> Team' (which does not seem to be the case to me because of "any one" and
> "purely optional"), I think the term 'Design Team' is not the right formal
> term here. We should seek guidance from chairs on this to ensure we are
> using the right terminology and process here.
> >
> >
> > [NLR] I interpret the IESG statement on design teams [2] differently.
> From my reading, the purpose of [2] is to prevent design teams from
> creating in-groups and out-groups at the institutional level that may
> otherwise act as incidental gatekeepers. The statement warns against
> **closed** design teams in particular, even if such closed teams are
> "acceptable" in form. It also outlines a "key point" that "the output of a
> design team is input to a working group, not a final document", and
> clarifies that "such a document must not be considered as more important
> than any other input to the working group". It also works to make WG chairs
> aware of potential "liability [risks] **if** a design team is formed with a
> restricted membership" (**emphasis** mine).
> >
> > In short, the statement appears to call for openness and transparency,
> clarifies that those who do participate in any such design team (formal or
> informal) are granted no unique authority above mailing-list only
> participants, and generally seeks to keep barriers to IETF participation as
> minimal as possible.
> >
> > Of course, as was suggested, specific input from the chairs on this
> topic is more than welcome.
>
> Not a chairperson, but... in my experience, DTs are usually appointed
> by chairs to solve a specific, difficult sub-problem or harmonise
> competing solutions / reconcile splintering.
> However, in this case, there is one adopted document with a
> sufficiently diverse pool of editors, and any (inevitable) tension
> surrounding it can be handled using the baseline process described in
> §6.3 of RFC 2418 (and the relevant parts of RFC 8874, since we are
> using GitHub).
> In other words, the conditions for setting up a DT are currently absent.
>
> I believe Yogesh simply intended to make the editorial process more
> open and transparent, and he used the term "design team" informally in
> his email.
>
> cheers, t
>