Subject: List of volunteers for the 2020-2021 NomCom

From: NomCom Chair 2020 <[email-masked]>
Date: Sun, 28 Jun 2020 09:04:46 -0700

This is a preliminary list of qualified volunteers for NomCom 2020-2021.

Because I only received the volunteer list from IETF 108 a few days ago and told people today whether https://www.ietf.org/registration/nomcom.py considered them eligible, it's possible some of those who appeared ineligible may choose to fix errors in prior registrations and become eligible. If that happens, I will add them to the next iteration of this list and note their addition.

I also did get a list from IETF 107. I've asked people from IETF 107 registrations who passed the attendance eligibility test to explicitly let me know if they're still interested in volunteering. But since I need to get on with this process, I'm including them in this preliminary list and will delete them in the next iteration if they ask to be removed. I've noted them with "(107)" next to them. I'll also need to get an affiliation from some of these. I did not send email to IETF 107 volunteers who did not pass the attendance eligibility check. There were too many of those.

The list contains 160 members, all of whom have been verified by me (and not yet officially by the Secretariat) as qualified for the position of voting member of NomCom by virtue of having attended 3 of IETF 102-106 meetings, and none of whom are known to me to be a member of any body that the NomCom will be selecting people for. But I could have missed a few. I'm expecting people to find some errors in this list.

We now enter the challenge period, which lasts until Monday, July 6, 2020. If anyone thinks that a name on the numbered list below is NOT qualified for some reason, please send me email before July 6 at: 

nomcom-chair-2020 at ietf dot org 

The Secretariat will also be doing the official qualification check. The next steps are listed on https://datatracker.ietf.org/nomcom/2020/ and I will be announcing random seed selections for the RFC 3797 process shortly.

The preliminary list of qualified volunteers are:

1. Melchior Aelmans, Juniper Networks
2. Zafar Ali, Cisco Systems
3. Ignas Bagdonas, Equinix
4. Frederick Baker,  (107)
5. Sarah Banks, Corelight, Inc.
6. Vishnu Pavan (Pavan) Beeram, Juniper Networks
7. Louis (Lou) Berger, LabN Consulting, L.L.C.
8. Vittorio Bertola, Open-Xchange GmbH
9. Henk Birkholz, Fraunhofer SIT
10. Michael Bishop, Akamai
11. Matthew Bocci, Nokia
12. Ronald Bonica, Juniper Networks
13. Stéphane Bortzmeyer,  (107)
14. Chris Bowers, Juniper Networks
15. Bob Briscoe,  (107)
16. Stewart Bryant, Futurewei
17. Luc André Burdet, Cisco    
18. Randy Bush, Internet Initiative Japan & Arrcus, Inc
19. Italo Busi, Huawei
20. Pablo Camarillo, Cisco Systems
21. David Carrel, Cisco Systems, Inc. (107)
22. Daniele Ceccarelli, Ericsson AB
23. Tommy Charles, NCSC
24. Mach CHEN, Beijing Huawei Digital Technologies Co., Ltd.
25. Huaimo Chen, Futurewei
26. Uma Chunduri, Futurewei Inc
27. Laurent Ciavaglia, Nokia
28. Alexander (Alex) Clemm, Futurewei Technologies, Inc.
29. Spencer Dawkins, Tencent America
30. Dhruv Dhody, Huawei
31. Jie Dong, Huawei Technologies
32. Linda Dunbar, Futurewei
33. Donald E. Eastlake, 3rd, Futurewei Technologies, Inc.
34. Charles Eckel, Cisco Systems
35. Toerless Eckert, Futurewei USA
36. Lars Eggert, NetApp
37. Theresa Enghardt, Netflix
38. David (Dawei) Fan, Huawei
39. Adrian Farrel, Old Dog Consulting (107)
"40. Bill Fenner, Arista Networks, Inc 	U (107)"
41. Maximilian Franke, TU Berlin (107)
42. Rakesh Gandhi, Cisco Systems (107)
43. Liang Geng, China Mobile
44. Xuesong Geng, Huawei
45. Bron Gondwana, Fastmail
46. James Gruessing, British Broadcasting Corporation
47. Yunan Gu, Huawei (107)
48. Jeffrey Haas, Juniper Networks (107)
49. Brian Haberman, Johns Hopkins University
50. Wassim Haddad, Ericsson
51. Phillip M. Hallam-Baker, Threshold Secrets LLC.
52. Dick Hardt, no affiliation at present
53. Susan Hares, Huawei
54. Nick Harper, Google
55. Leif Hedstrom, Apple
56. SHRADDHA HEGDE, Juniper Networks
57. Bob Hinden, Check Point Software
58. Bernie Hoeneisen,  (107)
59. Marco (Maarten) Hogewoning, RIPE NCC
60. Christian Hopps, LabN Consulting, L.L.C.
61. Russ Housley, Vigil Security, LLC
62. Daniel Huang, ZTE
63. Christian Huitema, Private Octopus Inc.
64. Geoff Huston, APNIC
65. LUIGI IANNONE, TELECOM PARIS
66. Jaehoon Jeong, Sungkyunkwan University
67. Yuanlong Jiang, Huawei Technologies Co., Ltd
68. Jaime Jimenez, Ericsson
69. Michael Jones, Microsoft
70. Georgios Karagiannis, Huawei Technologies Dusseldorf GmbH
71. Daniel King, Lancaster University
72. Dirk Kutscher, University of Applied Sciences Emden/Leer (107)
73. David Lawrence, Salesforce
74. Eliot Lear, Cisco Systems
75. Edward (Ted) Lemon, Apple, Inc.
76. Henrik Levkowetz, 
77. Cheng Li, Huawei
78. Guangpeng Li, Huawei
79. Yizhou Li, Huawei Technologies
80. Tony Li, Arista Networks
81. Bing Liu, Huawei Technologies
82. Julien Maisonneuve, Nokia
83. Kiran Makhijani, Futurewei Technologies
84. Allison Mankin, Salesforce
85. Scott Mansfield, Ericsson
86. Mark McFadden, internet policy advisors
87. Patrick McManus, Fastly
88. George Michaelson, APNIC
89. Matthew A. Miller, Mozilla
90. Gregory (Greg) Mirsky, ZTE TX, Inc.
91. Mankamana Mishra, Cisco Systems
92. Sanjay Mishra, Verizon
93. Tal Mizrahi, Huawei
94. Gabriel Montenegro, Independent
95. Marie-Jose Montpetit, MJMontpetit.com
96. Anthony Nadalin,  (107)
97. Yoav Nir, Dell Technologies (formerly Dell-EMC)
98. Börje Ohlman,  (107)
99. Yutaka OIWA, AIST Japan (107)
100. Benno Overeinder, NLnet Labs
101. Kirsty Paine, NCSC
102. Wei Pan, Huawei
103. Keyur Patel,  (107)
104. Shuping Peng, Huawei
105. Tony Przygienda, Juniper
106. Fengwei Qin, China Mobile
107. Yingzhen Qu,  Futurewei Technologies
108. Reshad Rahman, Cisco
109. Eric Rescorla, Mozilla
110. Pete Resnick, Episteme Technology Consulting LLC
111. Michael C.  Richardson,  Sandelman Software Works Inc.
112. MARIA INES ROBLES, ----     
113. Simon Romano, Meetecho/University of Napoli
114. Kyle Rose, Akamai
115. Brian Rosen, Unaffiliated
116. Jogebeth (Joey) Gomez Salazar, ARTICLE 19
117. Gonzalo Salgueiro,  (107)
118. David Schinazi, Google LLC
119. Benjamin Schwartz, Google / Jigsaw
120. John G. Scudder, Juniper Networks
121. Chris Seal,  (107)
122. Göran Selander, Ericsson
123. Yaron Sheffer, Intuit
124. Yimin Shen, Juniper Networks
125. Valery Smyslov, ELVIS-PLUS
126. Job Snijders, NTT, OpenBSD
127. Haoyu Song, Futurewei Technologies
128. Michael StJohns, NthPermutation Security
129. Ondřej Surý, ISC (107)
130. Ketan Jivan Talaulikar, Cisco Systems, India
131. Darshak Thakore, CableLabs
132. Martin Thomson, Mozilla
133. Pascal Thubert, Cisco Systems
134. Nathalie Trenaman,  (107)
135. Hannes Tschofenig, Arm Ltd.
136. Stig Venaas, Cisco
137. Aijun Wang, China Telecom
138. Tim Wattenberg, Unaffiliated. (Student and Consultant)
139. YUEHUA (Corona) WEI, ZTE CORPORATION
140. Samuel Weiler, W3C/MIT
141. Timothy Winters, QA Cafe
142. Christopher Wood,  (107)
143. Suzanne Woolf, Public Interest Registry (.ORG) (107)
144. Bo Wu, Huawei Technologies
145. QIN WU, Huawei
146. Liang Xia,  (107)
147. Min Xiao, ZTE
148. Jingrong Xie, Huawei
149. Quan Xiong, ZTE Corporation
150. GANG YAN, Huawei
151. Huaru Yang, Beijing Huawei Digital Technologies Co., Ltd
152. Jeffrey Yasskin, Google Chrome
153. XIANG YU, Huawei
154. Zhaohui (Jeffrey) Zhang, Juniper
155. Zheng Zhang, ZTE
156. Haomian Zheng, Huawei Technologies Co., Ltd.
157. guangying zheng, huawei
158. Xingwang (Joe) Zhou, Huawei
159. Tianran Zhou, Huawei (107)
160. Shunwan Zhuang, Huawei

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jun 2020 10:12:13 +1200

