GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6730

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 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; see Section 2 of RFC 5741.
 Information about the current status of this document, any
 errata, and how to provide feedback on it may be obtained at
 http://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 to BCP 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 2012

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 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) and
    https://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 2012

3. 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 in Appendix 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 2012

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.

Krishnan & Halpern Informational [Page 9] RFC 6730 NomCom Tools September 2012

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

Krishnan & Halpern Informational [Page 10]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6730.txt · Last modified: 2012/09/26 03:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki