[Mtgvenue] Jari's comments on -04

Jari Arkko <jari.arkko@piuha.net> Wed, 01 February 2017 00:17 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 213D812968E for <mtgvenue@ietfa.amsl.com>; Tue, 31 Jan 2017 16:17:37 -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 VUeVFqzSX1VH for <mtgvenue@ietfa.amsl.com>; Tue, 31 Jan 2017 16:17:35 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 75797129620 for <mtgvenue@ietf.org>; Tue, 31 Jan 2017 16:17:34 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id BA4C32D299 for <mtgvenue@ietf.org>; Wed, 1 Feb 2017 02:17:32 +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 OfkqD5tpOofQ for <mtgvenue@ietf.org>; Wed, 1 Feb 2017 02:17:32 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id E794B2CC9B for <mtgvenue@ietf.org>; Wed, 1 Feb 2017 02:17:31 +0200 (EET) (envelope-from jari.arkko@piuha.net)
From: Jari Arkko <jari.arkko@piuha.net>
X-Pgp-Agent: GPGMail
Content-Type: multipart/signed; boundary="Apple-Mail=_EBC2399C-B393-4CCF-B6F4-FBDA2D5B9F7F"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Date: Wed, 01 Feb 2017 02:17:37 +0200
Message-Id: <5D57E3D1-48DD-44D2-8857-163473651822@piuha.net>
To: mtgvenue@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/Jt0YraPlpI_eSgdASHH7NiotDm8>
Subject: [Mtgvenue] Jari's 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: Wed, 01 Feb 2017 00:17:37 -0000

I’ve been reviewing the -04 version in the last couple of days,
and had some comments:

> 2.2.  Venue Selection Non-Objectives
> 
> …
> 
>    Maximal attendance:
>       Because the IETF garners a significant portion of its revenue from
>       IETF meeting fees, there is considerable incentive for decision-
>       makers to prefer a Venue that will attract more attendees.  It is
>       important to resist this temptation: a larger meeting in which key
>       contributors could not make it is not a better meeting; neither is
>       one with a lot of "tourists”.

This is correct, but sounds a bit strange. Maybe not the whole
truth.

I’d add “Yet, meetings need to be open and accessible for
both key contributors and others, including new contributors."

>    +------------------------------------------------------+------------+
>    | The Venue is assessed as favorable for obtaining a   | "Mandatory |
>    | host and sponsors. That is, the Meeting is in a      | "          |
>    | location and at a price that it is possible and      |            |
>    | probable to find a host and sponsors.                |            |
>    +------------------------------------------------------+——————+

My personal opinion is that with increasing number of
large global corporations working on Internet tech, and
the IETF global host program, the reliance on finding
local hosts is reduced a bit. We still have to fight to find
sponsors and hosts, and if the meeting location is
somehow undesirable for sponsorship, that would be
an issue. But the text above could be interpreted
in different ways. I’m worried that we may not all
understand it the same. Does it assume a local
host model?

My suggestion would be to change text or downgrade
from mandatory.

>    +------------------------------------------------------+------------+
>    | It is possible to enter into a multi-event contract  | "Desired"  |
>    | with the Venue to optimize meeting and attendee      |            |
>    | benefits, i.e., reduce administrative costs and      |            |
>    | reduce direct attendee costs, will be considered a   |            |
>    | positive factor. Such a contract can be considered   |            |
>    | after at least one IETF meeting has been held at the |            |
>    | Venue.                                               |            |
>    +------------------------------------------------------+------------+

Yes, support that.

But, I wonder if we’re hiding important things in the
details; cart before horse. In an so far unpublished
note that I’m writing on IASA 2.0, I had written
the following suggestion:

   Repetitive Meeting Schedule

      The IETF meeting cycle should move to a model where 5 meetings
      within a year are repeats in previously qualified hotels and
      locations, and at most 1 meeting is a new one.  The process for
      the previously qualified and new meetings shall be separated.  For
      instance, a contractor can be asked to arrange the repeat meetings
      with only approval for the final hotel agreement taken to the
      IAOC, and then more community and IAOC energy can be used to vet
      the new locations.

I’m not necessarily suggesting this exact model be adopted.
But if the document said “do repeats, and when you are
not repeating, THEN this complex set of requirements need
to be investigated”, maybe that would improve our process?

Note that the IAOC has pretty much gotten the point that the
community wants repeats. Looking from inside, the process
though is largely still the same for everything, which to me
seems wasting effort.

Of douse, it is not necessarily easy to “just repeat”, hotel availability
is a big issue for instance. I’ve been wanting to go back to Japan
for instance so many times already, but there are
challenges :-)

>    Mandatory:
>       If this requirement cannot be met, a location under consideration
>       is unacceptable.  We walk away.

This definition doesn’t seem to match recent discussion, i.e.,
what seems to be mandatory is that the IAOC does look
at this requirement, and assess that it passes the level
that the IAOC (in their judgment) considers a minimum
acceptable level for that requirement.

>    +-----------------------------------------------------+-------------+
>    | The Facility permits easy wheelchair access.        | "Mandatory" |
>    +-----------------------------------------------------+-------------+
>    | The Facility is accessible by people with           | "Important" |
>    | disabilities.                                       |             |
>    +-----------------------------------------------------+-------------+

1) Odd that the requirement levels differ

2) As an IAOC member I don’t have a clear understanding of what
to look for when assessing the second item.

>    +-----------------------------------------------------+-------------+
>    | The Facility directly provides, or permits and      | "Mandatory" |
>    | facilitates, the delivery of a high performance,    |             |
>    | robust, unfiltered and unmodified IETF Network.     |             |
>    +-----------------------------------------------------+-------------+
>    | The IETF Hotel(s) directly provide, or else permit  | "Mandatory" |
>    | and facilitate, the delivery of a high performance, |             |
>    | robust, unfiltered and unmodified Internet service  |             |
>    | for the public areas and guest rooms; this service  |             |
>    | is typically included in the cost of the room.      |             |
>    +-----------------------------------------------------+——————+

I didn’t understand the distinction between these two items.

>    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.

As noted in another mail, this is unclear. The consensus is on the process,
not on individual venue selection decisions. (And perhaps you could
also explain that if there’s widespread concern of a venue, then
that should show up in the public consultation, and hence the location
should not make it to selection.)

> 5.5.  Final Check
> 
> 
>    ~3 Months prior to the Meeting, the site is checked for continued
>    availability and conformance to expectations.

This might have to be split; three months is a good time to do
a review, but clearly issues could occur at any moment. And we
get reports from our contractor of safety or other issues appearing
in the region.

Jari