> 81. Bing Liu, Huawei Technologies

There are two people of that name from Huawei who have participated in the IETF recently, who have different email addresses of course. It seems that they were both at IETF 102, 103, 105 and 106. Can you please check that they have been counted separately, and clarify which of them is the qualified volunteer? 

Regards
   Brian Carpenter

On 29-Jun-20 04:04, NomCom Chair 2020 wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sun, 28 Jun 2020 22:23:52 +0000

I was intending to mention in my next Announcement what I’ll be considering “same affiliation” when limiting NomCom membership to no more than 2 people with the same affiliation. But inquiring minds want to know. So I’ll mention it here and in my next Announcement. 

People who are employed by wholly or majority owned (controlling interest) subsidiaries of a single parent company will be considered affiliated with that parent company. 

People who contract with a company for more than 50% of their time spent doing IETF activities will be considered affiliated with that company.

Barbara 

> On Jun 28, 2020, at 11:05 AM, NomCom Chair 2020 <[email-masked]> wrote:
> 
> Because I only received the volunteer list from IETF 108 a few days ago and told people today whether <nomcom eligibility checker> considered them eligible, it's possible some of those who appeared ineligible may choose to fix errors in prior registrations and become eligible. If that happens, I will add them to the next iteration of this list and note their addition.
> 
> The Secretariat will also be doing the official qualification check. The next steps are listed on <NomCom 2020 datatracker pages> and I will be announcing random seed selections for the RFC 3797 process shortly.
>

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 20:35:55 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > People who contract with a company for more than 50% of their time
    > spent doing IETF activities will be considered affiliated with that
    > company.

If I understand then:
  So if company X contracts me to work 25 hours/week, but only 15 of those hours
  are IETF related, then I wouldn't count for X? (assuming 40hr/week total)

I think that's probably wrong.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Jun 2020 00:38:49 +0000

I took it the opposite way:
	If you do IETF work, and more than 50% of your time is working for "X" then you are considered to be an affiliate of "X"

---

From: Rob Sayre <[email-masked]>
Date: Sun, 28 Jun 2020 18:11:46 -0700

On Sun, Jun 28, 2020 at 5:40 PM Salz, Rich <rsalz=
[email-masked]> wrote:

>         If you do IETF work, and more than 50% of your time is working for
> "X" then you are considered to be an affiliate of "X"
>

Hmm. I think the IETF policy of treating everyone as an individual makes
sense here.

It can be difficult to unpack who is actually paying some tiny company or
consultant. So, why bother?

thanks,
Rob

---

From: Melinda Shore <[email-masked]>
Date: Sun, 28 Jun 2020 17:38:54 -0800

It's a mechanism for mitigating the efforts of a few companies to stuff the
Nomcom and get their employees on the I*.  I'm not sure it's the best way,
or sufficient, to assure the independence of leadership bodies but I don't
think it's unreasonable.

Melinda

On Sun, Jun 28, 2020, 17:12 Rob Sayre <[email-masked]> wrote:

>>         If you do IETF work, and more than 50% of your time is working
>> for "X" then you are considered to be an affiliate of "X"
>>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 29 Jun 2020 13:48:59 +1200

On 29-Jun-20 13:11, Rob Sayre wrote:
> On Sun, Jun 28, 2020 at 5:40 PM Salz, Rich <rsalz=[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hmm. I think the IETF policy of treating everyone as an individual makes sense here.
> 
> It can be difficult to unpack who is actually paying some tiny company or consultant. So, why bother?

We bother in order to avoid a NomCom that is overloaded with loyalty to any one company. But I think Michael's question was reasonable: if someone spends 51% of her working hours on business for company C, of which half (25.5%) is IETF work, and another 49% on IETF work as an individual, is she treated as an affiliate of C for NomCom purposes? If so, why?

I think it's a question that can't be answered. And BCP 10 (RFC 8713) says that it shouldn't be answered:
'Rather than defining precise rules for how to define "affiliation", the IETF community depends on the honor and integrity of the participants to make the process work.'

> People who contract with a company for more than 50% of their time spent doing IETF activities will be considered affiliated with that company.

then the above statement about honor and integrity would not have been part of the BCP.

   Brian

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Jun 2020 01:52:49 +0000

*   It's a mechanism for mitigating the efforts of a few companies to stuff the Nomcom and get their employees on the I*.  I'm not sure it's the best way, or sufficient, to assure the independence of leadership bodies but I don't think it's unreasonable.

Strong agreement.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 28 Jun 2020 23:22:55 -0400

> then the above statement about honor and integrity would not have been part of the BCP.

I just don't understand the "IETF activities" part :-)

I'm employed by Big-Router-Company for 100% of my time, and
I spend 80% of the time writing code, and 20% of my time doing IETF work
(writing drafts..) then I think we'd all agree I work for Big-Router-Company, right?

If I'm contracted to Company1 to write code for 80% of my time,
and I'm contracted to Company2 to write drafts for 20% of my time,

I think we'd say I'm effectively Company1's body.
Whether Company1 has any other IETF people or not, is another question :-)
Doesn't matter that I write code.

The point is that I probably can't be told what to do as a nomcom person by
Company2.

I am neutral as to whether the NomCom should have any publically stated rule
or not.  I don't think I had a rule as NomCom chair, but I did ask when it
was unclear, and the 50% mark was important to

