MIME-Version: 1.0
References: 
 <DB9PR08MB98518BFCAAA81994758D74478E3B2@DB9PR08MB9851.eurprd08.prod.outlook.com>
In-Reply-To: 
 <DB9PR08MB98518BFCAAA81994758D74478E3B2@DB9PR08MB9851.eurprd08.prod.outlook.com>
From: Nathanael Ritz <nathanritz@gmail.com>
Date: Sun, 10 May 2026 18:10:12 -0600
Message-ID: 
 <CAHxYnaNz9L76C1uzkYDtp-Xv4ucZUYLyTi57kNakSh9Co=ipRA@mail.gmail.com>
To: Yogesh Deshpande <Yogesh.Deshpande@arm.com>
Content-Type: multipart/alternative; boundary="000000000000ad2a1e06517f922b"
Message-ID-Hash: 4SCEVWSHQQMWW7L4VMY55TIED7655DOZ
CC: rats <rats@ietf.org>, nd <nd@arm.com>, rats-chairs@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BRats=5D_Re=3A_RATS_Multi_Verifier_Design_Team_Meeting?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/rats/ibP9EZDdYROlyAPSP8Dq_rrD3AI>

--000000000000ad2a1e06517f922b
Content-Type: text/plain; charset="UTF-8"

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 [
muhammad_usama.sardar@tu-dresden.de]() 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.

Cheers,

Nathanael

[0] https://mailarchive.ietf.org/arch/msg/rats/ZgcZ1uK8HoVvbNbstP82csXQ0pA/

[1] https://www.rfc-editor.org/rfc/rfc2418#section-6.5

[2]
https://datatracker.ietf.org/doc/statement-iesg-on-design-teams-20011221/

--000000000000ad2a1e06517f922b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hello!<br><br>Thanks Yogesh for sharing t=
his update and for the availability survey.<br><br>Another WG member raised=
 some questions regarding the process for how working group design teams ar=
e to be operated [0], and as a recent active participant with the IETF, I t=
ook a special interest in the topic. As such, I am sharing my understanding=
 for the WG&#39;s consideration below [NLR].<br><br>&gt; On Sun, 10 May 202=
6 at 14:51, Muhammad Usama Sardar [<a href=3D"mailto:muhammad_usama.sardar@=
tu-dresden.de">muhammad_usama.sardar@tu-dresden.de</a>]() wrote: [0]<br>&gt=
; &gt; On 10.05.26 22:08, Yogesh Deshpande wrote:<br>&gt; &gt; I am referri=
ng to [<a href=3D"https://www.rfc-editor.org/rfc/rfc2418#section-6.5](https=
://www.rfc-editor.org/rfc/rfc2418#section-6.5)">https://www.rfc-editor.org/=
rfc/rfc2418#section-6.5](https://www.rfc-editor.org/rfc/rfc2418#section-6.5=
)</a> [1]<br><br>&gt; Thanks for the clarification. [...] &quot;any one&quo=
t; and &quot;purely optional&quot; does not seem appropriate for [2]. IIUC,=
 &#39;Design Team&#39; members have a clear terse mission statement and the=
y require committed members to deliver specific output. Unless you are recr=
uiting specific members to the &#39;Design Team&#39; (which does not seem t=
o be the case to me because of &quot;any one&quot; and &quot;purely optiona=
l&quot;), I think the term &#39;Design Team&#39; is not the right formal te=
rm here. We should seek guidance from chairs on this to ensure we are using=
 the right terminology and process here.<br><br><br>[NLR] I interpret the I=
ESG 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 a=
t 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 &quot;acceptable&quot; in form. It also outlines a &=
quot;key point&quot; that &quot;the output of a design team is input to a w=
orking group, not a final document&quot;, and clarifies that &quot;such a d=
ocument must not be considered as more important than any other input to th=
e working group&quot;. It also works to make WG chairs aware of potential &=
quot;liability [risks] **if** a design team is formed with a restricted mem=
bership&quot; (**emphasis** mine).<br><br>In short, the statement appears t=
o call for openness and transparency, clarifies that those who do participa=
te in any such design team (formal or informal) are granted no unique autho=
rity above mailing-list only participants, and generally seeks to keep barr=
iers to IETF participation as minimal as possible.<br><br>Of course, as was=
 suggested, specific input from the chairs on this topic is more than welco=
me.<br><br>Cheers,<br><br>Nathanael<br><br>[0] <a href=3D"https://mailarchi=
ve.ietf.org/arch/msg/rats/ZgcZ1uK8HoVvbNbstP82csXQ0pA/">https://mailarchive=
.ietf.org/arch/msg/rats/ZgcZ1uK8HoVvbNbstP82csXQ0pA/</a><br><br>[1] <a href=
=3D"https://www.rfc-editor.org/rfc/rfc2418#section-6.5">https://www.rfc-edi=
tor.org/rfc/rfc2418#section-6.5</a> <br><br>[2] <a href=3D"https://datatrac=
ker.ietf.org/doc/statement-iesg-on-design-teams-20011221/">https://datatrac=
ker.ietf.org/doc/statement-iesg-on-design-teams-20011221/</a></div></div>

--000000000000ad2a1e06517f922b--