Re: Hawaii Block - going, going, gone for Saturday

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 03 September 2014 20:31 UTC

Return-Path: <brian.e.carpenter@gmail.com>
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 879D11A6FAB for <ietf@ietfa.amsl.com>; Wed, 3 Sep 2014 13:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 CI13BjzfY8h1 for <ietf@ietfa.amsl.com>; Wed, 3 Sep 2014 13:31:29 -0700 (PDT)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 676B51A6F70 for <ietf@ietf.org>; Wed, 3 Sep 2014 13:31:19 -0700 (PDT)
Received: by mail-pa0-f54.google.com with SMTP id fb1so18078851pad.41 for <ietf@ietf.org>; Wed, 03 Sep 2014 13:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kNLkY9lApUlEBdKfwZui8sOV1R5PEYZqS1Nom5Y/7sI=; b=uzrwp1wU7rTXPFhfrwQ652WonmHLs7oib3H0SD0dPXAQs4VkzEGaSVcRBe8VocPZTM vKEBdUuUopIkeEizuzYaaSHe+NbKvnBE5VXeXg8HtwRh0jDy6b3Z18X0dnPLEz5KjT94 UN38/oH2YceO0dtwCnk0+qbenEwZ2vU6vetpapUN6siqEMtCMXjxAJjfvCGX8FQ5Y6Zh u/+Jka7b6qkLeTKcSyLYdIKysFTX0mSc8rt3on0cYX7NjMGezxIS5Cmcyt7QPIxIzmF0 rINvK+ASxFQ0G0+axdpLmgBkUHnb9UZqEG4zYB+Vb+YZpS9iRj5rqY3khLEGeohMePcc I9Uw==
X-Received: by 10.66.154.234 with SMTP id vr10mr34215pab.44.1409776278935; Wed, 03 Sep 2014 13:31:18 -0700 (PDT)
Received: from [192.168.178.23] (71.193.69.111.dynamic.snap.net.nz. [111.69.193.71]) by mx.google.com with ESMTPSA id zr6sm7635720pbc.50.2014.09.03.13.31.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Sep 2014 13:31:18 -0700 (PDT)
Message-ID: <54077AAC.8040509@gmail.com>
Date: Thu, 04 Sep 2014 08:31:40 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Ray Pelletier <rpelletier@isoc.org>
Subject: Re: Hawaii Block - going, going, gone for Saturday
References: <20140826213208.12469.qmail@joyce.lan> <7F6E6339-9126-416A-A624-F1A7428B12A0@ecs.soton.ac.uk> <EMEW3|0311e95c5dde8df0ab05251b7ca72087q7PNCN03tjc|ecs.soton.ac.uk|7F6E6339-9126-416A-A624-F1A7428B12A0@ecs.soton.ac.uk> <53FD1A7B.2070108@gmail.com> <CAC1-dtkgsyyD6UptB5ejUk7B5Qf0fM0AcJeSqE8ZM3MHvD+1AQ@mail.gmail.com> <2F424559-DD27-4DE3-ABAC-0A2B8E7EAA73@piuha.net> <FC63BF7C-5C9F-4A40-B032-0EA6BC99EB50@netapp.com> <FED39F20-0810-4FAE-853C-5790519B7F6C@isoc.org> <54070A7B.9050002@cisco.com> <26BE2541-AB55-4A1E-9CB0-2B96D8A6748A@isoc.org>
In-Reply-To: <26BE2541-AB55-4A1E-9CB0-2B96D8A6748A@isoc.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/B6bIfHQC7Hf3p08zVTF8MYa5v2w
Cc: IETF Discussion <ietf@ietf.org>, Stewart Bryant <stbryant@cisco.com>
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: <http://www.ietf.org/mail-archive/web/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: Wed, 03 Sep 2014 20:31:31 -0000

Ray,

I can understand why you didn't have contractual arrangements
with other hotels, but the web site doesn't even identify a few
nearby hotels - it doesn't even mention the fact that we will
be in Waikiki, which consists mainly of hotels. Naturally people
have all tried to get into the main hotel, which breaks your normal
statistical assumption of 600 beds.

