Nominating Committee Eligibility
draft-ietf-elegy-rfc8989bis-05

# Internet AD comments for draft-ietf-elegy-rfc8989bis-04
CC @ekline

## Nits

### S4.2

* "Note that the counting remote participation" ->
  "Note that the counting of remote participation" or perhaps
  "Note that counting remote participation"

Thank you for the work on this document.

Many thanks to Scott Hollenbeck for his ART ART Review: https://mailarchive.ietf.org/arch/msg/art/wPl_szdPTb1WBf3Ov_IebyH4oUk/ and to the author for addressing Scott's comments.

Thanks to Scott Hollenbeck for his ARTART review.

From Section 4.1.1:

"A sudden surge in the number of volunteers, particularly of people that no one recognizes as a part of the community, is an early-warning sign for the community, leadership and the IETF Secretariat to further investigate. The community should monitor and assess a sudden increase in the number of online registration fee waivers awarded [...]"

This seems vague to me.  It's curious that this is non-specific about what is meant by "leadership", for example.  Is the IESG tasked with this monitoring?  Is it ISOC, who appoints the NomCom Chair?  The tools team?  Is the community at large supposed to remember to do it?  What are the limits of such an investigation, or of the corrections it may impose?

From Section 4.1.3:

"In the event of abuse of process, the leadership would then have months to adjust policy in response before the NomCom cycle begins."

That's presuming it notices in time.  How late is too late?

I wonder if it should be made more explicit about exactly who should be checking for what, and when.

Thank you to Vincent Roca for the SECDIR review.

** Section 1.  Editorial.

OLD
   The actual NomCom is selected at random
   from the pool of eligible volunteers.

NEW
Appointment to the NomCom is selected at random from the pool of eligible volunteers.

** Section 1.

(2) author or editor of an IETF Stream RFC in the past
   five years, including internet-drafts in the RFC Editor queue

Section 4 of RFC8989 actually says “the person has been a listed author or editor (on the front page) of at least two IETF Stream RFCs within the last 5 years prior to the day the call for NomCom volunteers is sent to the community.”  The text in this document suggests that a single RFC constitutes eligibility, but RFC8989 says it is at least two.
** Section 2.  Considering mentioning that attending an the IETF F2F meeting used to be considered an essential part of participation in the community
** Section 2.
   Two days of travel and an attendance fee is a relatively large
   expenditure of time and money

I don’t understand the basis of the “two days of travel” metric.
** Section 2.
   However, attitudes to business travel evolve, and remote meeting
   technology continues to improve, to the extent that many longstanding
   community members choose to participate remotely.  

Do we have conclusive data on _many_ “longstanding members now participating remotely”?  Can we cite this and define what is “many” and “longstanding”?
** Section 2.

   Further, the NomCom has
   completed two cycles using entirely online tools.

-- What is meant by “entirely online tools”?
-- Please cite the NomCom years in question.
** Section 2.
   Finally, overly restrictive criteria work against getting a broad
   talent pool.

Recommend against the phrase “talent pool”.  To me it suggestions some set of skill or qualifications, which is not the diversity which the current NomCom process is engineering.
** Section 3.
In-person
   attendance is as determined by the record keeping of the Secretariat.    Online attendance is based on being a registered person who logged in
   for at least one session of an IETF meeting.


-- Section 1 has already said the in-person criteria amounts to “... the volunteer picked up their registration badge at an in-person meeting”, why not explicitly say that? 

-- Per the online attendance, is that also “determined by the records keeping of the Secretariat”, as in, they get the logs from Meetecho?
** Section 4.1.1.
   A sudden surge in the number of volunteers, particularly of people
   that no one recognizes as a part of the community, is an early-
   warning sign for the community, leadership and the IETF Secretariat
   to further investigate.

What is the recourse of this behavior is discovered?

"The two-per-organization limit in [RFC8713] complicates such an attack.  To circumvent it, an organization must either [...] (3) propose candidates with false affiliations."

It's not really clear to me what a "false affiliation" actually is -- in some other organizations, where voting is a thing, it is common for there to be lots of one or two person consulting companies. These consultants all have different affiliations, they just *happen* to have contracts with the same larger organization, and also just *happen* to all vote in the same way... Would these be false affiliations? Note that I don't really view this as major issue -- if we end up in a scenario where people are gaming this, then we've already lost.

As a nit: 'either' is generally used with 2 options.

Thanks to Dan Romascanu for the OpsDir review.

Clearing my discuss following conversations with Martin

Hi Martin,

Thanks for documenting this - it needed to be done.  One comment/concern inline below ...

(1) p 5, sec 4.1.3.  One Year of Participation

   Attendance at three meetings requires at least eight months of
   waiting.  Given the volume of volunteers necessary to capture the
   process, an attack requires a surge in attendees over the course of a
   year.  Such a surge might trigger a community challenge to the list
   of eligible volunteers, and/or a leadership investigation to detect
   suspicious behavior (e.g., logging in to a single session and then
   immediately logging out).  In the event of abuse of process, the
   leadership would then have months to adjust policy in response before
   the NomCom cycle begins.

For section 4, I think that it would be helpful to identify which leadership body is responsible for adjusting policy, and also have clear text that empowers the leadership body to act to mitigate any abuse of the NomCom selection process, if needed.  I'm presuming this the leadership body here would be the IESG, backed by the IAB (in that any IESG decision is appealable to the IAB).  The reason that I believe that it is helpful to indicate the the IESG is obliged to act is because it may be impossible for the IESG to adjust policy through the normal IETF consensus process (although they should try) within the required timeframe - a sustained attack on the IETF processes would likely slow, or make it impossible, for an AD to call consensus, and if under attack, any decision would likely be appealed regardless, further slowing the process.  In this scenario, I think that it might be necessary for the IESG to act in the best interests of the IETF, but outside of the formal consensus process (e.g., perhaps via an IESG statement), which of course also also be subject to the normal appeals process if needed.

Regards,
Rob