Movatterモバイル変換

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

INFORMATIONAL

Internet Engineering Task Force (IETF) S. KrishnanRequest for Comments: 6730 J. HalpernCategory: Informational EricssonISSN: 2070-1721 September 2012Requirements for IETF Nominations Committee ToolsAbstract This document defines the requirements for a set of tools for use by the IETF Nominations Committee.Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; seeSection 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained athttp://www.rfc-editor.org/info/rfc6730.Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject toBCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.Krishnan & Halpern Informational [Page 1]

RFC 6730 NomCom Tools September 2012Table of Contents1. Introduction ....................................................21.1. Conventions Used in This Document ..........................22. Meta Requirement ................................................23. Authentication ..................................................34. Security and Access Control .....................................35. Nominations .....................................................46. Accepting and Declining Nominations .............................57. Questionnaires ..................................................68. Feedback Collection .............................................79. Security Considerations .........................................810. Acknowledgements ...............................................812. Normative References ...........................................8Appendix A. Example for Key Generation .............................91. Introduction The IETF Nominations Committee (NomCom) is a body that selects candidates for open IESG, IAB, and IAOC positions following the process outlined in [RFC3777]. There is a need for a set of tools to aid the NomCom in efficient operation. This document presents a set of requirements for such a tool.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 is an existing tool for supporting NomCom work. The set of requirements specified in this document are mainly enhancement requirements or behavioral changes to the existing tool. Unless otherwise stated, all of the current functions of the existing NomCom tool need to be supported in the new tool as well. o 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) andhttps://www.ietf.org/group/nomcom/2012/ displays the community member accessible parts of the tool (Public NomCom tool).Krishnan & Halpern Informational [Page 2]

RFC 6730                      NomCom Tools                September 20123.  Authentication   All access to NomCom tools needs to be authenticated.  Users of the   tools have different privileges based on their role.  The tool needs   to support at least three levels of access: community member, NomCom   member, and NomCom chair.  The levels of access are set up by the   staff of the IETF Secretariat.  It is to be noted that the   Secretariat staff do not have any access to the tool.  They are   responsible for administering the server on which the tool runs;   hence, they set up the access control list for the tool.   Community member access is applicable to the Public NomCom tool.  The   NomCom member access and the NomCom chair access are applicable to   the Private NomCom tool.  NomCom members can use the interfaces on   the Public NomCom tool in the community member role.  The NomCom   chair access authentication applies to the private webpage in the   same fashion as a NomCom member, with the additional ability to   update the information on both webpages (i.e., what is visible in the   various forms, the templates for the automatic emails, etc.).   o  AUTH-001: The tool MUST allow members of the community to log in      with their existing datatracker.ietf.org credentials.   o  AUTH-002: The tool MUST allow members of the community to create a      new login using the datatracker.ietf.org login system.   o  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   All communication between the community and the NomCom and amongst   the members of the NomCom needs to be stored in an encrypted form.   This information can only be accessed by members of the NomCom.   o  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.   o  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 inAppendix A.Krishnan & Halpern            Informational                     [Page 3]

RFC 6730                      NomCom Tools                September 2012   o  SEC-003: All communication sent to the NomCom mailing list MUST be      encrypted with the NomCom public key before being committed to      persistent storage.   o  SEC-004: All community feedback entered using the NomCom tool MUST      be encrypted with the NomCom public key before being committed to      persistent storage.   o  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.   o  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.5.  Nominations   After the NomCom is constituted, the NomCom chair issues a call for   nominations for the open positions.  There are two broad ways in   which nominees are introduced into the system.  The predominant way   is that nominations are entered into the system directly by members   of the community.  The secondary way is that the nominees are entered   in by members of the NomCom.  The main difference is that members of   the NomCom can enter nominations that are originated by other   community members.  In both of the cases, an email address for the   nominee needs to be entered into the tool.  Please note that NomCom   members usually use the Public NomCom tool, not the Private NomCom   tool, to enter their personal nominations and comments.   o  NOM-001: The tool MUST allow members of the community to enter      nominations into the Public NomCom tool.   o  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.Krishnan & Halpern            Informational                     [Page 4]

RFC 6730 NomCom Tools September 2012 o 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. o 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. o NOM-005: The tool MUST allow the content of this email to be customized by the NomCom chair. o NOM-006: The tool MUST automatically attach the questionnaires for the positions for which the nominee has been nominated to this email. o 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. o 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. o 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. o 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. o NOM-011: The tool MUST keep track of the accept and decline status for the nominees.6. Accepting and Declining Nominations After receiving the nomination mail, nominees usually respond to indicate either that they accept the nomination or that they are unwilling to do so. o 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.Krishnan & Halpern Informational [Page 5]

RFC 6730 NomCom Tools September 2012 o 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. o 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. o AD-004: The tool MUST allow NomCom members to view the list of all nominees along with their accept or decline status. o 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. o 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. o 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 for which they accept a nomination. 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). o QR-001: The tool MUST allow the NomCom chair to enter a different questionnaire for each open position. o QR-002: The tool MUST allow the NomCom chair to point to email responses from the nominees and flag them as questionnaires. o QR-003: The tool MUST allow NomCom members to directly access questionnaires completed by nominees. o 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.Krishnan & Halpern Informational [Page 6]

RFC 6730 NomCom Tools September 2012 o 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. o 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. o 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. Community feedback about nominees is the primary mechanism by which NomCom members evaluate nominees. o FB-001: The tool MUST allow members of the community to enter feedback about any of the accepting nominees into the Public NomCom tool. o 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. o 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. o FB-004: The NomCom members MUST be able to enter their interview comments as feedback for the nominee being interviewed. o 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.Krishnan & Halpern Informational [Page 7]

RFC 6730                      NomCom Tools                September 2012   o  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   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.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.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.Krishnan & Halpern            Informational                     [Page 8]

RFC 6730                      NomCom Tools                September 2012Appendix 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_namestring_mask        = utf8onlyx509_extensions    = ss_v3_ca[ req_distinguished_name ]commonName           = Common Name (e.g., NomComYY)commonName_default  = NomCom12[ ss_v3_ca ]subjectKeyIdentifier = hashkeyUsage = critical, digitalSignature, keyEncipherment, dataEnciphermentbasicConstraints = critical, CA:truesubjectAltName = email:nomcom12@ietf.orgextendedKeyUsage= 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.Krishnan & Halpern            Informational                     [Page 9]

RFC 6730                      NomCom Tools                September 2012Authors' 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.comKrishnan & Halpern            Informational                    [Page 10]

[8]ページ先頭