Requirements for IETF Nominations Committee Tools
draft-krishnan-nomcom-tools-02

[Ballot comment]
Thanks for addressing my Discuss positions and previous Comments.

I have one final nit to point out:

In FB-002:

    that, as in FB-002, anonymous feedback is allowed, and thus the

s/FB-002/NOM-002/

[Ballot comment]
I have moved all of my discuss points to comments on the basis of
my discussion with the Authors and Shepherding AD.

=========

This is basically a sound document, but there are some details that need attention.
Once these are addressed I will be happy to vote yes.

=====

Sec-001 and Sec-005 look the same

=====

This information can only be accessed by the members of the Nomcom.

Does the above mean voting members, voting members + chair.....?

=====

AD-004: The tool MUST allow to view a list of all nominees along
      with their accepance or decline status.

Must allow who?

=====


AD-005: The tool MUST allow the reporting of accepance or decline
      status both per nominee as well as per open position.

Reporting to who?

=====

The nominees fill in a questionnaire for each of the positions for
  which they accept a nomination.

.. and does what with it? Sends an email, posts it on the web site
completes it on the web site?

=====

FB-005: All email received on the Nomcom mailing list MUST be
      archived. 

For what period, and who has access to the archive?

=====
========

AUTH-003: The tool MUST allow the secretariat to input an email
      address to be provided the Nomcom chair role and a list of email
      addresses to be provided the Nomcom member role.

The above requirement does not read correctly - possibly missing some "by"s

=====

The filled in questionnaires are
      received as emails to the Nomcom mailing list.

Surely they are sent as emails

=====

[Ballot comment]
I think it is important to hurry this document through if we are
serious about developing tools to make the work of NomCom less
arduous. But I also think it is important to get the specification
right so that the tools developed do what is required wasting neither
time nor effort. In view of this, I support a number of the existing
Discusses that focus on the precision of the requirements.

---

We should try to learn from the tools database issues that arose in
NomCom 2011. How can we ensure that the feedback that has been entered
remains available to the NomCom and does not have to be reconstructed
or retrieved by special action?

---

Section 8

IIRC the current tools do not allow an individual to revist the feedback
that they have already entered for a candidate. Although it is possible
to request an email copy of the feedback at the time it is entered, it
is not possible to recall the feedback through the web page. Such a
feature would be useful as a reminder before an interview, for
correlation of feedback against multiple candidates, and to allow
updates to feedback as new thoughts arise.

It would be nice to add this feature.

[Ballot discuss]
I see some of these issues have been noted by other ADs.

1. (cleared)

2. What is the difference between requirements SEC-000 and SEC-005;
  what is the "data accumulated by the tool"?

3. FB-001 needs to have a requirement for annoymous feedback, and for
  tracking the submitter of non-anonymous feedback.

4. In FB-006, should that read "copy" rather than "move"?

[Ballot discuss]
I see some of these issues have been noted by other ADs.

1. (cleared)

2. What is the difference between requirements SEC-000 and SEC-005;
  what is the "data accumulated by the tool

3. FB-001 needs to have a requirement for annoymous feedback, and for
  tracking the submitter of non-anonymous feedback.

4. In FB-006, should that read "copy" rather than "move"?

[Ballot discuss]
I see some of these issues have been noted by other ADs.

1. Is there a need for a separate "NomCom Liaison" role?

2. What is the difference between requirements SEC-000 and SEC-005;
  what is the "data accumulated by the tool

3. FB-001 needs to have a requirement for annoymous feedback, and for
  tracking the submitter of non-anonymous feedback.

4. In FB-006, should that read "copy" rather than "move"?

[Ballot comment]
I see some of these comments have been noted by other ADs.

1. In NOM-00[12], what are the "Public Nomcom tool" and the "Private
  Nomcom tool"?

2. In NOM-002, is the "originator of the nomination" the Nomcom member
  who entered the nomination?  Is this information recorded for
  nominations from the public as well?

3. I don't understand AD-002.  Aren't the responses from the nominees
  restricted to "accept" or "decline"?

4. AD-004: "MUST allow to view" seems to be missing a word between
  "allow" and "to".

5. In FB-002, who is "the originator of the feedback"?

6. Section 9 is not written in the form of requirements.  The first
  two sentences seem to be a duplicate of text from section 3 (which
  was also not written in the form of a requirement).

