Subject: Updated Nomcom 2020-2021: Result of random selection process

From: NomCom Chair 2020 <[email-masked]>
Date: Wed, 08 Jul 2020 10:09:57 -0700

Luigi Iannone has informed me his affiliation has recently changed to "Huawei". That would make 3 Huawei people, which means one must be disqualified. 
Luigi requested that, since he was the person who didn't mention this prior to selection, he should be the one removed. I have no problem with this, so I will honor this request rather than removing Tal Mizrahi (as the last of the Huawei people selected). 

So, here is the updated list:

65. Dirk Kutscher, University of Applied Sciences Emden/Leer
114. Ketan Jivan Talaulikar, Cisco Systems, India
127. Christopher Wood, Cloudflare
38. Xuesong Geng, Huawei
121. Rüdiger Volk, no affiliation
86. Gabriel Montenegro, Independent
18. Pablo Camarillo, Cisco Systems
13. Chris Bowers, Juniper Networks
85. Tal Mizrahi, Huawei
94. Tony Przygienda, Juniper

Disqualified selections are noted below:
58. LUIGI IANNONE, Huawei (Maximum of 2 for Huawei reached) - 8th in randomness order, but requested to be the one removed
96. Reshad Rahman, Cisco (Maximum Number of 2 for Cisco reached) - 10th in randomness order

With this updated announcement, the challenge period continues through Wednesday, July 15, 2020 at 23:59 UTC, wherein the community may challenge the results to the NomCom Chair (in writing, by email).  See RFC 8713, Section 4.17 for details.

I will be contacting the selected volunteers to ensure they remain willing and available to serve.

Random selection data used:

** Random Source 1 - EuroMillions Lottery **
** Date - Tuesday July 7, 2020 **
EuroMillions Lottery Results
https://www.euro-millions.com/results
Tuesday, July 7, 2020 Results (drawn after 21:00 CEST):
https://www.euro-millions.com/results/07-07-2020
(7 numbers, including the star balls: 5 numbers between 1 and 50 and 2 star balls between 1 and 12)  

12 16 23 33 41 8 10

** Random Source 2 - US Total Debt **
** Date - Monday July 6, 2020 **
US Total Debt
https://www.treasurydirect.gov/govt/reports/pd/pd_debttothepenny.htm
Monday July 6, 2020 (as published after 3pm EDT on Tuesday July 7): 
(Last 8 digits entered as a single number, ignore the commas and periods -- 6 digits before the period and 2 digits after) 

23703560

** Random Source 3 - Australian TattsLotto **
** Date - Saturday July 4, 2020 **
TattsLotto Results
https://thelott.com/tattslotto/results 
Saturday July 4, 2020 results:
(6 winning numbers, between 1 and 45; no Supps numbers)

17 31 33 35 39 42 

** Random Source 4 - Emirates Loto **
** Date - Saturday July 4, 2020 **
https://www.emiratesloto.com/loto/winningnumber/previous
Saturday July 4 results:
(6 winning numbers, between 1 and 49)

10 20 21 24 26 34 

--------------- tool output -----------
Key is:
 8.10.12.16.23.33.41./23703560./17.31.33.35.39.42./10.20.21.24.26.34./
index        hex value of MD5        div  selected
 1  270D83B3AFE172BE3DAE13D5AFE10025  143  -> 65 <-
 2  FE6FBE4A6FCAEFD6570D957596C0BC9A  142  -> 114 <-
 3  AD10AAF6B527062D0E2F0E7B29AD3546  141  -> 127 <-
 4  8614C1D4C4EBFACE6A5049AF1F9782CD  140  -> 38 <-
 5  7D1EE81F1788AEA0FF359230F8096076  139  -> 121 <-
 6  E7013327C78EA666CFA0ADD69E017D37  138  -> 86 <-
 7  67135E88868DFC359459BF509920ACBD  137  -> 18 <-
 8  ADDCDE6B8985E911E19CC6107B587597  136  -> 58 <-
 9  D520F04487BA1AFE92B49AE7C613A7D0  135  -> 13 <-
10  4CC1EA463D3BC82C7009830F8ACDF431  134  -> 96 <-
11  9366F9278BD4CEE289093677432B2C03  133  -> 85 <-
12  A60E734755D605CD1189716F7FB1183E  132  -> 94 <-

Barbara Stark
nomcom-chair-2020 at ietf dot org

---

From: Michael StJohns <[email-masked]>
Date: Fri, 10 Jul 2020 12:04:50 -0400

Hi -

I hate to do this, but I'm going to be challenging this particular 
outcome as it isn't strictly following the rules - basically, Luigi may 
not be replaced by Tal.  He either serves, or if he declines to serve, 
the next person on the list - not Tal - will be selected.

Here's my reasoning:

