MIME-Version: 1.0
References: <178541641850.2608.17682053882379945403@mail2.ietf.org>
In-Reply-To: <178541641850.2608.17682053882379945403@mail2.ietf.org>
From: Craig Partridge <craig@tereschau.net>
Date: Thu, 30 Jul 2026 10:27:15 -0600
Message-ID: 
 <CAHQj4CfwWgJY+VHOQufErMo6xYWjixZpOpft9KLtJQCo6a1kWw@mail.gmail.com>
Subject: Re: ietf Digest, Vol 218, Issue 49 (making decisions)
To: IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002e3ca10657d68c29"
Message-ID-Hash: 745IZMIFCFSNUSKUQLWNTYWRVD47XYXG
Precedence: list
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ietf/PDqKMNHgGAcw-Pebn1slwCagndM>

--0000000000002e3ca10657d68c29
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
>
>
> On Wed, Jul 22, 2026, 4:38=E2=80=AFPM Benjamin Kaduk <kaduk@mit.edu> wrot=
e:
>
> In my view the lesson learned is "don't": avoid situations where one has =
to
> pick one of two options unless absolutely necessary. This especially
> applies when there are few technical criteria to apply.
>
>
The issue of choosing between options is longstanding and dates back to my
time on the initial IESG in the late 1980s.  Historically, the answer is to
allow both choices where they can co-exist.  This decision means a
marketplace process ultimately decides. While the marketplace uncertainy
can be messy, it ensures a standard solution is available in a timely way.

When the choices are mutually exclusive, the delay caused by the struggle
to choose can be destructive.  I've argued elsewhere that the delay picking
the IP over ATM encapsulation harmed ATM (one of many harms, but still...
there were three encapsulations, all achieving the same result, so it
became a beauty contest...).  At some point the WG needs to be pushed
toward consensus on which choice(s) to exclude.

Craig
--=20
*****
Craig Partridge's email account for professional society activities and
mailing lists.

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

<div dir=3D"ltr"><div class=3D"gmail_quote gmail_quote_container"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><br><br>
On Wed, Jul 22, 2026, 4:38=E2=80=AFPM Benjamin Kaduk &lt;<a href=3D"mailto:=
kaduk@mit.edu" target=3D"_blank">kaduk@mit.edu</a>&gt; wrote:<br>
<br>
In my view the lesson learned is &quot;don&#39;t&quot;: avoid situations wh=
ere one has to<br>
pick one of two options unless absolutely necessary. This especially<br>
applies when there are few technical criteria to apply.<br>
<br></blockquote><div><br></div><div>The issue of choosing between options =
is longstanding and dates back to my time on the initial IESG in the late 1=
980s.=C2=A0 Historically, the answer is to allow both choices where they ca=
n co-exist.=C2=A0 This decision means a marketplace process ultimately deci=
des. While the marketplace uncertainy can be messy, it ensures a standard s=
olution is available in a timely way.</div><div><br></div><div>When the cho=
ices are mutually exclusive, the delay caused by the struggle to choose can=
 be destructive.=C2=A0 I&#39;ve argued elsewhere that the delay picking the=
 IP over ATM encapsulation harmed ATM (one of many harms, but still... ther=
e were three encapsulations, all achieving the same result, so it became a =
beauty contest...).=C2=A0 At some point the WG needs to be pushed toward co=
nsensus on which choice(s) to exclude.</div><div><br></div></div><div>Craig=
</div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr"=
 class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=
=3D"ltr">*****<br><div>Craig Partridge&#39;s email account for professional=
 society activities and mailing lists.</div></div></div></div></div></div><=
/div>

--0000000000002e3ca10657d68c29--