RFC 8788

Eligibility for the 2020-2021 Nominating Committee

📅 published May 2020, from ietf

Eligibility for the 2020-2021 Nominating Committee ✨

Okay bestie, this is RFC 8788 🎀, written by Barry Leiba of FutureWei Technologies and published in May 2020. It's a Best Current Practice (it's BCP 10, the NomCom rules doc, so it's officially part of the BCP series 🧚) with ISSN 2070-1721. Its header doesn't list any RFCs it obsoletes or updates, so nothing gets replaced there. It's a one-time fix for a weird situation, and it says so loudly 📣.

Abstract

The 2020-2021 Nominating Committee (NomCom) has to be formed between the IETF 107 and IETF 108 meetings 🗓️, and nobody was sure who was actually eligible to serve on it. This doc gives a one-time interpretation of the eligibility rules, needed because the in-person IETF 107 meeting got cancelled 😭. It only affects the seating of the 2020-2021 NomCom and any rules or processes about NomCom eligibility before IETF 108. It does not set a precedent for the future 🙅‍♀️.

Status of This Memo

This memo documents an Internet Best Current Practice 💅.

This doc is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on BCPs, check Section 2 of RFC 7841 📚.

Info about the doc's current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc8788 🔗.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved ©️.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read those carefully, because they explain your rights and restrictions for this document 🧾. Code Components pulled out of this doc have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🖤.

Table of Contents

   1.  Introduction
   2.  Background
   3.  Eligibility for the 2020-2021 Nominating Committee
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Author's Address

1. Introduction ✨

So the COVID-19 outbreak got declared a global pandemic [PANDEMIC] 😷, and that led to the in-person IETF 107 meeting getting cancelled [CANCEL107]. It turned into a virtual meeting with a limited agenda and remote participation only [VIRTUAL107] 💻.

The 2020-2021 NomCom has to be formed between IETF 107 and IETF 108 🗓️, and the eligibility question for who can serve on it needed clarifying. The answer is a one-time interpretation of the eligibility rules, for this one exceptional situation 🦋. That interpretation covers the seating of that NomCom and any rules or processes about NomCom eligibility before the scheduled time for IETF 108 💜.

2. Background ✨

Section 4.14 of [RFC8713] (BCP 10) has these eligibility requirements 📋:

Members of the IETF community must have attended at least three of the last five IETF meetings in order to volunteer. The five meetings are the five most recent meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community.

On 13 March 2020, someone posted to the IETF discussion list [SOLICITINPUT] 📬. They suggested two possible interpretations and asked the community for input, including other interpretations if people had them 🙋‍♀️. The discussion over the next two weeks mostly centered around three options 👀:

  1. Don't count IETF 107 at all for NomCom eligibility, since BCP 10 clearly refers to in-person meetings only. Eligibility would then be based on attendance at IETFs 102 through 106 🌸.
  2. Don't make anyone lose eligibility because of IETF 107, but do count someone as having attended 107 if they joined the IETF 107 virtual meeting (signed the electronic blue sheet). People could gain eligibility from IETF 107 but couldn't lose it from it, and eligibility would be based on attendance at IETFs 102 through 107 🌈.
  3. Count virtual attendance at IETF 107 and treat IETF 107 as one of the last five meetings, so NomCom eligibility would be based on attendance at IETFs 103 through 107 💫.

When it came to judging rough consensus, the IESG looked at the arguments and the levels of support for and against each option ⚖️. The arguments were mostly about fairness to newer participants, letting more people into the volunteer pool, and sticking as close as possible to the spirit of the rules in BCP 10, which is the community-consensus basis everything here is built on 🫶.

On 25 March 2020, someone posted to the IETF discussion list [COMMENTDEADLINE] asking for final comments by 30 April 2020 ⏰. This doc records the outcome of that discussion, and the community picked interpretation 1 from above 🎉.

3. Eligibility for the 2020-2021 Nominating Committee 👑

For the 2020-2021 NomCom cycle only, the following text changes the first two paragraphs (quoted above) of Section 4.14 of [RFC8713] (BCP 10) 💅:

Members of the IETF community must have attended at least three of the last five in-person IETF meetings in order to volunteer. The five meetings are the five most recent in-person meetings that ended prior to the date on which the solicitation for NomCom volunteers was submitted for distribution to the IETF community. Because no IETF 107 in-person meeting was held, for the 2020-2021 Nominating Committee, those five meetings are IETFs 102, 103, 104, 105, and 106.

This update is an emergency interpretation of what BCP 10 is trying to do, for this exceptional situation only 🚨. It applies only to the 2020-2021 NomCom, which is expected to be seated before IETF 108, and to any rules or processes about NomCom eligibility before IETF 108. It will explicitly not apply to any future NomCom and does not set a precedent 🙅‍♀️. If future eligibility needs fixing, BCP 10 gets an actual update, because there will be time for proper community work on it (see [ELIGIBILITYDISCUSS]) 🗣️. That future update could change any part of the BCP 10 process, including anything specified in this doc 🔄.

4. IANA Considerations 🧾

This document has no IANA actions.

5. Security Considerations 🔐

This doc is purely procedural, so there are no related security considerations. Nothing to panic about here 🙈.

6. References 📚

6.1. Normative References

  • [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, Confirmation, and Recall Process: Operation of the IETF Nominating and Recall Committees", BCP 10, RFC 8713, DOI 10.17487/RFC8713, February 2020, https://www.rfc-editor.org/info/rfc8713.

6.2. Informative References

Author's Address 🖊️

Barry Leiba FutureWei Technologies

Phone: +1 914 433 2749 Email: barryleiba@computer.org URI: http://internetmessagingtechnology.org/

That's the whole doc, bestie 🌈💖 It's a tiny one-time fix with a big "this is NOT a precedent" energy.

📦 where this page comes from