After Luigi belatedly indicated his association with Huawei, the defined 
process results in him remaining on the list but Tal being disqualified 
(as there being 2 previous Huawei people selected before him).   If 
Luigi - at a later time - decided he couldn't serve, *_we don't reach 
back on the list for the previously disqualified people, we look 
forward_* - e.g. Tal once disqualfied is no longer a candidate for 
future pulls.  If the next selected (#13 I think) is Huawei, they could 
serve as Luigi's departure would move the Huawei count back down to 1.

The whole idea of this random draw is that people can't pick and choose 
to substitute someone else for themselves.  Ideally, we would do a new 
random number generator for each additional selection rather than 
continuing down the list to completely eliminate those possibilities, 
but in the current model, I believe Tal is disqualified and will stay 
that way.

If Luigi still wants to remove himself, then the next selectee will be 
the one in the 13th position, not Tal in the disqualified 8th.

Mike

On 7/8/2020 1:09 PM, NomCom Chair 2020 wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 10 Jul 2020 16:31:14 +0000

*   I hate to do this, but I'm going to be challenging this particular outcome as it isn't strictly following the rules - basically, Luigi may not be replaced by Tal.  He either serves, or if he declines to serve, the next person on the list - not Tal - will be selected.

I agree with this challenge, for the reasons Mike posted.

---

From: Mary B <[email-masked]>
Date: Fri, 10 Jul 2020 11:35:19 -0500

I totally agree with Mike.

Regards,
Mary.

On Fri, Jul 10, 2020 at 11:05 AM Michael StJohns <[email-masked]>
wrote:

> Hi -
>
> I hate to do this, but I'm going to be challenging this particular outcome
> as it isn't strictly following the rules - basically, Luigi may not be
> replaced by Tal.  He either serves, or if he declines to serve, the next
> person on the list - not Tal - will be selected.
>
> Here's my reasoning:
>
> process results in him remaining on the list but Tal being disqualified (as
> there being 2 previous Huawei people selected before him).   If Luigi - at
> a later time - decided he couldn't serve, *we don't reach back on the
> list for the previously disqualified people, we look forward* - e.g. Tal
> once disqualfied is no longer a candidate for future pulls.  If the next
> selected (#13 I think) is Huawei, they could serve as Luigi's departure
> would move the Huawei count back down to 1.
>
> The whole idea of this random draw is that people can't pick and choose to
> substitute someone else for themselves.  Ideally, we would do a new random
> number generator for each additional selection rather than continuing down
> the list to completely eliminate those possibilities, but in the current
> model, I believe Tal is disqualified and will stay that way.
>
> If Luigi still wants to remove himself, then the next selectee will be the
> one in the 13th position, not Tal in the disqualified 8th.
>
> Mike
>
>
>
> EuroMillions Lottery Resultshttps://www.euro-millions.com/results
> Tuesday, July 7, 2020 Results (drawn after 21:00 CEST):https://www.euro-millions.com/results/07-07-2020
> US Total Debthttps://www.treasurydirect.gov/govt/reports/pd/pd_debttothepenny.htm
> TattsLotto Resultshttps://thelott.com/tattslotto/results
> ** Date - Saturday July 4, 2020 **https://www.emiratesloto.com/loto/winningnumber/previous
> Saturday July 4 results:
> IETF-Announce mailing [email-masked]://www.ietf.org/mailman/listinfo/ietf-announce
>
>
>

---

From: Kyle Rose <[email-masked]>
Date: Fri, 10 Jul 2020 12:52:45 -0400

+1.

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Jul 2020 14:27:59 -0400

Mike,

I (somewhat reluctantly for sa few reasons) agree.  Once
disqualified, always disqualified for that Nomcom.  While I'm
confident that no such thing happened here, it also suggests
something about which I think the rules are unclear and that we
might want to work on for the future.

The attack scenario would be: suppose EvilCo [1] wants to get,
not only two people on the Nomcom but, if possible, two of their
most skilled committee-manipulators.  In that case, they put
_many_ people into the Nomcom candidate pool, enough to create,
not only high odds of getting two positions in the top ten but
good odds of getting several of slots 11-15 as well.  Then those
who are selected stop down in favor of of the preferred
manipulators.  Note that redoing the random draw would not
effect that scenario and the likelihood that more people in the
pool would yield more top slots (as sell as more bottom slots of
course)-- it would just reshuffle the deck.  

At least statistically, the right solution for this is that, as
soon as a company gets two people in the top 10, every other
member of the pool from that company is eliminated from the
rankings.  If one of the people from that company steps down
(change of affiliation, change of time availability, loss in
argument with the proverbial truck, ...) or is removed for an
unrelated reason, the company just loses that second seat
(nothing both Michael's "1 of 10" arguments and the theory that
those people are not supposed to be representing the company or
its interests in any way, that should not make much difference).

There is a related scenario that we should consider eventually
but that fortunately did not arise in this case.  It may
indicate the wisdom or your analysis.  Assume for purposes of
discussion that, instead of going to work for Huawei, Luigi had
gone to work for Juniper before or just after the selections
were announced.  There are already two Juniper employees on the
list, one of whom ranked lower than Luigi.  So, Luigi announces
that he has just gone to work for Juniper.  If he didn't
voluntarily step down, I think that retroactively eliminates
Tony and takes us to the next (not already eliminated or Juniper
employee) on the list.  But I'm not sure that is clear.  

Having not studied the rule carefully in recent weeks, I'm also
not sure they are clear about what is supposed to happen, if the
Nomcom were to get well into the interview stage or beyond and a
voting member were to switch affiliations to a company that
already had two seats.

But let's hope we can think about that at our leisure, maybe in
the eligibility-discuss context, rather than having to wrestle
with it this year.

When the Nomcom mechanisms were first being designed, there was
an implicit assumption that the IETF and the collection of
people who were likely to volunteer for the Nomcom pool were
sufficiently diverse that we didn't need special rules for,
e.g., multiple people from one company: the randomization
process would work well enough to much more than one person per
company a vary rare event (and "1 of 10") a good answer to
almost any question.  As the industry became more concentrated
we felt a need to at the "no more than two" rule but, I think,
expected that it would not be exercised often.   Noting that the
latest list contains two people from each of Cisco, Huawei, and
Juniper (and with no assumption that they would collaborate in
any way but one could still be concerned about large-company
influences in the leadership selection process), we may need to
some more fundamental thinking about Ncomom selection above and
beyond random selection from a not-so-random pool.  Again, not
this year.

best,
    john

[1] There is, AFAIK, no company of that name or inclination
involved (or with its employees involved) in the IETF today or
in the past.  But this is all about future planning and one can
never tell what might happen.

--On Friday, July 10, 2020 12:04 -0400 Michael StJohns
<[email-masked]> wrote:

> Hi -
> 
> I hate to do this, but I'm going to be challenging this
> particular outcome as it isn't strictly following the rules -
> basically, Luigi may not be replaced by Tal.  He either
> serves, or if he declines to serve, the next person on the
> list - not Tal - will be selected.
> 
> Here's my reasoning:
> 
> After Luigi belatedly indicated his association with Huawei,
> the defined process results in him remaining on the list but
> Tal being disqualified (as there being 2 previous Huawei
> people selected before him).   If Luigi - at a later time -
> decided he couldn't serve, *_we don't reach back on the list
> for the previously disqualified people, we look forward_* -
> e.g. Tal once disqualfied is no longer a candidate for future
> pulls.  If the next selected (#13 I think) is Huawei, they
> could serve as Luigi's departure would move the Huawei count
> back down to 1.
> 
> The whole idea of this random draw is that people can't pick
> and choose to substitute someone else for themselves. 
> Ideally, we would do a new random number generator for each
> additional selection rather than continuing down the list to
> completely eliminate those possibilities, but in the current
> If Luigi still wants to remove himself, then the next selectee
> will be the one in the 13th position, not Tal in the
> disqualified 8th.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 10 Jul 2020 23:25:46 +0300

WARNING: RFC lawyering follows.

I’m not sure I agree.  Two paragraphs in section 4.17 of RFC 7437 govern this.

The first is the second paragraph:

   No more than two volunteers with the same primary affiliation may be
   selected for the nominating committee.  The Chair reviews the primary
   affiliation of each volunteer selected by the method in turn.  If the
   primary affiliation for a volunteer is the same as two previously
   selected volunteers, that volunteer is removed from consideration and
   the method is repeated to identify the next eligible volunteer.

Clearly this is the procedure for the chair to follow if she detects that the list contains more than two people with the same affiliation. This is the procedure that was followed to remove Reshad Rahman, but note that the RFC does not call this being disqualified; just “removed from consideration”.  This was not what happened with the Huawei candidates. In that case, the relevant paragraph is the sixth paragraph:

   If a selected volunteer, upon reading the announcement with the list
   of selected volunteers, finds that two or more other volunteers have
   the same affiliation, then the volunteer should notify the Chair who
   will determine the appropriate action.

This puts the determination of how to proceed in the hands of the chair.  She is not required to roll back the clock to simulate a situation in which Luigi Iannone had filled in the volunteer form correctly. I believe she has made such a determination, and has acted within the mandate of RFC 7437.

Yoav

> On 10 Jul 2020, at 19:04, Michael StJohns <[email-masked]> wrote:
> 
> Hi - 
> 
> I hate to do this, but I'm going to be challenging this particular outcome as it isn't strictly following the rules - basically, Luigi may not be replaced by Tal.  He either serves, or if he declines to serve, the next person on the list - not Tal - will be selected.
> 
> Here's my reasoning:
> 
> After Luigi belatedly indicated his association with Huawei, the defined process results in him remaining on the list but Tal being disqualified (as there being 2 previous Huawei people selected before him).   If Luigi - at a later time - decided he couldn't serve, we don't reach back on the list for the previously disqualified people, we look forward - e.g. Tal once disqualfied is no longer a candidate for future pulls.  If the next selected (#13 I think) is Huawei, they could serve as Luigi's departure would move the Huawei count back down to 1.
> 
> The whole idea of this random draw is that people can't pick and choose to substitute someone else for themselves.  Ideally, we would do a new random number generator for each additional selection rather than continuing down the list to completely eliminate those possibilities, but in the current model, I believe Tal is disqualified and will stay that way.
> 
> If Luigi still wants to remove himself, then the next selectee will be the one in the 13th position, not Tal in the disqualified 8th.
> 
> Mike
> 
> 
> 
>> https://www.euro-millions.com/results <https://www.euro-millions.com/results>
>> https://www.euro-millions.com/results/07-07-2020 <https://www.euro-millions.com/results/07-07-2020>
>> https://www.treasurydirect.gov/govt/reports/pd/pd_debttothepenny.htm <https://www.treasurydirect.gov/govt/reports/pd/pd_debttothepenny.htm>
>> https://thelott.com/tattslotto/results <https://thelott.com/tattslotto/results> 
>> https://www.emiratesloto.com/loto/winningnumber/previous <https://www.emiratesloto.com/loto/winningnumber/previous>
>> Saturday July 4 results:
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
>

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 10 Jul 2020 16:47:01 -0400 (EDT)

On Fri, 10 Jul 2020, John C Klensin wrote:

> ... I'm also

That part, at least, is clear.  End of section 5.7:

    A change in the primary affiliation of a voting volunteer during
    the term of the NomCom is not a cause to request the recall of
    that volunteer, even if the change would result in more than two
    voting volunteers with the same affiliation.

To the matter at hand, though, I like Yoav's analysis. [1]  Let's let 
the Nomcom get to work.

-- Sam

[1] Though he should be citing RFC8713, not 7437.  :-)

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Jul 2020 23:13:12 +0200

Thanks, Michael, inline

On Fri, Jul 10, 2020 at 12:04:50PM -0400, Michael StJohns wrote:
> there being 2 previous Huawei people selected before him).

Can you please do me the favour of pointing to written evidence or prior
examples of this specifically being the process ? I don't remember a
place where the situation of belated disclosure is discussed, nor do
i remember that we had to adjudicate such a case in before. But that
can of coursee just me not remembering/finding such evidence.

If there is no unambiguous evidence as to what you suggesting there is,
then it would be good to understand if there is written rules for who
has the authority to resolve such ambiguous situations. Eg.: NomCom
chair, Michael StJohns or some other authority. Thats maybe written down.

Just helpfull to have the rules explicitly in the thread so not everbody
has to hunt them down.

> If Luigi - at a
> later time - decided he couldn't serve, *_we don't reach back on the list
> for the previously disqualified people, we look forward_* - e.g. Tal once
> disqualfied is no longer a candidate for future pulls.  If the next selected
> (#13 I think) is Huawei, they could serve as Luigi's departure would move
> the Huawei count back down to 1.

Sounds as if i would agree pending on the above listed conditions, wrt process.

> substitute someone else for themselves.

Is this a rule, is there prior evidence of this being applied this way,
is this something NomCom chair could/should decide on her own,  are
suggestions from IETF mailing lisst or formal complaint the right process ?

Adjudication by mailing list is difficult, so again: would be good to
first be crisp about whats written down, or what we have as case law.

Of course, i am happy if this "whole idea" was made clear in update to the
rules in case they are not clear, but that can not be retroactive.

> one in the 13th position, not Tal in the disqualified 8th.

Thanks for bringing this up. I hope i am not too anal either, but i
think it is helpfull to fully understand the rules and act on them.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Martin Duke <[email-masked]>
Date: Fri, 10 Jul 2020 14:26:26 -0700

> course)-- it would just reshuffle the deck.

I don't believe this analysis is correct. For EvilCo's plan to work, the
two preferred people have to be in positions N+1 and N+2 on the list, which
is exceedingly unlikely. If the secondary people withdraw, it's as if they
had never been on the list in terms of positioning.

What is possible is for EvilCo to increase the probability of getting
someone onto the NomCom, and if more than two people are drawn, for EvilCo
to pick which two actually serve. This eliminates the disincentive for more
staff from a single entity to volunteer, because they might bump someone
more senior or capable. That may or may not be a problem! But adding dummy
volunteers doesn't get you any closer to getting a certain person on, IIUC.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 10 Jul 2020 18:58:39 -0400

On 7/10/2020 4:25 PM, Yoav Nir wrote:
> Clearly this is the procedure for the chair to follow if she detects 
> that the list contains more than two people with the same affiliation. 
> This is the procedure that was followed to remove Reshad Rahman, but 
> note that the RFC does not call this being disqualified; just “removed 
> from consideration”.  This was not what happened with the Huawei 
> candidates. In that case, the relevant paragraph is the sixth paragraph:
>
> This puts the determination of how to proceed in the hands of the 
> chair.  She is not required to roll back the clock to simulate a 
> situation in which Luigi Iannone had filled in the volunteer form 
> correctly.

You're mischaracterizing what happened I believe.  Luigi was always a 
Huawei employee, but the chair did not have that information.  Once the 
chair had that information, the results of the selection process needed 
to be corrected so they were based on reality - Note: not "changed".

The whole process is designed to eliminate discretion from the selection 
process.   While I agree that the document says the above, it does not 
mean that the chair may take any action they choose.  E.g. there were 
three Huawei members - what if she kept Luigi and Tal and got rid of 
Xuesong?   We still end up with two Huawei members.  In any event, you 
need to look at more than just the above.

The correct path is to take the list from all common knowledge and work 
from there.  And that list built from the common knowledge (the 
volunteer list, plus associations plus the random seeds) has Luigi on it 
and Tal off of it.   Per

>     It must be possible to repeat the selection method, either through
>     iteration or by restarting in such a way as to remain fair and
>     unbiased.  This is necessary to replace selected volunteers should
>     they become unavailable after selection.

and

>     If a single voting volunteer position on the nominating committee is
>     vacated, regardless of the circumstances, the committee may choose to
>     proceed with only nine voting volunteers at its own discretion.  In
>     all other cases, a new voting member must be selected, and the Chair
>     must repeat the random selection process including an announcement of
>     the iteration prior to the actual selection as stated elsewhere in
>     this document.

If Luigi declines to take the position, "the chair must repeat the 
random selection process" or work with 9 members.   In general, that's 
meant continuing down the list, not going back and picking up someone 
who was already not selected.

> I believe she has made such a determination, and has acted within the 
> mandate of RFC 7437.

Luigi indicating he works for Huawei restructures the list and 
eliminates Tal.  Luigi indicating he won't serve triggers 5.7. These are 
two separate events.

This is not ambiguous.

Mike

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 01:55:01 +0200

On Fri, Jul 10, 2020 at 06:58:39PM -0400, Michael StJohns wrote:
> > This puts the determination of how to proceed in the hands of the chair.
> >  She is not required to roll back the clock to simulate a situation in
> > which Luigi Iannone had filled in the volunteer form correctly.
> 
> You're mischaracterizing what happened I believe.  Luigi was always a Huawei
> employee, but the chair did not have that information.  Once the chair had
> that information, the results of the selection process needed to be
> corrected so they were based on reality - Note: not "changed".

I am not going to ask you again to provide evidence, e.g.: text from RFC
that says what you write because you already did not do this when i asked
for it in my first mail on this subject. Instead, i will just state my
opinion:

I think what you write is your opinion, and you are not providing evidence
that what you write is an actual rule. Yoav did provide evidence by
citing relevant RFC paragraphs.

> process.   While I agree that the document says the above, it does not mean
> that the chair may take any action they choose.

In my reading of the RFC paragraph cited by Yoav, it does not support
that opinion of yours.

> E.g. there were three
> Huawei members - what if she kept Luigi and Tal and got rid of Xuesong?   We
> still end up with two Huawei members.

And your point being ?

>  In any event, you need to look at more than just the above.
> 
> The correct path is to take the list from all common knowledge and work from
> there.  And that list built from the common knowledge (the volunteer list,
> plus associations plus the random seeds) has Luigi on it and Tal off of
> it.   Per
> 
> If Luigi declines to take the position, "the chair must repeat the random
> selection process" or work with 9 members.   In general, that's meant
> continuing down the list, not going back and picking up someone who was
> already not selected.

   rfc3797

   The best way to handle this is to maintain the announced schedule,
   INCLUDE in the published pool all those whose eligibility is
   uncertain and to keep the published pool list numbering IMMUTABLE
   after its publication.  If someone in the pool is later selected by
   the algorithm and random input but it has been determined they are
   ineligible, they can be skipped and the algorithm run further to make
   an additional selection.  Thus the uncertainty only effects one
   selection and in general no more than a maximum of U selections where
   there are U uncertain pool members.

   Other courses of action are far worse (refer to the RFC for the why...)

> Luigi indicating he works for Huawei restructures the list and eliminates
> Tal.  Luigi indicating he won't serve triggers 5.7. These are two separate
> events.

I don't think the period for complaints is over, so the nomcom is not
officially enacted yet, which makes 5.7 irrelevant i think. I may be wrong.
Even when i am wrong, i am not sure why you say 5.7 is in play here.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 10 Jul 2020 19:55:26 -0400

I agree with Mike’s analysis 
Olafur

> On Jul 10, 2020, at 12:04 PM, Michael StJohns <[email-masked]> wrote:
> 
> Hi - 
>

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 02:28:00 +0200

> I agree with this challenge, for the reasons Mike posted.

I think Mike did a good job in confusing the facts, and maybe the
explanations from NomCom chair also do not correctly describe what
IMHO happened:

Luigi simply declared that he can not serve, and NomCom chair
had to take the 12th hashed candidate. Where and how is the
reason for declaring that one does not want to serve an aspect
in changing the process for selecting the next candidate from the
list ? I can't find anything about this in he rules. What if
Luigi had said he can not serve without explaining his employer
change ?

Now, if Luigi had said he wanted to serve, and now he works
for Huawei, then i guess NomCom chair would have had the
freedom to decide whether to remove Tal or Luigi. But in either
case this would not change that Tony would be the next one on
the list.

Cheers
---
[email-masked]

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Jul 2020 17:44:34 -0700

> On Jul 10, 2020, at 5:28 PM, Toerless Eckert <[email-masked]> wrote:
> 
> explanations from NomCom

IMO, Mike is correct.

I think the intent here is simple: there aren’t Huawei slots; when someone from a given company steps out, that doesn’t mean someone from that company steps in.

The right thing is to re-run the process and see what the result is. Otherwise, as is being seen, one person can “game” who is on the committee. That’s exactly what the detailed automated process is intended to prevent.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 03:11:08 +0200

On Fri, Jul 10, 2020 at 02:27:59PM -0400, John C Klensin wrote:
> disqualified, always disqualified for that Nomcom.

See my answer to Rich.

> While I'm

I am sure there are a lot of refinements that can be done, but
this specific case to me looks crystal clear.

> most skilled committee-manipulators.
>
> In that case, they put
> manipulators.

EvilCo needs to invest a lot, like 50% or more of Nocom candidates
to get even 2 folks safely into slot 11-15. and if it has so
many employees but only some of tham have the special degree of
skilled committee-manipulator it still wouldn't help much.

Much easier to give a quick committee-manipulator training to
the two electect nomcom members. And let the skilled committe-manipulators
work on orchestrating official nomcom input. 

> Note that redoing the random draw would not
> rankings. 

> If one of the people from that company steps down

I already said my opinion about the IMHO unfair punishment of
company affiliation over all the other type of loyalty 
ecosystems (geo, business communities, government adjacencies) that we
have in the community. Your proposal even further beats up on
employers without any eveidence IMHO of such evilness.

This would be stepping from the theoretical argument of
an EvilCorp over to increasing punishment of large contributors
to the IETF.

If pigs could fly, the would need sun glasses.
Now all pig farmers MUST buy parachutes for their pigs.

> employee) on the list.  But I'm not sure that is clear.  

I was thinking about Rashed quickly filing a sabattical so as
not to receive money fro Cisco and get back onto the List,
asking NomCom chair to be reinstated and kick of Tal. Not
sure if current rules would allow/prohibit that.

As long as we don't have EvilNomComChair, i wonder how much more
fine-tuning we should do as opposed to leave it up to GoodNomComChair.
> the eligibility-discuss context, rather than having to wrestle

I am still for at most 2 candidate from each country,
not just to make a point of spreading the pain of discrimination
beyond large employers, but also because i think it could help
diversity. While nomcom this time is quite diverse from
where people are originally from, there are 4 who live in USA.

> beyond random selection from a not-so-random pool.  Again, not

This is just like discrimination based on skin-color: Aka:
Its more difficult to figure out other loyalty groups,
so lets only discriminate based on what we can figure out
easily. Hence the question: Why not add discrimination based
on country. We are also tracking that in registrations. easy.
How about people who find the overwhelming influence of people
living in the the USA bad for the IETF ?

Just saying. If we open up this book again it will simply lead
to another road kill by whoever manages to bring the most vocal
crowd to the microphone / mailing list. Already the "me too" voices
in this thread don't give me the impression that everybody was doing
their own sincere analysis of the situation, but jumping to the
opportunity to disciminate further against a specific entity.
Again, just my reading of some of the feedback in the thread.
I hope i am wrong.

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 03:19:15 +0200

On Fri, Jul 10, 2020 at 05:44:34PM -0700, Joseph Touch wrote:
> I think the intent here is simple: there aren???t Huawei slots; when someone from a given company steps out, that doesn???t mean someone from that company steps in.

Of course not, but: 
On which planet did this happen ?
How do you come to interpret what happened in that way ?
Luigi declined to serve. Thats all.

What am i overlooking here ?

> The right thing is to re-run the process and see what the result is.

rfc3797  section 5.1, paragraph 3.

> Otherwise, as is being seen, one person can ???game??? who is on the committee. That???s exactly what the detailed automated process is intended to prevent.

And if 99% of NomCom qualified people are from one company,
we can't build a NomCom. Please do not use ridiculous theories
to justify changes in process or mishandling of the existing
rules.

Toerless

-- 
---
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Jul 2020 18:28:01 -0700

> Luigi declined to serve. Thats all.

I'm not sure that we actually have enough information to say that.
https://mailarchive.ietf.org/arch/msg/ietf/o8p6rh9boOs65QTTIpBb73t-fV4/
says "has informed [the Nomcom chair] his affiliation has recently
changed".  That's not exactly "has said he cannot serve", and doesn't say
anything about when the affiliation changed with respect to the timeline of
the Nomcom selection process.  Is there other information available that
I'm missing (n.b. I'm quite behind on IETF mail at the moment)?

