Re: Hotel situation

Jari Arkko <jari.arkko@piuha.net> Mon, 04 January 2016 20:27 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2499D1A9174 for <ietf@ietfa.amsl.com>; Mon, 4 Jan 2016 12:27:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.79
X-Spam-Level:
X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 zea7Zjn_r1CG for <ietf@ietfa.amsl.com>; Mon, 4 Jan 2016 12:27:47 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 143DF1A916F for <ietf@ietf.org>; Mon, 4 Jan 2016 12:27:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 51F0D2CCE5; Mon, 4 Jan 2016 22:27:46 +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 qEHIoQv3UYXi; Mon, 4 Jan 2016 22:27:45 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 587E22CCAE; Mon, 4 Jan 2016 22:27:45 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Subject: Re: Hotel situation
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_3D70AB0D-7E77-4595-A9BA-14E4BAF13A6A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5.1
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <CABmDk8n2TFvmoMVa8t3FOGXtKF9GUii=wrEyMpJucAoLzCix1Q@mail.gmail.com>
Date: Mon, 04 Jan 2016 22:27:42 +0200
Message-Id: <346B0259-F6BD-4207-988F-950D6C03F7FD@piuha.net>
References: <567192F3.9090506@gmail.com> <8D23D4052ABE7A4490E77B1A012B630797A09BC1@mbx-03.WIN.NOMINUM.COM> <48E1A67CB9CA044EADFEAB87D814BFF6449900E0@eusaamb107.ericsson.se> <CABmDk8n2TFvmoMVa8t3FOGXtKF9GUii=wrEyMpJucAoLzCix1Q@mail.gmail.com>
To: Mary Barnes <mary.h.barnes@gmail.com>, Eric Gray <eric.gray@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/rHCaONoWAbcylOQREQz3wwvM-Ic>
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2016 20:27:50 -0000

Eric, Mary,

> And this has been a worsening trend.  I've attended most IETF meetings in the last 20 years (I have the t-shirts to prove it) and I can remember when it was still possible to book a room at one of the meeting hotels at the IETF rate at least up to the block cut-off date (as opposed to an hour after the hotel information is made available).

I think you are right, and we need to fix that.

> Something changed for IETF hotel bookings about the time of the bubble-burst and most of us don't have any visibility into what that is.  We can speculate, but there seems to be empirical data that supports the idea that it is not an unsolvable problem.

It is not, I think.

Still, it is a set of tradeoffs. The IETF has a set of requirements, and one needs to balance them all. For instance, bigger room blocks mean some more risk / smaller pool of hotels to choose from / at least theoretically higher price. I readily acknowledge though that we have not succeeded as well as we should have in some recent cases, such as the BA hotel block size combined with the fact that the next hotels were not across the street.

> [MB] My personal thought here is that the change has been due to the fact that we seem to be going to more exotic venues and also to venues that are more touristy destinations - e.g., Orlando during one of the busiest weeks of the year, Europe in the summer, Hawaii in November, etc.

Out of the last fifteen meetings:

Yokohama, Prague, Dallas, Honolulu, Toronto, London, Vancouver, Berlin, Orlando, Atlanta, Vancouver, Paris, Taipei, Quebec, Praque, Beijing

I count only two (Honolulu and Orlando) that were clearly touristy destinations. I’m not sure you should count summer meetings in Europe as touristy, we still plan to meet somewhere during summers - unless of course we go the Adelaides and Buenos Aireses during the northern hemisphere summer :-)

In any case, I think given our participants, it seems fair to have something resembling the 1-1-1* circulation model. We could discuss whether there should be more standardisation of the destinations in those areas. In the last 15 meetings there was two repeats (Prague and Vancouver) where I think we had successful meeting environments. We have one announced repeat coming up soon, and the IAOC is working on several more. I expect at least two of those to succeed, maybe more.

I take the guidance to the IAOC should be at least:

- make sure the room blocks are better sufficient than they have been in last meetings
- use successful meeting places multiple times

What else?

> prefers Minneapolis

Personally, I love cold places, particularly during winter. But for the record, Minneapolis has some drawbacks, too, such as flight connections being somewhat limited compared to, say, Vancouver or Dallas or Atlanta. In my experience, at least. The IETF has been to many hotels and cities where we’ve had a great experience from their meeting environment and sufficient availability of rooms.

Jari