Re: [Mtgvenue] Venue 'requirements' language

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 31 October 2016 17:46 UTC

Return-Path: <ajs@anvilwalrusden.com>
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 22688129978 for <mtgvenue@ietfa.amsl.com>; Mon, 31 Oct 2016 10:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 P3J489UqQCV5 for <mtgvenue@ietfa.amsl.com>; Mon, 31 Oct 2016 10:46:34 -0700 (PDT)
Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 659B7129964 for <mtgvenue@ietf.org>; Mon, 31 Oct 2016 10:46:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 6C41F10502 for <mtgvenue@ietf.org>; Mon, 31 Oct 2016 17:46:37 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQI1LS9c7rme for <mtgvenue@ietf.org>; Mon, 31 Oct 2016 17:46:36 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id B0D151038F for <mtgvenue@ietf.org>; Mon, 31 Oct 2016 17:46:36 +0000 (UTC)
Date: Mon, 31 Oct 2016 13:46:31 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: mtgvenue@ietf.org
Message-ID: <20161031174631.GU3387@mx2.yitter.info>
References: <1559ca2e-1f30-bbc6-30a5-05b178aff2e6@dcrocker.net> <35CB3BF1-67E6-41B1-8243-11188EFAB625@cooperw.in> <5d31a272-c523-b273-257f-cafc3790e052@dcrocker.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5d31a272-c523-b273-257f-cafc3790e052@dcrocker.net>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/n1qmya6GGovmgnS89dcKOSE31qI>
Subject: Re: [Mtgvenue] Venue 'requirements' language
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: Mon, 31 Oct 2016 17:46:36 -0000

On Mon, Oct 31, 2016 at 08:43:56AM -0700, Dave Crocker wrote:
> special phrasing of the requirement.  In effect, the requirement needs to be
> phrased more like a process requirement than as a simple, objective
> criterion.

> Thoughts?

I think this is the opposite direction to the draft that I put
together with Alissa, but I think it might work.

The reason I, at least, worked on the draft we submitted was that I
felt draft-baker-mtgvenue-iaoc-venue-selection-process had two issues:
too many things listed, and no guidance for the IAOC to understand
when it had done the right thing.

This "do the right thing" problem is I think part of the issue we've
faced.  The IAOC knows there are a bunch of things to take into
account.  What it does not know is how to balance the various things
against each other, and as a result it sometimes just blows it and
everyone gets angry.

I thought that a way to answer that was to give an ordered list of
priorities.  This would mean that a venue that satisfied them all
would be preferable to one that didn't, but if the IAOC couldn't get
everything then it would be in a position to tell the community, "We
tried, we couldn't get everything, and here's the way we decided
(which has consensus)."

An alternative is, I suppose, to list the criteria that must somehow
be satisfied and to describe what satisfaction looks like without
specifying the particular satisfaction mechanism.  The problem with
that, of course, is that it puts the squishiness issue back onto the
IAOC and makes way for these sorts of dispute in the future, too.  But
at least there's an unambiguous list of what must be achieved.

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com