Thanks,

Ben

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 04:16:20 +0200

> I'm missing (n.b. I'm quite behind on IETF mail at the moment)?

Sure, but yada yada yada -> he decided that he did not want to serve.

Aka: How is all the justification how he arrived at that decision relevant ?

And even if the reasons where relevant, for which i can not find
any evidence in the relevant RFCs, then i can't see how this woud
have changed the outcome.

And even if he would have decided that he did want to serve, it
would have been up to NomCom chair to decide (my reading of the RFC),
and but i can't seriously not think of how a NomCom chair would have
kicked out anyone else (from that company) than the person newly announcing
the affiliation.

The argument made on the list is to violate section 5.1 of rfc3793 AFAIK.

Cheers
   Toerless

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Jul 2020 19:55:36 -0700

> On Jul 10, 2020, at 6:19 PM, Toerless Eckert <[email-masked]> wrote:
> 

Luigi’s new affiliation disqualifies Tai.

If Luigi wants to step out, that’s his decision - but he doesn’t get to then control the fact that Tai gets put back in. That’s the “but there is now a Huawei slot” issue - so, to answer your first question, planet Earth.

> rfc3797  section 5.1, paragraph 3.

Mike already spoke to this point.

> to justify changes in process or mishandling of the existing

Conflict of interest is based on whatever anyone (including me) thinks COULD be a motivation.

That concept is no more ridiculous than the automated system that’s been created to go out of our way to avoid it.

Joe

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Jul 2020 20:04:18 -0700

> Sure, but yada yada yada -> he decided that he did not want to serve.

I still don't see that as the only possibly conclusion possible from the
available data.  I see a difference between "he concluded that he could not
comply with the rules and still serve" and "he decided that he did not want
to serve".

> kicked out anyone else (from that company) than the person newly announcing

My understanding is that we do not know that it's about anyone's specific
with (other than to comply with the BCPs, I guess).  It might be, but it
might just be about complying with the BCPs.  Specifically, Section 4.17 of
RFC 7437 makes a prohibition regarding "volunteers with the same primary
affiliation may be selected".  I read that as saying that the "selection"
occurs when the randomness is finalized and the 3797 algorithm run, and
thus that the relevant affiliation is the primary affiliation at that time.
If the affiliation at that time is disclosed after that time, then we are
into the Section 5.1 of 3797 case that you mention below.

-Ben

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 05:28:32 +0200

On Fri, Jul 10, 2020 at 07:55:36PM -0700, Joseph Touch wrote:
> Luigi???s new affiliation disqualifies Tai.
> 
> If Luigi wants to step out, that???s his decision - but he doesn???t get to then control the fact that Tai gets put back in. That???s the ???but there is now a Huawei slot??? issue - so, to answer your first question, planet Earth.

   If a selected volunteer, upon reading the announcement with the list
   of selected volunteers, finds that two or more other volunteers have
   the same affiliation, then the volunteer should notify the Chair who
   will determine the appropriate action

I don't see any further constraints than letting it be up to the NomCom
chair to decide what appropriate action is.

Given how Luigi could have simply said "i withdraw from serving", an
interpretation like the one Michael and you are alluding to would just
create an incentive in similar future case for volunteers to not be fully
forthcoming as to their motivation to withdraw so as not to punish
 colleagues in a new employer they just joined. Thats quite silly. 

If i compare the silly EvilEmpire theories invented in support of the
argument vs. the simple rule that its NomCom chairs decision as i think
also the RFC says is IMHO the much more logical conclusion. And given
how the existing 2-only rule is already discrimination, its also a lot
more logical for the NomCom chair to be acting without paranoia.

But this is not how it ends. Now the demand is not to actually remove
only person (Luigi) who was forthcoming, trying to be a good IETF'er,
but also a second person (Tal). If you are getting enough support to
misread 7437, then at least acknowledge that in hindsight and
misunderstanding the rules like you propose to, Luigi and i think
NomCom chair as well would have simply concluded to keep Luigi and drop Tal
instead of dropping both of them.

Cheers
    Toerless

> That concept is no more ridiculous than the automated system that???s been created to go out of our way to avoid it.
> 
> Joe

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 05:46:40 +0200

> comply with the rules and still serve" and "he decided that he did not want

See my reply to Joseph.

> with (other than to comply with the BCPs, I guess).

parsing failed, please rephrase.

> It might be, but it

> into the Section 5.1 of 3797 case that you mention below.

Which to me means that the appropriate action for NomCom chair should have
been to disqualify Luigi because 5.1 is about not to readjucate other
admitted nomcom members (my reading). 

Also just logical it makes more sense. If i was Tal, it would be quite
annoying to be kicked out after the announcement because of somebody 
elses affiliation change. Whereas if i was in Luigis place i would have
been fine to be taken off the list for me given how the employer change would
have been my decision.

Of course i haven't really thought about what i would think about the
improbable stochastically impossible evil conspiracy theory that was
invented in this thread, but if IETF starts to make rules
assuming large companies are such EvilCorps and ignore probabilities,
should IETF then still accept money from the same big corporations ?

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Fri, 10 Jul 2020 20:14:17 -0800

On 7/10/20 7:46 PM, Toerless Eckert wrote:
> invented in this thread, 

I really wish you'd stop diminishing this issue and in particular
would stop mocking it.  It seems unlikely to me that it's changed
anybody's mind, particularly of those of us who've been around long
enough to see companies actually attempt to stuff nomcom.  However,
even if it's not a deliberate attempt bias can creep in because of some
companies supporting employee participation in nomcom while others
do not (not to mention people who participate on their own).

It's not evil in any particular sense, it's self-interested.  But,
it's also a source of bias and it's reasonable to try to eliminate
bias in the selection process.  If you perceive other sources of
bias definitely feel free to put together a proposal to deal with
them.

At any rate, you've made the same argument repeatedly and I
think you're entering the realm of diminishing returns.

Thanks,

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Jul 2020 21:46:26 -0700

> On Jul 10, 2020, at 8:28 PM, Toerless Eckert <[email-masked]> wrote:
> 
> colleagues in a new employer they just joined.

That incentive has its own response, once detected. 

> Thats quite silly. 

Conflict of interest is not about ONE possible scenario that YOU (or anyone else) find valid. It’s about whether ANY of US consider ANY possible scenario unacceptable.

What you call “silly” some of us call “ethics”.

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 07:56:02 +0200