Yes, there are many ways to game this, but not in an honourable way.
(And I've already disclosed to the NomCom chair, btw)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Jun 2020 21:13:02 +0200

[rant]

The long time NOMCOM scheme we have, strongly punishes direct
employment by single big entities over other forms of loyalty
and ecosystem structures. I think this is a historic artefact
and lazyness in thinking about better solution, and it does IMHO
not well take into account the evolution we had in the IETF
over the last 20 years or so.

How about all those one or two people (consulting) companies that
all have loyalty to a single undisclosed larger employer, like various
agencies of a single government ? AFAIK we do not ask, but
would we even consider different agencies of a single government
to be a single entity wrt. NOMCOM ? I don't think we have
done so when it comes to direct employment by them.

I can attest that the interests and loyalties of different groups in
large vendors wrt. IETF leadership can easily be more diverse than
i would expect the goals of different agencies in a some governments
are.

Not to speak of individuals who have a lot more loyalty to
the IETF purely from the self serving perspective that their
career in IETF may be longer than that in any individual employer
and behave accordingly. Wait. are we not all well advised to
all behave like that ? But we're obviously not trusted to do so
when working for a large employer.

How about many small companies whose loyalties lie with the
specific business models such as those of OTTs/cloud-based ?

How about the most likely subconcious "i have no idea on most
IETF area candidates, but in doubt i will vote for someone with
my own country/geo-area or cultural background" ?

Why are big vendors the only aspect we try to protect NOMCOM
against ?

Of course, i do not expect anything to improve, but at least
we could be more open about the fact how the NOMCOM scheme
is traditionally discriminatory in this respect. Because i don't
think people would even agree with this classiciation (discrimination).

Having worked for 20 years for big vendors, i at least feld
this rule to be discrimination after having served once in
Nomcom and came out of it thinking that my specific vendor
association had no impact on my Nomcom choices. Sure, i can be
lying to myself. Who knows.

Of course, i do favour for IAB and all IETF areas those candidates
who do not think the Internet infrastructure can be ignored
or commoditized because it just needs to macially come out
a wifi thingy into a notebook or cloud server and one just needs
to build applications on top of it.

And exactly that candidate selection bias would likely be most
dominant in those nomcom candidates to which the discrimination
rule is applied, and if one wonders why the Internet infrastructure
standards evolution is (at least IMHO) so ossified where as the
applications running on top of it are not, then one has to wonder.

Even if we cannot figure out how to improve the actual process,
it would be fairer to the IETF members working for large
employers if the Nomcom procedures would more explicitly
highlight the discrimination introduced to acknowledge this
unfairness. And write something like

"we don't know how to do better, but if you have an
 idea, please bring it forward".

Just saying. 

[/rant]

Cheers
    Toerless

-- 
---
[email-masked]

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 29 Jun 2020 19:24:17 +0000

Hi Brian,
Bing Liu checked the volunteer box when registering for IETF 108. There is only this one Bing Liu registered for IETF 108, and he is remy dot liubing at huawei dot com. That email address was registered in IETF 104, too, but under the name "Remy Liu". I'm considering all registrations of this one email address to be the same person.
Barbara

> -----Original Message-----
> From: Brian E Carpenter <[email-masked]>
> Sent: Sunday, June 28, 2020 6:12 PM
> To: NomCom Chair 2020 <[email-masked]>
> Cc: [email-masked]
> Subject: Re: List of volunteers for the 2020-2021 NomCom
> 
> There are two people of that name from Huawei who have participated in
> the IETF recently, who have different email addresses of course. It seems
> that they were both at IETF 102, 103, 105 and 106. Can you please check that
> they have been counted separately, and clarify which of them is the qualified
> volunteer?
> 
> Regards
>    Brian Carpenter
> 
> > Because I only received the volunteer list from IETF 108 a few days ago and
> told people today whether
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_registration_nomcom.py&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=5ucTs3_LLZJ6nPcxOEEB7o_y7tO1lJPR7CNvt6fZ2Ug&s=S
> 3-546XqLmu_D8sUD3_RklqFM5qX-gqkMIVj6hiKPuM&e=  considered them
> eligible, it's possible some of those who appeared ineligible may choose to fix
> errors in prior registrations and become eligible. If that happens, I will add
> them to the next iteration of this list and note their addition.
> >
> > I also did get a list from IETF 107. I've asked people from IETF 107
> registrations who passed the attendance eligibility test to explicitly let me
> know if they're still interested in volunteering. But since I need to get on with
> this process, I'm including them in this preliminary list and will delete them in
> the next iteration if they ask to be removed. I've noted them with "(107)"
> next to them. I'll also need to get an affiliation from some of these. I did not
> send email to IETF 107 volunteers who did not pass the attendance eligibility
> check. There were too many of those.
> >
> > The list contains 160 members, all of whom have been verified by me (and
> not yet officially by the Secretariat) as qualified for the position of voting
> member of NomCom by virtue of having attended 3 of IETF 102-106
> meetings, and none of whom are known to me to be a member of any body
> that the NomCom will be selecting people for. But I could have missed a few.
> I'm expecting people to find some errors in this list.
> >
> > We now enter the challenge period, which lasts until Monday, July 6, 2020.
> If anyone thinks that a name on the numbered list below is NOT qualified for
> some reason, please send me email before July 6 at:
> >
> > The Secretariat will also be doing the official qualification check. The next
> steps are listed on https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_nomcom_2020_&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzhC-
> 8sc8SY8Tq4vrfog&m=5ucTs3_LLZJ6nPcxOEEB7o_y7tO1lJPR7CNvt6fZ2Ug&s=6
> B99L2kvydeUaxwbOYM5qxDaBx0zTyL8E5ErZjaiGO8&e=  and I will be
> announcing random seed selections for the RFC 3797 process shortly.
> >
> > 6. Vishnu Pavan (Pavan) Beeram, Juniper Networks 7. Louis (Lou)
> > Berger, LabN Consulting, L.L.C.
> > 8. Vittorio Bertola, Open-Xchange GmbH 9. Henk Birkholz, Fraunhofer
> > SIT 10. Michael Bishop, Akamai 11. Matthew Bocci, Nokia 12. Ronald
> > Bonica, Juniper Networks 13. Stéphane Bortzmeyer,  (107) 14. Chris
> > Bowers, Juniper Networks 15. Bob Briscoe,  (107) 16. Stewart Bryant,
> > Futurewei
> > 18. Randy Bush, Internet Initiative Japan & Arrcus, Inc 19. Italo
> > Busi, Huawei 20. Pablo Camarillo, Cisco Systems 21. David Carrel,
> > Cisco Systems, Inc. (107) 22. Daniele Ceccarelli, Ericsson AB 23.
> > Tommy Charles, NCSC 24. Mach CHEN, Beijing Huawei Digital Technologies
> > Co., Ltd.
> > 41. Maximilian Franke, TU Berlin (107) 42. Rakesh Gandhi, Cisco
> > Systems (107) 43. Liang Geng, China Mobile 44. Xuesong Geng, Huawei
> > 45. Bron Gondwana, Fastmail 46. James Gruessing, British Broadcasting
> > Corporation 47. Yunan Gu, Huawei (107) 48. Jeffrey Haas, Juniper
> > Networks (107) 49. Brian Haberman, Johns Hopkins University 50. Wassim
> > Haddad, Ericsson 51. Phillip M. Hallam-Baker, Threshold Secrets LLC.
> > 52. Dick Hardt, no affiliation at present 53. Susan Hares, Huawei 54.
> > Nick Harper, Google 55. Leif Hedstrom, Apple 56. SHRADDHA HEGDE,
> > Juniper Networks 57. Bob Hinden, Check Point Software 58. Bernie
> > Hoeneisen,  (107) 59. Marco (Maarten) Hogewoning, RIPE NCC 60.
> > Christian Hopps, LabN Consulting, L.L.C.
> > 66. Jaehoon Jeong, Sungkyunkwan University 67. Yuanlong Jiang, Huawei
> > Technologies Co., Ltd 68. Jaime Jimenez, Ericsson 69. Michael Jones,
> > Microsoft 70. Georgios Karagiannis, Huawei Technologies Dusseldorf
> > GmbH 71. Daniel King, Lancaster University 72. Dirk Kutscher,
> > University of Applied Sciences Emden/Leer (107) 73. David Lawrence,
> > Salesforce 74. Eliot Lear, Cisco Systems 75. Edward (Ted) Lemon,
> > Apple, Inc.
> > 76. Henrik Levkowetz,
> > 77. Cheng Li, Huawei
> > 78. Guangpeng Li, Huawei
> > 83. Kiran Makhijani, Futurewei Technologies 84. Allison Mankin,
> > Salesforce 85. Scott Mansfield, Ericsson 86. Mark McFadden, internet
> > policy advisors 87. Patrick McManus, Fastly 88. George Michaelson,
> > APNIC 89. Matthew A. Miller, Mozilla 90. Gregory (Greg) Mirsky, ZTE
> > TX, Inc.
> > 95. Marie-Jose Montpetit, MJMontpetit.com 96. Anthony Nadalin,  (107)
> > 97. Yoav Nir, Dell Technologies (formerly Dell-EMC) 98. Börje Ohlman,
> > (107) 99. Yutaka OIWA, AIST Japan (107) 100. Benno Overeinder, NLnet
> > Labs 101. Kirsty Paine, NCSC 102. Wei Pan, Huawei 103. Keyur Patel,
> > (107) 104. Shuping Peng, Huawei 105. Tony Przygienda, Juniper 106.
> > Fengwei Qin, China Mobile 107. Yingzhen Qu,  Futurewei Technologies
> > 108. Reshad Rahman, Cisco 109. Eric Rescorla, Mozilla 110. Pete
> > Resnick, Episteme Technology Consulting LLC 111. Michael C.
> > Richardson,  Sandelman Software Works Inc.
> > 113. Simon Romano, Meetecho/University of Napoli 114. Kyle Rose,
> > Akamai 115. Brian Rosen, Unaffiliated 116. Jogebeth (Joey) Gomez
> > Salazar, ARTICLE 19 117. Gonzalo Salgueiro,  (107) 118. David
> > Schinazi, Google LLC 119. Benjamin Schwartz, Google / Jigsaw 120. John
> > G. Scudder, Juniper Networks 121. Chris Seal,  (107) 122. Göran
> > Selander, Ericsson 123. Yaron Sheffer, Intuit 124. Yimin Shen, Juniper
> > Networks 125. Valery Smyslov, ELVIS-PLUS 126. Job Snijders, NTT,
> > OpenBSD 127. Haoyu Song, Futurewei Technologies 128. Michael StJohns,
> > NthPermutation Security 129. Ondřej Surý, ISC (107) 130. Ketan Jivan
> > Talaulikar, Cisco Systems, India 131. Darshak Thakore, CableLabs 132.
> > Martin Thomson, Mozilla 133. Pascal Thubert, Cisco Systems 134.
> > Nathalie Trenaman,  (107) 135. Hannes Tschofenig, Arm Ltd.
> > 136. Stig Venaas, Cisco
> > 138. Tim Wattenberg, Unaffiliated. (Student and Consultant) 139.
> > YUEHUA (Corona) WEI, ZTE CORPORATION 140. Samuel Weiler, W3C/MIT
> 141.
> > Timothy Winters, QA Cafe 142. Christopher Wood,  (107) 143. Suzanne
> > Woolf, Public Interest Registry (.ORG) (107) 144. Bo Wu, Huawei
> > Technologies 145. QIN WU, Huawei 146. Liang Xia,  (107) 147. Min Xiao,
> > ZTE 148. Jingrong Xie, Huawei 149. Quan Xiong, ZTE Corporation 150.
> > GANG YAN, Huawei 151. Huaru Yang, Beijing Huawei Digital Technologies
> > Co., Ltd 152. Jeffrey Yasskin, Google Chrome 153. XIANG YU, Huawei
> > 154. Zhaohui (Jeffrey) Zhang, Juniper 155. Zheng Zhang, ZTE 156.
> > Haomian Zheng, Huawei Technologies Co., Ltd.
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mail
> > man_listinfo_ietf-2Dannounce&d=DwIFaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=LoGzh
> > C-
> 8sc8SY8Tq4vrfog&m=5ucTs3_LLZJ6nPcxOEEB7o_y7tO1lJPR7CNvt6fZ2Ug&s=7
> DRvuUqiXjA045rIUMeFImoWCYRClKclEUku06TnbFs&e=
> >

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Jun 2020 20:39:04 +0000

>  But we're obviously not trusted to do so

I don't believe this is correct.  The individuals are trusted, but the risk is that the large employer will "flood the field."

    against ?

Because those are the main potential adversary of trying to tip the playing field to get their staff into leadership.

Isn't that implicit in everything the IETF does?

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 29 Jun 2020 15:55:29 -0500

Hi, Rich,

On Mon, Jun 29, 2020 at 3:40 PM Salz, Rich <rsalz=
[email-masked]> wrote:

> I don't believe this is correct.  The individuals are trusted, but the
> risk is that the large employer will "flood the field."
>

When it mattered, that was my experience (I believe I'm one of two eligible
Nomcom participants from my current employer, but that's a HUGE change from
2005-2019).

> Because those are the main potential adversary of trying to tip the
> playing field to get their staff into leadership.
>

It's worth noting that we tend to shoot where the duck is, rather than
leading the target.

We've had some periods where a few large companies sent lots of
participants to the IETF often enough to qualify them for Nomcom, and we
thought that having a Nomcom where half the voting members were from one or
two companies was a bad look).

