Ballot for draft-ietf-elegy-rfc8989bis
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Thanks for the solid work on this document. One comment that I'd like to discuss, I believe the reference to ietf-shmoo-remote-fee should be normative, since this document makes reference to a long term commitment to free remote participation, and to my knowledge absent the shmoo-remote-fee document that isn't a commitment that is codified.
The Shepherd writeup indicates that this document will become part of BCP10. Good. What about rfc8788? It only applied to the 2020-2021 nomcom and is also part of BCP 10. Therefore, this document should also Obsolete rfc8788 "to make it clear that that document has been superseded" (the same reason that it Obsoletes RFC8989).
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. This 4.1 subsection is the only one that doesn't list the counter-move. Maybe add to say something like: to further investigate and where needed take action as defined in RFC 8713 Section 3.7.3 to invalidate such candidates. Section 4.1.3 Why is the counter-move here "to adjust policy in response" instead of simply rejecting those candidates as per RFC 8713 Section 3.7.3 ?
Thank you Martin for the work done in the document. I strongly support it, but Murray's comments should be taken into account. Regards -éric
# 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"
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.
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
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.