On Fri, Jul 10, 2020 at 08:14:17PM -0800, Melinda Shore wrote:
> I really wish you'd stop diminishing this issue

Please remember that the sentence was in the context of attempts
to do evil by a switcharoo. This discussion was at all NOT about
loyalty bias that is influencing nomcom members.

> and in particular would stop mocking it.

I did not introduce the term EvilCo into the discussion, i was just
commenting on it. How else should i have written that its stochastically
extremely unlikely to be able to push a specific other company
employee into NomCom. Hence its IMHO very unlikely that any evil but
not stupid company would attempt to do that. But if thats what would happen,
then that would be an evil conspiracy IMHO.

> It seems unlikely to me that it's changed
> enough to see companies actually attempt to stuff nomcom.

What you call stuffing, others might call one contributor, one voice.

The larger the percentage of contributors from fewer, larger companies is,
the less fair the max2 rule is wrt. for proportional representation of
the interests of those contributors in what are IETF elections. In the
whole long thread i initiated 2? weeks ago about that, nobody even bothered
to even acknowledge that fact, less than to think about whether the
current rules could be made more fair.

> However,

Sure, the individuals or companies not participating in the elections
have not seen enough reason to care about their outcomes by participating
in them. Nothing special about NomCom vs. any other elections.

What is your point ?

> think you're entering the realm of diminishing returns.

I did not talk about the loyalty bias problem at all in this nomcom
thread, just about the switcharoo theory in response to prior mails
in the thread. You are the one who brought up the bias issue in this mail.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 08:05:40 +0200

> That incentive has its own response, once detected. 

I can not parse that.

> > Thats quite silly. 
> 
> Conflict of interest is not about ONE possible scenario that YOU (or anyone else) find valid. It???s about whether ANY of US consider ANY possible scenario unacceptable.
> 
> What you call ???silly??? some of us call ???ethics???.

Sure, goes the other way around as well. I do not only think NomCom chair
was completely in her right to decide as she did i also think that both she and
Luigi acted ethical. I find the request to remove both Luigi and Tal
unethical and the proposal to consider this to be the desirable
reading of the rules silly because it seems to be purely based on
the presumption of having to protect nomcom against a very improbable
evil scenario.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jul 2020 12:44:08 +0300

> On 10 Jul 2020, at 23:47, Samuel Weiler <[email-masked]> wrote:
> 
> To the matter at hand, though, I like Yoav's analysis. [1]  Let's let the Nomcom get to work.
> 
> -- Sam
> 
> 

Whoops. In my defense, the tools version of RFC 8713 [1] says that it obsoletes 7437, but the tools version of 7437 [2] does not say that it is obsoleted by 8713.

Yoav

[1] https://tools.ietf.org/html/rfc8713 <https://tools.ietf.org/html/rfc8713>
[2] https://tools.ietf.org/html/rfc7437 <https://tools.ietf.org/html/rfc7437>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jul 2020 12:50:57 +0300

> On 11 Jul 2020, at 1:58, Michael StJohns <[email-masked]> wrote:
> 
> If Luigi declines to take the position, "the chair must repeat the random selection process" or work with 9 members.   In general, that's meant continuing down the list, not going back and picking up someone who was already not selected.  

As others noted, that if for the period after the seating of the nomcom. 
> 
>> I believe she has made such a determination, and has acted within the mandate of RFC 7437.
> Luigi indicating he works for Huawei restructures the list and eliminates Tal.  Luigi indicating he won't serve triggers 5.7.  These are two separate events.
> 
> This is not ambiguous.
> 
> 
I disagree.

You cannot un-emit data. Once the NomCom chair has send the message with the list of NomCom members, they are the presumptive NomCom and all changes and challenges must be based on that list. What you are suggesting is to turn back the clock to re-run the process as if that message had never been sent.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jul 2020 13:02:16 +0300

> On 11 Jul 2020, at 6:46, Toerless Eckert <[email-masked]> wrote:
> 
> 
>> It might be, but it

Knowing Tal, I’d guess he is amused by all the lawyering going on here. But we usually treat NomCom membership as a burden to be shouldered, not as a prize to be won. So fairness to the candidate doesn’t come into play.
> should IETF then still accept money from the same big corporations ?

The rules are against accidental stacking of the NomCom. There are plenty of ways for EvilCorp to game the system by having its IETF people work as independent consultants paid by EvilCorp’s customers rather than directly by EvilCorp.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 11 Jul 2020 13:20:31 +0200

Joe, Toerless, Mike:

Yoav may be correct about the letter of the rule, but Mike is certainly correct about the spirit.  

Specifically:

The RFC does not take into account all possible failure or exception scenarios.  The chair is expected to adhere to the spirit of the process when the letter fails us.  This may be one of those cases.

The chair should avoid using discretion or influencing in any way the selection of specific individuals.  That is why we produce an ordered list of randomly selected individuals from a pool.
As a corollary corporate affiliation should only play a role in removals and not on additions.  There should be no room for selective substitution on the part of the chair in this process.

Eliot

Full disclosure: I work for a company that would generally be viewed as a competitor to Huawei and affiliates.  That same company could be viewed as a reason we have these sorts of limits on NOMCOM participation, so take this for what it’s worth.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 17:47:47 +0200

Eliot,

I have no problem with this interpretation to be proposed for an update
RFC to the current rules. I do appreciate the logic, also of Eliots
corollary. I do not think it is appropriate to assume consensus on
this interpretation without an actual RFC update to the rules that would
explicitly say so.

Specifically with the RFC as written now, i do not think it was
"inappropriate" for NomCom chair to have decided as she did in the
absence of better RFC text. Hence there is IMHO no ground to
contest the decision. The same IMHO would hold true for future NomComs
in the absence of more explicit RFC text.

Cheers
    toerless

On Sat, Jul 11, 2020 at 01:20:31PM +0200, Eliot Lear wrote:
> Full disclosure: I work for a company that would generally be viewed as a competitor to Huawei and affiliates.  That same company could be viewed as a reason we have these sorts of limits on NOMCOM participation, so take this for what it???s worth.

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 11 Jul 2020 19:09:30 +0200

On Sat, Jul 11, 2020 at 01:02:16PM +0300, Yoav Nir wrote:
> Knowing Tal, I???d guess he is amused by all the lawyering going on here.

> But we usually treat NomCom membership as a burden to be shouldered, not as a prize to be won. So fairness to the candidate doesn???t come into play.

Unless you are unhappy with IETF leadership and silly enough to think the
pool of candidates has better options.

> The rules are against accidental stacking of the NomCom.

I think like Melinda, you are missing my point. The text you cite from
me in the paragraph above was NOT referring to limiting candidates of
a company to two, it was solely commenting on the desire to refine
the rules such as to eliminate the "switcharoo EvilCo attack" (if that's
an appropriate shorthand).

Cheers
    Toerless

> There are plenty of ways for EvilCorp to game the system by having its IETF people work as independent consultants paid by EvilCorp???s customers rather than directly by EvilCorp.

---

From: Michael StJohns <[email-masked]>
Date: Sat, 11 Jul 2020 13:17:57 -0400

On 7/11/2020 5:50 AM, Yoav Nir wrote:
>
>
>> On 11 Jul 2020, at 1:58, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> random selection process" or work with 9 members.   In general, 
>> that's meant continuing down the list, not going back and picking up 
>> someone who was already not selected.
>
>> eliminates Tal.  Luigi indicating he won't serve triggers 5.7.  These 
>> are two separate events.
>>
>> This is not ambiguous.
>>
>>
> I disagree.
>
> You cannot un-emit data. Once the NomCom chair has send the message 
> with the list of NomCom members, they are the presumptive NomCom and 
> all changes and challenges must be based on that list. What you are 
> suggesting is to turn back the clock to re-run the process as if that 
> message had never been sent.

Hi Yoav -

Let me try and explain why I think you're making claims that don't meet 
the reasonableness test by using the example from 5.1 of RFC3797.

Let's pretend for a moment, that Luigi, upon seeing the presumptive list 
and his selection suddenly remembers that instead of attending 3 of 5 
meetings, he'd registered for one of those meetings, but was unable to 
attend.  He didn't end up cancelling, so a record keeping error had him 
as eligible.   He reports his ineligibility, he's skipped over (per 
second para of 5.1), and the next person on the list is selected.   It 
doesn't matter that the Nomcom chair had announced that he was selected, 
once he's ineligible, the list gets corrected based on the input data 
(of the ordered list, the input seeds, and the fact of Luigi's 
ineligibility, and the various organizational associations).

That's not running the clock backwards, that's reinterpreting the result 
of the selection (and the down-selection of too many from a single 
company) in the face of updated input data.

In this case, the chair ran the process and provided a presumptive 
list.  Luigi took a look at it, realized he was listed with an incorrect 
organization and the chair made a discretionary call based on Luigi's 
request and provided a new presumptive list based on that request rather 
than providing a new presumptive list based solely on the data at 
hand.   Again, the presumptive list changed by reinterpreting the 
selection data.  That's not running the clock backwards (nor was the 
first example).   And specifically, Luigi was not disqualified from 
serving, so he doesn't get skipped over in the order.

Given the data of the ordered list, the updated organizational 
associations, and the input seeds, the new presumptive list had to have 
Luigi on it and Tal off of it.   If Luigi *then* decides not to serve, a 
new selection has to be made - either continuing down the list or 
re-running the random selection for the new member. If the latter, Tal 
may be part of the selection pool again, if the former, he's a ball 
that's already been selected and discarded.

There was no need, and in fact it was an error, for the chair to 
exercise discretion at this point and that's the basis of the challenge.

Second example:  The chair transposes two numbers in the random seed 
input, leading to a presumptive list.   During the challenge period, a 
sharp eyed IETF type notes the error and challenges. The chair does not 
have discretion to keep the presumptive list and must publish a new list 
based on the actual data.  And again, the new presumptive list would 
replace the old presumptive list as valid.

Later, Mike

ps - Note that RFC3797 is *one* way to do the selection, not *the* way.  
It's an informative reference for 8713 for that reason.  It was 
published about the same time as 3777 which is when the "not more than 
two" condition was added and at least for that reason probably didn't 
provide specific examples along the lines we're experiencing.  The RFC 
does apply here because this is the method that the chair announced.

pps - someone was complaining about the use of the term "disqualified" 
with respect to the greater that 2 eliminated volunteers - I'm just 
using the term the chair used in her message.  Feel free to substitute 
"volunteers eliminated as exceeding the limit of 2 from an organization" 
for "disqualified" where context indicates that.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jul 2020 20:48:11 +0300

Hi, Eliot.

I disagree that this is the spirit of the rule.

The spirit is to get as close as possible to having the NomCom be the first 10 candidates on the list without breaking constraints. 

The first 10 include 3 Cisco people, so the last of them had to be removed, and the 11th one added. Note that Reshad is not disqualified. He was just skipped over to meet our affiliation diversity requirements.

As it turned out after the fact, the first 11 also included 3 Huawei people, so we need the 12th candidate.  Note that neither Luigi nor Tal are disqualified. They both meet the criteria for NomCom eligibility.

Mike’s interpretation would have us get the 13th candidate into NomCom. This goes against the spirit of the rule, because we can meet the constraints with only the first 12. It hinges on treating Luigi’s revelation that he works for Huawei and Luigi’s volunteering to be the one kicked off the list as two separate events. They are not. The chair’s message makes it clear that they were one event.

Assuming Mike’s interpretation, which I still think is incorrect, is accepted, then Luigi should be allowed to withdraw his resignation. It was only done because, to quote the chair’s email, "since he was the person who didn't mention this prior to selection, he should be the one removed”

Yoav

> On 11 Jul 2020, at 14:20, Eliot Lear <lear=[email-masked]> wrote:
> 
> Joe, Toerless, Mike:
>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 11 Jul 2020 20:59:31 +0300

