RFC 6730

Requirements for IETF Nominations Committee Tools

📅 published September 2012, from ietf

RFC 6730: Requirements for IETF Nominations Committee Tools ✨

Okay bestie, let's get into it 💖 This is RFC 6730, and it's Informational, not a Standards Track spec, so it's a "here's what we need" doc rather than a rulebook. It was written by S. Krishnan and J. Halpern from Ericsson and published in September 2012 (ISSN 2070-1721). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🌸

Internet Engineering Task Force (IETF)                       S. Krishnan
Request for Comments: 6730                                    J. Halpern
Category: Informational                                         Ericsson
ISSN: 2070-1721                                           September 2012


           Requirements for IETF Nominations Committee Tools

Abstract

This doc lays out the requirements for a set of tools that the IETF Nominations Committee (NomCom) can use 🧚

Status of This Memo 📋

Quick reality check: this is NOT an Internet Standards Track spec. It's published just for info.

It's still a real IETF product though 💅 It reflects what the IETF community agrees on, it got public review, and the IESG approved it for publication. Just know that not every IESG-approved doc is up for any level of Internet Standard. For the details, see Section 2 of RFC 5741.

If you want the current status, errata, or a place to leave feedback, check http://www.rfc-editor.org/info/rfc6730.

Copyright (c) 2012 IETF Trust and the document authors. All rights reserved.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood when it was published. Please actually read these, because they spell out your rights and restrictions 🥹 Any 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, same as the Simplified BSD License says.

Table of Contents 🗂️

1. Introduction ....................................................2
   1.1. Conventions Used in This Document ..........................2
2. Meta Requirement ................................................2
3. Authentication ..................................................3
4. Security and Access Control .....................................3
5. Nominations .....................................................4
6. Accepting and Declining Nominations .............................5
7. Questionnaires ..................................................6
8. Feedback Collection .............................................7
9. Security Considerations .........................................8
10. Acknowledgements ...............................................8
12. Normative References ...........................................8
Appendix A. Example for Key Generation .............................9

1. Introduction ✨

The IETF Nominations Committee (NomCom) is the group that picks candidates for open IESG, IAB, and IAOC seats, following the process in [RFC3777]. The NomCom needs tools to help it run efficiently, so this doc sets out the requirements for one 🎀

1.1. Conventions Used in This Document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Meta Requirement 🌈

There's already a tool that supports NomCom work. The requirements in this doc are mostly enhancements or behaviour changes to that existing tool. Unless it says otherwise, every current function of the NomCom tool still needs to work in the new one too 💜

  • META-001: The tool MUST provide all the functionality that is provided by the current NomCom tool, except in cases where a requirement specified in this document overrides a current behavior. The current NomCom tool can be found at the following URLs: https://www.ietf.org/group/nomcom/2012/private/ displays the NomCom private parts of the tool (Private NomCom tool), and https://www.ietf.org/group/nomcom/2012/ displays the community member accessible parts of the tool (Public NomCom tool).

3. Authentication 🔐

Every single access to NomCom tools needs to be authenticated. Different users get different privileges depending on their role. The tool needs to support at least three access levels: community member, NomCom member, and NomCom chair. The IETF Secretariat staff set up these levels. Fun fact: the Secretariat staff have no access to the tool itself. They run the server it lives on, so they're the ones who set up the access control list 👀

Community member access applies to the Public NomCom tool. NomCom member access and NomCom chair access apply to the Private NomCom tool. NomCom members can use the Public NomCom tool's interfaces in the community member role. The NomCom chair's authentication works on the private webpage the same way a NomCom member's does, but the chair can also update the information on both webpages (meaning what shows up in the various forms, the templates for the automatic emails, and so on) 🦋

  • AUTH-001: The tool MUST allow members of the community to log in with their existing datatracker.ietf.org credentials.
  • AUTH-002: The tool MUST allow members of the community to create a new login using the datatracker.ietf.org login system.
  • AUTH-003: The tool MUST allow the secretariat to enter the email address of the NomCom chair and to enter a list of email addresses of the NomCom members. The logins associated with these email addresses MUST be accorded the respective roles.

4. Security and Access Control 🔒

