Re: [datatracker-rqmts] Last Call: <draft-ietf-genarea-charter-tool-07.txt> (Requirements for a Working Group Charter Tool) to Informational RFC

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 19 March 2011 00:56 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: datatracker-rqmts@core3.amsl.com
Delivered-To: datatracker-rqmts@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7D633A69E0; Fri, 18 Mar 2011 17:56:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.881
X-Spam-Level:
X-Spam-Status: No, score=-101.881 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZBJ+TqysYpv; Fri, 18 Mar 2011 17:56:31 -0700 (PDT)
Received: from hoffman.proper.com (unknown [IPv6:2001:4870:a30c:41::81]) by core3.amsl.com (Postfix) with ESMTP id ADE963A69B9; Fri, 18 Mar 2011 17:56:30 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p2J0vw8f074501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 Mar 2011 17:57:59 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <AE893EF9-04B7-4B8B-95FD-EF54F0BA8ABC@nostrum.com>
Date: Fri, 18 Mar 2011 17:57:58 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <01E104C7-3372-4671-8578-7FA570EFC81A@vpnc.org>
References: <20110311221124.17584.25925.idtracker@localhost> <AE893EF9-04B7-4B8B-95FD-EF54F0BA8ABC@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1082)
Cc: datatracker-rqmts@ietf.org, ietf@ietf.org
Subject: Re: [datatracker-rqmts] Last Call: <draft-ietf-genarea-charter-tool-07.txt> (Requirements for a Working Group Charter Tool) to Informational RFC
X-BeenThere: datatracker-rqmts@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <datatracker-rqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/datatracker-rqmts>, <mailto:datatracker-rqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/datatracker-rqmts>
List-Post: <mailto:datatracker-rqmts@ietf.org>
List-Help: <mailto:datatracker-rqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/datatracker-rqmts>, <mailto:datatracker-rqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Mar 2011 00:56:31 -0000

On Mar 15, 2011, at 3:20 PM, Robert Sparks wrote:

> Hi Paul -

Thanks again for the copious comments; they are greatly appreciated.

> In section 2.2, I would prefer either using the names the tracker currently uses for IESG evaluation:
> "Discuss" and "Comment", or some set of words that do not intersect those, perhaps "Blocking" and
> "Not-Blocking". The current set ("discuss" and "regular") will lead to confusion.

Changed to "blocking" and "non-blocking". (I'm not a big fan of gratuitous capitalization, as exemplified by "a DISCUSS"...)

> In section 2.7, you don't specifically capture WGs that currently exist, but are not rechartering at the moment.
> I think you meant to as part of the second paragraph, but the last phrase could be read to be exclusive.

Yeeps; fixed.

> (As an aside - do you intend that for existing working groups, this history will go all the way back to when
> the group was formed? Will we be able to count on <foo-charter-00> being the charter that the working group
> formed with for all foo?)

I have no idea. That's why I use the waffle-words "as much information as is currently known...that can be done in a mostly-automated fashion". It's up to the IAOC to decide how much effort to throw at that part.

> In section 3.1 - It would be better to have the ability to override the tool's rejection of a name because some
> previous effort (particularly abandoned ones) had the same name. If someone thought about using a name
> 5 years ago, but never took it even to the point of Internal Review, why should the tool force it not be be used now?
> This is a place that human judgement should be allowed to be exercised.

Fixed. Changed "so the tool will tell the AD if the acronym that is being proposed has been used in earlier WG charter proposals and prevent its use" to "so the tool will warn the AD if the acronym that is being proposed has been used in earlier WG charter proposals and suggest against its use".

> Also, we should make sure the tool doesn't unintentionally make reopening a closed WG harder than intended.

I think that is covered above.


> It would help to clarify in the first bullet in 3.1 that the tool should prompt the AD, but not prevent them from
> completing the move if that's the right thing to do. (The tool is providing a reminder, not enforcing a rule).

Done.

> In the 4th bullet of that list, you ask the tool to send a note to the scretariat to schedule discussion on a telechat.
> In practice today, this happens as part of the transition into External Review. I suggest moving the sentence into
> the 3rd bullet.

That was not my reading of the current IESG procedures. Let me talk that one over with the IESG.

> In section 3.2's second bullet, it is possible, I believe, to directly approve a recharter from internal review. The tool
> should allow that transition.

Added.

> I'm a little concerned about taking working groups for which a recharter is being considered out of the state named
> "WG Exists". Semantically, if you aren't in that state, it implies the WG doesn't exist, and I could see someone
> drawing the wrong conclusion from a search. The best way to avoid this might be to rename the "WG Exists" state
> to something like "WG Chartered - no rechartering effort currently in progress" (which I realize is too wordy).

Yes, wordy. Currently, that list is followed by "All states above, except for "WG exists", are given the annotation "Rechartering"." Would it suffice to change the annotation to "WG continuing during rechartering" or something of that ilk?

--Paul Hoffman