> On 11 Jul 2020, at 20:17, Michael StJohns <[email-masked]> wrote:
> 
> Hi Yoav - 
> Let me try and explain why I think you're making claims that don't meet the reasonableness test by using the example from 5.1 of RFC3797.
> 
> Let's pretend for a moment, that Luigi, upon seeing the presumptive list and his selection suddenly remembers that instead of attending 3 of 5 meetings, he'd registered for one of those meetings, but was unable to attend.  He didn't end up cancelling, so a record keeping error had him as eligible.   He reports his ineligibility, he's skipped over (per second para of 5.1), and the next person on the list is selected.   It doesn't matter that the Nomcom chair had announced that he was selected, once he's ineligible, the list gets corrected based on the input data (of the ordered list, the input seeds, and the fact of Luigi's ineligibility, and the various organizational associations).
> 
> That's not running the clock backwards, that's reinterpreting the result of the selection (and the down-selection of too many from a single company) in the face of updated input data.  
> 
> In this case, the chair ran the process and provided a presumptive list.  Luigi took a look at it, realized he was listed with an incorrect organization and the chair made a discretionary call based on Luigi's request and provided a new presumptive list based on that request rather than providing a new presumptive list based solely on the data at hand.   Again, the presumptive list changed by reinterpreting the selection data.  That's not running the clock backwards (nor was the first example).   And specifically, Luigi was not disqualified from serving, so he doesn't get skipped over in the order.
> 

And these are very different cases. In the first case, Luigi is disqualified. In the second case, neither Luigi nor Tal are disqualified. And addressing your pps, disqualified is very different from "eliminated as exceeding the limit of 2 from an organization”. Someone is either qualified or not qualified, but whether they are eliminated or not is situation dependent. If Luigi has taken himself out of consideration at the same time as revealing his employment by Huawei, then Tal needs not be eliminated.

> Luigi requested that, since he was the person who didn't mention this prior to selection, he should be the one removed. I have no problem with this, so I will honor this request rather than removin…

Clearly, Luigi requested to be removed because both he and the NomCom chair agreed with an interpretation like mine. If the powers that be (which AFAIK is the NomCom chair) decide that this is a wrong interpretation, he should at least be allowed to withdraw his resignation which was made in error.

---

From: Rob Sayre <[email-masked]>
Date: Sun, 12 Jul 2020 01:28:16 -0700

On Sat, Jul 11, 2020 at 11:00 AM Yoav Nir <[email-masked]> wrote:

> Clearly, Luigi requested to be removed because both he and the NomCom
> chair agreed with an interpretation like mine. If the powers that be (which
> AFAIK is the NomCom chair) decide that this is a wrong interpretation, he
> should at least be allowed to withdraw his resignation which was made in
> error.
>

I don't agree with your reading of the RFC. But, even if I did, it seems
unwise to do this kind of negotiation. Your reading grants the chair a lot
of discretion, but does not make a case for this particular decision.
For example, one relevant piece of information might be who the next few
candidates would have been.

It would be a shame to call any of these into question:

- selection of NomCom members
- the actions of their nominees
- the IETF itself

If those seem questionable, there is no benefit to publishing an RFC over
an Internet Draft.

thanks,
Rob

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 12 Jul 2020 16:19:00 +0200

It seems to me as if better RFC text, it could IMHO pick either of the
following two options to amend the text we have now:

A) removal of Tal - because of re-evaluation of hash-list.
B) removal of Luigi - because of new disclosure about his affiliation.

To me, B) looks more logical because it maintains a bit more of the
"individual contributor" pretense the IETF claims to have (and directly violates
with the max2 rule). Aka: It only eliminates a person for which there is a
new disclosure, not a different person.

Any disucssion between Luigi and NomCom chair to me just looks like an
attempt to decide which one of these two cases would be best match the
intent of the process given how the RFCs are not prescriptive enough.

Both options i think match Eliots corollary of removal based on association.

The more important corollary from Eliot not well written down either is the
non-addition based on association, e.g.: If Luigi would have been Huawei initially
and would have left Huawei instead, then that would not raise Tal from the max2
eliminations of the initial run.

Cheers
    Toerless

P.S.: If there was a new RFC done, you should ask for the rights to use the
names Luigi and Tal, otherwise use Alice and Bob ;-))

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jul 2020 09:22:29 +1200

I suggest that at this point, we should wait and see the NomCom chair's
response to the challenge. After that, there is a defined dispute
resolution procedure if people don't agree with her resolution.

Regards
   Brian Carpenter

---

From: Mike StJohns <[email-masked]>
Date: Sun, 12 Jul 2020 19:13:10 -0400

Hmm.  She’s overdue,  but it’s a weekend so....   Mike

Sent from my iPad

> On Jul 12, 2020, at 17:23, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Victor Kuarsingh <[email-masked]>
Date: Sun, 12 Jul 2020 20:54:11 -0400

All,

My understanding its under review.  Sufficient time for
community discussion and input.

regards,

Victor K

P.S. serving as past chair advisor.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 13 Jul 2020 02:46:41 +0000

Apologies for not replying sooner. But, my house was being packed on Wednesday, loaded on the truck on Thursday, we cleaned out the old house on Friday, drove 800 miles on Saturday (and I ended up having to drive one of the cars the whole way), and started putting the new house together on Sunday. I was totally off-line and blithely unaware of this storm.

I’ll be chatting with Victor and Suresh tomorrow. I’m also going to reach out to Luigi and Tal, to make sure they’re aware (in case they aren’t on this list). I’ll send an email Monday before 23:59 UTC.

Thanks for all your thoughtful discussion. Much appreciated.
Barbara

From: ietf <[email-masked]> On Behalf Of Victor Kuarsingh
Sent: Sunday, July 12, 2020 8:54 PM
To: Mike StJohns <[email-masked]>
Cc: The IETF List <[email-masked]>
Subject: Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process

All,

My understanding its under review.  Sufficient time for community discussion and input.

regards,

Victor K

On Sun, Jul 12, 2020 at 7:14 PM Mike StJohns <[email-masked]<mailto:[email-masked]>> wrote:
Hmm.  She’s overdue,  but it’s a weekend so....   Mike

Sent from my iPad

> On Jul 12, 2020, at 17:23, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
>
>>>> On Sat, Jul 11, 2020 at 11:00 AM Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
>>>

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 13 Jul 2020 11:44:05 +0200 (CEST)

>     Il 13/07/2020 04:46 STARK, BARBARA H <[email-masked]> ha scritto:
>      
>      
> 
Sorry to join late - I don't know Luigi, but coming from the same cultural background, I would like to point out that it is quite likely that his decision to give up his appointment was meant as a courtesy to a colleague in a company he just joined, under the understanding that it was possible for Tal to keep his appointment (which, by the way, is a bit different than "replace Luigi with Tal", since Tal was since the beginning in all the Nomcom membership lists that were published). Should you decide to change that, you should check with Luigi if this was his motivation - if so, he should have the opportunity to reconsider his decision after being given correct information.

More generally, if people are so concerned about companies "stuffing" the Nomcom, we should just reduce the maximum number of Nomcom members per company to one. However, if ensuring diversity in the Nomcom is a requirement, then the IETF should rather enforce it under all its dimensions, starting from gender and geography (of people and of employers). Incidentally, if you consider the company-affiliated members, Huawei seems to be the only non-American employer in this year's Nomcom, so if we really value diversity in employers so much, having Huawei employees looks like a plus.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Eliot Lear <[email-masked]>
Date: Mon, 13 Jul 2020 11:59:05 +0200

Hi

> On 13 Jul 2020, at 11:44, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
>  
>> Il 13/07/2020 04:46 STARK, BARBARA H <[email-masked] <mailto:[email-masked]>> ha scritto:
>>  
>>  

+1.  Yoav mentioned this course of action and I agree.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Jul 2020 12:25:24 -0400

On 7/13/2020 5:59 AM, Eliot Lear wrote:
> Hi
>
>> On 13 Jul 2020, at 11:44, Vittorio Bertola 
>> <vittorio.bertola=[email-masked] 
>> <mailto:vittorio.bertola=[email-masked]>> wrote:
>>
>>> Apologies for not replying sooner. But, my house was being packed on 
>>> Wednesday, loaded on the truck on Thursday, we cleaned out the old 
>>> house on Friday, drove 800 miles on Saturday (and I ended up having 
>>> to drive one of the cars the whole way), and started putting the new 
>>> house together on Sunday. I was totally off-line and blithely 
>>> unaware of this storm.
>>>
>>>
>>> I’ll be chatting with Victor and Suresh tomorrow. I’m also going to 
>>> reach out to Luigi and Tal, to make sure they’re aware (in case they 
>>> aren’t on this list). I’ll send an email Monday before 23:59 UTC.
>>>
>> Sorry to join late - I don't know Luigi, but coming from the same 
>> cultural background, I would like to point out that it is quite 
>> likely that his decision to give up his appointment was meant as a 
>> courtesy to a colleague in a company he just joined, under the 
>> understanding that it was possible for Tal to keep his appointment 
>> (which, by the way, is a bit different than "replace Luigi with Tal", 
>> since Tal was since the beginning in all the Nomcom membership lists 
>> that were published). Should you decide to change that, you should 
>> check with Luigi if this was his motivation - if so, he should have 
>> the opportunity to reconsider his decision after being given correct 
>> information.
>
>

I don't disagree with this and wouldn't challenge it if it happens but:

a) Generally, the Nomcom has held resignations to be irreversible for 
quite a while; this was part of the "once you're on the Nomcom and it 
starts deliberations, you're ineligible to stand for any Nomcom selected 
position" thing.

b) The fact that we're getting "meant as a courtesy to a colleague in a 
company" as a reason suggests that some of the general fears about 
members potentially being more focused on what their company wants 
rather than what the IETF needs may have a strong foundation on reality.

c) If Luigi - or for that matter any member - decides to resign, then 
the full randomness process needs to be taken.  E.g. once discretion 
enters the process, the pre-calculated list needs to go away and new 
numbers selected. (and yes, Tal would be eligible to be selected 
assuming there was only 1 Huawei member on the Nomcom).

Later, Mike

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 13 Jul 2020 19:50:25 +0000

I’m resolving this challenge as follows:

The random selections should have been done with Luigi’s affiliation listed as “Huawei”. We will be proceeding with the outcome that would have resulted from the selection being done with the correct affiliation.

That result is

38. Xuesong Geng, Huawei

58. LUIGI IANNONE, Huawei

85. Tal Mizrahi, Huawei (Maximum Number of 2 for Huawei reached) - 11th in randomness order

Luigi has already expressed his willingness to serve.

I’ll be posting this update to the Announcement list.

I realize this won’t make everyone happy. I also realize there is no solution that would make everyone happy. However, this is the exact result presented by the previously advertised random selection process. There had been an offer by Luigi to step aside *iff* that would have resulted in Tal being allowed to serve. Since this would not result in Tal being allowed to serve, Luigi is not stepping aside.

Thanks to all who advised me in this decision.

Barbara

From: Michael StJohns <[email-masked]>
Sent: Friday, July 10, 2020 11:05 AM
To: [email-masked]; NomCom Chair 2020 <[email-masked]>
Subject: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process

Hi -

Here's my reasoning:

Mike

38. Xuesong Geng, Huawei

85. Tal Mizrahi, Huawei

https://www.euro-millions.com/results<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.euro-2Dmillions.com_results&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Kmz55mCAbYcwQokqhilIeD6l59sDatn-ogy4_dBIwKs&s=T4EtTVu0SmEhyNsCI2c6AoClponDEmHYAJEYVKeNpdU&e=>

https://www.euro-millions.com/results/07-07-2020<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.euro-2Dmillions.com_results_07-2D07-2D2020&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Kmz55mCAbYcwQokqhilIeD6l59sDatn-ogy4_dBIwKs&s=q0oa9Oxdsc170H68e6YrNVtxVMOf_Hfc-VR0rh5oKtA&e=>

