Re: [Gendispatch] Re: Comments on Composition and Comportment of the IETF Nominating Committee draft
Eric Rescorla <[email protected]> Wed, 22 Jul 2026 08:45:20 -0700
| Newsgroups | gmane.ietf.general |
|---|---|
| Message-ID | <CABcZeBNtXX1DKr4pn2awnkRTt-sSLu1cXS4gT0OTrRNkyrhZHQ@mail.gmail.com> |
--000000000000107d7e06573509e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wanted to follow up on the discussion we had during the meeting about the impact proposed rule in S 2.1 for the selection process. The text states that: The =E2=80=9Ctwo-per-organisation limit=E2=80=9D of Section 4.17 of [RFC= 8713] can easily be extended to ensure a nomcom consisting of no more than n-1 members from any one gender (where n is the number of available volunteer slots), requiring skips for the nth slot until a gender minority volunteer is chosen. And then later you write: As part of nomcom processes that change as a result of this document's recommended remedy, the gender of eligible nomcom volunteers must not be publicly documented, and wherein this information is used to determine the pool, it must be kept private. The result of this would be to make the selection process not publicly verifiable. Recall that the way selection works is by generating an ordered list of candidates via a predetermined process and then by walking down the list iteratively rejecting candidates who exceed the "two-per-organization limit". This entire process is verifiable and independently reproducible given the list of candidates, their affiliations, and the random sources. In order to extend this process to gender requires knowing the gender of each candidate examined up to the point where you have at least one candidate for each gender, though not for candidates after that, and as a practical matter probably requires each candidate to disclose their gender to the nomcom chair at the time they volunteer [0]. While the text in 8713 isn't quite as clear as one might like, I think the text requiring that it be possible to "independently verify that the selection method used is both fair and unbiased" strongly suggests that the actual selection needs be publicly verifiable, which is thus obviously in tension with having the gender of all volunteers being kept private [1]. We could obviously decide that it's not necessary that the selection actually be verifiable, but that seems like something that needs some discussion. -Ekr [0] Otherwise you have an iterative process where you have to ask each candidate for their gender at the time they are selected. [1] Note that it is not necessary to disclose the gender of all volunteers, but only those up to the "at least one for each gender" point. The way that this works is that the nomcom chair publishes a cryptographic commitment (e.g., for candidate i HMAC(<random-i>, gender-i)) to the gender of each candidate along with their name on the list. After candidates are selected, the chair then opens the commitments for the candidates that were examined by publishing the per-candidate random value. It's probably possible to do better than this, but I think it probably requires much fancier techniques. On Wed, Jul 22, 2026 at 3:47=E2=80=AFAM Mallory Knodel <mallory.knodel=3D [email protected]> wrote: > Hi all, > Following today's dispatch of this draft to [email protected], > I have two requests: > 1. To the community: Please join this list to continue support this draf= t > or add points for consideration. > 2. To the gendispatch chairs and/or Roman: this is a closed WG which > means that while there is a list, there is no chair. I requested in today= 's > session that there be persons responsible for determining rough consensus > on this document for publication. That request is outstanding. Please > advise. > Thanks everyone, > -Mallory > > On Mon, Jul 13, 2026 at 10:46=E2=80=AFAM Mallory Knodel <mallory.knodel@n= yu.edu> > wrote: > >> Hi all, >> Top posting to note that this document will be on the agenda for >> gendispatch. Comments now and then are both welcome. >> Thank you to commenters and gendispatch chairs, >> -Mallory >> >> On Wed, Jul 8, 2026 at 6:04=E2=80=AFPM S Moonesamy <[email protected]= > wrote: >> >>> Hi Vittorio, Brian, George, >>> At 07:00 AM 08-07-2026, Vittorio Bertola wrote: >>> >This is why I did not say that you should always prefer the most >>> >competent and expert candidates, but rather that you need to set a >>> >minimum threshold of competence and experience, somewhere mid-way >>> >between "at their first IETF meeting" and "been here 20 years". >>> >>> I included three points in my previous comments. The comments I have >>> seen have been on Point 1. >>> >>> I looked up the expertise required for an IESG member. The first one >>> I found was from 2009 [1]. It should be possible to get the >>> information for other years as that is in the datatracker. >>> >>> "It is also imperative that IESG members attend all IETF meetings, >>> typically arriving one or two days early. IESG members also >>> attend one, and sometimes two, IESG retreats per year." >>> >>> There is also: >>> >>> (a) Because of the large time and travel commitments, employer >>> support for a full two year term is essential. >>> >>> (b) Because of personal impact, including awkwardly timed >>> conference calls, an IESG member's family must also be >>> supportive. >>> >>> I also looked up the results from the surveys. Between 80% to 85% of >>> the people who provided information were from gender A. >>> >>> There has been discussions on Point (a), (b), and also the >>> composition of attendees/participants, etc. over the years. One of >>> the side effects of Point (a) is that it is a disqualification factor >>> for anyone who cannot get employer support for a full two year >>> term. I am not commenting on Point (b) as there are people who may >>> be better placed to comment on that. >>> >>> One of the issues in setting a high bar is that it could be viewed as >>> a disqualification factor. That is not to argue that there wouldn't >>> be a minimum threshold (re. somewhat along the lines of Vittorio's >>> comment). If I had to explain the level of expertise in the IETF >>> community, I would say that that a few of the subscribers to this >>> mailing list could write and submit a review within five minutes. I >>> would not argue that those subscribers should go away (there is a >>> parable from Chesterton which explains that). >>> >>> >Also, in past Nomcoms I was part of in other organizations, this was >>> >often seen as an aggregate assessment, e.g. you had to select three >>> >people for the same board and you strived to pick a mix of insiders >>> >and outsiders, engineers and business people, Western and Southern, >>> >etc. It was rare to achieve balance under all dimensions, but you >>> >tried to get as many as possible. >>> >>> I agree with the above. >>> >>> >This is also why I think that high level principles plus cultural >>> >commitment work better than hard quotas. >>> >>> It is not possible to see whether the high level principles worked if >>> there are no known targets. Setting a requirement (re. quota) would >>> be needed if the targets are being missed repeatedly. John Levine >>> commented as follows: "the only applicants are (to oversimplify only >>> slightly) two guys from the San Francisco suburbs". A switch would >>> be: the only applicants are two persons from same location. The >>> question is whether that would be a desirable change if the >>> requirement was introduced. >>> >>> At 09:35 PM 07-07-2026, George Michaelson wrote: >>> >Admittedly this probably says as much about me as it does about them >>> >but the point is, I think this runs against the "incumbency" issue. >>> >Yes, because to be a WG chair demands time, and because time as a WG >>> >chair demands prior time as an author, by the time you meet tech >>> >goals and understanding of IETF process to merit IESG you have been >>> >around a long time, but no, I don't think this is an overwhelming >>> >tendency to incumbents. >>> > >>> >I see new faces, new players. >>> > >>> >So tendency? Yes. possible. Actual eventuating circumstance? Less >>> >sure. Perhaps weighted by age/experience but also, a LOT of new faces. >>> >>> Nowadays, the information about whether someone has been a working >>> group chair, RFC author, etc. can easily be found in the >>> datatracker. The authorship listing does not mean that the person >>> was directly involved in the review/publication process. >>> >>> I agree with George that a person may find out that he/she has been >>> around for a long time when he/she is aware that he/she understands >>> the finer details. I would not use the word "merit" as it might >>> convey that the title is an award; it's a personal choice. The >>> weighting (re. above comment) could be one of several factors to >>> consider. >>> >>> I don't know most of the IESG or IAB members. I found out that a >>> person is an IESG member when I read "DISCUSS" emails. >>> >>> Regards, >>> S. Moonesamy >>> >>> 1. >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= .org_nomcom_ann_1969_&d=3DDwIBAg&c=3DslrrB7dE8n7gBJbeO0g-IQ&r=3DkrANNudPSfU= TEf2kXiduBUqRjXhDsKNCASr1kibHLfs&m=3DLv0FWItoBoY_NDix8DYlA_hW0HyiPjx8MuKIUM= x5XLeRfMAlpV-mhMt7_oWKMjoc&s=3DX2xkxBT8rCJ1jP4Vs5BHW_3Y6tJonr8sQrs5fTkmXok&= e=3D >>> >>> >>> -- > Gendispatch mailing list -- [email protected] > To unsubscribe send an email to [email protected] > --000000000000107d7e06573509e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I wanted to follow up on the discussion we had during the = meeting<br>about the impact proposed rule in S 2.1 for the selection proces= s.<br>The text states that:<br><br>=C2=A0 =C2=A0The =E2=80=9Ctwo-per-organi= sation limit=E2=80=9D of Section 4.17 of [RFC8713] can<br>=C2=A0 =C2=A0easi= ly be extended to ensure a nomcom consisting of no more than n-1<br>=C2=A0 = =C2=A0members from any one gender (where n is the number of available<br>= =C2=A0 =C2=A0volunteer slots), requiring skips for the nth slot until a gen= der<br>=C2=A0 =C2=A0minority volunteer is chosen.<br><br>And then later you= write:<br><br>=C2=A0 =C2=A0As part of nomcom processes that change as a re= sult of this<br>=C2=A0 =C2=A0document's recommended remedy, the gender = of eligible nomcom<br>=C2=A0 =C2=A0volunteers must not be publicly document= ed, and wherein this<br>=C2=A0 =C2=A0information is used to determine the p= ool, it must be kept private.<br><br>The result of this would be to make th= e selection process not publicly<br>verifiable. Recall that the way selecti= on works is by generating an<br>ordered list of candidates via a predetermi= ned process and then by<br>walking down the list iteratively rejecting cand= idates who exceed the<br>"two-per-organization limit". This entir= e process is verifiable and<br>independently reproducible given the list of= candidates, their<br>affiliations, and the random sources.<br><br>In order= to extend this process to gender requires knowing the gender<br>of each ca= ndidate examined up to the point where you have at least one<br>candidate f= or each gender, though not for candidates after that, and<br>as a practical= matter probably requires each candidate to disclose<br>their gender to the= nomcom chair at the time they volunteer [0].<br><br>While the text in 8713= isn't quite as clear as one might like, I think<br>the text requiring = that it be possible to "independently verify that<br>the selection met= hod used is both fair and unbiased" strongly suggests<br>that the actu= al selection needs be publicly verifiable, which is<br>thus obviously in te= nsion with having the gender of all volunteers<br>being kept private [1].<b= r><br>We could obviously decide that it's not necessary that the select= ion<br>actually be verifiable, but that seems like something that needs som= e<br>discussion.<br><br>-Ekr<br><br><br>[0] Otherwise you have an iterative= process where you have to ask each<br>candidate for their gender at the ti= me they are selected.<br><br>[1] Note that it is not necessary to disclose = the gender of all<br>volunteers, but only those up to the "at least on= e for each gender"<br>point. The way that this works is that the nomco= m chair publishes a<br>cryptographic commitment (e.g., for candidate i HMAC= (<random-i>,<br>gender-i)) to the gender of each candidate along with= their name on<br>the list. After candidates are selected, the chair then o= pens the<br>commitments for the candidates that were examined by publishing= the<br>per-candidate random value. It's probably possible to do better= than<br>this, but I think it probably requires much fancier techniques.<br= ><br><br><br></div><br><div class=3D"gmail_quote gmail_quote_container"><di= v dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 22, 2026 at 3:47=E2=80=AFAM = Mallory Knodel <mallory.knodel=3D<a href=3D"mailto:[email protected].= org">[email protected]</a>> wrote:<br></div><blockquote class=3D"= gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= 4,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Hi all,</div><div>Follow= ing=C2=A0today's dispatch of this draft to=C2=A0<a href=3D"mailto:eligi= [email protected]" target=3D"_blank">[email protected]</a>= , I have two requests:</div><div>=C2=A01. To the community: Please join thi= s list to continue support this draft or add points for consideration.</div= ><div>=C2=A02. To the gendispatch chairs and/or Roman: this is a closed WG = which means that while=C2=A0there is a list, there is no chair. I requested= in today's session that there be persons responsible=C2=A0for determin= ing rough consensus on this document for publication. That request is outst= anding. Please advise.</div><div>Thanks everyone,</div><div>-Mallory</div><= /div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O= n Mon, Jul 13, 2026 at 10:46=E2=80=AFAM Mallory Knodel <<a href=3D"mailt= o:[email protected]" target=3D"_blank">[email protected]</a>> = wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0= px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir= =3D"ltr"><div>Hi all,</div><div>Top posting to note that this document will= be on the agenda for gendispatch. Comments now and then are both welcome.<= /div><div>Thank you to commenters and gendispatch chairs,</div><div>-Mallor= y</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail= _attr">On Wed, Jul 8, 2026 at 6:04=E2=80=AFPM S Moonesamy <<a href=3D"ma= ilto:sm%[email protected]" 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 solid rgb(204,204,204);padding-left:1ex">Hi Vitto= rio, Brian, George,<br> At 07:00 AM 08-07-2026, Vittorio Bertola wrote:<br> >This is why I did not say that you should always prefer the most <br> >competent and expert candidates, but rather that you need to set a <br> >minimum threshold of competence and experience, somewhere mid-way <br> >between "at their first IETF meeting" and "been here 20 = years".<br> <br> I included three points in my previous comments.=C2=A0 The comments I have = <br> seen have been on Point 1.<br> <br> I looked up the expertise required for an IESG member.=C2=A0 The first one = <br> I found was from 2009 [1].=C2=A0 It should be possible to get the <br> information for other years as that is in the datatracker.<br> <br> =C2=A0 =C2=A0"It is also imperative that IESG members attend all IETF = meetings,<br> =C2=A0 =C2=A0 typically arriving one or two days early.=C2=A0 IESG members = also<br> =C2=A0 =C2=A0 attend one, and sometimes two, IESG retreats per year."<= br> <br> There is also:<br> <br> =C2=A0 =C2=A0(a) Because of the large time and travel commitments, employer= <br> =C2=A0 =C2=A0 =C2=A0 =C2=A0support for a full two year term is essential.<b= r> <br> =C2=A0 =C2=A0(b) Because of personal impact, including awkwardly timed<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0conference calls, an IESG member's family mu= st also be<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0supportive.<br> <br> I also looked up the results from the surveys.=C2=A0 Between 80% to 85% of = <br> the people who provided information were from gender A.<br> <br> There has been discussions on Point (a), (b), and also the <br> composition of attendees/participants, etc. over the years.=C2=A0 One of <b= r> the side effects of Point (a) is that it is a disqualification factor <br> for anyone who cannot get employer support for a full two year <br> term.=C2=A0 I am not commenting on Point (b) as there are people who may <b= r> be better placed to comment on that.<br> <br> One of the issues in setting a high bar is that it could be viewed as <br> a disqualification factor.=C2=A0 That is not to argue that there wouldn'= ;t <br> be a minimum threshold (re. somewhat along the lines of Vittorio's <br> comment).=C2=A0 If I had to explain the level of expertise in the IETF <br> community, I would say that that a few of the subscribers to this <br> mailing list could write and submit a review within five minutes.=C2=A0 I <= br> would not argue that those subscribers should go away (there is a <br> parable from Chesterton which explains that).<br> <br> >Also, in past Nomcoms I was part of in other organizations, this was <b= r> >often seen as an aggregate assessment, e.g. you had to select three <br= > >people for the same board and you strived to pick a mix of insiders <br= > >and outsiders, engineers and business people, Western and Southern, <br= > >etc. It was rare to achieve balance under all dimensions, but you <br> >tried to get as many as possible.<br> <br> I agree with the above.<br> <br> >This is also why I think that high level principles plus cultural <br> >commitment work better than hard quotas.<br> <br> It is not possible to see whether the high level principles worked if <br> there are no known targets.=C2=A0 Setting a requirement (re. quota) would <= br> be needed if the targets are being missed repeatedly.=C2=A0 John Levine <br= > commented as follows: "the only applicants are (to oversimplify only <= br> slightly) two guys from the San Francisco suburbs".=C2=A0 A switch wou= ld <br> be: the only applicants are two persons from same location.=C2=A0 The <br> question is whether that would be a desirable change if the <br> requirement was introduced.<br> <br> At 09:35 PM 07-07-2026, George Michaelson wrote:<br> >Admittedly this probably says as much about me as it does about them <b= r> >but the point is, I think this runs against the "incumbency" = issue. <br> >Yes, because to be a WG chair demands time, and because time as a WG <b= r> >chair demands prior time as an author, by the time you meet tech <br> >goals and understanding of IETF process to merit IESG you have been <br= > >around a long time, but no, I don't think this is an overwhelming <= br> >tendency to incumbents.<br> ><br> >I see new faces, new players.<br> ><br> >So tendency? Yes. possible. Actual eventuating circumstance? Less <br> >sure. Perhaps weighted by age/experience but also, a LOT of new faces.<= br> <br> Nowadays, the information about whether someone has been a working <br> group chair, RFC author, etc. can easily be found in the <br> datatracker.=C2=A0 The authorship listing does not mean that the person <br= > was directly involved in the review/publication process.<br> <br> I agree with George that a person may find out that he/she has been <br> around for a long time when he/she is aware that he/she understands <br> the finer details.=C2=A0 I would not use the word "merit" as it m= ight <br> convey that the title is an award; it's a personal choice.=C2=A0 The <b= r> weighting (re. above comment) could be one of several factors to consider.<= br> <br> I don't know most of the IESG or IAB members.=C2=A0 I found out that a = <br> person is an IESG member when I read "DISCUSS" emails.<br> <br> Regards,<br> S. Moonesamy<br> <br> 1. <a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatr= acker.ietf.org_nomcom_ann_1969_&d=3DDwIBAg&c=3DslrrB7dE8n7gBJbeO0g-= IQ&r=3DkrANNudPSfUTEf2kXiduBUqRjXhDsKNCASr1kibHLfs&m=3DLv0FWItoBoY_= NDix8DYlA_hW0HyiPjx8MuKIUMx5XLeRfMAlpV-mhMt7_oWKMjoc&s=3DX2xkxBT8rCJ1jP= 4Vs5BHW_3Y6tJonr8sQrs5fTkmXok&e=3D" rel=3D"noreferrer" target=3D"_blank= ">https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_nomcom_ann_1969_&d=3DDwIBAg&c=3DslrrB7dE8n7gBJbeO0g-IQ&r=3Dk= rANNudPSfUTEf2kXiduBUqRjXhDsKNCASr1kibHLfs&m=3DLv0FWItoBoY_NDix8DYlA_hW= 0HyiPjx8MuKIUMx5XLeRfMAlpV-mhMt7_oWKMjoc&s=3DX2xkxBT8rCJ1jP4Vs5BHW_3Y6t= Jonr8sQrs5fTkmXok&e=3D</a>=C2=A0 =C2=A0<br> <br> </blockquote></div> </blockquote></div> -- <br> Gendispatch mailing list -- <a href=3D"mailto:[email protected]" target= =3D"_blank">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]= g" target=3D"_blank">[email protected]</a><br> </blockquote></div> --000000000000107d7e06573509e8--