Re: Making Decisions in the IETF
Watson Ladd <[email protected]> Wed, 29 Jul 2026 11:00:28 -0700
| Newsgroups | gmane.ietf.general |
|---|---|
| Message-ID | <CACsn0cm9=qNb=RgUnuvWwWYdokXWXb2_XSMvMeji-UUkgWpKOw@mail.gmail.com> |
--000000000000bcce7d0657c3bb0b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2026, 4:38=E2=80=AFPM Benjamin Kaduk <[email protected]> wrote: > Hi SM, > > On Wed, Jul 22, 2026 at 04:04:00PM -0700, S Moonesamy wrote: > > Hi Mark, Pete, > > > > I read the draft about "Making Decisions in the IETF". > > I assume this refers to draft-nottnick-ietf-decisions? > > > Section 1 of the draft states that the guidance in RFC 2418 has served > the > > IETF well for more than thirty years. It then goes on to argue that th= e > > IETF has grown and the decisions made are more than ever relevant to > > society. > > > > (a) It's not often that one finds guidance which has served a group > well > > for over > > thirty years. Why is the guidance no longer working as it did > thirty > > years ago? > > I'm not either Mark or Pete, but I would argue that we have at least one > worked example of the original guidance not working well > (draft-ietf-tls-mlkem) and it seems totally reasonable to use that as a > prompt to provide better guidance. > 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. > > (b) What changed in the group as it grew? > > > > (c) What is the difference in the decisions made thirty years ago and > > those taken > > nowadays? > > > > Section 1.1 has the following: "decision making by voting is > inappropriate > > -- it would make our processes vulnerable to rule by majority and vote > > stuffing." I followed a few working groups today. There was voting in= a > > few of those working groups. If I read the text from the draft > literally, I > > would conclude that there was something inappropriate going on. > > I don't think your description of what you observed provides enough > information to be able to really answer the question. It might indicate > something inappropriate, or it might just be a proxy for soliciting > objections and assesing support, and such a proxy is probably fine in the > absence of objections. > > > Section 2 of the draft has the following: "groups SHOULD maintain a > record > > of decisions". Are there cases where a group does not have to record = a > > decision? > > > > Section 3 of the draft states that adoption does not consensus. I > thought > > that little gem was fairly well-known. That is not reflected in the > various > > mailing list discussions which I have seen. > > Are you proposing a change to the draft? > > > Having been prompted to look at the draft, I also have some comments not > inspired by SM's review. > > On the whole, I think it's broadly aligned with my understanding of what = a > WG chair is supposed to be doing when gauging consensus. > > However, I find parts of 2.3 (Handling Objections) underwhelming, largely > relating to the assumption that any given objection must either be upheld > or discounted, and also about what constitutes grounds for discounting an > objection. > > In particular, the document is silent on the class of scenarios where the= re > is a tradeoff between two or more options that have different strengths a= nd > weaknesses, with objections raised as to the weaknesses of each option. = I > do not think it is correct (in the general case) to say that all the > objections are upheld and the WG can do nothing; the WG should be able to > make some decision. If we take that as the premise, that leads to a > situation where we have a valid objection that we choose to ignore for > other reasons, e.g., as part of a tradeoff between options. > > When consensus callers are faced with such a tradeoff situation, I think > the guidance should be roughly that the tradeoff needs to be considered i= n > the scope of the identified use cases (which implicitly weakens the > position of unidentified use cases), probably weighted by the number of > impacted end users if needed (see RFC 8890 for the IAB's take), while > trying to enable as many use cases as possible to achieve some kind of > useful (even if not optimal) result and minimize the number of use cases > that experience drastic harm from the given choice (as compared to some > other alternative choice). I would also generally expect the tradeoff > to be described in some form in the resulting document (presumably with > some exceptions possible). > > I also think it would be helpful to give guidance to consensus callers on > how to convey the results of the decision to the group, e.g., what > information needs to be included, how to describe the decision process, > what tradeoffs and use-cases were weighed against each other. IIRC it to= ok > a significnat amount of time to produce summaries like > https://mailarchive.ietf.org/arch/msg/tls/2QHMMX9g5vpFJaeH0okj40N3WjQ/ bu= t > I only remember ever getting positive feedback about having produced them= . > > -Ben > > --000000000000bcce7d0657c3bb0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"auto"><div dir=3D"auto"><br></div><div class= =3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Wed,= Jul 22, 2026, 4:38=E2=80=AFPM Benjamin Kaduk <<a href=3D"mailto:kaduk@m= it.edu" target=3D"_blank">[email protected]</a>> wrote:<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so= lid rgb(204,204,204);padding-left:1ex">Hi SM,<br> <br> On Wed, Jul 22, 2026 at 04:04:00PM -0700, S Moonesamy wrote:<br> > Hi Mark, Pete,<br> > <br> > I read the draft about "Making Decisions in the IETF".<br> <br> I assume this refers to draft-nottnick-ietf-decisions?<br> <br> > Section 1 of the draft states that the guidance in RFC 2418 has served= the<br> > IETF well for more than thirty years.=C2=A0 It then goes on to argue t= hat the<br> > IETF has grown and the decisions made are more than ever relevant to<b= r> > society.<br> > <br> >=C2=A0 =C2=A0(a) It's not often that one finds guidance which has s= erved a group well<br> > for over<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0thirty years.=C2=A0 Why is the guidance no l= onger working as it did thirty<br> > years ago?<br> <br> I'm not either Mark or Pete, but I would argue that we have at least on= e<br> worked example of the original guidance not working well<br> (draft-ietf-tls-mlkem) and it seems totally reasonable to use that as a<br> prompt to provide better guidance.<br></blockquote></div><div dir=3D"auto">= <br></div><div dir=3D"auto">In my view the lesson learned is "don'= t": avoid situations where one has to pick one of two options unless a= bsolutely necessary. This especially applies when there are few technical c= riteria to apply.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></= div><div class=3D"gmail_quote" dir=3D"auto"><blockquote class=3D"gmail_quot= e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex"> <br> >=C2=A0 =C2=A0(b) What changed in the group as it grew?<br> > <br> >=C2=A0 =C2=A0(c) What is the difference in the decisions made thirty ye= ars ago and<br> > those taken<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0nowadays?<br> > <br> > Section 1.1 has the following: "decision making by voting is inap= propriate<br> > -- it would make our processes vulnerable to rule by majority and vote= <br> > stuffing."=C2=A0 I followed a few working groups today.=C2=A0 The= re was voting in a<br> > few of those working groups.=C2=A0 If I read the text from the draft l= iterally, I<br> > would conclude that there was something inappropriate going on.<br> <br> I don't think your description of what you observed provides enough<br> information to be able to really answer the question.=C2=A0 It might indica= te<br> something inappropriate, or it might just be a proxy for soliciting<br> objections and assesing support, and such a proxy is probably fine in the<b= r> absence of objections.<br> <br> > Section 2 of the draft has the following: "groups SHOULD maintain= a record<br> > of decisions".=C2=A0 =C2=A0Are there cases where a group does not= have to record a<br> > decision?<br> > <br> > Section 3 of the draft states that adoption does not consensus.=C2=A0 = I thought<br> > that little gem was fairly well-known.=C2=A0 That is not reflected in = the various<br> > mailing list discussions which I have seen.<br> <br> Are you proposing a change to the draft?<br> <br> <br> Having been prompted to look at the draft, I also have some comments not<br= > inspired by SM's review.<br> <br> On the whole, I think it's broadly aligned with my understanding of wha= t a<br> WG chair is supposed to be doing when gauging consensus.<br> <br> However, I find parts of 2.3 (Handling Objections) underwhelming, largely<b= r> relating to the assumption that any given objection must either be upheld<b= r> or discounted, and also about what constitutes grounds for discounting an<b= r> objection.<br> <br> In particular, the document is silent on the class of scenarios where there= <br> is a tradeoff between two or more options that have different strengths and= <br> weaknesses, with objections raised as to the weaknesses of each option.=C2= =A0 I<br> do not think it is correct (in the general case) to say that all the<br> objections are upheld and the WG can do nothing; the WG should be able to<b= r> make some decision.=C2=A0 If we take that as the premise, that leads to a<b= r> situation where we have a valid objection that we choose to ignore for<br> other reasons, e.g., as part of a tradeoff between options.<br> <br> When consensus callers are faced with such a tradeoff situation, I think<br= > the guidance should be roughly that the tradeoff needs to be considered in<= br> the scope of the identified use cases (which implicitly weakens the<br> position of unidentified use cases), probably weighted by the number of<br> impacted end users if needed (see RFC 8890 for the IAB's take), while<b= r> trying to enable as many use cases as possible to achieve some kind of<br> useful (even if not optimal) result and minimize the number of use cases<br= > that experience drastic harm from the given choice (as compared to some<br> other alternative choice).=C2=A0 I would also generally expect the tradeoff= <br> to be described in some form in the resulting document (presumably with<br> some exceptions possible).<br> <br> I also think it would be helpful to give guidance to consensus callers on<b= r> how to convey the results of the decision to the group, e.g., what<br> information needs to be included, how to describe the decision process,<br> what tradeoffs and use-cases were weighed against each other.=C2=A0 IIRC it= took<br> a significnat amount of time to produce summaries like<br> <a href=3D"https://mailarchive.ietf.org/arch/msg/tls/2QHMMX9g5vpFJaeH0okj40= N3WjQ/" rel=3D"noreferrer noreferrer" target=3D"_blank">https://mailarchive= .ietf.org/arch/msg/tls/2QHMMX9g5vpFJaeH0okj40N3WjQ/</a> but<br> I only remember ever getting positive feedback about having produced them.<= br> <br> -Ben<br> <br> </blockquote></div></div> </div> --000000000000bcce7d0657c3bb0b--