12 16 23 33 41 8 10

US Total Debt

https://www.treasurydirect.gov/govt/reports/pd/pd_debttothepenny.htm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.treasurydirect.gov_govt_reports_pd_pd-5Fdebttothepenny.htm&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Kmz55mCAbYcwQokqhilIeD6l59sDatn-ogy4_dBIwKs&s=7IIaUt1Sz-yfabMc3DJVKbqFIYP6MOOJRi9VqbHqhVo&e=>

23703560

TattsLotto Results

https://thelott.com/tattslotto/results<https://urldefense.proofpoint.com/v2/url?u=https-3A__thelott.com_tattslotto_results&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Kmz55mCAbYcwQokqhilIeD6l59sDatn-ogy4_dBIwKs&s=4hYByJ5ItJl3FdGvkJrtOFoM7iQM92H23pspU-B8oTc&e=>

17 31 33 35 39 42

https://www.emiratesloto.com/loto/winningnumber/previous<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.emiratesloto.com_loto_winningnumber_previous&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Kmz55mCAbYcwQokqhilIeD6l59sDatn-ogy4_dBIwKs&s=Jz5BnZcDwDSOGVroijrf71c5R2UIcrcQNWtP7TtH3Us&e=>

Saturday July 4 results:

10 20 21 24 26 34

--------------- tool output -----------

Key is:

Barbara Stark

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ietf-announce<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ietf-2Dannounce&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=Kmz55mCAbYcwQokqhilIeD6l59sDatn-ogy4_dBIwKs&s=li2YAZ2Z101_Zq0sm0aA5FKxFLFgys3QGd5zhaxbR5M&e=>

---

From: Michael StJohns <[email-masked]>
Date: Mon, 13 Jul 2020 15:56:40 -0400

On 7/13/2020 3:50 PM, STARK, BARBARA H wrote:
> The random selections should have been done with Luigi’s affiliation 
> listed as “Huawei”. We will be proceeding with the outcome that would 
> have resulted from the selection being done with the correct affiliation.
>
> That result is
>
> I realize this won’t make everyone happy. I also realize there is no 
> solution that would make everyone happy. However, this is the exact 
> result presented by the previously advertised random selection 
> process. There had been an offer by Luigi to step aside **iff** that 
> would have resulted in Tal being allowed to serve. Since this would 
> not result in Tal being allowed to serve, Luigi is not stepping aside.
>
Thanks Barbara - I consider this challenge resolved to my 
satisfaction.   Mike

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 01:43:15 +0200

Dear NomCom chair,

I challenge your characterization of "the random selection should have been done with..."
as a justified ecision reason.

I do not think there is adequate evidence from the RFCs that that characterization 
is a mandatory interpretation of the RFC. I am not the only one who said so.

I have also asked, but i have seen NO further attempt to cite sentences from the
RFC to prove that this is a necessary reading of the RFCs, so for all intent and
purpose, instead, my questions and input have been explicitly been ignored.

Therefore unfortunately, i must challenge the reasoning of your decision.

In my reading of the relevant RFCs as well as the "spirit of the rules", there 
is no clear evidence as to how NomCom chair should decide in this situation. You
declaring that there is would create inacceptable case law for one, in opinion non-preferrable
option.

Cheers
    Toerless

On Mon, Jul 13, 2020 at 07:50:25PM +0000, STARK, BARBARA H wrote:
> I???m resolving this challenge as follows:
> 
> The random selections should have been done with Luigi???s affiliation listed as ???Huawei???. We will be proceeding with the outcome that would have resulted from the selection being done with the correct affiliation.
> 
> That result is
> 
> I???ll be posting this update to the Announcement list.
> 
> 
> 
> I realize this won???t make everyone happy. I also realize there is no solution that would make everyone happy. However, this is the exact result presented by the previously advertised random selection process. There had been an offer by Luigi to step aside *iff* that would have resulted in Tal being allowed to serve. Since this would not result in Tal being allowed to serve, Luigi is not stepping aside.
> 
> 
> 

-- 
---
[email-masked]

---

From: Mike StJohns <[email-masked]>
Date: Mon, 13 Jul 2020 22:26:48 -0400

Hi Toerless 

I think this is a disagreement with the result of a challenge, rather than a new challenge.  Assuming that characterization, then 4.17 points to the dispute resolution process in section 6.  That means the dispute must be directed to the ISOC president, not the Chair of the Nomcom who is responsible for appointing an arbiter.  

Mike

Sent from my iPad

> On Jul 13, 2020, at 19:43, Toerless Eckert <[email-masked]> wrote:
> 
> Dear NomCom chair,
>

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Jul 2020 22:53:23 -0400

Toerless,

I agree with Mike's comment about disagreement with the result
of a challenge, but let me add a substantive comment or two
about your note (if you think it appropriate, to your message to
the ISOC President).  Inline

--On Tuesday, July 14, 2020 01:43 +0200 Toerless Eckert
<[email-masked]> wrote:

> Dear NomCom chair,
> 
> I challenge your characterization of "the random selection
> should have been done with..." as a justified ecision reason.
> 
> I do not think there is adequate evidence from the RFCs that
> that characterization  is a mandatory interpretation of the
> RFC. I am not the only one who said so.
>...

For better or worse, many of our procedural RFCs, not unlike
many of our technical specifications, do not provide "mandatory
interpretation"s of large numbers of things.  If that were a
requirement, we'd need to drop the use of SHOULD in
specifications and we'd need to drop the convention that our
leadership is given rather broad discretion when they think it
is necessary, subject, of course, to appeals.  So, if there is
an ambiguity (apparently some people, including you given that
mandatory interpretation comment, think there is) then the
Nomcom Chair gets to decide.  If one believes that the Nomcom
Chair decided incorrectly, either because there is an ambiguity
or because one reads the documents differently than she does,
then you can appeal if you want to, but that means a discussion
with the ISOC Present, not requesting (or demanding) that the
Nomcom Chair reconsider.

> I have also asked, but i have seen NO further attempt to cite
> sentences from the RFC to prove that this is a necessary
> reading of the RFCs, so for all intent and purpose, instead,
> my questions and input have been explicitly been ignored.

I can't speak for others, especially Barbara, but I, at least,
tried to understand your argument, questions, and input, at
least up to the point of concluding (perhaps correctly, perhaps
not) that you were repeating yourself.  That is not ignoring
you, much less doing so explicitly.  I have seen no evidence
that Barbara explicitly ignored you either.  For me at least, it
is just, in the end, disagreeing.

   john

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 05:53:29 +0200

I disagree with this characterization. I am challenging the announced result
from NomCom chair in the same way as you originally did. I understand the
escalation process.

Cheers
    Toerless

On Mon, Jul 13, 2020 at 10:26:48PM -0400, Mike StJohns wrote:
> > ???Dear NomCom chair,

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 06:02:45 +0200

John,

NomCom chair did not write that she used discretion, she declared
what read like a statement of rules. This characterization i disagree
with. I said from the beginning that i think NomCom chair has
discretion. Mike disagreed with that. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Jul 2020 21:17:49 -0700

Hi Toerless,

> discretion. Mike disagreed with that. 

Just to be fully clear: as I understand it, you are not disputing the
outcome (since, if the matter is up to the discretion of the NomCom chair,
it is a permissible outcome), but only the assertion that "the random
selections should have been done" in a specific way (with the argument that
this is an unjustified claim, since no one has pointed to specific RFC text
that requires it).

Is that correct?

Thanks,

Ben

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 06:26:38 +0200

Yes.

-- 
---
[email-masked]

---

From: Rob Sayre <[email-masked]>
Date: Mon, 13 Jul 2020 22:34:40 -0700

>
>
> Thanks Barbara - I consider this challenge resolved to my satisfaction.
> Mike
>

I also think this resolution is satisfactory.

thanks,
Rob

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Jul 2020 01:37:18 -0400

--On Tuesday, July 14, 2020 06:02 +0200 Toerless Eckert
<[email-masked]> wrote:

> John,
> 
> NomCom chair did not write that she used discretion, she
> declared what read like a statement of rules. This
> characterization i disagree with. I said from the beginning
> that i think NomCom chair has discretion. Mike disagreed with
> that. 

Understood.  But consider where we are now, given the above.

Possibility 1: Barbara used discretion in interpreting the
rules.  If she is entitled to do that, then you can appeal the
decision made with that discretion, but cannot challenge it.

Possibility 2: Barbara read the rules in a certain way that led
to her current list and result.  You can claim the way she read
the rules was improper and appeal on that basis, but you have no
basis for challenging the list.

and, I guess, Possibility 3: You believe Barbara should have
stated whether she applied discretion or read the rules in a
particular way and object to her not doing to.  I suppose you
could appeal that although my personal opinion is that it would
be a waste of the community's time (your opinion may, of course,
differ).  But, again, that is not a basis on which you can
challenge the current list.

While I was not explicit about it before, I believe those are
all of the cases.  And they lead to exactly the same place: if
you want to pursue this further, take it up with the ISOC
President.  I would encourage you to first ask what you expect
to accomplish, but that, again, is up to you.

Finally, as others have suggested, if you think the rules in
this area need clarification, I strongly encourage you to
produce an I-D that amends/updates the current specs or replaces
them and/or to propose a WG or BOF to address those questions.
I won't promise to support you in that, but I think it is the
only possible way to make actual progress.

best,
   john

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 14 Jul 2020 09:14:47 +0200

How is my challenge any more a waste of community time than Mike's ?

-- 
---
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Tue, 14 Jul 2020 02:33:55 -0700

Hi Toerless,
>from NomCom chair in the same way as you originally did. I understand the

RFC 8713 (Section 4.17) allows any member to challenge the results of 
the random selection.  My interpretation is that it is within your 
rights to challenge the announced results.

I don't understand the reasoning behind "the random selection should 
have been done with..." as that was not provided in the "resolution" email.

There is a special past-past chair advisor.  The explanation for that 
is "this year is so strange".  Making such an appointment was not 
discussed during the evaluation of the document which was published 
as RFC 8788.  There isn't any information about which rule(s) was 
used to make that appointment.

Regards,
S. Moonesamy

---

From: "Mehmet Ersue" <[email-masked]>
Date: Tue, 14 Jul 2020 13:39:58 +0200

I believe this is a good solution.

Anything else would be complex and therefor questionable.

Thanks,

Mehmet

From: ietf <[email-masked]> On Behalf Of Michael StJohns
Sent: Monday, July 13, 2020 9:57 PM
To: STARK, BARBARA H <[email-masked]>; [email-masked]' <[email-masked]>; 'NomCom Chair 2020' <[email-masked]>
Subject: Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process

That result is 

38. Xuesong Geng, Huawei 

Barbara

Thanks Barbara - I consider this challenge resolved to my satisfaction.   Mike

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jul 2020 07:45:39 -0400 (EDT)

On Tue, 14 Jul 2020, S Moonesamy wrote:

> There is a special past-past chair advisor.  The explanation for 
> that is "this year is so strange".  Making such an appointment was 
> not discussed during the evaluation of the document which was 
> published as RFC 8788.  There isn't any information about which 
> rule(s) was used to make that appointment.

The list at [1] also includes Henrik as a tools team advisor.

One might presume that the NomCom chair intends to propose both 
additional advisors to the NomCom according to the usual process in 
section 4.3 of RFC8713.  It is odd to see them announced before the 
voting memebers of NomCom are seated.

It is interesting how the number of non-voting NomCom members has 
grown over time.  This list has nine(!) non-voting members, and that 
is before the voting members have been seated and potentially added 
more.  NomCom 2019 had 8.  NomCom 2018 had 7.  NomCom 2017 had 6. 
NomComs 2016 and 2015 each had only 5. [2]

If I were a voting member of this NomCom, I would be concerned about 
being overwhelmed by advisors, particularly since the advisors get a 
vote on procedural matters, including the removal of voting NomCom 
members.

