Re: [Mtgvenue] Comments on -04

Dave Crocker <dhc@dcrocker.net> Tue, 31 January 2017 04:23 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BCE128B44 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 20:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 9lLbkgxDnQf0 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 20:23:45 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBA0129D87 for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 20:23:45 -0800 (PST)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v0V4PInc028176 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2017 20:25:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1485836719; bh=ajXMQGsazz0YfMZQCIpE2SomkEYtUgURYf8MJKk1n0E=; h=Subject:To:References:From:Reply-To:Date:In-Reply-To:From; b=DMKHuEB/J7MQZjiZx7pkopVtkR2Hu90c4EW+ok4E4Qui/Sc5NcDMpnuaUbVuIUvqp wJ/RD2ba9pTLfZQ6iapoCUQTf3jiOgHCOVZoR4OLc86/kr+eHGmgpkpG6xof39X6Dd Bv+pkpO/Q4QYKLnYebh1691gg6YvQBFMVTpeNX78=
To: Andrew Sullivan <ajs@anvilwalrusden.com>, mtgvenue@ietf.org
References: <20170131010548.GL47762@mx2.yitter.info> <de401360-8827-c427-19fe-ace8d2987f40@gmail.com> <20170131040757.GM47762@mx2.yitter.info>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <2c957e0e-999f-f8a2-3a61-3aff3606b087@dcrocker.net>
Date: Mon, 30 Jan 2017 20:23:33 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <20170131040757.GM47762@mx2.yitter.info>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/CcJfeCEgzj_9VTcjWMh83aK_qbo>
Subject: Re: [Mtgvenue] Comments on -04
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2017 04:23:46 -0000

On 1/30/2017 8:07 PM, Andrew Sullivan wrote:
> On Tue, Jan 31, 2017 at 02:31:13PM +1300, Brian E Carpenter wrote:
>>
>> Really? That's only an issue of document organisation.
>> Personally I think it's more readable arranged the way it is,
>> by topic. YMMV.
>
> I don't actually care about readability.  I care about utility in
> decision-making (as I noted in the preamble to my note), and this
> organization is impenetrable for that

The current organization aggregates related items.  Related by topic, 
which is what the category labels indicate.  This permits reviewing them 
together, to see how they cover their category.

Organizing things by level of requirement is remarkably unhelpful. 
Imagine, please if we wrote protocols specifications, with all of the 
MUSTs together, then all of the SHOULDs, then all of the MAYs, rather 
than putting things together that are related to the same semantic 
aspect of the protocol.

So no, not impenetrable.  Practical.

{Small procedural nit:  You've raised this issue at least twice before 
(July and November) and got quite a lot of discussion, but little-to-no 
supporting traction.  On the average, the IETF frowns on persistently 
re-raising issues that have been previously considered, absent new 
information about them.)


>> But that is the whole point. Most of the 'mandatory' items are
>> in fact judgment calls. So it's mandatory to make the call, but
>> it's made by the IAOC (on the recommendation of the meetings
>> committee, presumably). And yes, most of the criteria we've
>> identified are in that category. That's a good sign, IMHO,
>> because it means that we aren't wasting time on minor issues.
>
> This is a completely absurd meaning of "mandatory" (and not the one in
> the document).  It's not that it's mandatory to make the call, but
> rather that if the criterion cannot be satisfied then the meeting is
> not to be held there.  It's perfectly clear in the text:
>
>    Mandatory:
>       If this requirement cannot be met, a location under consideration
>       is unacceptable.  We walk away.

Requiring due diligence about specific issues is quite common when 
writing requirements and procedures.  So calling it absurd is... absurd. 
  As for possibly not matching the meaning of Mandatory in the document: 
  In some cases getting the necessary information is problematic.  So we 
don't go there.  Again, not absurd.

d/

-- 
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net