Regards
   Brian Carpenter

On 04/09/2014 01:03, Ray Pelletier wrote:
> On Sep 3, 2014, at 8:32 AM, Stewart Bryant <stbryant@cisco.com> wrote:
> 
>> Ray
>>
>> This looks like we only got 600 rooms in the block at a meeting
>> that we would expect to get over 1000 people at and where pretty
>> much everyone needs to travel to.
>>
>> Is that the normal ratio we assume for planning and why were
>> there no backups listed this time?
> 
> For the Hilton Hawaiian Village we contracted for (“booked”) 600 rooms on a peak night, 
> 3,459 room nights all together.  
> 
> We book nights over a 12 day period which provides room availability for staff and 
> contractors to arrive the Wednesday before, through the Sunday after the meeting.
> 
> Our contracts provide that the Hotels will make our rates available up to 3 days before and
> after the meeting, if there is space available.  
> 
> The HiltonHV has about 3,000 rooms, but other groups have room blocks and the Hilton 
> needs to check with the other groups to see if they are prepared to give up some rooms 
> in response to our request for more rooms.  
> 
> We did look into overflow hotels (backups) but we chose not to enter into a contract 
> because the hotels wanted Attrition clauses whereby we (ISOC) would be liable for making 
> up the difference in sales if we didn’t meet at least 80% of the room block.  Their reason 
> for the Attrition clause: they are concerned that there are so many hotels in the area where 
> our attendees could elect to book that without the Attrition, they will not agree to contract.  
> And they are right. There are many hotels in the area at various price points that signing a 
> contract with an attrition clause would be to assume unacceptable risk.  We (ISOC) have never 
> paid for not meeting our contracted block for an IETF meeting.  
> 
> As a matter of practice I like to book 600 on a peak night, about 50% of the expected attendance.  
> Often we can get that at the HQ hotel, but not always.  Sometimes it’s only 400.  Yokohama is 
> about 300, Buenos Aires is much less also. 
> 
> I will then do Overflow Hotels to get us up to the 600, and beyond if there is no Attrition clause 
> in the contracts AND if we can get a better deal for the community than they can get for themselves.  
> But this is an art not a science.  In Anaheim we were surrounded by lots of hotels at different price 
> points providing all kinds of competition for the HQ hotel.  We typically don’t do overflows in that 
> scenario and our HQ room block will likely be lower than 600.  In Paris we did a HQ hotel and the 
> hotel across the street.  We were negotiating with others but they wanted $300 a night.  We didn’t 
> contract with them.  
> 
> I hope this provides some context.
> 
> Ray
> 
> 
> 
>> - Stewart
>>
>>
>> On 03/09/2014 13:15, Ray Pelletier wrote:
>>> All,
>>>
>>> I want to update you on the numbers for what has been reserved by attendees as of
>>> Tuesday 2 September compared to what was blocked.
>>>
>>> 		Block	Reservations
>>> Mon		0		1
>>> Tues		0		8
>>> Wed		10		19
>>> Thur		15		32
>>> Fri		60		127
>>> Sat		270		375
>>> Sun		552		558
>>> Mon		600		563
>>> Tues		600		560
>>> Wed		582		557
>>> Thur		528		551
>>> Fri		183		386
>>> Sat		54		95
>>> Sun		5		2
>>> 		3,459	3,844
>>>
>>> Of course we have asked for more to accommodate the demand, but
>>> I am not optimistic.  I will report back when we have heard about
>>> our request.
>>>
>>> Ray
>>>
>>> On Sep 3, 2014, at 7:19 AM, Eggert, Lars <lars@netapp.com> wrote:
>>>
>>>> On 2014-8-27, at 16:56, Jari Arkko <jari.arkko@piuha.net> wrote:
>>>>> For your information, Ray and the secretariat are looking into the room block situation. Stay tuned.
>>>> Is there any new information? Co-workers are not succeeding in booking rooms.
>>>>
>>>> Lars
>>
>> -- 
>> For corporate legal information go to:
>>
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>
> 
>