-- Sam

[1] https://datatracker.ietf.org/nomcom/2020/

[2] n.b. I'm looking at the lists at [1].  It is possible these 
NomComs added advisors that are not listed.  I'm pretty sure NomCom 
2015 added Henrik as an advisor.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 14 Jul 2020 09:22:10 -0400

> used to make that appointment.

RFC8713 (sec 4.7) allows for additional advisors.  Section 4.9 briefly
describes it as well.

Additional info.  RFC8713 also states in section 4.14 that all volunteers
must identify their full names, email and primary company / affiliation
when volunteering.

The random selection was run per section 4.17 which resulted in the final
volunteer list announced on July 13, 2020 in accordance with the guidance
on affiliation. My understanding is that affiliations are to be corrected
as part of the list being published (often multiple times) during the list
challenge period, if the data is not correct (e.g. someone does not want to
serve and/or there are changes in affiliation), that information should be
corrected at that time.  I recall last year, I had some folks self-identify
during the challenge period and ask for affiliation adjustments (which is
acceptable and needed).

In this case, one person in question was unable and/or did not notice the
error.   The person in question was working in a capacity for an
affiliation different than what was stated on the list, which was material
to the selection process.

The outcome we have now (as far as I can see), is in accordance with what
would have occurred had the affiliation been corrected in the time allotted
during the week the list(s) were made available.

List provided on June 28, 2020
https://datatracker.ietf.org/nomcom/ann/162646/

List provided on July 2, 2020
https://datatracker.ietf.org/nomcom/ann/164059/

It would be during this time, that an incorrect affiliation should have
been corrected.

regards,

Victor K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 14 Jul 2020 08:35:27 -0700

Hi Sam,

Yes.

Yes.

Yes.

I don't remember which title was used previously for the tools side.

>vote on procedural matters, including the removal of voting NomCom members.

I did not know that advisors are allowed to vote on procedural 
matters.  It is like anticipating the decisions of a Nomination 
Committee by adding advisors before the Nomination Committee is selected.

Regards,
S. Moonesamy

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 14 Jul 2020 12:35:51 -0400

> >NomComs 2016 and 2015 each had only 5. [2]

The rationale here is that the IETF structure has changed
substantially over the past 3 years with the introduction of IASA 2.0.
Given two of these bodies are new or new in how they function, getting
input from a representative from these bodies seems quite reasonable.  The
changes were related to additional (chair requested) liaisons (at least
through my tenure).  The presumption that voting members will naturally
know what is required for a given role (especially since two of them had
substantially changed or were added), seems unreasonable and
utilizing liaisons seems to make sense.   LIaisons cna provide needed
information as to what the demands or needs are for a given role.  As far
as I can tell, Liaisons have acted honorably and in accordance with how the
Chair has requested they participate.

Tools advisors are common since there is a lot of process involved in
executing the role correctly, much of which is tooled and/or requires tools
support.  The past chair typically serves as an advisor as both a backup
and to ensure process is followed and guidance (based on experience
executing that function) provided.  The defined process for executing the
Nomcom (on purpose) needs to be followed to ensure fairness and
consistency.

Victor K

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 14 Jul 2020 21:08:28 +0000

I'm replying to this message to provide additional clarity regarding the non-voting NomCom members.
While only certain of the I* organizations are required to provide liaisons, all are allowed to name liaisons. They have all chosen to do so. This is helpful with ensuring the NomCom voting members have someone who can properly represent the qualifications for a position on that I*.
The liaisons are selected by each I* organization. Who the voting members are is not relevant to the selection of liaisons by the I* orgs. Therefore, there is no need for sequencing of liaison naming vis-à-vis the selection of voting members. My request to the I* orgs was that they provide me with names prior to next week, so I could onboard the entire NomCom at the same time. When an I* org provided me with a name, I put the name on the NomCom 2020 web page. While they have been named, and I've had some communication with them about open positions on their I* (and qualifications for those positions), I haven't discussed anything else with them.
I needed the tools advisor in place when I started the volunteer process. Henrik made sure the eligibility checking tool was properly set to check for attendance at IETF 102-106 and did other magical tools things. 
The previous year's NomCom chair is automatically an advisor. Victor has been very helpful and I've needed his advice a lot. I also asked Suresh to be an advisor, as permitted by RFC 8713. This is a weird year. I'm new to this NomCom thing. And process isn't my strong suit.

As it relates to all of this process stuff (how to get volunteers, selecting seeds, handling challenges, etc.), the only people advising me have been Victor and Suresh. The liaisons are not advisors for NomCom process. They are liaisons. See RFC 8713 for a description of liaison responsibilities.
The tool advisor provides support related to tools.
As stated in RFC 8713:
   An advisor is responsible for such duties as specified by the
   invitation that resulted in the appointment.

Barbara

> From: Samuel Weiler
> Sent: Tuesday, July 14, 2020 6:46 AM
> 
> > discussed during the evaluation of the document which was published as
> > RFC 8788.  There isn't any information about which
> additional advisors to the NomCom according to the usual process in section
> 4.3 of RFC8713.  It is odd to see them announced before the voting
> memebers of NomCom are seated.
> 
> grown over time.  This list has nine(!) non-voting members, and that is
> before the voting members have been seated and potentially added more.
> NomCom 2019 had 8.  NomCom 2018 had 7.  NomCom 2017 had 6.
> being overwhelmed by advisors, particularly since the advisors get a vote on
> procedural matters, including the removal of voting NomCom members.
> 
> -- Sam
> 
> 
> [2] n.b. I'm looking at the lists at [1].  It is possible these NomComs added
> advisors that are not listed.  I'm pretty sure NomCom

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 14 Jul 2020 18:10:40 -0400 (EDT)

On Tue, 14 Jul 2020, STARK, BARBARA H wrote:

> I needed the tools advisor in place when I started the volunteer 
> process.

...

> I also asked Suresh to be an advisor, as permitted by RFC 8713.

My read of RFC8713 section 4.3 is that you are not premitted to 
appoint advisors on your own.  The relevant text is:

    Any committee member may propose the addition of an advisor to
    participate in some or all of the deliberations of the committee.
    The addition must be approved by the committee according to its
    established voting mechanism.

I do not object to you having sought advice from Henrik and Suresh up 
to this point, but, as I wrote this morning, I hope that you will 
propose these new advisors to the NomCom once it is seated and give 
the NomCom (excluding the two proposed additions) the opportunity to 
approve the additions (or not, as they deem appropriate).

I look forward to your confirmation that you will take this path.

-- Sam

---

From: Warren Kumari <[email-masked]>
Date: Tue, 14 Jul 2020 18:17:59 -0400

On Tue, Jul 14, 2020 at 5:09 PM STARK, BARBARA H <[email-masked]> wrote:
> As it relates to all of this process stuff (how to get volunteers, selecting seeds, handling challenges, etc.), the only people advising me have been Victor and Suresh.

I have no opinions on the challenge / selection / voting vs non-voting
/ etc[0], but I did quickly want to chime in to say "Thank you" to
Barbara, Victor and Suresh.

Serving on the NomCom is a huge undertaking and being chair/similar is
an even larger undertaking.

It's important that we get this right, but let's not lose track of the
fact that people participate as volunteers, the process is somewhat
complex (and doesn't cover all corner cases), and everyone is trying
to do the right thing.

>From my sanctimonious soapbox,
W

> The liaisons are not advisors for NomCom process. They are liaisons. See RFC 8713 for a description of liaison responsibilities.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: John C Klensin <[email-masked]>
Date: Tue, 14 Jul 2020 23:48:14 -0400

--On Tuesday, July 14, 2020 18:10 -0400 Samuel Weiler
<[email-masked]> wrote:

>> I needed the tools advisor in place when I started the
>> volunteer  process.
> 
> ....
> 
> My read of RFC8713 section 4.3 is that you are not premitted
> to appoint advisors on your own.  The relevant text is:
> 
> I do not object to you having sought advice from Henrik and
> Suresh up to this point, but, as I wrote this morning, I hope
> that you will propose these new advisors to the NomCom once it
> is seated and give the NomCom (excluding the two proposed
> additions) the opportunity to approve the additions (or not,
> as they deem appropriate).
> 

Sam,

I disagree a bit with your reading.  The language you quote is
about advisors who will "participate in some or all of the
deliberations of the committee".   Taking Henrik and tools as an
example, I would see no possible reason why he would need to
participate in committee deliberations.  If Barbara has felt a
need to seek his advice in getting things set up (especially in
these unusual times), he is advising her, not becoming an
advisor to the Nomcom.  Common sense applies here too; if one
does not make that particular distinction, then she would end up
in a race condition in which she needs advice to run the Nomcom
volumteer and member selection process but cannot get that
advice until the members are seated to approve the selection.

It wasn't clear to me what role Suresh has been serving or what
role Barbara expects him to serve as the Nomcom gets going (now
that it has a list of members).   If that role includes any
participation in the Nomcom's actual work (I would think even
exposure to candidate data, whether taking positions on
candidates or other issues or not), I agree with you that
Barbara should submit his name and try get approval as you
suggest. Even if he were going to provide procedural advice
after the voting members have been selected, but not be exposed
to candidate data, I'd encourage her to go through that process
in the interest of transparency and the avoidance of doubt.  

As I said, I disagree a bit.  I hope not a lot.

I do have another concern, but perhaps it is better addressed in
a separate note.

   thanks,
    john

---

From: Mary B <[email-masked]>
Date: Wed, 15 Jul 2020 09:00:32 -0500

I'm very puzzled over the concern about Henrik as Tools Advisor.  He was
tools advisor way back when I was Nomcom chair 2009-2010 and I know it goes
back at least to the one prior.   He has been an essential part of the
process from that perspective. But, he did not (and I assume still does
not) participate in any deliberations at all and as I recall he actually
can't see any of the comments input by the community.   But, his role has a
dramatic impact on the ability of the nomcom to review the community input
in the form other than a bunch of emails  and of course, his work also has
provided the community a nice tool so that we can provide that input.

As far as other advisors, I will add that I do think it's important that
their roles are clear cut from the outset in terms of the scope being
providing input into the specific roles for the organization they represent
or in the case of Suresh on process aspects.   There had been Nomcoms where
liaisons were more active, which I disagree with, but it is up to the
specific Nomcom in terms of how they take input.

If the concern is that there will be lots of folks that can see your input
to the Nomcom, you can always provide input anonymously by contacting the
chair or a Nomcom member with whom you're comfortable sharing.

Regards,
Mary.

On Tue, Jul 14, 2020 at 5:11 PM Samuel Weiler <[email-masked]> wrote:

> section
> vote on

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 15 Jul 2020 11:09:10 -0400

Henrik has been tools advisor just about forever - well he was the tools advisor back when I was on the IESG  -
he came with the job as nomcom chair - I do not recall that previous chairs specifically appointed him he was just "it"

but the key point is in the citation you provide
" advisor to participate in some or all of the deliberations of the committee"