If the community has concerns about other significant vulnerabilities, we
should probably try to fix them. Which leads me to

> Isn't that implicit in everything the IETF does?

I'd like to think so ;-)

The best proof of that is what gets brought forward, of course.

Best,

Spencer

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Jun 2020 17:11:00 -0400

Toerless,

As Spencer says, the current rule (which is well documented in section 4.17
of RFC 8713) is intended (for better or worse) to prevent NomCom from being
made up of a small set of affiliations.

I think that we're all in agreement that the more diversity in the I*, the
better. Which implies that the more diversity on the NomCom, the better.
However, there are very few levers that the IETF actually has to produce
NomCom diversity other than affiliation.

If you have a better idea, propose an update to RFC 8713.

Cheers,
Andy

On Mon, Jun 29, 2020 at 3:13 PM Toerless Eckert <[email-masked]> wrote:

> >   *   It's a mechanism for mitigating the efforts of a few companies to
> stuff the Nomcom and get their employees on the I*.  I'm not sure it's the
> best way, or sufficient, to assure the independence of leadership bodies
> but I don't think it's unreasonable.
> >
> > Strong agreement.
>
> --
> ---
> [email-masked]
>
>

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 29 Jun 2020 23:57:21 +0200

> made up of a small set of affiliations.

Sure, but but if some part of the IETF community comes
from an industry which for better or worse is structured into
fewer large companies than other parts of the community then it
puts this part of the community at a disadvantage.

I am looking at this in comparison with IMHO similar difficult
constructs. Aka: In ITU, each country has one vote. Is this fair
wrt. e.g.: USA/China with one vote each vs. E.g.: Europe or
Africa ? We are just seeing what this leads to. Even the electoral
college in the USA recognizes difference in size between states.

> NomCom diversity other than affiliation.

How about we introduced a rule saying that there can be at most
two Nomcom people from one country ? That would create a lot more
diversity. Huh ? Unfair ? Why ? Because it affects more candidates than
the vendor role ? How is that a good argument if we are after diversity ?

I could equally say that the NomCom procedures suppress the diversity
from all the different voices just because they work for one company
instead of oh, for example a loyalty group built as a franchise
around a popular business model.

> If you have a better idea, propose an update to RFC 8713.

The first thing is for IETF attendants to even start thinking about
whether the current scheme is fair. I think most do. I don't. I also
said that the first stage of updating RFC8713 would be to consider
better acknowledging this fact and wondering if this is still appropriate
under the evolution in the community. I for once don't think it is
anywhere as useful as it might have been in the past. Definitely not
by itself as a one-off it is right now.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 30 Jun 2020 00:10:12 +0200

For the record I was always under impression that participation in IETF is
all based on individuals and their contributions not about their sponsors
or affiliations.

Sure some come to IETF to represent and market their sponsor's solutions
but those should be treated as incidents and controlled as early as
possible.

On the other hand I know first hand folks who while being paid for travel
and hotel as well as registration fees by their day jobs do not represent
their marketing orgs and do still act  and contribute as individuals. So
the limit imposed here for NomCom seems rather like a penalty for those
independent engineers.

So if I may I would recommend that if at all required - such limit is to be
imposed to vendors only and never applied to operators or research
organizations or academia.

Thx,
R.

---

From: "John Levine" <[email-masked]>
Date: 29 Jun 2020 18:15:19 -0400

>puts this part of the community at a disadvantage.

I think you've just shown why we need this rule. No sane person
actively wants to tbe on the nomcom. It's a lot of work, it keeps you
away from the sessions in at least one full meeting (assuming we ever
meet again.) People do it anyway for the benefit of the IETF. The
normal reaction to learning that you are less likely to be selected
because there's a lot of your co-workers on the list is great, that
means it's likely I'll have to do it.

The point of the selection rules is to get nomcoms that can work
effectively without undue external influence, not to be something you
can check off on your next bigcorp annual review.

R's,
John

---

From: Melinda Shore <[email-masked]>
Date: Mon, 29 Jun 2020 14:48:34 -0800

> but those should be treated as incidents and controlled as early as

It's natural and desirable that people bring their companies'
technologies to the IETF, I think, if for no other reason that
we'd like to incentivize, I think, open technology/standards
and interoperability.

What we *don't* want is companies successfully gaming the
leadership selection process in a way that compromises the
quality of the IETF's output, or that favors a particular
technology on the basis of something other than technical merit.
IETF process needs to be as open as it can be without damaging
the organization itself, and this seems like a reasonable
and low-impact defense mechanism.  It's still the case that nomcom
members can and will be fierce advocates for appointing someone
from their own company, but by balancing nomcom membership there is, at
least, a builtin defense against appointing someone completely
unsuitable.

> So if I may I would recommend that if at all required - such limit is to
> be imposed to vendors only and never applied to operators or research

Oh, if only we had the problem of too many participants or volunteers
from operators or research organizations or academia ...

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 29 Jun 2020 16:00:37 -0700

Well said Melinda!
Just basic abuse prevention and balance.

Cheers,
Jeff

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 01:41:08 +0200

> I think you've just shown why we need this rule.

> No sane person > actively wants to tbe on the nomcom.

Are you implying my prior emails reads to you as if i would want to actively
on NomCom, hence i am insance, hence the rule is needed to help me
against my insanity ?