Everything sent between the community and the NomCom, and among NomCom members, needs to be stored in encrypted form. Only NomCom members can access this info 🫶

  • SEC-001: The security procedures for the tool MUST be structured so that even system administrators do not have routine or accidental visibility to any data accumulated by the tool. This data includes all confidential feedback and discussions.
  • SEC-002: The tool MUST allow the NomCom chair to input a public key ("NomCom public key"). This key is generated by the NomCom chair independent of the tool, for example, using the procedure described in Appendix A.
  • SEC-003: All communication sent to the NomCom mailing list MUST be encrypted with the NomCom public key before being committed to persistent storage.
  • SEC-004: All community feedback entered using the NomCom tool MUST be encrypted with the NomCom public key before being committed to persistent storage.
  • SEC-005: After logging in, the tool MUST allow the NomCom members to input a private key ("NomCom private key") that corresponds to the NomCom public key. This key will be used to decrypt the feedback/communications that the member is trying to access. Once entered, this key MUST be available for the entire length of the session until the user logs out. This private key MUST NOT be stored in plaintext form into persistent storage at any point of time.
  • SEC-006: The tool MUST provide a mechanism for the NomCom Chair to destroy all data collected by the NomCom at the end of the NomCom's term. Since the NomCom's term overlaps with that of the next year's NomCom, the tool MUST ensure that data collected by the next year's NomCom is not affected by this deletion.
Heads up: SEC-005 is the big one. The private key can live in the session, but it must never end up sitting in plaintext in persistent storage. Not even for a second 😭

5. Nominations 🎉

Once the NomCom is formed, the NomCom chair puts out a call for nominations for the open positions. Nominees come into the system in two main ways. The most common way is that community members enter nominations directly. The second way is that NomCom members enter the nominees. The big difference is that NomCom members can enter nominations that came from other community members. Either way, the tool needs an email address for the nominee. Also, NomCom members usually use the Public NomCom tool, not the Private one, to enter their personal nominations and comments 💅

  • NOM-001: The tool MUST allow members of the community to enter nominations into the Public NomCom tool.
  • NOM-002: The tool MUST allow members of the NomCom to enter nominations into the Private NomCom tool. The tool MUST allow the NomCom member to optionally enter information about the originator of the nomination. The tool MUST record the identity of the originator (if known) of the nomination for audit purposes. Note that anonymous nominations are allowed; thus, the actual identity of an originator may not always be entered into the tool.
  • NOM-003: The tool MUST allow the NomCom chair to specify information that is required for the nominations. This information will be entered by the NomCom chair as freeform text and will be presented to the individual performing the nomination.
  • NOM-004: The tool MUST email the nominee after the nomination and mention the position(s) that they have been nominated for. This email MUST NOT disclose to the nominee the identity of the person who performed the nomination.
  • NOM-005: The tool MUST allow the content of this email to be customized by the NomCom chair.
  • NOM-006: The tool MUST automatically attach the questionnaires for the positions for which the nominee has been nominated to this email.
  • NOM-007: The tool MUST be able to identify duplicate nominations of the same person with the same email address and consolidate them to point to the same nominee.
  • NOM-008: In case the same person has been nominated multiple times using different email addresses, the tool MUST allow the NomCom chair to mark duplicate nominations of the same person and consolidate them to point to the same nominee.
  • NOM-009: The tool MUST allow a communication email address for a nominee to be set to one different than the email address with which they were nominated.
  • NOM-010: The tool MUST be able to use the datatracker address book system as the basis for requirements NOM-007, NOM-008, and NOM-009 but MUST allow the NomCom chair to perform manual overrides.
  • NOM-011: The tool MUST keep track of the accept and decline status for the nominees.

6. Accepting and Declining Nominations ✨

Once the nomination mail lands, nominees usually reply to say whether they're in 🙌 or whether they're out 💅.

  • AD-001: The tool MUST allow nominees to indicate whether they are accepting or declining their nomination. This is preferably done by providing distinct hyperlinks in the email that the nominees receive. 🔗
  • AD-002: The tool MUST allow the NomCom chair to select specific email responses from the nominees and flag them as having been accepted or declined. 🏷️
  • AD-003: The tool MUST allow the NomCom chair to manually flag nominees as having accepted or declined the nomination without the need for any nominee action. 🫶
  • AD-004: The tool MUST allow NomCom members to view the list of all nominees along with their accept or decline status. 👀
  • AD-005: The tool MUST allow NomCom members to view reports of the accept or decline status both per nominee as well as per open position. 📊
  • AD-006: The tool MUST be configurable to send reminder mails to all nominees who have not responded, either on specified dates or at specified intervals. The contents of the reminder mails MUST be customizable by the NomCom chair. ⏰
  • AD-007: The tool MUST be able to generate a summary report containing statistics (total/accept/decline/no response) concerning nominations by position. 📈

7. Questionnaires 📝

