[Eligibility-discuss] Re: systers liaison Re: Re: Fwd: New Version Notification for draft-knodel-nomcom-gender-representation-07.txt

[Mallory Knodel <[e-mail]>]

Hi John,

Since we moved back to discussing the draft, I’ve removed the systers list
and brought it back to the elegy list.

On Mon, Nov 2, 2026 at 11:36 John C Klensin <[e-mail]> wrote:

> Hi Mallory,
>
> First, I am not trying to delay the draft.   If I thought it was
> ready to go, or even good enough, I'd want to push ahead, as I have
> done with many other drafts (both procedural and technical) in the
> past.  I'd don't think that is the case:
>
> (i) Because of the "representativeness" problems and what I see as
> the the false analogies to the maximum company membership, I don't
> believe the rationale holds water.  Even if this were the right thing
> to do, doing the right things for the wrong reasons does not strike
> me as the right foundation for what I see as an important change in
> how the IETF does things.   If I was not in favor of addressing the
> issue or didn't think it was important, I wouldn't care.   So "trying
> to delay", no.  "Trying to get things right and propose an interim
> mechanisms in the meantime", yes.    And, again, no matter how
> rapidly the draft (revised or not) can be expedited, it would not be
> effective for the better part of a year, so simply delaying it as a
> goal in itself would be a pointless waste of time.
>

It’s just an analogy, not a false one. Analogies are always a bit
imperfect. This really just establishes IETF legacy more than anything.



> (ii) While I would like to see more (e.g.) women active in, and
> contributing to, the IETF --and started working on bringing more
> women in during the 1990s-- I do not see the draft as clear enough
> about what it is trying to accomplish and how it will do that.   I
> don't want to either bring the virtue signaling argument back up or
> see anyone else do so, but your response to Tara (the one that
> finally caused me to write my first comment on the issue in many,
> many, months) emphasized to me the lack of clarity about goals.  So I
> think either goals and how they are to be evaluated should be made
> clear... or that we should devise a way to do some lightweight and
> low-cost experimenting rather than instituting what I see as a rather
> heavyweight, precedent-setting and hard-to-change, mechanism.
>

The draft is extremely concise about its goal. You are just arguing with
whether or not the goal is valid and achievable.

Thank you to Rob who made this paragraph sharper.


> If you have a way to address those concerns, especially one that
> would affect the composition of the current Nomcom, by all means
> charge ahead.
>

We have already been down both of these roads before. The group has moved
on. We’ve agreed not to confront more elaborated problem statement, wider
research, or entertain additional solutions at least within the context of
this document.

A draft that’s been sitting around for years has not exactly been charging
forward, unfortunately.

-Mallory


