[Gen-art] Gen-ART review: draft-krishnan-nomcom-tools-01.txt

[Mary Barnes <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at <
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

I apologize for not taking the time to review this before this point in
time.

Document: draft-krishnan-nomcom-tools-01.txt
Reviewer:  Mary Barnnes
Review Date:  16 July 2012
IETF LC End Date:  11 July 2012
IESG Telechat Date: 19 July 2012

Summary:  Almost ready; comments and editorial nits.

Comments:
--------------

- Section 2, first paragraph:  It seemed to me that what is described here
is a lot of what is already supported by the current toolset - perhaps the
user interface is not as slick.  It would be good to actually identify what
are requirements that are not currently supported.  Perhaps my memory is
just a little stale.

- Section 3.  It seems to me that the Authentication is different for the
public side of the tool and the private and this section doesn't make that
differentiation.  Nomcom members have the same access to the public side as
does anyone else.  The private side authentication is entirely different
from the public side.  You need a unique ACL for the tool for the private
side - it's not just a matter of the nomcom members creating an account.
 The nomcom members are on that ACL and they also need to be on the closed
mailing list that's encrypted. I don't think AUTH-003 has to do with
authentication - the email alias and membership in the nomcom mailing list
would more appropriately be in the Access control section.

More generally, I think it needs to be explained somewhere that the current
tool caches the email archives and mines those archives for information
with which to populate the information for the nominees, positions, etc. on
the private nomcom webpage.  And, that is the model for the requirements in
this document.  So, I suggest rewording the intro paragraph as:

   All users access to the Nomcom tools need to be authenticated.
   The users of the tools have different privileges based on their role.
   The tools need to support at least three levels of access: Community
   member, Nomcom member, Nomcom chair.  The Community member access
   applies to the public Nomcom webpage interfaces. The Nomcom member
   access applies only to the private Nomcom webpage, as Nomcom members use
   the interfaces on the public webpage 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.).

I also have to wonder if there shouldn't be an "admin" role in terms of
being able to change how the tools work if necessary (note, you do mention
"system administrators" in section 4).

-- AUTH-002:  I would suggest minor rewording  I think it's important to
clarify that a user doesn't have to use the same email address for
everything IETF and it shouldn't need to be a data tracker email address,
unless you are suggesting that is the requirement. I don't think it should
be as that was always confusing.

OLD:
      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.
NEW:
      The tool MUST allow the members of the community to
      create a new login using any e-mail address. The system MUST
      verify the e-mail address used for creating the login.

-- AUTH-003:  I think this is saying that the secretariat should provide
support for the nomcom-chair email alias, as well as an email alias that
reaches all the noncom members.   It seems to me that this is not
necessarily something "The tool" would provide and isn't really related to
authentication, but rather just a more general requirement for the Nomcom.
I would almost suggest that you have a category of requirements around
"Identity" in which there is a role for the secretariat is to create the
Nomcom-chair alias and a mailing list.  I think it's the "chair" or "admin"
role that could add the Nomcom members to the mailing list (and to the
ACL).

- Section 5:
-- first paragraph, 4th sentence.  I suggest this be clarified the the
members of the nomcom *only* enter the nominations manually when requested
by the community.  I think it's extremely important that the nomcom members
*always* use the public interface to input their nominations, comments,
etc. or it corrupts the process. I'd like to put that in normative
language, but that's really something that should be in RFC 3777.

OLD:
   The secondary way is that the nominees are
   entered in by the members of the Nomcom
NEW:
   The secondary way is that the nominees are
   entered in by the members of the Nomcom based upon requests (via email
   or verbally) from the community.  It is important to note that Nomcom
   members ought to use the public interface to input their personal
   nominations and comments.

-- NOM-002 - related to my comment above, I suggest this be changed as
follows.  I also don't quite get why the last item is MUST record the
identity. I believe it MUST provide a mechanism to record the identity,
but anonymous input is allowed, thus the identity may not be the originator
of the nomination, so I have a suggested rewording for that.
OLD:
      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.   The tool MUST
      record the identity of the
      originator of the nomination for audit purposes.
NEW:
      NOM-002: The tool MUST allow the members of the Nomcom to enter
      nominations into the Private Nomcom tool based upon input
      from members of the community.   The tool MUST allow the
      Nomcom member to optionally enter information about the member
      of the community that originated the nomination.   The tool MUST
      provide a mechanism to record the identity of the
      originator of the nomination for audit purposes.  Note, that
      anonymous nominations are allowed, thus the actual identify of
      an originator may not be entered into the tool.

- Section 7:
-- QR-002: I'm assuming this is talking about questionnaires sent by email,
in which case that should be qualified.  Note: this is mentioned in QR-004,
but really should be earlier, thus I suggest the following change:
OLD:
      QR-002: The tool MUST allow the Nomcom chair to point to responses
      from the nominees and flag them as Questionnaires.
NEW:
      QR-002: The tool MUST allow the Nomcom chair to point to email
      responses from the nominees and flag them as Questionnaires.

OR perhaps better, just move the 2nd sentence from QR-004 to QR-002.

- Section 8:
-- FB-002: I think the second sentence should be consistent with my
suggestion for NOM-002 - i.e., anonymous input, which is implied by the
wording of this second sentence.



Editorial nits:
---------------
- Section 5:
-- 1st sentence, first paragraph:  I couldn't find that constituted was a
word.  I would suggest "formed".
-- NOM-009: "that the email address" -> "than the email address"

- Section 6:
-- AD-004: "allow to view a list of all nominees" -> "allow viewing the
list of all nominees"
-- AD-005: "accepance" -> "acceptance"

- Appendix A.
-- first sentence:  "pait" -> "pair"