Nothing against calling me insance, i think i proved that by writing
an email against the established tradition of the NomCom rules.

I just don't think my insanity proves your point: Just because i would
not want folks from a category i belong to be more easily disqualified
from NomCom election does not mean i would like the work associated with it.
Difference between rights and responsibilities resulting from rights...

[ Have you tried to run the math on this ? I am not even sure that
  a change would increase an individual large company candidate to be
  elected. Probably rather the opposite... Hmm, can't guess the outcome. ]

>  It's a lot of work, it keeps you

Well.. if you are lucky and there where good candidates and those also
got elected, there is some satisfaction from that in the end.

> effectively without undue external influence,

Sure, and i think i made clear how i think this goal is IMHO badly applied.

> not to be something you can check off on your next bigcorp annual review.

I think its a lucky position for an IETF attendee to be on a job where
the employeer would actually recognize time spent on NomCom as a
good thing. Why against does this make big companies that do this
evil ? At least thats what it sounds like to me.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 02:07:40 +0200

> technology on the basis of something other than technical merit.

+1

> and low-impact defense mechanism.

Yes, but its selective to a specific part of the community just
because it was so easy to make that rule as opposed to rules for
similar problems (as i decribed my other emails).

> It's still the case that nomcom

I am not sure if if this is actually true, to me that would rather
be "blindly promoting". But i think this does equally, if not more
happen now across other loyalty groups within Nomcom.

> from operators or research organizations or academia ...

Well... thats a too long argument here. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Joel Halpern <[email-masked]>
Date: Mon, 29 Jun 2020 20:57:17 -0400

Toerless, you do understand that not only was the affiliation rule 
arrived at by rough consensus, but as I recall it was added during the 
process at the request of the community?

If you really think it is wrong, write a clear proposal of what you 
think a better rule looks like.  And then try to get some indication the 
the community agrees with you.

But please do not suggest that the current nomcom chair should apply 
some other rules.

Yours,
Joel

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 29 Jun 2020 22:42:24 -0400

> puts this part of the community at a disadvantage.
That may be true, but there is not much we can do about that.  However, I
am not sure I fully understand what the major issue is with respect to this
point.  Whereas its true some people whom are willing to volunteer for
Nomcom, but are clustered into a set of companies and therefore can be
excluded from voting member selection (I guess that's the disadvantage),
there are certainly other advantages that come with that.  That said, not
being selection because one is the third member of their company does not
deny a person the ability to contribute, take on a leadership role and
serve the community in many other ways.  It only ensures we limit the real
or perceived influence of a given company (should the random selection
result in 3 or more for Nomcom).  Although I think most (if not all)
participate in good faith, bias can occur, and it is sometimes manifest in
unconscious bias.

> college in the USA recognizes difference in size between states.

I guess one could compare the ITU (and the per-country voting system),
however I would suggest that body operates very differently than the IETF,
and such a comparison would be much more complex.

> the vendor role ? How is that a good argument if we are after diversity ?

I am not sure countries are a defining boundary for how work in the IETF is
done and how contributions are made, nor how agendas and/or
commercial interests are most manifest (note I did not say none here).
Business entities and primarily affiliations are the most impactful
association of people which can be quantified.

> around a popular business model.

How do we quantify this in a rule which can be defined and executed on a
consistent basis?   This is likely, given the randomness of the selection
process, a corner case.  And as such, there is oversight with liaisons and
the selection process includes a confirming body.

> by itself as a one-off it is right now.

I still am not sure I understand how the current process is
inherently unfair.   Other than primary affiliation (which is an obvious
vector for real or perceived bias) and participation/attendance, there are
no limitations that know of that restrict one from volunteering and being
selected.  Starting to bias on other factors (such as country) would be, in
my mind, more of a limitation for potential volunteers (and this can also
be gamed by having employees for a given company volunteer from a more
diverse set of countries). I would agree that for people whom work for a
large entity, they are potentially limited, but this also means that people
from small entities, (even as small as a group of 1) have a reasonable
opportunity to participate.   The process should also maximize against the
widest set of the community needs (vs. attempting to compensate for corner
cases - IMO).

There is of course the aspect of traditional attendant requirements, but
that is being discussed within the community.

regards,

Victor K

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 29 Jun 2020 22:45:38 -0400

> process at the request of the community?

Indeed, initially there was no affiliation rule (see, for example, RFC
2027). But it is common that one company sends substantially more
people to IETF meetings than any other company. Which company changes
as the years pass but it takes only a gentle hint by the technical
management of that company for them to have a lot of people in the
nomcom member volunteer pool. If I recall correctly, there came a year
when 3 voting members of the nomcom were affiliated with the same
company and then the next year 4 members were affiliated with that
same company. And, to any outside observer, this smells really bad as
well as being surprising and somewhat upsetting to many IETF
participants. Furthermore, some calculations from the typical
distribution of the volunteer pool at the time showed something like a
9% or so probability of that company having 4 or more members on the
nomcom in any year. (This is all from memory.) So, the rule limiting
voting members to no more than 2 with the same affiliate was adopted
by a pretty strong consensus.

I realize that people affiliated with a large company are not
necessarily aligned with their employer. I remember one IETF when I
was talking to an employee of a large company and they thought there
was a good chance they were going to get a call during the IETF week
saying they were fired due to a more severe mis-alignment than usual
:-) But this sort of thing just isn't visible; what's visible without
an affiliation limit is apparent domination by one company.

+1

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 29 Jun 2020 22:47:08 -0400

> process at the request of the community?

Agreed.

> the community agrees with you.
Agreed.  There is ample opportunity to seek community feedback on an
alternative.

> But please do not suggest that the current nomcom chair should apply

Highly agree.  Consistency is very important in a fair and open process.
The chair should follow the process. .

regards,

Victor K

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 05:01:02 +0200

On Mon, Jun 29, 2020 at 08:57:17PM -0400, Joel Halpern wrote:
> Toerless, you do understand that not only was the affiliation rule arrived
> at by rough consensus, but as I recall it was added during the process at
> the request of the community?
> 
Of course.

> If you really think it is wrong, write a clear proposal of what you think a
> better rule looks like.  And then try to get some indication the the
> community agrees with you.

I did say what i wanted to say. Including that it is way too early in what i
think is the predominant thinking in the community to move this argument further.
I am disappointed by this, but i do not need to run any further against windmills
that showing that there is at last no 100% agreement with the rules.

> But please do not suggest that the current nomcom chair should apply some
> other rules.

I did not do this in my emails so far, and i do not intend to do this.
I have some question about what constitutes a subsidiary wrt. to specific
candidate Nomcom members, but i sent that specifically to the nomcom chair.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 Jun 2020 00:12:59 -0400

> candidate Nomcom members, but i sent that specifically to the nomcom chair.

To put some real numbers behind this I grabbed the list, and did some 
consolidation and sorting.  There were basically only a few companies 
where I ended up merging things:  Anything with "Huawei" in the name was 
Huawei.  (Huawei, Huawei Technologies, Huawei Tech Dusseldorf, Beijing 
Huawei, Ditto for Google (Chrome, Jigsaw). The remainder of the list 
were slight variants (Cisco vs Cisco Systems, etc) and easy to merge.  I 
wasn't sure of whether Futurewei should be grouped with Huawei, so I did 
the calculations both ways.

Taking only the groups with 3 or more volunteers you get:

Cisco - 13 - 8.1% of the pool - 24.2% chance of having 1, 65.6% of 2
Ericsson - 6 -   3.8% of the pool 37.5/26.9
Futurewei - 10 - 6.3% of pool 31.5/51.5
Google - 4  2.5% 34.9/14.6
Huawei - 28 17.5%  3.2/95.9
Juniper - 10  6.3% 31.5/51.5
Mozilla - 3 1.9%, 30.9, 9.1
Nokia - 3  1.9%  30.9/9.1
ZTE - 6 - 3.8% 37.5/26.9

(Huawei + Future Wei ) 23.8% .6/95.6

Using the current model, Huawei with 17.5% of the pool has only a (100 - 
95.9 - 3.2)  .6% chance of having no volunteers selected, a 3.2% chance 
of having 1, and a 95.9% chance of having 2.   If Futurewei and Huawei 
are counted as separate companies, together they have about a 50% chance 
of having 4 members between them (estimate rather than doing the 
calculations).

Cisco and Juniper each have more than a 50/50 chance of having two 
members and a >80% chance of having at least one each.

The above numbers were calculated using the BINOMDIST function in Excel.

Mike

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 06:54:12 +0200

Thanks for the analysis.

Inline.

On Tue, Jun 30, 2020 at 12:12:59AM -0400, Michael StJohns wrote:
> consolidation and sorting.  There were basically only a few companies where
> I ended up merging things:  Anything with "Huawei" in the name was Huawei. 
> (Huawei, Huawei Technologies, Huawei Tech Dusseldorf, Beijing Huawei, Ditto
> for Google (Chrome, Jigsaw). The remainder of the list were slight variants
> (Cisco vs Cisco Systems, etc) and easy to merge.  I wasn't sure of whether
> Futurewei should be grouped with Huawei, so I did the calculations both
> ways.
> 
> 95.9 - 3.2)  .6% chance of having no volunteers selected, a 3.2% chance of
> having 1, and a 95.9% chance of having 2.   If Futurewei and Huawei are
> counted as separate companies, together they have about a 50% chance of
> having 4 members between them (estimate rather than doing the calculations).
>
> Cisco and Juniper each have more than a 50/50 chance of having two members
> and a >80% chance of having at least one each.
> 

Whats the probability of a single individual from  e.g: Huawei+Futurewei
to be elected to NomCom. vs. the probability of an individual from
a company where he/she is the only nomcom volunteer ?

I saw some folks without listed company affiliations that have i think
known company affiliations. Whats the process ? Is NomCom chair
having to try to figure that out, best effort ?

Obvious, and this is the root of what i think is our problem dealing with
candidate bias: There are no simple critera to demonstrate other than
company affiliation clusters of bias that would imact the quality of
the nomcom results. So big companies are the easy pinata.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jun 2020 02:16:37 -0400

--On Tuesday, June 30, 2020 00:12 -0400 Michael StJohns
<[email-masked]> wrote:

>...
> To put some real numbers behind this I grabbed the list, and
> did some consolidation and sorting.  There were basically
> only a few companies where I ended up merging things: 
> Anything with "Huawei" in the name was Huawei.  (Huawei,
> Huawei Technologies, Huawei Tech Dusseldorf, Beijing Huawei,
> Ditto for Google (Chrome, Jigsaw). The remainder of the list
> were slight variants (Cisco vs Cisco Systems, etc) and easy to
> merge.  I wasn't sure of whether Futurewei should be grouped
> with Huawei, so I did the calculations both ways.
> 
> Using the current model, Huawei with 17.5% of the pool has
> only a (100 - 95.9 - 3.2)  .6% chance of having no volunteers
> selected, a 3.2% chance of having 1, and a 95.9% chance of
> having 2.   If Futurewei and Huawei are counted as separate
> companies, together they have about a 50% chance of having 4
> members between them (estimate rather than doing the
> calculations).
>...

Mike, I have read through the above several times, and can't
figure out how, if some organization has a likelihood of having
one person selected, say NN%, that they can have a higher
likelihood, MM%, MM > NN of having two (or more, but that would
be restricted by the current rules) selected.   Moreover, even
if I do sampling without replacement such as the first person
selected for that company reduces the size of the pool, I can't
come up with a model that makes MM > NN for some companies but
MM < NN for others.

Am I missing something about either how you are reporting the
results of your calculations or the calculations themselves?

thanks,
    john

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jun 2020 08:35:19 +0100

> 
> I think that we're all in agreement that the more diversity in the I*, the better. Which implies that the more diversity on the NomCom, the better. However, there are very few levers that the IETF actually has to produce NomCom diversity other than affiliation.

Diversity in the I* is absolutely good, but so is an I* with members that have enough time made available to dedicate to the job.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jun 2020 10:47:27 +0100

An interesting list of issues that deserve wider discussion.

The use of company employment as a proxy for conflict of interest is dated, in part due to the very success of our technologies.

What is needed is a full declaration of the conflicts as part of the selection process.

I was going to say that this can be in confidence, but I am not so sure. If someone is not prepared to openly state their COIs, then how can one be sure who’s interest they are working towards when doing regular work?

The IETF’s claim is that we are an open transparent process, and that in my view requires declaring all conflicts of interest, especially when accepting a position of authority.

When applied to Nomcom, the right process is for the chair to examine the COIs and accept/reject accordingly, but to put that statement on record as part of the challenge process.

- Stewart

> On 29 Jun 2020, at 20:13, Toerless Eckert <[email-masked]> wrote:
> 
> [rant]
>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jun 2020 11:25:38 +0100

> On 29 Jun 2020, at 23:48, Melinda Shore <[email-masked]> wrote:
> 
> the organization itself, 

I agree with that.

> and this seems like a reasonable

“This" here is the use of employment as a poor approximation for what we should have which is a conflict of interest declaration.

> from their own company, 

That needs delving in some more detail. It is wrong for someone to be an advocate because the person works for the same company. BUT it is not work if the Nomcom member knows that person well and is convinced that they have the required qualities for the post, including the required degree of independence of thought and action.

> but by balancing nomcom membership there is, at

However, we need to balance against COI, not just do it the easy way.

Indeed I think there really needs to be a COI register as you would have in any decision making position in most bodies. Take an example, I sit on the Board of the UK Amateur Radio Society (RSGB). At every Board meeting I am asked if I have any conflict of interest not already declared. The officials at the IETF have a much larger commercial and “regulatory” impact and yet we skirt the subject with a very crude proxy.

- Stewart

---

From: Joel Halpern <[email-masked]>
Date: Tue, 30 Jun 2020 09:06:54 -0400

In terms of procedures for selecting nomcom and for nomcom operation, I 
do not understand what a more extensive COI disclosure would do.
What rules would apply to the selection for nomcom?
What effect would it have on nomcom participation?  Note that we 
currently do not expect folks to recuse from votes that include subjects 
from their own company.  And such recusal would be somewhere between 
impractical and impossible.

Yours,
Joel

On 6/30/2020 6:25 AM, Stewart Bryant wrote:
> 
> 
>> On 29 Jun 2020, at 23:48, Melinda Shore <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
> “This" here is the use of employment as a poor approximation for what we 
> should have which is a conflict of interest declaration.
> 
> That needs delving in some more detail. It is wrong for someone to be an 
> advocate because the person works for the same company. BUT it is not 
> work if the Nomcom member knows that person well and is convinced that 
> they have the required qualities for the post, including the required 
> degree of independence of thought and action.
> 
> Indeed I think there really needs to be a COI register as you would have 
> in any decision making position in most bodies. Take an example, I sit 
> on the Board of the UK Amateur Radio Society (RSGB). At every Board 
> meeting I am asked if I have any conflict of interest not already 
> declared. The officials at the IETF have a much larger commercial and 
> “regulatory” impact and yet we skirt the subject with a very crude proxy.
> 
> - Stewart
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 30 Jun 2020 14:02:45 +0000

*   “This" here is the use of employment as a poor approximation for what we should have which is a conflict of interest declaration.

I think that requiring a COI disclosure for all potential Nomcom members will shrink the pool.  You can’t consider COI without looking at other factors.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 Jun 2020 10:44:15 -0400

> a company where he/she is the only nomcom volunteer ?

The raw probabilities are the same.  E.g. Ptot ~=  1 - ((1-1/160)^10) or 
about 6% chance for any individual in the pool being selected.  Its 
approximate because the pool actually shrinks with each pick changing 
the probability upwards for each subsequent pick.  For Huawei+Futurewei, 
let's assume they end up with two members (as that's a near 100% 
chance).  The Ptot for each would be ~= 1-((1-1/38)^2) or about 5%.  Not 
really a great difference.  (It's actually %5.19% * 95.6% or 4.96% plus 
.6% * 2.6% - call it 5%).

Note:  Figure the probability of not being selected N times (which is 
(1-Psel)^N) and subtract that from 1 to get the probability of being 
selected at least once.

> having to try to figure that out, best effort ?
I saw three I think.  One from Cisco, one from Huawei and one from 
Cloudflare.  I expect those will be filled in.

---

From: Töma Gavrichenkov <[email-masked]>
Date: Tue, 30 Jun 2020 17:59:48 +0300

Peace,

> having to try to figure that out, best effort ?

1) RFC 8713, 4.17:
"The Chair reviews the primary affiliation of each volunteer selected
by the method in turn."

2) The beginning of the thread:
"I've asked people from IETF 107 registrations who passed the
attendance eligibility test [..] I've noted them with "(107)" next to
them. I'll also need to get an affiliation from some of these."

