[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
- [Mtgvenue] Jari's comments on -04 Jari Arkko