[Mtgvenue] testing draft-ietf-mtgvenue-iaoc-venue-selection-process against the venue change that just occurred

Eliot Lear <lear@cisco.com> Tue, 18 July 2017 09:37 UTC

Return-Path: <lear@cisco.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 22D16131DCE; Tue, 18 Jul 2017 02:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.503
X-Spam-Level:
X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 74Lm-ozaRlVY; Tue, 18 Jul 2017 02:37:43 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3A9131A8C; Tue, 18 Jul 2017 02:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3644; q=dns/txt; s=iport; t=1500370662; x=1501580262; h=to:from:subject:message-id:date:mime-version; bh=n65xwfU0v0VohTRdHwsA+M5CF9UN9agiBlGNMAWqa5U=; b=d/C4oEK3CKYBjiQUpMEKE8azfkvmuMojWwQs0RLSBkDZdx/LE0j30Ymn orYkz/ysfmU3pdn3/32r/9nWy2IX8hLHn89t5frG8tbu/KN0JSYwnRfDh tOf+bmLFSsK3UTPzCbcBZgbDcphyTtwhVr99gayji/5+d7815RsInm38Q g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BKAQBK1m1Z/xbLJq1dGwEBAQMBAQEJAQEBk11zkE6BFpUQghEHiVAYAQIBAQEBAQEBayiFGgQkUglRBwJfAQwIAQEQihMIrk+CJosKAQEIAgEWD4MohS4rC4I6iDGCYQWLT5NlhCyCHY1Niy6HAZVXHziBCjEhCBsVhVwcGYFQPokOAQEB
X-IronPort-AV: E=Sophos;i="5.40,377,1496102400"; d="asc'?scan'208";a="695885426"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jul 2017 09:37:38 +0000
Received: from [10.61.216.188] ([10.61.216.188]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v6I9bbRb025880; Tue, 18 Jul 2017 09:37:37 GMT
To: "mtgvenue@ietf.org" <mtgvenue@ietf.org>, IAOC <iaoc@ietf.org>
From: Eliot Lear <lear@cisco.com>
Message-ID: <27b1a6a1-5dfc-6403-1d24-3171f7dba74a@cisco.com>
Date: Tue, 18 Jul 2017 11:37:36 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="AJdqAo82URDh2S3vNU0wR80ERLRqldSsM"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/9rqwUl3s3uAOBUsjsgpRGcWSSz8>
Subject: [Mtgvenue] testing draft-ietf-mtgvenue-iaoc-venue-selection-process against the venue change that just occurred
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.22
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, 18 Jul 2017 09:37:45 -0000

Dear colleagues and IAOC members,

The change of venue for IETF 102 provides us an opportunity to check
whether or not draft-ietf-mtgvenue-iaoc-venue-selection-process would
represent appropriate running code.  That is- was there a criteria that
became violated, and was the processed described in the draft  appropriate?

To answer the first question we look to the following Important criteria:

>    o  Travel barriers to entry, including visa requirements, are
>       unlikely to impede attendance by an overwhelming majority of
>       participants.


This wording seems to fail the "document running code" test, because it
is unlikely that the overwhelming majority of people would have problems
getting to San Francisco.  However, it seems likely that a significant
number of people would, and that seems to me what we meant in the first
place.  To avoid arguments over what "significant" means, I propose to
change the text to the following:

o Travel barriers to entry, including visa requirements, are unlikely to
impede attendance by more than 5% of expected participants.

To put this in perspective, and to demonstrate my multiplication skills;

5% of 1200  = 60 people.

If people prefer we could simply say "significant", and leave it ambiguous.

Let's assume such a change were in place.  At that point, we have text
in Section 5.5 that reads as follows:

>    If at any time after a contract is signed the IAOC learns where a
>    Venue's circumstances have significantly changed, such that the
>    Important or Mandatory criteria can no longer be met, the IAOC MUST
>    reconsider the selection.  A description of how reconsideration
>    currently takes place is found in Appendix B.  The IAOC will gauge
>    the cost of making a change against the ability of the IETF to
>    conclude a successful meeting, and make a final determination based
>    on their best judgment.  When there is enough time to do so, the IAOC
>    is expected to consult the community about changes.


It seems to me that this did indeed function as appropriate.

Would others mind having a look at the text and test my conclusions and
suggestions above?

Eliot