Re: [Mtgvenue] Comments on -04

Jari Arkko <jari.arkko@piuha.net> Tue, 31 January 2017 15:05 UTC

Return-Path: <jari.arkko@piuha.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 0F50F129499 for <mtgvenue@ietfa.amsl.com>; Tue, 31 Jan 2017 07:05:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.099
X-Spam-Level:
X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 QfnE0OVn_4xf for <mtgvenue@ietfa.amsl.com>; Tue, 31 Jan 2017 07:05:49 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 64998129472 for <mtgvenue@ietf.org>; Tue, 31 Jan 2017 07:05:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 345C82D299; Tue, 31 Jan 2017 17:05:48 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjkxwhxNiBzy; Tue, 31 Jan 2017 17:05:47 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 9FACD2CC9B; Tue, 31 Jan 2017 17:05:47 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_81C822B8-060D-4DDD-9E41-68320952279C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <20170131010548.GL47762@mx2.yitter.info>
Date: Tue, 31 Jan 2017 17:05:52 +0200
Message-Id: <0AF73C4A-7AC0-412C-9570-F4F1FA56E6C9@piuha.net>
References: <20170131010548.GL47762@mx2.yitter.info>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/nXPY3mc8lP_N3YcLuVbMFu7W0E0>
Cc: mtgvenue@ietf.org
Subject: Re: [Mtgvenue] Comments on -04
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: Tue, 31 Jan 2017 15:05:52 -0000

> Large issue 3: Process innovation
> ======================
> 
> I don't know whether I've just not made this clear, or whether the
> editors really disagree with me, but §4.1 appears to me to suggest
> that we have a standard IETF consensus call about many issues related
> to venues, and combined with the "is acceptable" language in §3 looks
> to me like an enormous potential burden with possibly appealable
> consequences.  I think this is a terrible idea.
> 
> It's this ¶ in particular that makes me worried:
> 
>   IETF consensus, with respect to this meeting Venue selection process
>   is judged via standard IETF process and not by any other means, e.g.,
>   surveys.  Surveys are used to gather information related to meeting
>   venues, but not to measure consensus or to be reported as
>   consensus.
> 
> If the below is what's meant instead, I can live with it (though I
> think it could in that case be removed as it is already determined
> elsewhere):
> 
>   IETF consensus, with respect to the meeting venue selection process
>   herein outlined, is judged according to standard IETF process and
>   not by any other means, e.g., surveys.  Surveys are used to gather
>   information related to Venues, but not to measure consensus
>   or to be reported as consensus.  By the same token, Venue decisions
>   are not themselves subject to IETF consensus, and are instead
>   decisions taken by the IAOC.

This absolutely needs to be there.

As for the large issue 2 (too much mandatory & in the passive voice)
I tend to agree with Andrew, but with a twist.

It would be beneficial to make the list of mandatory requirements
shorter, and at the very least, explicitly say what Brian suggested:

  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

Or rather, that the IAOC MUST establish that the chosen
location is above the minimum threshold for that particular
requirement. Which I think is what is meant.

I’ll just observe that even the criteria from draft-sullivan
is to an extent soft. Even things like sufficient meeting
space can be, because we occasionally have
discussions with the secretariat on whether
we’d fit in or if there’d be compromises on
things like bnb space or small side group meeting
rooms.

Jari