the tools advisor does not "participate in some or all of the deliberations of the committee"
so is not covered under RFC 8713 section 4.3 - the chair has the power to appoint advisors that
do not participate in some or all of the deliberations of the committee as long as
the advisor has minimal contact with the confidential information the nomcom collects
(and Henrik can be trusted with confidential information in any case - he has been there & done that

I say 'move on, there is nothing to do here'

Scott

> On Jul 15, 2020, at 10:00 AM, Mary B <[email-masked]> wrote:
> 
> I'm very puzzled over the concern about Henrik as Tools Advisor.  He was tools advisor way back when I was Nomcom chair 2009-2010 and I know it goes back at least to the one prior.   He has been an essential part of the process from that perspective. But, he did not (and I assume still does not) participate in any deliberations at all and as I recall he actually can't see any of the comments input by the community.   But, his role has a dramatic impact on the ability of the nomcom to review the community input in the form other than a bunch of emails  and of course, his work also has provided the community a nice tool so that we can provide that input.  
> 
> As far as other advisors, I will add that I do think it's important that their roles are clear cut from the outset in terms of the scope being providing input into the specific roles for the organization they represent or in the case of Suresh on process aspects.   There had been Nomcoms where liaisons were more active, which I disagree with, but it is up to the specific Nomcom in terms of how they take input.   
> 
> If the concern is that there will be lots of folks that can see your input to the Nomcom, you can always provide input anonymously by contacting the chair or a Nomcom member with whom you're comfortable sharing.   
> 
> Regards,
> Mary.. 
> 
> .....
> >> procedural matters, including the removal of voting NomCom members..
> >>
> >> -- Sam
> >>
> >>

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 15 Jul 2020 12:27:54 -0400

On Wed, Jul 15, 2020 at 11:09 AM Scott O. Bradner <[email-masked]> wrote:

> he came with the job as nomcom chair - I do not recall that previous
> chairs specifically appointed him he was just "it"
>

Having worked with him on Nomcom, I have no concerns with his
involvement as a tools advisor.

regards,

Victor K

> > If the concern is that there will be lots of folks that can see your
> input to the Nomcom, you can always provide input anonymously by contacting
> the chair or a Nomcom member with whom you're comfortable sharing.
> >
> > Regards,
> > Mary..
> >
> as
> is
> NomComs added

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Jul 2020 13:41:02 -0400

The reason why we need the tools advisor to be "sworn in" as it were, is so
that they can be allowed to see confidential information while debugging.

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 15 Jul 2020 12:54:52 -0500

Nobody objected to Henrik (or anyone else) being the Tools Advisor, or 
to any of the other non-8713-listed advisors being on NomCom. The only 
concern is that the voting members and the 8713-listed non-voting 
members need to explicitly decide whether or not they will (a) 
participate in deliberations and (b) be able to vote on procedural 
matters of the NomCom. The chair can't simply add additional advisors 
who can vote to change the procedures of the NomCom without the approval 
of the voting members of the NomCom.

pr

On 15 Jul 2020, at 11:27, Victor Kuarsingh wrote:

>> Henrik has been tools advisor just about forever - well he was the 
>> tools
>> advisor back when I was on the IESG  -
>> so is not covered under RFC 8713 section 4.3 - the chair has the 
>> power to
>> appoint advisors that
>> do not participate in some or all of the deliberations of the 
>> committee as
>> long as
>> (and Henrik can be trusted with confidential information in any case 
>> - he
>> has been there & done that
>>
>>>>>> that

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 15 Jul 2020 13:57:19 -0400

is there something I missed where the chair said that was happening (Henrik would be able to vote on procedures or candidates?)

Scott

> On Jul 15, 2020, at 1:54 PM, Pete Resnick <[email-masked]> wrote:
> 
> Nobody objected to Henrik (or anyone else) being the Tools Advisor, or to any of the other non-8713-listed advisors being on NomCom. The only concern is that the voting members and the 8713-listed non-voting members need to explicitly decide whether or not they will (a) participate in deliberations and (b) be able to vote on procedural matters of the NomCom. The chair can't simply add additional advisors who can vote to change the procedures of the NomCom without the approval of the voting members of the NomCom.
> 
> pr
> 
> Having worked with him on Nomcom, I have no concerns with his involvement as a tools advisor.   
> 
> regards,
> 
> Victor K
> 
>  
> 
> Scott
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Jul 2020 14:12:04 -0400

--On Wednesday, July 15, 2020 12:54 -0500 Pete Resnick
<[email-masked]> wrote:

> Nobody objected to Henrik (or anyone else) being the Tools
> Advisor, or to any of the other non-8713-listed advisors being
> on NomCom. The only concern is that the voting members and the
> 8713-listed non-voting members need to explicitly decide
> whether or not they will (a) participate in deliberations and
> (b) be able to vote on procedural matters of the NomCom. The
> chair can't simply add additional advisors who can vote to
> change the procedures of the NomCom without the approval of
> the voting members of the NomCom.

I would would have said "can't simply add additional advisors
who can vote to change the procedures of the NomCom or
participate in deliberations in a way that might alter Nomcom
decisions without..." but otherwise agree.

And, if anyone feels it is necessary to explicitly swear Henrik
to secrecy because his support efforts might lead him to stumble
across confidential materials, go for it, but that is a rather
different issue.

   john

---

From: Samuel Weiler <[email-masked]>
Date: Wed, 15 Jul 2020 14:16:16 -0400 (EDT)

On Wed, 15 Jul 2020, Mary B wrote:

> I'm very puzzled over the concern about Henrik as Tools Advisor.

Mary's note as well as others make it clear that I was perhaps not as 
clear as I could have been.  (Though I'm glad to see that Pete 
understood.)

I have no problem with the NomCom appointing Henrik as an advisor.

I'm raising a process issue, pointing out that only NomCom as a whole 
- not the chair acting on their own - is empowered to appoint advisors.

Separately, it is great that the chair has sought guidance and help 
from both Henrik and from additional past chair(s).  NomCom chair is 
not an easy job, and I'm sure their help is valuable, particularly in 
these early stages.

To Scott: yes, the Nomcom's webpages already list both Henrik and 
Suresh as "Non-Voting Members".  8713 establishes certain things that 
non-voting members can do.

(Some NomComs have formally appointed a tools team advisor, as Michael 
says should be done, though not always Henrik.  According to the 
public pages, the 2018 and 2019 NomComs appointed one.  The 2015 and 
2017 NomComs had Robert Sparks serving as IAB liaison, and he may have 
handling tooling issues, also.)

> input to the Nomcom, you can always provide input anonymously by 
> contacting the chair or a Nomcom member with whom you're comfortable 
> sharing.

That is not my concern.

Separate from the process concern, if I were on the NomCom, I would 
worry about the ratio of voting to non-voting members, particularly 
since the liaisons tend to be more experienced in the IETF than the 
voting members (on average, perhaps, some years?).  But that is a 
concern for the voting members to work out.

-- Sam

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 15 Jul 2020 13:18:47 -0500

On 15 Jul 2020, at 12:57, Scott O. Bradner wrote:

> is there something I missed where the chair said that was happening 
> (Henrik would be able to vote on procedures or candidates?)

It sounded from the chair's note of Tue, 14 Jul 2020 21:08:28 +0000 that 
she thought that the assorted additional folks in question were already 
appointed as advisors. Sam pointed out that if they were advisors, they 
would have the ability to vote on procedures, and therefore their 
appointment as advisors ought to be approved by the voting members. 
(Nobody thought they could vote on candidates, but only that they would 
be part of the deliberations.) After Sam's note, Mary, Victor, and you 
replied with defenses of Henrik being the tools advisor. That seemed 
curious, since none of you addressed Sam's point, and nobody ever 
suggested that Henrik shouldn't be tools advisor, which is why I 
replied.

pr

>> Nobody objected to Henrik (or anyone else) being the Tools Advisor, 
>> or to any of the other non-8713-listed advisors being on NomCom. The 
>> only concern is that the voting members and the 8713-listed 
>> non-voting members need to explicitly decide whether or not they will 
>> (a) participate in deliberations and (b) be able to vote on 
>> procedural matters of the NomCom. The chair can't simply add 
>> additional advisors who can vote to change the procedures of the 
>> NomCom without the approval of the voting members of the NomCom.
>>
>> pr
>>
>> tools advisor back when I was on the IESG  -
>> power to appoint advisors that
>> committee as long as
>> - he has been there & done that
>>
>>> I'm very puzzled over the concern about Henrik as Tools Advisor.  He 
>>> was tools advisor way back when I was Nomcom chair 2009-2010 and I 
>>> know it goes back at least to the one prior.   He has been an 
>>> essential part of the process from that perspective. But, he did not 
>>> (and I assume still does not) participate in any deliberations at 
>>> all and as I recall he actually can't see any of the comments input 
>>> by the community.   But, his role has a dramatic impact on the 
>>> ability of the nomcom to review the community input in the form 
>>> other than a bunch of emails  and of course, his work also has 
>>> As far as other advisors, I will add that I do think it's important 
>>> that their roles are clear cut from the outset in terms of the scope 
>>> being providing input into the specific roles for the organization 
>>> they represent or in the case of Suresh on process aspects.   There 
>>> had been Nomcoms where liaisons were more active, which I disagree 
>>> with, but it is up to the specific Nomcom in terms of how they take 
>>> input.
>>>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 16 Jul 2020 22:37:35 +0000

Thank you all for your advice regarding advisors.
I'm putting discussion of advisors on the agenda for my initial NomCom meeting.

<attempt at humor>I'm tempted to add [email-masked] as an additional advisor -- but not one with access to confidential info.</attempt at humor>
Barbara

> -----Original Message-----
> From: Pete Resnick
> 
> It sounded from the chair's note of Tue, 14 Jul 2020 21:08:28 +0000 that she
> thought that the assorted additional folks in question were already
> (Nobody thought they could vote on candidates, but only that they would be
> part of the deliberations.) After Sam's note, Mary, Victor, and you replied
> with defenses of Henrik being the tools advisor. That seemed curious, since
> none of you addressed Sam's point, and nobody ever suggested that Henrik
> shouldn't be tools advisor, which is why I replied.
> 
> pr
> 
> >> tools advisor back when I was on the IESG  - he came with the job as
> >> nomcom chair - I do not recall that previous chairs specifically
> >> appointed him he was just "it"
> >>
> >> but the key point is in the citation you provide " advisor to
> >> participate in some or all of the deliberations of the committee"
> >>
> >> power to appoint advisors that do not participate in some or all of
> >> the deliberations of the committee as long as the advisor has minimal
> >> contact with the confidential information the nomcom collects (and
> >> Henrik can be trusted with confidential information in any case
> >>> I do not object to you having sought advice from Henrik and Suresh
> >>> up to this point, but, as I wrote this morning, I hope that you will
> >>>>>> that is "this year is so strange".  Making such an appointment
> >>>>>> was not discussed during the evaluation of the document which was
> >>>>> grown over time.  This list has nine(!) non-voting members, and
> >>>>> that is before the voting members have been seated and potentially
> >>>>> added more.
> >>>>> If I were a voting member of this NomCom, I would be concerned
> >>>>> about being overwhelmed by advisors, particularly since the
> >>>>> advisors get a vote on procedural matters, including the removal
> >>>>> of voting NomCom members..
> >>>>>
> >>>>> -- Sam
> >>>>>
> >>>>>
> >>>>> [1]
> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.i
> >>>>> etf.org_nomcom_2020_&d=DwIBAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-8s
> >>>>>
> c8SY8Tq4vrfog&m=gkzPWOkPAQyFQsbmEULkAewFDOyYuyMoKwrrVakfltE&
> s=8yKW
> >>>>> gNsk2Epq1ZhvoSr6J2ABEbMfJAtdAqt_pgaroNE&e=
> >>>>>
> Pete Resnick https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.episteme.net_&d=DwIBAg&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=gkzPWOkPAQyFQsbmEULkAewFDOyYuyMoKwrrVakflt
> E&s=BbE9_ilXns8O1nds-mZq0_gNF-6Y7oYu-z0FWo9zmcQ&e=

---

From: Randy Bush <[email-masked]>
Date: Thu, 16 Jul 2020 16:09:05 -0700

> <attempt at humor>I'm tempted to add [email-masked] as an additional
> advisor -- but not one with access to confidential info.</attempt at
> humor>

it goes under the micro-management section

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 17 Jul 2020 14:17:40 +1200

> it goes under the micro-management section

There's that, but Barbara's right too. The NomCom specifically asks the
whole IETF for advice at a later stage in the process, which is how it
should be. Given that, and the randomness intentionally present in the
choice of NomCom members, a lot of the fears I've seen expressed or
implied in this thread seem unjustified.

Regards
    Brian