7. What about extensions for secure, audited voting?

[Ballot discuss]
Okay so I know it's just an example in Appendix A, but I bet everybody will use it.  Therefore, we'd better make sure to specify SHA-256 because SHA-1 is the default (more on that in the comments).

Does the key you just made need to be password protected?  The examples don't show it being encrypted and I don't turn PBE on in the one-step command.  If it is supposed to be encrypted let me know and we can tweak the commands.

[Ballot comment]
1) AUTH-002: should you be explicit about it being datatracker.ietf.org identity?  i.e.,:

o  AUTH-002: The tool MUST allow the members of the community to
    create a new datatracker.ietf.org login with an automated system.
    The system MUST verify that e-mail address used for creating the login.

It's not another kind of login is it?

2) AUTH-003: Do certs get made for the nomcom email address and are those email addresses provided certificates to encrypt email?

3) s9: This is about the noncom chair, but shouldn't we also warn that the nomcom chair better keep that private key private!  Shoul

5) A couple on Appendix A

a) openssl will put the generated key in the file with the -out command so I'm not sure why you need "| tee".

b) It'll do it all in one command :) (provided below)

c) We need to specify SHA-256 because SHA-1 is the default :(

d) hate it that we're not following recommendations and including the right bits  in the right places in the certs.  We could use a .cnf file to fix that (one included).

e) Should the lifetime of the cert be 2 years because that's how long the commitment is?

f) not sure why you did the -pubout command (#2) if the tool is just going to extract it.

g) what is this key used for?  Is it just TLS connections or is it also data at rest (answer changes the key usages)?  I assumed it was TLS and data at rest: hence EKU: clientAuth/serverAuth and KU: digitalSignature/keyEncipherment/dataEncipherment.  I omitted keyCertSign and cRLSign bits because we're not generating additional certs.

h) openssl is phasing out genrsa with genpkey so if you're not going to go for the one stop command should probably add:

  openssl genpkey -algorithm RSA -out rsakey2.pem \
          -pkeyopt rsa_keygen_bits:2048


Here's the nomcom-config.cnf file to prompt the chair for the name, put the email in the right place (yes they'll have to set the address), and include the correct extensions (we can debate which ones those are).

*****BEGIN FILE*****
[ req ]
distinguished_name = req_distinguished_name
string_mask        = utf8only
x509_extensions    = ss_v3_ca

[ req_distinguished_name ]
commonName          = Common Name (e.g., NomcomYY)
commonName_deafault  = Nomcom12

[ ss_v3_ca ]

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

# modify the email address to match the year.

*****END FILE*****

One step command:

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

[Ballot comment]
I support this document. However, I have some comments.

Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

- When I read:
  "The users of the tools may have different privileges based on their role. 
  The tool needs to support at least three levels of access:Community
  member, Nomcom member, Nomcom chair.

I don't understand the "may".
If you create different levels, isn't because the different levels "must" have different privileges?
From there, I was wondering: what are the different privileges based on the role?
I was hoping to find a definition of Nomcom member and/or Nomcom chair in one of the nomcom RFCs (RFC3777, RFC5078, RFC5633, RFC5680), along with their role definition.
However, it doesn't seem to exist.
Disclaimer: I have not seen https://www.ietf.org/group/nomcom/2011/private/, so it's difficult to understand if we miss requirements about the role versus privileges, or if this falls into the META-001 requirement.


- "The tool needs to support at least three levels of access:Community
  member, Nomcom member, Nomcom chair.
 
  ...

  o  AUTH-003: The tool MUST allow the secretariat to input an email
      address to be provided the Nomcom chair role and a list of email
      addresses to be provided the Nomcom member role."

So which of the three levels has the Secretariat? Nomcom member?
Or do you need a fourth role just for Secretariat/Tools admin?

Along the same lines:
  o  SEC-005: The data accumulated by the tool MUST be stored in a
      fashion that prevents accidental exposure of the data to people
      who administer the server(s) on which the data is stored.

Do you consider the Secretariat part of the "people who administer the server(s)"? I guess not. So how many roles do you need at the end?


Editorial comments
- OLD:

QR-005: Like all other correspondance on the Nomcom mailing list,
      the questionnaires MUST be encrypted by the Nomcom public key
      before being stored.

