Re: [Gendispatch] Re: Comments on Composition and Comportment of the IETF Nominating Committee draft
Eric Rescorla <[email protected]> Wed, 22 Jul 2026 09:57:43 -0700
| Newsgroups | gmane.ietf.general |
|---|---|
| Message-ID | <CABcZeBNsJKuC3zyoZhyX_VN-jmUwRT5qitznoZ=pxS5k5-YGiw@mail.gmail.com> |
--000000000000e35b2c0657360b0f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 22, 2026 at 9:37=E2=80=AFAM Mallory Knodel <mallory.knodel@nyu.= edu> wrote: > Hi, > > On Wed, Jul 22, 2026 at 12:27=E2=80=AFPM Eric Rescorla <[email protected]> wro= te: > >> >> >> On Wed, Jul 22, 2026 at 9:20=E2=80=AFAM Salz, Rich <[email protected]> wr= ote: >> >>> >>> - The result of this would be to make the selection process not >>> publicly >>> - verifiable. >>> >>> >>> I=E2=80=99m not so sure that this is true. To pick an obvious method, i= t might >>> require public disclosure of the gender of those skipped over, to show = that >>> you had to go to a different candidate. Or we could decide to require = that >>> being a NomCom volunteer might require disclosing your gender. >>> >> >> Yes, but these are both in contradiction with the paragraph >> directly above which >> requires them to be private. >> >> > I think that what could happen is the reasons for the skips are not > disclosed, corporate or otherwise. The section from RFC8713 says, > > "The number of NomCom members with the same primary affiliation is limite= d > in order to avoid the appearance of improper bias in choosing the > leadership of the IETF. *Rather than defining precise rules for how to > define "affiliation", the IETF community depends on the honor and integri= ty > of the participants to make the process work*." > > Emphasis on this language is probably what we should copy wholesale for > this draft, too. > I think this conflates two questions: 1. Whether it's possible to verify that participants have accurately represented themselves. 2. Whether it is possible to verify that given a candidate list the selection process picked the correct people. The current system deals with this as follows: 1. The entire list is published along with affiliations. 2. The selection process selects from that list given the affiliations. It's partly possible to verify (1) by looking to see if someone appears to have misrepresented their affiliation, and I assume that if someone just obviously did so, the community would challenge them. It's possible to verify (2) completely based on the published list. This does not require trusting the nomcom chair. > Now, if the reasons for the skips are not officially disclosed and just > presented without commentary I think this is probably good enough to not > have to gender every single IETFer and still provides verifiability for t= he > nomcom process. > Perhaps we should start by stating what "verifiable" means in this context. What I mean is that a third party can verify for themselves that the algorithm was correctly executed. What you describe is not verifiable according to this definition. To make things simpler, consider what happens if we wanted to select a three person nomcom. The initial draw gives us the following ordered list of candidates and genders: Candidate Gender 1 A 2 B 3 A 4 A 5 A The correct selection here is just to draw candidates 1-3 because there would be at least one person of each gender. However, the chair decides that they prefer candidate 4 to candidate 3 and so decides to skip 3 and select 4. This is precisely what a verifiable algorithm is intended to prevent, but the only way to know that this is wrong is to know the underlying genders for these candidates. Re "gendering every single IETFer", well sort of. As I stated in my original message, each volunteer would need to reveal their gender to the nomcom chair, but only the genders of enough people to demonstrate that there is at least one person from each gender need to be publicly revealed. -Ekr --000000000000e35b2c0657360b0f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><br></d= iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On = Wed, Jul 22, 2026 at 9:37=E2=80=AFAM Mallory Knodel <<a href=3D"mailto:m= [email protected]" target=3D"_blank">[email protected]</a>> wro= te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px = 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"= ltr"><div dir=3D"ltr"><div>Hi,</div><div><br></div></div><div class=3D"gmai= l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 22, 2026 at 12:2= 7=E2=80=AFPM Eric Rescorla <<a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a>> wrote:<br></div><blockquote class=3D"gmail_quote= " style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);= padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div clas= s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 22, 202= 6 at 9:20=E2=80=AFAM Salz, Rich <<a href=3D"mailto:[email protected]" tar= get=3D"_blank">[email protected]</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> <div> <ul style=3D"direction:ltr;margin-top:0px;margin-bottom:0px"> <li style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12pt;co= lor:rgb(0,0,0);direction:ltr;margin-top:0px;margin-bottom:0px;list-style-ty= pe:"\0027a2 ""> <div role=3D"presentation" style=3D"direction:ltr">The result of this would= be to make the selection process not publicly</div> </li><li style=3D"font-family:Aptos,Arial,Helvetica,sans-serif;font-size:12= pt;color:rgb(0,0,0);direction:ltr;margin-top:0px;margin-bottom:0px;list-sty= le-type:"\0027a2 ""> <div role=3D"presentation" style=3D"direction:ltr">verifiable.</div> </li></ul> <div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-serif;fo= nt-size:12pt;color:rgb(0,0,0)"> <br> </div><div style=3D"direction:ltr;font-family:Aptos,Arial,Helvetica,sans-se= rif;font-size:12pt;color:rgb(0,0,0)"> I=E2=80=99m not so sure that this is true. To pick an obvious method, it mi= ght require public disclosure of the gender of those skipped over, to show = that you had to go to a different candidate.=C2=A0 Or we could decide to re= quire that being a NomCom volunteer might require disclosing your gender.</div></div></blockquote><div><br></div><div>Yes, b= ut these are both in contradiction with=C2=A0the paragraph directly=C2=A0ab= ove which</div><div>requires them to be private.</div><div><br></div></div>= </div></blockquote><div><div><br></div><div>I think that what could happen = is the reasons for the skips are not disclosed, corporate or otherwise. The section from RFC8713 says,</div><di= v><br></div><div>"The number of NomCom members with the same primary affiliation is limited in order to avoid the appearance of improper bias in choosing the leadership of the IETF. <b><u><i>Rather than defining precise rules for how to define "affiliation", the IETF community depends on the honor and integrity of the participants to make the process work</i></u></b>."</div><div= ><br></div><div>Emphasis on this language is probably what we should copy w= holesale for this draft, too.</div></div></div></div></blockquote><div><br>= </div><div><div>I think this conflates two questions:</div><div><br></div><= div>1. Whether it's possible to verify that participants have accuratel= y represented themselves.</div><div>2. Whether it is possible to verify tha= t given a candidate list the selection process picked the correct people.</= div><div><br></div><div>The current system=C2=A0deals with this as follows:= </div><div><br></div><div>1. The entire list is published along with affili= ations.</div><div>2. The selection process selects from that list given the= affiliations.</div><div><br></div><div>It's partly possible to verify = (1) by looking to see if someone appears</div><div>to have misrepresented t= heir affiliation, and I assume that if someone</div><div>just obviously did= so, the community would challenge them.</div><div><br></div><div>It's = possible to verify (2) completely based on the published list. This</div><d= iv>does not require trusting the nomcom chair.</div><div><br></div>=C2=A0</= div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor= der-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div= class=3D"gmail_quote"><div><div>Now, if the reasons for the skips are not officially disclosed and=C2=A0just=20 presented without commentary I think this is probably good enough to not have to gender every single IETFer and still provides verifiability for the nomcom process.</div></div></div></div></blockquote><br></div><div cla= ss=3D"gmail_quote"><br>Perhaps we should start by stating what "verifi= able" means in this<br>context. What I mean is that a third party can = verify for themselves<br>that the algorithm was correctly executed.=C2=A0 W= hat you describe is not<br>verifiable according to this definition.<br><br>= To make things simpler, consider what happens if we wanted to select<br>a t= hree person nomcom. The initial draw gives us the following<br>ordered list= of candidates and genders:<br><br>Candidate =C2=A0 =C2=A0Gender<br>1 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A<br>2 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B<br>3 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A<br>4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 A<br>5 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 A<br><br>The correct selection here is just to draw candidates 1= -3 because<br>there would be at least one person of each gender. However, t= he chair<br>decides that they prefer candidate 4 to candidate 3 and so deci= des to<br>skip 3 and select 4. This is precisely what a verifiable algorith= m</div><div class=3D"gmail_quote">is intended to prevent, but the only way = to know that this is wrong is</div><div class=3D"gmail_quote">to know the u= nderlying genders for these candidates.<br><br></div><div class=3D"gmail_qu= ote">Re "gendering every single IETFer", well sort of. As I state= d in</div><div class=3D"gmail_quote"><div>my original message, each volunte= er would need to reveal their</div><div>gender to the nomcom chair, but onl= y the genders of enough</div><div>people to demonstrate that there is at le= ast one person from</div><div>each gender need to be publicly revealed.</di= v><div><br></div><div>-Ekr</div><div><br></div><div><br></div><div><br></di= v><br></div></div> </div> </div> --000000000000e35b2c0657360b0f--