Nominees fill in a questionnaire for each position they accept a nomination for. The completed questionnaire is sent in by email to the NomCom mailing list. If a person has been nominated for multiple positions, they may elect to send in a combined questionnaire for a subset (or all) of the positions (QR-002) or fill in one questionnaire per open position (QR-006). It's giving organized 🗂️

  • QR-001: The tool MUST allow the NomCom chair to enter a different questionnaire for each open position. 🎀
  • QR-002: The tool MUST allow the NomCom chair to point to email responses from the nominees and flag them as questionnaires. 🚩
  • QR-003: The tool MUST allow NomCom members to directly access questionnaires completed by nominees. 🔍
  • QR-004: The tool MUST keep track of the questionnaire receipt status for the nominees. The completed questionnaires are received as emails to the NomCom mailing list. 📬
  • QR-005: Like all other correspondence on the NomCom mailing list, the completed questionnaires MUST be encrypted by the NomCom public key before being stored. 🔐
  • QR-006: The NomCom chair MUST be able to flag an email as the completed questionnaire for a nominee corresponding to a specific open position. 💜
  • QR-007: Once flagged, the questionnaire provided by the nominee for a specific position MUST be directly accessible without needing to look through all other feedback received for that nominee. ✨

8. Feedback Collection 💬

Community feedback is very important in the NomCom process, bestie 🫶. Community feedback about nominees is the primary mechanism by which NomCom members evaluate nominees. Main character energy for the whole process 👑

  • FB-001: The tool MUST allow members of the community to enter feedback about any of the accepting nominees into the Public NomCom tool. 🌸
  • FB-002: The tool MUST allow members of the NomCom to enter feedback about any of the accepting nominees into the Private NomCom tool. The tool MUST allow the NomCom member to optionally enter information about the originator of the feedback. Note that, as in NOM-002, anonymous feedback is allowed; thus, the actual identity of an originator may not always be entered into the tool. 🙈
  • FB-003: The tool MUST allow NomCom members to view feedback entered for each nominee. The identity of the submitter should also be visible with the feedback, unless the submitter wishes to be anonymous. 👀
  • FB-004: The NomCom members MUST be able to enter their interview comments as feedback for the nominee being interviewed. 🎤
  • FB-005: All email received on the NomCom mailing list MUST be archived. This includes all correspondence among the NomCom members, feedback received over email, as well as completed questionnaires. 🗄️
  • FB-006: The tool MUST allow the NomCom chair to manually copy any of the archived mails into the feedback section of one or more nominees for one or more open positions. This is required because a single email may contain feedback concerning more than one nominee or more than one open position. 🧩

9. Security Considerations 🔐

🚨 This part is seriously important, so read it twice. Security is not optional, it's the whole vibe.

The tool must authenticate all users and must allow logins to be classified into three roles: NomCom chair, NomCom member, and community member. All communications to/from the NomCom and among members of the NomCom must be stored in an encrypted form. No exceptions, no cap 🔒💀

10. Acknowledgements 🫶

The authors would like to thank Russ Housley, Barry Leiba, Brian Haberman, Phillip Hallam-Baker, Stewart Bryant, Adrian Farrel, Stephen Farrell, Martin Stiemerling, Benoit Claise, Sean Turner, Ralph Droms, Mary Barnes, Subramanian Moonesamy, and Menachem Dodge for their valuable comments to improve this document. Literal legends 🌟

12. Normative References 📚

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3777] Galvin, J., Ed., "IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees", BCP 10, RFC 3777, June 2004.

Appendix A. Example for Key Generation 🔑

The NomCom chair generates a public/private key pair to be used to encrypt NomCom correspondence and feedback. As an example, the NomCom chair can use openssl to generate the key pair using the following commands:

First, the config file for openssl needs to be created with the following contents (example for the 2012-2013 NomCom).

[ req ]
distinguished_name = req_distinguished_name
string_mask        = utf8only
x509_extensions    = ss_v3_ca

[ req_distinguished_name ]
commonName           = Common Name (e.g., NomComYY)
commonName_default  = NomCom12

[ ss_v3_ca ]

subjectKeyIdentifier = hash
keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment
basicConstraints = critical, CA:true
subjectAltName = email:nomcom12@ietf.org
extendedKeyUsage= emailProtection

# modify the email address to match the year.

Figure 1: nomcom-config.cnf

Then the following command needs to be issued in order to generate the private key and the certificate.

$ openssl req -config nomcom-config.cnf -x509 -new -newkey rsa:2048
-sha256 -days 730 -nodes -keyout privateKey.pem -out nomcom12.cert

The certificate can then be provided to the tool in order to extract the public key. 🧚

Authors' Addresses 🦋

Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada

EMail: suresh.krishnan@ericsson.com

Joel Halpern Ericsson

EMail: joel.halpern@ericsson.com

📦 where this page comes from