NEW:
QR-005: Like all other correspondance on the Nomcom mailing list,
      the filled in questionnaires MUST be encrypted by the Nomcom public key
      before being stored.

[Ballot discuss]
Most of the issues are already covered by other COMMENTs raised about this draft, but:

Section 3., paragraph 2:

>    o  AUTH-001: The tool MUST allow the members of the community to
>      login with their existing datatracker.ietf.org credentials.
>    o  AUTH-002: The tool MUST allow the members of the community to
>      create a new login with an automated system.  The system MUST
>      verify that e-mail address used for creating the login.

  What does 'verify that e-mail address' mean? Verify for correctness
  of the syntax? I guess not. This could be clarified to 'MUST verify
  that the email address is in existence'.

Section 5., paragraph 2:

>    o  NOM-001: The tool MUST allow the members of the community to enter
>      nominations into the Public Nomcom tool.
>    o  NOM-002: The tool MUST allow the 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 of the nomination for audit purposes.

  Does the second MUST about the identity also apply to NOM-001?
And isn't a further NOM- requirement?


>    o  FB-006: The tool MUST allow the Nomcom chair to manually move 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.

  Moving an email implies removing it from the archive? Or is it
  meant to say "copy"?

Section 9., paragraph 1:

>    The tool must authenticate all users and must allow classifying
>    logins into 3 roles.  Nomcom chair, Nomcom member and community
>    member.  All communications to/from the Nomcom and among the members
>    of the Nomcom must be stored in an encrypted form.

  What about a role 'liaison'? This role seems to be distinct from
  the other roles.

[Ballot comment]
**Editorals:

Section 1., paragraph 1:

>    The IETF Nominations Committee (Nomcom) is a body that selects
>    candidates for the open IESG, IAB and IAOC positions.  There is a
>    need for a set of tools to aid the Nomcom to operate efficiently.
>    This document lays out a few requirements for such a tool

  s/a few requirements/a set of requirements/
s/tool/tool./

>    o  AD-005: The tool MUST allow the reporting of accepance or decline
>      status both per nominee as well as per open position.

  s/accepance/acceptance/

>    o  QR-004: The tool MUST keep track of the questionnaire receipt
>      status for the nominees.  The filled in questionnaires are
>      received as emails to the Nomcom mailing list.

  Sent to the Nomcom mailing list, isn't it?

[Ballot comment]

- General question and a near-discuss: What, if anything, should
happen to the stored/archived information after the nomcom has
done its work? And if something should happen, (e.g. deletion)
when ought that happen? This may all be in some RFC, but I just
don't know and I could see various good and bad answers being
possible here. 3777 says that: "The nominating committee should
archive the information it has collected or produced for a
period of time not to exceed its term." I don't know what's
actually done now, but could imagine that tools might make
it better or worse.

- Section 2, will those URLs containing 2011 remain good for
sufficiently long to be useful? Maybe s/2011/2012/ at least.

- Section 4, "should be stored using an encrypted cookie" is
wrong. Cookies may disappear (e.g. in http/2.0) and other better
technologies might come along.

- Section 4, I think you need to say somewhere that each nomcom
MUST use a different key pair.

- Section 4, s/using the procedure/for example, using the
procedure/ would be better.

- 2119 and 3777 should be referenced somewhere in the
text I guess.


- Section 4, I think you need to say somewhere that each nomcom
MUST use a different key pair.

- Section 4, s/using the procedure/for example, using the
procedure/ would be better.

[Ballot discuss]
This is basically a sound document, but there are some details that need attention.
Once these are addressed I will be happy to vote yes.

=====

Sec-001 and Sec-005 look the same

=====

This information can only be accessed by the members of the Nomcom.

Does the above mean voting members, voting members + chair.....?

=====

AD-004: The tool MUST allow to view a list of all nominees along
      with their accepance or decline status.

Must allow who?

=====


AD-005: The tool MUST allow the reporting of accepance or decline
      status both per nominee as well as per open position.

Reporting to who?

=====

The nominees fill in a questionnaire for each of the positions for
  which they accept a nomination.

.. and does what with it? Sends an email, posts it on the web site
completes it on the web site?

=====

FB-005: All email received on the Nomcom mailing list MUST be
      archived. 