I'm assuming not reporting or mis-reporting an existing affiliation is
a clear conflict of interest per se and would simply lead to the
termination of the NomCom term.  If you believe this is not exactly
clear as per RFC 8713, someone has already suggested that you write an
update to that.

--
Töma

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jun 2020 16:01:43 +0100

> On 30 Jun 2020, at 14:06, Joel Halpern <[email-masked]> wrote:
> 
> In terms of procedures for selecting nomcom and for nomcom operation, I do not understand what a more extensive COI disclosure would do.

That not more than two people with significant (say 10% of their income or time) interest in any entity (other than the IETF) served concurrently.

> What effect would it have on nomcom participation?  

I do not know.

> Note that we currently do not expect folks to recuse from votes that include subjects from their own company.  And such recusal would be somewhere between impractical and impossible.

I disagree, it depends on the degree of sensitivity and controversy. That is one reason why we run two in a box for a lot of tasks. I have certainly stepped aside from controversial issues to let a peer run the show where the decision was sensitive and thus strict neutrality was required.

- Stewart

>>> On 29 Jun 2020, at 23:48, Melinda Shore <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 30 Jun 2020 16:03:24 +0100

> On 30 Jun 2020, at 15:02, Salz, Rich <[email-masked]> wrote:
> 

So it’s better to travel in hope that arrive?