> best,
>    john
>
>
>
> --On Monday, November 2, 2026 11:08 -0500 Mallory Knodel
> <[e-mail]> wrote:
>
> > Hi John,
> >
> > Yes, it's very clear that you were trying to delay this draft. I
> > don't think your reasons are persuasive, nor do they reflect the
> > consensus discussion on the list or in gendispatches to date.
> >
> > Again, I really appreciate all of the ideas generation. Lots of
> > folks have come up with some really great suggestions, not the
> > least of which came from Tara and was then used to reshape the
> > draft's main mechanism.
> >
> > We have to balance lots of ideas with the need to keep this
> > intervention lightweight and straightforward.
> >
> > -Mallory
> >
> > On Mon, Nov 2, 2026 at 10:50 John C Klensin <[e-mail]>
> > wrote:
> >
> >> Mallory,
> >>
> >> I'm copying the Nomcom Chair.  While I'm sure Mankamana doesn't
> >> need any extra traffic in his mailbox, I assume that he has been
> >> following the eligibility-discuss messages and his reactions are
> >> key to my suggestion.
> >>
> >> I appreciate your recognizing that we are seeing an issue, or set
> >> of issues, that ought to be addressed in some way.  However, I
> >> think you may be missing part of the point that I, and I think
> >> Mike, are trying to make:
> >>
> >> While I found the selection mechanisms creative, even ingenious,
> >> the I-D, as written, won't work.  Mike has explained one key
> >> reason.  If the goal is representativeness of the community -- as
> >> it is, rather than how we would wish it to be-- it won't do that
> >> job for the reasons I described and several others have
> >> approximated.  Even if it, or a revised version, was workable and
> >> was accepted by the community, it could not have any effect until
> >> the 2027-2028 Nomcom. If it is worth making a change, it seems to
> >> me it is worth doing something sooner than that.
> >>
> >> So, to be very explicit, I am proposing:
> >>
> >> (1) If the Nomcom and Systers agree that something is worth doing,
> >> let's move in the direction of getting an Advisor appointed and do
> >> so Real Soon Now.  If they don't agree and/or don't believe it is
> >> feasible, that part of my proposal is dead.   However, especially
> >> if one or both are willing to explain their reasoning, even trying
> >> to get that moving would be useful input to discussions of your
> >> proposal or any plausible alternative.
> >>
> >> (2) We put your proposal on hold for IETF 127. I can imagine ways
> >> to address some of the issues Mike and I raised, and maybe some
> >> raised by others in the process, but find it hard to believe that
> >> can be done, and done well, in the slightly over eight \hours
> >> before the posting cutoff.   More important, I think (1), whether
> >> the outcome is an Advisor or not, would provide useful information
> >> for reworking the draft.  In particular, while I hope it is
> >> unlikely, if the Systers group does not believe that making _some_
> >> changes in this area is important enough for them to get involved,
> >> that would be a really important message.
> >>
> >> (3) I don't believe that trying to generate a proposal for a
> >> standing/ permanent liaison right now is a good idea.  While I've
> >> written enough already that I could probably drop other things and
> >> get a draft posted by UTC midnight, it would be very rough and
> >> leave a many loose ends.  As just one example, while I think
> >> asking Systers to appoint/recommend an advisor if the Nomcom is
> >> open to having one, whether their current relationship with the
> >> IETF (about which I'm somewhat vague, largely because it has not
> >> been important before this), makes them appropriate as a formal
> >> body to appoint a liaison to the Nomcom is an open question.  But,
> >> if anyone reading this thinks having that alternative in the form
> >> of a draft before IETF 127 starts would be helpful, and can let me
> >> know within the next hour or two, I can probably throw something
> >> together before UTC midnight.
> >>
> >> thanks,
> >>    john
> >>
> >>
> >> --On Monday, November 2, 2026 09:33 -0500 Mallory Knodel
> >> <[e-mail]> wrote:
> >>
> >> > John, Michael,
> >> >
> >> > I really appreciate your genuine and good-faith dedication to
> >> > diversity, equity and inclusion in the IETF.
> >> >
> >> > Your suggestion could be pursued separately but of course only if
> >> > there's interest from the systers group.
> >> >
> >> > This suggestion, however, is not in scope for the draft on nomcom
> >> > composition that is currently being discussed on the elegy list,
> >> > so I've BCCed that list for this thread going forward.
> >> >
> >> > Thanks,
> >> > -Mallory
> >> >
> >> > On Mon, Nov 2, 2026 at 9:07 AM John C Klensin
> >> > <[e-mail]> wrote:
> >> >
> >> >> Hi Mike,
> >> >>
> >> >> Thanks for this, particularly the reminder about how the process
> >> >> actually works.   It intersects with my comments about Mallory's
> >> >> statement that the draft does not  affect gender composition of
> >> >> the nomcom's selections or its results more generally.   I
> >> >> think the two sets of comments reinforce each other.
> >> >>
> >> >> If you already suggested a liaison (or nomcom-appointed advisor
> >> >> for at least the near term), I apologize for not mentioning it
> >> >> -- I think I reviewed your messages among the many others, but
> >> >> have been a bit overwhelmed by the volume and it didn't stick.
> >> >> And, as I tried to explain to Mallory in a note sent a few
> >> >> minutes ago, if a liaison would be a good solution (as we both
> >> >> seem to believe), then let's pause with trying to process an
> >> >> I-D now, convince the nomcom to ask Systers to appoint an
> >> >> advisor during one of their sessions at IETF 127 (or earlier),
> >> >> and then expect the nomcom and Systers tell us, around or after
> >> >> IETF 128, if that was useful and make recommendations.
> >> >>
> >> >>     john
> >> >>
> >> >>
> >> >> --On Sunday, November 1, 2026 20:48 -0500 Michael StJohns
> >> >> <[e-mail]> wrote:
> >> >>
> >> >> > Hi Mallory -
> >> >> >
> >> >> > It's rare that a "Give me all I ask for, or nothing" strategy
> >> >> > is actually all that successful - perhaps this will be one of
> >> >> > the rare exceptions, but I would be somewhat surprised if
> >> >> > that were the case.
> >> >> >
> >> >> > But I wanted to correct what appears to be a misunderstanding
> >> >> > implicit in what you wrote below and in the document itself.
> >> >> > The Nomcom is not a body that has power per se - it is a body
> >> >> > that serves the community by recruiting candidates, doing the
> >> >> > vetting on them and suggesting them to the confirming bodies.
> >> >> > It's work. Or at least it is with committed members. While
> >> >> > the choices within the Nomcom come down to a vote among 10
> >> >> > people, by the time any given vote is actually taken, there's
> >> >> > usually no real suspense about who. By that time, the Nomcom,
> >> >> > including the liaisons have all been heard and argued with.
> >> >> >
> >> >> > Any given Nomcom selection can be rejected by the appropriate
> >> >> > confirming body.  So is the next ask that we ensure that 1/3
> >> >> > to 1/2 of the IESG and/or 1/3 to 1/2 of the IAB meet a
> >> >> > particular demographic - as that's where the power actually
> >> >> > is?  How does that work given the participant demographics as
> >> >> > they exist today?
> >> >> >
> >> >> > But guaranteeing a liaison is not "in scope" for this
> >> >> > document...
> >> >> >
> >> >> > So I ask you - what's more important? The ability to have a
> >> >> > voice?  Or the ability to have a vote given the realities of
> >> >> > how the Nomcom actually operates?  Perhaps a thoughtful
> >> >> > consideration and discussion with the document of John's (and
> >> >> > for that matter my) suggestion rather than rejecting it out
> >> >> > of hand might be a mindful approach to understanding what is
> >> >> > needed vs what the document wants.
> >> >> >
> >> >> > Later, Mike
> >> >> >
> >> >> >
> >> >> > On 11/1/2026 18:52, Mallory Knodel wrote:
> >> >> >> Hi John,
> >> >> >> I haven't retrod the arguments you admit have already been
> >> >> >> made. But I did take your specific suggestion seriously and
> >> >> >> CC'ed the systers list.
> >> >> >> If folks want to consider this idea it would need to be a
> >> >> >> separate draft because the suggestion to bring in a volunteer
> >> >> >> from an underrepresented group and charge them with shaping
> >> >> >> discussions while  explicitly not giving them decision making
> >> >> >> power is out of scope for  what we are aiming for in this
> >> >> >> document.
> >> >> >> Thanks,
> >> >> >> -Mallory
> >> >> >>
> >> >> >> On Sun, Nov 1, 2026 at 6:24 PM John C Klensin
> >> >> >> <[e-mail]> wrote:
> >> >> >>
> >> >> >>     TL;DR: Much of this note questions that relationship
> >> >> >>     between this draft and concepts of "representativeness"
> >> >> >>     of the Nomcom, and ways to consider community diversity,
> >> >> >>     some (but I think only some) of which overlap comments
> >> >> >>     others have made before.  Per the note to which it
> >> >> >>     specifically responds, it also addresses the objectives
> >> >> >>     of the I-D. I then have a suggestion about an
> >> >> >>     alternative to this proposal that might address the same
> >> >> >>     issues but have immediate effect and be useful as an
> >> >> >>     experiment rather than pushing forward with this I-D
> >> >> >>     now.  Scan for "=======" if you want to skip ahead to
> >> >> >>     that suggestion.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>     --On Sunday, November 1, 2026 13:30 -0500 Mallory Knodel
> >> >> >>     <mallory.knodel=[e-mail]> wrote:
> >> >> >>
> >> >> >>     > On 10/20/26 23:54, John Levine wrote:
> >> >> >>     >
> >> >> >>     >> It appears that Tara Tarakiyee  <[e-mail]>
> >> >> >>     >> said:
> >> >> >>     >>>    * The Introduction now says the aim is to avoid
> >> >> >>     >>>    bias, not only    its appearance.
> >> >> >>     >> Could you be more specific about what sort of bias you
> >> >> >>     >> believe a gender quota will prevent?
> >> >> >>     >>
> >> >> >>     >> In particular, I understand that you do not claim this
> >> >> >>     >> will make any difference to the gender mix of the
> >> >> >>     >> people the nomcom selects. It would be helpful if you
> >> >> >>     >> could state one way or the other whether that's
> >> >> >>     >> correct.
> >> >> >>     >
> >> >> >>     > The draft only covers the makeup of the nomcom, the
> >> >> >>     > gender composition of appointees is not in scope.
> >> >> >>     >
> >> >> >>     > Bias here should not be read as individual but
> >> >> >>     > structural, and a more representative nomcom brings in
> >> >> >>     > more networks and community knowledge to improve
> >> >> >>     > deliberations.
> >> >> >>
> >> >> >>     Mallory, whether intentionally or not, I think this might
> >> >> >>     be a bit disingenuous.   If the intent is not to affect
> >> >> >>     results [1], then making specific provisions for non-male
> >> >> >>     membership on the Nomcom is of purely symbolic importance
> >> >> >>     and it is hard for me to believe that symbolism would be
> >> >> >>     worth the bias the mechanism would create (and that
> >> >> >>     others have explained). That bias _might_ be worth it if
> >> >> >>     the intent was to increase the odds of adjusting the
> >> >> >>     composition of one or more leadership bodies or to
> >> >> >>     produce some other significant effect and there were
> >> >> >>     community agreement to do so, but otherwise, I think the
> >> >> >>     case is very weak.
> >> >> >>
> >> >> >>     I think this has been adequately covered by others, but
> >> >> >>     I do remain concerned that creating special rules for
> >> >> >>     gender representation would encourage special rules for
> >> >> >>     other groups.  In particular, I've grown concerned in
> >> >> >>     recent months about whether typical nomcom memberships
> >> >> >>     adequately reflects IETF diversity based on age and/or
> >> >> >>     years of active participation in Internet technical work
> >> >> >>     and/or the IETF itself.  Diversity requirements in those
> >> >> >>     areas would complement the minimum requirements of
> >> >> >>     Section 3 of RFC 9389 just as this proposal does (and
> >> >> >>     create the same sorts of issues).
> >> >> >>
> >> >> >>     I do agree that a more representative nomcom is desirable
> >> >> >>     for the reasons you give, but requiring inclusion of
> >> >> >>     members of a particular group (even by the rather clever
> >> >> >>     and sophisticated mechanism of the I-D's Section 4)
> >> >> >>     reduces statistical representativeness.  If we wanted to
> >> >> >>     force a completely representative Nomcom, we would
> >> >> >>     develop an approach along the following (IMO, completely
> >> >> >>     implausible) lines:
> >> >> >>
> >> >> >>      (i) Figure out a way to objectively determine who is an
> >> >> >>      IETF participant and consider that a starting pool.
> >> >> >>      (ii) Remove from that pool all sitting members of
> >> >> >>      leadership groups.
> >> >> >>      (iii) Make a random draw of the desired number of nomcom
> >> >> >>             members from that pool.
> >> >> >>      (iv) Require that those drawn serve on the Nomcom -- no
> >> >> >>             excuses, no opt-out, no differentiation along
> >> >> >>     _any_ criteria.
> >> >> >>
> >> >> >>     Now, the first and fourth of those steps made the
> >> >> >>     approach, as I said, completely implausible, especially
> >> >> >>     given the interaction between the nomcom's workload and,
> >> >> >>     e.g., day job, resource, and health factors for
> >> >> >>     potential members. But any claim of "more
> >> >> >>     representative" should be evaluated against the
> >> >> >>     statistics of that approach, not by singling out some
> >> >> >>     particular group for special treatment.
> >> >> >>
> >> >> >>     Against that approach, even the exclusion of more than
> >> >> >>     two people from the same company that you use as an
> >> >> >>     analogy might make the nomcom less representative.  But
> >> >> >>     I suggest that it is not a good analogy because, in that
> >> >> >>     case, the possible harm of not doing that -- having a
> >> >> >>     single, or small number of cooperating, companies
> >> >> >>     dominate the nomcom and be in a position to create at
> >> >> >>     least the appearance of "packing" one or more leadership
> >> >> >>     bodies to reflect company interests -- is pretty clear.
> >> >> >>     Whether intentional or not, we've seen examples that
> >> >> >>     look suspiciously like such a desire to control things.
> >> >> >>     Those issues are explained reasonably well in RFC 9389.
> >> >> >>     Nomcom members doing so would violate other IETF codes
> >> >> >>     and criteria, primarily requirements to act as
> >> >> >>     individuals rather than in company interests, but RFC
> >> >> >>     9389 appears to reflect community judgment that,
> >> >> >>     especially since any sort of evaluation would compromise
> >> >> >>     nomcom confidentiality requirements, it does not provide
> >> >> >>     sufficient protection.  As 9389 explains, "packing" one
> >> >> >>     of the leadership groups to possibly reflect a corporate
> >> >> >>     agenda would cause obvious harm, if only in perceptions
> >> >> >>     of the IETF.
> >> >> >>
> >> >> >>     As I (and several others) have suggested before, the best
> >> >> >>     way to solve the (real or perceived) problem you are
> >> >> >>     identifying is to work on improving the number of women
> >> >> >>     and non-binary individuals participating (ideally, IMO,
> >> >> >>     with a focus on technical work, not procedures or
> >> >> >>     politics) in the IETF --with no requirement that they
> >> >> >>     publicly identify their gender-- and to increase the
> >> >> >>     number of people from those groups who volunteer for the
> >> >> >>     nomcom.   It isn't obvious how to do that, but it would
> >> >> >>     be good to see more effort on those topics rather than
> >> >> >>     on this particular and, IMO, problematic, patch.
> >> >> >>
> >> >> >>        =======
> >> >> >>
> >> >> >>     Suggestion that I hope you and others will see as
> >> >> >>     constructive:  We have an internal organization,
> >> >> >>     important enough to rate listing on meeting agendas, not
> >> >> >>     just as side meetings, called "Systers".   While I'm a
> >> >> >>     bit concerned that the nomcom has too many liaisons
> >> >> >>     already, it strikes me that it would be reasonable to
> >> >> >>     allow/encourage that group to appoint a liaison to the
> >> >> >>     nomcom.  That might be useful even if the random draw
> >> >> >>     process selected one or more non-male members, but maybe
> >> >> >>     not as important.   Given that BCP10 allows "Any
> >> >> >>     committee member may propose the addition of a liaison
> >> >> >>     from other unrepresented organizations", if the nomcom
> >> >> >>     members and the Systers group were willing, that could
> >> >> >>     even be done as an informal experiment with immediate
> >> >> >>     effect (i.e., on the 2026-2027 nomcom discussions, not
> >> >> >>     having to wait for some future one) with information
> >> >> >>     about its utility reported later (like the Chair report,
> >> >> >>     without compromising any private information).
> >> >> >>
> >> >> >>     Just as one of the functions of the liaisons from the
> >> >> >>     IESG and IAB can include identifying concerns about
> >> >> >>     particular candidates of which the Nomcom might
> >> >> >>     otherwise be unaware, a Systers liaison might, in
> >> >> >>     extreme cases, have knowledge that a particular
> >> >> >>     candidate has behaved like a chauvinist pig, behavior,
> >> >> >>     that had not been visible to the broader community,
> >> >> >>     moderators, etc.   I'd also hope (and assume) they could
> >> >> >>     make more general and constructive comments. That
> >> >> >>     information might be more effectively delivered directly
> >> >> >>     to the Nomcom membership than by, e.g., raising it
> >> >> >>     privately with the nomcom Chair. Of course, raising it in
> >> >> >>     public might create issues with codes of conduct and the
> >> >> >>     Moderator Team does not appear to have a specific,
> >> >> >>     direct, channel to the nomcom.
> >> >> >>
> >> >> >>        john
> >> >> >>
> >> >> >>     [1] From my point of view, to qualify as "results", they
> >> >> >>     would need only to change the nomcom discussions in some
> >> >> >>     way, possibly causing a difference in the candidate
> >> >> >>     selections from the entirely hypothetical profile of what
> >> >> >>     they might have been had the specially selected nomcom
> >> >> >>     members not been present. It does  not require anything
> >> >> >>     easily measured, e.g., selection of more non-men to serve
> >> >> >>     on the relevant groups.
> >> >> >>
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> Eligibility-discuss mailing list
> >> >> >> [e-mail] To unsubscribe send an email
> >> >> >> [e-mail]
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>