For what period, and who has access to the archive?

=====

[Ballot comment]

AUTH-003: The tool MUST allow the secretariat to input an email
      address to be provided the Nomcom chair role and a list of email
      addresses to be provided the Nomcom member role.

The above requirement does not read correctly - possibly missing some "by"s

=====

The filled in questionnaires are
      received as emails to the Nomcom mailing list.

Surely they are sent as emails

=====

[Ballot comment]
I support the publication of this document and only have the following, non-blocking, comments:

1. The last sentence of the Introduction is missing a period.

2. Why does the security section start numbering at 000 and all the other sections start at 001?

3. With AD-006, is there a need to allow for the specification of time windows when generating statistics?

4. AD-002 refers to "Acceptances and declines".  Is there a reason for the capitalization of "Acceptances", but not of "declines"?

5. The QR requirements also mix and match capitalization of "Questionnaires".

6. I support Barry's feedback on the use of 2119 keywords when referring to the management of the key and encrypted cookie.

IANA has reviewed draft-krishnan-nomcom-tools-01, which is currently
in Last Call, and has the following comments:

IANA notes that this document does not contain a standard IANA
Considerations section. After examining the draft, IANA understands
that, upon approval of this document, there are no IANA Actions that
need completion.

[Ballot comment]
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

Section 3
Is there really no need for a fourth "Nomcom advisor or liaison" role?

Sec-004
The MUST in the second sentence is silly: this isn't a normative command, but a simple statement, "This key will be used to decrypt...."  But in the third sentence, shouldn't it be, "Once entered, this key MUST be stored using an encrypted cookie?", rather than "should be stored"?

Section 6
It's not clear to me why there's a difference between a community member entering a nomination and a Nomcom member doing it.  Maybe you can explain that a little more, briefly.

QR-002 & QR-006
Please make it clearer what the substantive difference is between these two.

========
Other comments; no need to respond to these. Take them or modify them
as you please:

Auth-003
Maybe it's just me, but I found that I had to read the "to be provided" bits a few times before I correctly parsed them.  "To be given" or "to get" sounds better to me.

AD-004
I don't think "allow " is proper usage, though it's common.  Anyway, to make it parallel to the other items, how about, "allow the viewing of a list..."?

Appendix A
Typo "pait" -> "pair"

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Requirements for IETF Nominations Committee tools) to Informational RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Requirements for IETF Nominations Committee tools'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the requirements for a set of tools for use by
  the IETF Nominations Committee.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-krishnan-nomcom-tools/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-krishnan-nomcom-tools/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Writeup

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

This document is targeted at becoming an Informational RFC. This
targeted status is appropriate because this draft is being used to
specify the requirements for a Nomcom tool.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

The IETF Nominations Committee (Nomcom) is a body that selects
candidates for the open IESG, IAB and IAOC positions.  There is a need
for a set of tools to aid the Nomcom to operate efficiently.  This
document lays out a few requirements for such a tool

Working Group Summary

This document is not the product of an IETF WG.

Document Quality

The document has been reviewed by four prior Nomcom chairs, a Nomcom
voting member, the IETF chair, and a member of the IETF
secretariat. All issues that have been identified in the prior
versions of this document have been addressed in this revision

Personnel

Who is the Document Shepherd? Who is the Responsible Area Director?

Suresh Krishnan  is the document
shepherd.
Russ Housley  is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document shepherd is one of the authors of the document. The
document shepherd feels that the document is ready to be sent for
publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The subject matter of the document is extremely specialized and there
is a very small number of people in the community (i.e. past Nomcom
chairs) that can do a deep review of this document. This document has
been reviewed by four Nomcom chairs (including two authors). I think
there is a sufficiently large community of people who have dealt with
the Nomcom in some fashion (voting member, liaison, nominee etc.) that
can provide reviews from a different perspective during the IETF last
call.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the interested community has
discussed those issues and has indicated that it still wishes to advance
the document, detail those concerns here.

None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any discussion and conclusion regarding the IPR
disclosures.

No.

(9) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

The subject matter of the document is extremely specialized and there
is a very small number of people in the community who are
interested. They are strongly behind this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the interested community considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

This document does not require any IANA actions.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

This document does not require any IANA actions.

(19) Describe reviews and automated checks performed by to validate
sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.

N/A