idnits 2.17.1 draft-krishnan-nomcom-tools-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 23, 2012) is 4288 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3777 (Obsoleted by RFC 7437) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF Nomcom S. Krishnan 3 Internet-Draft J. Halpern 4 Intended status: Informational Ericsson 5 Expires: January 24, 2013 July 23, 2012 7 Requirements for IETF Nominations Committee tools 8 draft-krishnan-nomcom-tools-02 10 Abstract 12 This document defines the requirements for a set of tools for use by 13 the IETF Nominations Committee. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 24, 2013. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Conventions used in this document . . . . . . . . . . . . . 3 51 2. Meta requirement . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Security and Access Control . . . . . . . . . . . . . . . . . . 4 54 5. Nominations . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Acceptances and Declines . . . . . . . . . . . . . . . . . . . 6 56 7. Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8. Feedback Collection . . . . . . . . . . . . . . . . . . . . . . 7 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 59 10. Security considerations . . . . . . . . . . . . . . . . . . . . 8 60 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 61 12. Normative References . . . . . . . . . . . . . . . . . . . . . 8 62 Appendix A. Example for key generation . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 The IETF Nominations Committee (Nomcom) is a body that selects 68 candidates for the open IESG, IAB and IAOC positions following the 69 process outlined in [RFC3777]. There is a need for a set of tools to 70 aid the Nomcom to operate efficiently. This document lays out a set 71 of requirements for such a tool. 73 1.1. Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Meta requirement 81 There is an existing tool for supporting Nomcom work. The set of 82 requirements specified in this document are mainly enhancement 83 requirements or behavior changes to the existing tool. Unless 84 otherwise stated all of the current functions of the existing Nomcom 85 tool need to be supported in the new tool as well. 87 o META-001: The tool MUST provide all the functionality that is 88 provided by the current Nomcom tool except in the cases where one 89 of the requirements specified in this document overrides the 90 current behavior. The current Nomcom tool can be found at the 91 following URLs; https://www.ietf.org/group/nomcom/2012/private/ 92 that displays the Nomcom private parts of the tool (Private Nomcom 93 tool) and https://www.ietf.org/group/nomcom/2012/ that displays 94 the community member accessible parts of the tool (Public Nomcom 95 tool). 97 3. Authentication 99 All access to the Nomcom tools needs to be authenticated. The users 100 of the tools have different privileges based on their role. The tool 101 needs to support at least three levels of access:Community member, 102 Nomcom member, Nomcom chair. The levels of access are setup by the 103 staff of the IETF Secretariat. It is to be noted that the 104 Secretariat staff do not have any access to the tool. They are 105 responsible for administering the server that the tool runs on and 106 hence they setup the access control list for the tool. 108 The Community member access is applicable to the Public Nomcom tool. 109 The Nomcom member and the Nomcom chair access are applicable to the 110 Private Nomcom tool, as Nomcom members can use the interfaces on the 111 Public Nomcom tool in the community member role. The Nomcom chair 112 access authentication applies to the private webpage in the same 113 fashion as a Nomcom member, with the additional ability to update the 114 information on both webpages (i.e., what is visible in the various 115 forms, the templates for the automatic emails, etc.). 117 o AUTH-001: The tool MUST allow the members of the community to 118 login with their existing datatracker.ietf.org credentials. 119 o AUTH-002: The tool MUST allow the members of the community to 120 create a new login using the datatracker.ietf.org login system. 121 o AUTH-003: The tool MUST allow the secretariat to input an email 122 address to be granted the Nomcom chair role and a list of email 123 addresses to be granted the Nomcom member role. 125 4. Security and Access Control 127 All communication between the community and the Nomcom and amongst 128 the members of the Nomcom needs to be stored in an encrypted form. 129 This information can only be accessed by the members of the Nomcom. 131 o SEC-001: The security procedures for the tool MUST be structured 132 so that even system administrators do not have routine or 133 accidental visibility to any data accumulated by the tool. This 134 data includes all confidential feedback and discussions. 135 o SEC-002: The tool MUST allow the Nomcom chair to input a public 136 key ("Nomcom public key"). This key is generated by the Nomcom 137 chair independent of the tool, for example, using the procedure 138 described in Appendix A. 139 o SEC-003: All communication sent to the Nomcom mailing list MUST be 140 encrypted with the Nomcom public key before being committed to 141 persistent storage. 142 o SEC-004: All community feedback entered using the Nomcom tool MUST 143 be encrypted with the Nomcom public key before being committed to 144 persistent storage. 145 o SEC-005: After logging in, the tool MUST allow the Nomcom members 146 to input a private key ("Nomcom private key") that corresponds to 147 the Nomcom public key. This key will be used to decrypt the 148 feedback/communications that the member is trying to access. Once 149 entered, this key MUST be available for the entire length of the 150 session until the user logs out. This private key MUST NOT be 151 stored in plaintext form into persistent storage at any point of 152 time. 153 o SEC-006: The tool MUST provide a mechanism for the Nomcom Chair to 154 destroy all the data collected by the Nomcom at the end of the 155 Nomcom's term. Since the Nomcom's term overlaps with that of the 156 next year's Nomcom, the tool MUST ensure that the data collected 157 by the next year's Nomcom is not affected by this deletion. 159 5. Nominations 161 After the Nomcom is consituted, the Nomcom chair issues a call for 162 nominations for the open positions. There are two broad ways in 163 which nominees are introduced into the system. The predominant way 164 is that the nominations can be entered into the system directly by 165 members of the community. The secondary way is that the nominees are 166 entered in by the members of the Nomcom. The main difference is that 167 members of the Nomcom can enter nominatios that are originated by 168 other community members. In both of the cases an email address for 169 the nominee needs to be entered into the tool. Please note that 170 Nomcom members usually use the Public Nomcom tool, and not the 171 Private Nomcom tool, to enter their personal nominations and 172 comments. 174 o NOM-001: The tool MUST allow the members of the community to enter 175 nominations into the Public Nomcom tool. 176 o NOM-002: The tool MUST allow the members of the Nomcom to enter 177 nominations into the Private Nomcom tool. The tool MUST allow the 178 Nomcom member to optionally enter information about the originator 179 of the nomination. The tool MUST record the identity of the 180 originator (if known) of the nomination for audit purposes. Note 181 that anonymous nominations are allowed, and thus the actual 182 identify of an originator may not always be entered into the tool. 183 o NOM-003: The tool MUST allow the Nomcom chair to specify the 184 information that is required for the nominations. This 185 information will be entered by the Nomcom chair as freeform text, 186 and will be presented to the individual performing the nomination. 187 o NOM-004: The tool MUST email the nominee after the nomination 188 mentioning the position(s) that they have been nominated for. 189 This email MUST NOT disclose to the nominee the identity of the 190 person who performed the nomination. 191 o NOM-005: The tool MUST allow the content of this email to be 192 customized by the Nomcom chair. 193 o NOM-006: The tool MUST automatically attach the questionnaires for 194 the positions for which the nominee has been nominated to this 195 email. 196 o NOM-007: The tool MUST be able to identify duplicate nominations 197 of the same person with the same email address and consolidate 198 them to point to the same nominee. 199 o NOM-008: In case the same person has been nominated multiple times 200 using different email addresses the tool MUST allow the Nomcom 201 chair to mark duplicate nominations of the same person and 202 consolidate them to point to the same nominee. 203 o NOM-009: The tool MUST allow the setting of a communication email 204 address for a nominee that is different than the email address 205 with which they were nominated. 207 o NOM-010: The tool MUST be able to use the datatracker address book 208 system as the basis for requirements NOM-007, NOM-008, and NOM-009 209 but MUST allow the Nomcom chair to perform manual overrides. 210 o NOM-011: The tool MUST keep track of the accept and decline status 211 for the nominees. 213 6. Acceptances and Declines 215 After receiving the nomination mail, the nominees usually respond to 216 indicate either their acceptance of the nomination or their 217 unwillingness to do so. 219 o AD-001: The tool MUST allow the nominees to indicate their 220 acceptance or decline of their nomination. This is preferably 221 done by providing distinct hyperlinks in the email that the 222 nominees receive. 223 o AD-002: The tool MUST allow the Nomcom chair to point to email 224 responses from the nominees and flag them as acceptances or 225 declines. 226 o AD-003: The tool MUST allow the Nomcom chair to manually flag 227 nominees as accepting or declining without the need for any 228 nominee action. 229 o AD-004: The tool MUST allow the Nomcom members to view the list of 230 all nominees along with their acceptance or decline status. 231 o AD-005: The tool MUST allow the Nomcom members to view reports of 232 acceptance or decline status both per nominee as well as per open 233 position. 234 o AD-006: The tool MUST be configurable to send reminder mails to 235 all nominees who have not responded, either on specified dates or 236 at specified intervals. The contents of the reminder mails MUST 237 be customizable by the Nomcom chair. 238 o AD-007: The tool MUST be able to generate a summary report 239 containing statistics (total/accept/decline/no response) 240 concerning nominations by position. 242 7. Questionnaires 244 The nominees fill in a questionnaire for each of the positions for 245 which they accept a nomination. The filled in questionnaire is sent 246 in by email to the Nomcom mailing list. If a person has been 247 nominated for multiple positions they may elect to send in a combined 248 questionnare for a subset (or all) of the positions (QR-002) or fill 249 up one questionnaire per open position (QR-006). 251 o QR-001: The tool MUST allow the Nomcom chair to enter a different 252 questionnaire for each of the open positions. 253 o QR-002: The tool MUST allow the Nomcom chair to point to email 254 responses from the nominees and flag them as questionnaires. 255 o QR-003: The tool MUST allow the Nomcom members to directly access 256 the filled in questionnaires of the nominees. 257 o QR-004: The tool MUST keep track of the questionnaire receipt 258 status for the nominees. The filled in questionnaires are 259 received as emails to the Nomcom mailing list. 260 o QR-005: Like all other correspondance on the Nomcom mailing list, 261 the filled in questionnaires MUST be encrypted by the Nomcom 262 public key before being stored. 263 o QR-006: The Nomcom chair MUST be able to flag an email as the 264 filled in questionnaire for a nominee corresponding to a specific 265 open position. 266 o QR-007: Once flagged, the questionnaire provided by the nominee 267 for a specific position MUST be directly accessible without 268 needing to look through all the other feedback received for that 269 nominee. 271 8. Feedback Collection 273 Community feedback is very important in the Nomcom process. 274 Community feedback about the nominees is the primary mechanism by 275 which the Nomcom members evaluate the nominees. 277 o FB-001: The tool MUST allow the members of the community to enter 278 feedback about any of the accepting nominees into the Public 279 Nomcom tool. 280 o FB-002: The tool MUST allow the members of the Nomcom to enter 281 feedback about any of the accepting nominees into the Private 282 Nomcom tool. The tool MUST allow the Nomcom member to optionally 283 enter information about the originator of the feedback. Note 284 that, as in FB-002, anonymous feedback is allowed, and thus the 285 actual identify of an originator may not always be entered into 286 the tool. 287 o FB-003: The tool MUST allow the Nomcom members to view the 288 feedback entered for each nominee. If the submitter of the 289 feedback did not wish to be anonymous, the identity of the 290 submitter should also be visible along with the feedback. 291 o FB-004: The Nomcom members MUST be able to enter their interview 292 comments as feedback for the nominee being interviewed. 293 o FB-005: All email received on the Nomcom mailing list MUST be 294 archived. This includes all correspondance among the Nomcom 295 members, feedback received over email as well as filled in 296 questionnaires. 298 o FB-006: The tool MUST allow the Nomcom chair to manually copy any 299 of the archived mails into the feedback section of one or more 300 nominees for one or more open positions. This is required because 301 a single email may contain feedback concerning more than one 302 nominee or more than one open position. 304 9. IANA Considerations 306 This document does not require any IANA actions. 308 10. Security considerations 310 The tool must authenticate all users and must allow classifying 311 logins into 3 roles. Nomcom chair, Nomcom member and community 312 member. All communications to/from the Nomcom and among the members 313 of the Nomcom must be stored in an encrypted form. 315 11. Acknowledgements 317 The authors would like to thank Russ Housley, Barry Leiba, Brian 318 Haberman, Phillip Hallam-Baker, Stewart Bryant, Adrian Farrel, 319 Stephen Farrell, Martin Stiemerling, Benoit Claise, Sean Turner, 320 Ralph Droms, Mary Barnes, Subramanian Moonesamy and Menachem Dodge 321 for their valuable comments to improve this document. 323 12. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, March 1997. 328 [RFC3777] Galvin, J., "IAB and IESG Selection, Confirmation, and 329 Recall Process: Operation of the Nominating and Recall 330 Committees", BCP 10, RFC 3777, June 2004. 332 Appendix A. Example for key generation 334 The Nomcom chair generates a public/private key pair to be used to 335 encrypt Nomcom correspondence and feedback. As an example, the 336 Nomcom chair can use openssl to generate the key pair using the 337 following commands: 339 First the config file for openssl needs to be created with the 340 following contents (example for the 2012-2013 Nomcom). 342 [ req ] 343 distinguished_name = req_distinguished_name 344 string_mask = utf8only 345 x509_extensions = ss_v3_ca 347 [ req_distinguished_name ] 348 commonName = Common Name (e.g., NomcomYY) 349 commonName_default = Nomcom12 351 [ ss_v3_ca ] 353 subjectKeyIdentifier = hash 354 keyUsage = critical, digitalSignature, keyEncipherment, dataEncipherment 355 basicConstraints = critical, CA:true 356 subjectAltName = email:nomcom12@ietf.org 357 extendedKeyUsage= emailProtection 359 # modify the email address to match the year. 361 Figure 1: nomcom-config.cnf 363 Then the following command needs to be issued in order to generate 364 the private key and the certificate. 366 $ openssl req -config nomcom-config.cnf -x509 -new -newkey rsa:2048 367 -sha256 -days 730 -nodes -keyout privateKey.pem -out nomcom12.cert 369 The certificate can then be provided to the tool in order to extract 370 the public key. 372 Authors' Addresses 374 Suresh Krishnan 375 Ericsson 376 8400 Blvd Decarie 377 Town of Mount Royal, Quebec 378 Canada 380 Email: suresh.krishnan@ericsson.com 382 Joel Halpern 383 Ericsson 385 Email: joel.halpern@ericsson.com