If there is a COI and this is more subtle than just who you are full time employed by, we should not take this into account?

Stewart

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 30 Jun 2020 15:07:08 +0000

*   So it’s better to travel in hope that arrive?

I didn’t say that (cute phrase, tho).  I said consider other factors as well.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 Jun 2020 11:38:14 -0400

Sorry - I screwed up badly.  Cut and pasted the wrong values for the 
function.  The actual numbers are :

=BINOMDIST (number of selectees [0-10], number of slots [10], percent of 
pool [n/160], FALSE (non cumulative)) - this is the probability of 
getting exactly the number of selectees, given the number of tries 
(slots) and how large your group is relative to the pool size.

Cisco - 13 - 8.1% of pool, 37.9% of having exactly 1 , 19.3% of having 2 
(sum of 2-10 selectees).
Ericsson - 6 - 3.8%, 26.6,5.2
Futurewei - 10 - 6.3%, 35, 12.6
Google - 4 - 2.5% 19.9, 2.5
Huawei - 28 - 17.5%, 31/54.4
Juniper - 10 - 6.3%, 35, 12.6
Mozilla - 3 - 1.9% , 15.8, 1.4
Nokia - 3 - 1.9%, 15.8, 1.4
ZTE  - 6 3.8%, 26.6, 5.2

(Huawei + Futurewei)  23.8% 20.7, 72.7

Abject apologies.  And thanks for John's note that made me go back and 
check.   I'll revise my email to Toerless with new values shortly.

John - For Huawei + Futurewei, the entire row looks like:

	Number of Nomcom Members 	
Percent of Volunteer Pool 	0 	1 	2 	3 	4 	5 	6 	7 	8 	9 	10 	>= 2 	>=1
23.8% 	6.6% 	20.7% 	29.0% 	24.1% 	13.1% 	4.9% 	1.3% 	0.2% 	0.0% 	0.0% 
0.0% 	72.7% 	93.4%

The >= 2 is the sum of 2-10 columns .   Leading to the MM >> NN.  
Basically, you've got 10 tries to get 2 or more selectees.  So any 
result from 2-10 represents 2 actual selectees.

Note that the BINOMDIST function does the calculation with replacement 
so there is some slight upward bias.

Mike

On 6/30/2020 12:12 AM, Michael StJohns wrote:
> Using the current model, Huawei with 17.5% of the pool has only a (100 
> - 95.9 - 3.2)  .6% chance of having no volunteers selected, a 3.2% 
> chance of having 1, and a 95.9% chance of having 2.   If Futurewei and 
> Huawei are counted as separate companies, together they have about a 
> 50% chance of having 4 members between them (estimate rather than 
> doing the calculations).
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 30 Jun 2020 11:44:41 -0400

On 6/30/2020 10:44 AM, Michael StJohns wrote:
> The raw probabilities are the same.  E.g. Ptot ~=  1 - ((1-1/160)^10) 
> or about 6% chance for any individual in the pool being selected. Its 
> the probability upwards for each subsequent pick.  For 
> Huawei+Futurewei, let's assume they end up with two members (as that's 
> a near 100% chance).  The Ptot for each would be ~= 1-((1-1/38)^2) or 
> about 5%.  Not really a great difference.  (It's actually %5.19% * 
> 95.6% or 4.96% plus .6% * 2.6% - call it 5%).
>

Sorry - updating.  the raw probabilities remain the same.   The 
Huawei+Futurewei numbers are

5.19% * 72.7% + 2.6% * 20.7% - >   ~4.3% chance of a given H+F volunteer 
being selected vs a ~6% chance of someone either unaffiliated or in a 
group of 2 or less being selected.

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 30 Jun 2020 12:13:19 -0400

My take on the affiliation rule is substantially different. I see it more
as a protection for the members of the NOMCON.

To have three employees appointed to NOMCON, it is overwhelmingly likely
that a company had a large number of people volunteer which means that they
have a large number attending IETFs. So either they are an entryist faction
(see Sick Puppies / Worldcon) or they are doing a lot of IETF work in which
case they likely have a lot of employees being considered for IESG and IAB.

Now consider the case in which the X-co dominated NOMCON chooses the X-co
employee over someone else in a contentious position. They are going to be
accused of doing it because they are biased. Or maybe they decide not to
out of concern that they are accused of bias.

A preponderance of members from one company creates a no win position for
all the NOMCON members and it should therefore be avoided.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 30 Jun 2020 17:08:48 +0000

I'm finally getting out from underneath all the emails in my inbox (I won't bore you with all the excitement of my past week), and thought I'd provide just a little additional info on a couple of items.
I was provided the list of IETF 107 and 108 "people who checked the volunteer for NomCom box" last Wednesday, and had no time to process them till Sunday. The IETF 107 list I was given didn't include affiliation. Because BCP 10 has a very strict schedule to maintain, and I had initially created for myself a schedule that had me sending out the preliminary list of volunteers this past Friday, I decided to send out a list (on Sunday) that I was confident would need to be modified over the next few days. I'll ask forgiveness now 😉.

The reason I noted the "107" people was I didn't have time to confirm with these people whether they were still interested in volunteering. Much has happened since they checked that box. I've asked for all those people (24 people) to please send me a positive confirmation of interest. According to attendance eligibility requirements (using the nomcom.py tool) all the people in that list are attendance-eligible. I assumed that anyone who sent me an email over the past month or checked the box on 108 registration was still interested, without asking for additional confirmation. If a person was in my "emailed me" list AND (108 or 107) lists, I deleted their 108 and 107 entries and kept the info they emailed me. Similarly, if they were in 108 AND 107, I deleted their 107 entry. So the only people with "107" next to them are ones who checked the box in 107 but did not email me AND DID NOT (register for 108 by the Wednesday deadline AND check the NomCom volunteer box).

Normally, I could get affiliation from the Attendees listed for an IETF meeting on its past Proceedings page. Unfortunately, no Attendees link exists for IETF 107 on its Proceedings page. I've asked the Secretariat to provide me with the affiliation info for the list of 107 people they gave me. But interested "107" people are also welcome to provide me directly with affiliation (and some have). I did check (on Sunday) the 107 entries against the 108 registered participants -- any affiliations listed for 107 people came from a 108 registration. If they registered for 108 after Wednesday and checked the box in 108, I wouldn't know, since Wednesday was the volunteer cut-off.

I hope this is clear? 
Thx,
Barbara

> From: ietf <[email-masked]> On Behalf Of Michael StJohns
> Sent: Tuesday, June 30, 2020 10:44 AM
> To: Toerless Eckert <[email-masked]>
> Cc: [email-masked]
> >> where I ended up merging things:  Anything with "Huawei" in the name
> was Huawei.
> >> (Huawei, Huawei Technologies, Huawei Tech Dusseldorf, Beijing Huawei,
> >> Ditto for Google (Chrome, Jigsaw). The remainder of the list were
> >> slight variants (Cisco vs Cisco Systems, etc) and easy to merge.  I
> >> wasn't sure of whether Futurewei should be grouped with Huawei, so I
> >> did the calculations both ways.
> >>
> >> Ericsson - 6 -   3.8% of the pool 37.5/26.9 Futurewei - 10 - 6.3% of
> >> pool 31.5/51.5 Google - 4  2.5% 34.9/14.6 Huawei - 28 17.5%  3.2/95.9
> >> Juniper - 10  6.3% 31.5/51.5 Mozilla - 3 1.9%, 30.9, 9.1 Nokia - 3
> >> 1.9%  30.9/9.1 ZTE - 6 - 3.8% 37.5/26.9
> >>
> >> 95.9 - 3.2)  .6% chance of having no volunteers selected, a 3.2%
> >> chance of having 1, and a 95.9% chance of having 2.   If Futurewei
> >> and Huawei are counted as separate companies, together they have
> >> about a 50% chance of having 4 members between them (estimate rather
> than doing the calculations).
> >>
> > Whats the probability of a single individual from  e.g:
> > Huawei+Futurewei to be elected to NomCom. vs. the probability of an
> > individual from a company where he/she is the only nomcom volunteer ?
> 
> The raw probabilities are the same.  E.g. Ptot ~=  1 - ((1-1/160)^10) or about
> 6% chance for any individual in the pool being selected.  Its approximate
> because the pool actually shrinks with each pick changing the probability
> upwards for each subsequent pick.  For Huawei+Futurewei, let's assume
> they end up with two members (as that's a near 100% chance).  The Ptot for
> each would be ~= 1-((1-1/38)^2) or about 5%.  Not really a great
> difference.  (It's actually %5.19% * 95.6% or 4.96% plus ..6% * 2.6% - call it
> 5%).
> 
> (1-Psel)^N) and subtract that from 1 to get the probability of being selected
> at least once.
> 
> 
> >
> > known company affiliations. Whats the process ? Is NomCom chair having
> > to try to figure that out, best effort ?
> > Obvious, and this is the root of what i think is our problem dealing
> > with candidate bias: There are no simple critera to demonstrate other
> > than company affiliation clusters of bias that would imact the quality
> > of the nomcom results. So big companies are the easy pinata.
> >
> > Cheers
> >      Toerless
> >
> >> Mike
> >>
> >>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 30 Jun 2020 20:59:01 +0300

> On 30 Jun 2020, at 18:03, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
>> On 30 Jun 2020, at 15:02, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Checking a box is easy, so I did.  Declaring that I work for Dell Technologies is also easy enough and public information enough, so I typed that in to the same form with the checkbox.

Submitting a legal document disclosing all potential COI is more difficult. It’s probably better that I consult with the company lawyer first.  The company lawyer would advise me to forget it. So I wouldn’t volunteer.

Now that’s just me, but I don’t think my position is all that unique.

Yoav

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jun 2020 16:17:11 -0400

--On Tuesday, June 30, 2020 20:59 +0300 Yoav Nir
<[email-masked]> wrote:

> Submitting a legal document disclosing all potential COI is
> more difficult. It's probably better that I consult with the
> company lawyer first.  The company lawyer would advise me to
> forget it. So I wouldn't volunteer.
> 
> Now that's just me, but I don't think my position is all
> that unique.

No, it is not that unique.   Nor, I think, is someone who is
independent but has multiple consulting clients and/or Board
affiliations.  Hypothetically, none of them amount to more than
10%-20% of time and several have absolutely nothing to do with
anything the IETF is working on or likely to be working on
(e.g., the relationships are to real estate investments, local
small-town politics, support for litigation in which the IETF is
not potentially involved in any way, or even user interface or
customer support issues that the IETF has several times declined
to get anywhere near).  And, again hypothetically, some of those
unrelated activities come with non-disclosure agreements about
the details of the work or who it is for.  I ran across an
article recently in which a condition for inheritance and
continuing involvement with and support from a family business
was a great deal of privacy for the family to the extent of
photographs -- nothing to do with the IETF, but possibly
instructive.

The bottom line is that, while it is really easy to make simple
(and, I think, somewhat self-righteous) statements to the effect
that no one should be on the nomcom or participating in the
leadership who is not willing or able to make all of their
involvements and commitments public (or even to trust the IETF
leadership with all of that information), the result would be a
reduction in the diversity of views and perspectives represented
in the IETF.  Possibly we could make more sophisticated rules
but, especially given the discussions of the last few months,
I'm skeptical about it. 

And, in that regard, the (admittedly rather simplistic) "no more
than two actually on the Nomcom from one company" rule is
attractive in two ways, the need to take a conservative view of
relationships like subsidiaries and significant ownership
notwithstanding.  One is that it provides the IETF some
protection against a hypothetical company (or corporate culture)
that would encourage or reward people for getting on the Nomcom,
or participating in particular decisions one there, for reasons
we might consider nefarious. The other is that, even if the
reasons there are many volunteers from one company and/or many
of its (or its subsidiaries, etc.) in the leadership and the
reason for that is that the organizational culture includes
public-spirited participation (with no company involvement in
actual decision-making), it looks bad to outsiders trying to
examine the IETF and asking questions about who is in control.
I don't believe that the two person rule provides enough
protection against either situation, but it is lots better than
nothing and I despair of our being able to do significantly
better without side effects that are worse.

    john

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 30 Jun 2020 22:47:59 +0200

On Tue, Jun 30, 2020 at 04:17:11PM -0400, John C Klensin wrote:
> notwithstanding.

>  One is that it provides the IETF some

Uhmmm... is that big evil company called IETF ? Because i think we here
all do encourage each other to volunteer for NomCom. And before
corona there was also a nice dinner reward included from IETF.

> we might consider nefarious.

IMHO the main reason why members of one company rightfully often
promote job candidates from the same company is just a sepcial case
of more likely knowing and having worked with that person and/or
being able to better inquire about that persons suitability for
the job. The same though is true for NomCom members working
for a tiny company but being involved with a larger loyalty
perimeter of people they worked with. Only that that second case
is not discriminated against by NomCom rules.

And i think we already start being unhappy about NomCom members
way short of nefarious. Simple "lazy" "i have no ideas about
what is important in a person, i will just vote for the guy
from the same company as myself" is not fitting to the job given.
But again: this is not limited to being in the same company.

> The other is that, even if the

Yeah, well, if IETF would want to live up to its ideal
instead of (as you said) making the rules just "look good",
then even individuals working for large companies would be
given the benefit of the doubt as participating as individuals
whereever it counts.

> better without side effects that are worse.

I like the idea of examining what would happen if we limited
per-country NomCom membership to two. How would that
decrease diversity ?

Cheers
    Toerless

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 30 Jun 2020 18:48:32 -0400

The concept of satisficing is useful.

There are many cases where a perfect control of a risk is
counter-productive. The costs are greater than the rewards. The probability
of a conflict is not very large to start with. The costs Yoav and others
point to are real.

At the end of the day, the great defense against a hostile takeover of the
IETF does not lie in organizational controls. The defense is that nobody is
actually in charge of the Internet, not even us. We can publish an RFC
mandating lawful intercept of every communication but that would not make
it happen.

On Tue, Jun 30, 2020 at 2:00 PM Yoav Nir <[email-masked]> wrote:

>    - “This" here is the use of employment as a poor approximation for
>    what we should have which is a conflict of interest declaration.
>
>
> I think that requiring a COI disclosure for all potential Nomcom members
> will shrink the pool.  You can’t consider COI without looking at other
> factors.
>
>
> If there is a COI and this is more subtle than just who you are full time
> employed by, we should not take this into account?
>
>
> Checking a box is easy, so I did.  Declaring that I work for Dell
> Technologies is also easy enough and public information enough, so I typed
> that in to the same form with the checkbox.
>
> Submitting a legal document disclosing all potential COI is more
> difficult. It’s probably better that I consult with the company lawyer
> first.  The company lawyer would advise me to forget it. So I wouldn’t
> volunteer.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Jul 2020 14:58:31 +1200

The whole business of NomCom eligibility is based on the assumption that
the list of eligible people can be generated automatically from objective
date. Anything that requires human interpretation is simply out of the
question. It doesn't scale. Even human interpretation of affiliation seems
like a burden on the NomCom chair, but would be a bit hard to automate.
Calling for human interpretation of CoI declarations is unreasonable,
as far as I can see, and exposes the NomCom chair to challenge.

Updating the objective eligibility criteria has its own list
([email-masked]).

Regards
   Brian

On 01-Jul-20 01:06, Joel Halpern wrote:
> .