Re: I-D Action: draft-kucherawy-nomcom-procexp-00.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 10 April 2016 20:29 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7CD12D0F3 for <ietf@ietfa.amsl.com>; Sun, 10 Apr 2016 13:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnfV5iPBtyrl for <ietf@ietfa.amsl.com>; Sun, 10 Apr 2016 13:29:54 -0700 (PDT)
Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17ABF12B00C for <ietf@ietf.org>; Sun, 10 Apr 2016 13:29:54 -0700 (PDT)
Received: by mail-pf0-x233.google.com with SMTP id 184so110251437pff.0 for <ietf@ietf.org>; Sun, 10 Apr 2016 13:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Q+b7Q9hDJcX0btRzP0UZ0BSY+0c91EjXFZYqJ95b3vQ=; b=FYnf5sBEJQa+32UbH5XNGXBfbcGj7k0c+ecq48IVJzkQzbr+/FOTJmd1MaG1sy6aQa UkGEYtrzQaAGzpcjH1yYiXQglcZHNFro68MnmvA6zSV8RdSgsbw8elWF7luZII6P+Rvq PbWhFw9dcUUyN7LqGflTIpPuseqDpK4huSfjKLSuVZ2Ki3CUZqR9AXQgRjRwZ8wP4nC6 sHmMRG8eCKL/ptLuzQSbrcLz9V6lPTfCAfBt6dDLLLtwMEuh6N9N04hzuIwpGQmn5CRe vOE5ypbEkZVgqp8x2hUSndqIpBG14L8ct/8+SkLDs1BqBEobAZHsBdMdd2nslXmt07oA zBVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Q+b7Q9hDJcX0btRzP0UZ0BSY+0c91EjXFZYqJ95b3vQ=; b=dQUU/DO9lr0L940Iy7L12BUY3IMuspJB3Eu1mzaur1CVJ4PS6ON5ahBoTUDdYeZhSz d+pUBq+G8bUCStUuafBf6MF5i8AuLQzuwF0rA+mpIjAbWRVTHKF0LkyNUfGSE5W/MkEA kdwXeVCjy0SH4LIX9pJ64dT+T1syYpisFyp3gZk7BJWrdDCCIk9oSx8z4YjxhoSPzgff jLTEanppvreJksU7oL+KQ2FuToNf9aFbgsAOv/K1KjUH2l9broFpXay8afvet6DVwNtO FdrzHQroedNSONYntBg0MwVa+FbuQODJajiz0XhuVmYgS9N4X+eijvzeuJMO39NvWbuF Ms6g==
X-Gm-Message-State: AD7BkJKUEgja2f6f01qKM3EYAOML4sB+NcjNkgCLj/FymwLIjbiGUvgxzFAcnsEJlxxY0w==
X-Received: by 10.98.18.212 with SMTP id 81mr28261983pfs.104.1460320193734; Sun, 10 Apr 2016 13:29:53 -0700 (PDT)
Received: from ?IPv6:2406:e007:4e39:1:28cc:dc4c:9703:6781? ([2406:e007:4e39:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id y3sm9677287par.2.2016.04.10.13.29.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 10 Apr 2016 13:29:52 -0700 (PDT)
Subject: Re: I-D Action: draft-kucherawy-nomcom-procexp-00.txt
To: John C Klensin <john-ietf@jck.com>, "Murray S. Kucherawy" <superuser@gmail.com>
References: <20160408185636.23101.86017.idtracker@ietfa.amsl.com> <570882CE.9010501@gmail.com> <13214.1460236486@obiwan.sandelman.ca> <CAL0qLwYKbB3_PQcUAUDqJwnddc4oywffVD+sVusOK2xiBYu4PA@mail.gmail.com> <5709CE36.3040605@gmail.com> <CAL0qLwbROnW8pKKtd=7hkHHyP=xA-_eNoBuoKqPpaGjjpgUH+Q@mail.gmail.com> <47541D4081FC9856A5390378@JcK-HP8200.jck.com> <7FBF15BB56B5908D0A908194@JcK-HP8200.jck.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
Message-ID: <570AB7BC.8040605@gmail.com>
Date: Mon, 11 Apr 2016 08:29:48 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <7FBF15BB56B5908D0A908194@JcK-HP8200.jck.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/xQPffW-GCnZZxHKOD4aLi1QtT6U>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2016 20:29:55 -0000

1) Murray asked:

> Does bullet 3 in Section 2 need to say more than it does now on that topic?

No. "Such a challenge must be
accompanied by an explanation of why that particular member is
not suitable." allows any kind of challenge, including libel.
I'm saying that the only allowable challenge here should be
on the grounds of insufficient recent IETF experience.

2) Therefore, with respect to what John writes below, +1.

   Brian
On 11/04/2016 04:59, John C Klensin wrote:
> Murray,
> 
> One more thought about the challenge process.  Without
> performing the experiment, we can only guess at how many
> challenges there would be and that might make a difference.
> However, I wonder whether, instead of adding "didn't attend
> enough meetings and isn't appropriate" on to the challenge
> criteria for post-selection challenges, it might be better to
> create a different category and allow challenges on that basis
> to people entering the selection pool.
> 
> In other words, 
> 
> (1) The pool is announced (as today) with the "fewer meetings"
> people identified (as you now suggest).
> 
> (2) There is a brief period for community challenges to those
> who have not attended three of five meetings, paralleling the
> period in which the Secretariat checks to be sure those who have
> claimed three of five meetings really did attend.
> 
> (3) Once we get past step 2, the pool is the pool and, while any
> one selected can be challenged under the rules of RFC 7437,
> challenges based on meeting attendance are no longer allowed.
> 
> I'm not sure, and I'm a tad concerned about DoS attacks (see
> above), but it seems to me that might be a little bit cleaner.
> It would also have the property that potentially-controversial
> challenges based on unsuitability would occur much earlier in
> the process, before the random draw is made, and that might be
> an advantage.
> 
>      john
> 
> 
>