Re: Hotel situation

Toerless Eckert <eckert@cisco.com> Fri, 18 December 2015 17:16 UTC

Return-Path: <eckert@cisco.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 83F7C1B375B for <ietf@ietfa.amsl.com>; Fri, 18 Dec 2015 09:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 J4A2P7YLEn4l for <ietf@ietfa.amsl.com>; Fri, 18 Dec 2015 09:16:57 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02A81B375A for <ietf@ietf.org>; Fri, 18 Dec 2015 09:16:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5768; q=dns/txt; s=iport; t=1450459016; x=1451668616; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=NDQqTS9V2Ap+VDtO7rqGpsr7OF8f2BFXaL2l3sAXvlM=; b=bAf3HWSYD2gt0gehL1HdvrMKo4MMUQ8BIvC7ZXARCiekOaXVGf3Fy2Vj KAruLchShwHc+BcMFljdXaZ+4V/56E+ZH2EkP8ROmHuDM2Q0ixj01RTlH o6hQWVXK5YqDOBPRvnLrWHXhE2bHd7K2En0EnfXg0XG24FTzPmhGqZLSb k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DEDgA5PnRW/49dJa1egzpSLEG2I4kjIYIsg0ACgTo7EQEBAQEBAQGBCoQ0AQEBAwE6LhEFCwsYCSUPBUkTHogJCA69TAEBAQEBAQEBAQEBAQEBAQEBAQEBARiKToEGhDQEg26BGgWHXIZSiFGFO4JxhRUJgiWbBDgsghEdgXcdNINGBIFHAQEB
X-IronPort-AV: E=Sophos;i="5.20,447,1444694400"; d="scan'208";a="219478832"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Dec 2015 17:16:56 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id tBIHGtUW002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Dec 2015 17:16:55 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id tBIHGtJK029186; Fri, 18 Dec 2015 09:16:55 -0800
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id tBIHGsTb029185; Fri, 18 Dec 2015 09:16:54 -0800
Date: Fri, 18 Dec 2015 09:16:54 -0800
From: Toerless Eckert <eckert@cisco.com>
To: Warren Kumari <warren@kumari.net>
Subject: Re: Hotel situation
Message-ID: <20151218171654.GA27965@cisco.com>
References: <8D23D4052ABE7A4490E77B1A012B630797A09BC1@mbx-03.WIN.NOMINUM.COM> <56719864.8010604@gmail.com> <8D23D4052ABE7A4490E77B1A012B630797A09C09@mbx-03.WIN.NOMINUM.COM> <56719B42.2040902@gmail.com> <alpine.OSX.2.01.1512160924570.39773@rabdullah.local> <D296DF8F.8DA39%glenn.deen@nbcuni.com> <1DEF233B-FBA8-4750-AB4B-3E0F55822C9E@isoc.org> <D297326B.8DCF8%glenn.deen@nbcuni.com> <CAC8QAcf=yAAGVN35tUCpX38y6_qGstGhK4iYuyhK94LVWrz-+A@mail.gmail.com> <CAHw9_iL+eAFtGHKXVWMHaqi=3mGO9H1CfE4e=yZCekE9UzPR6A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAHw9_iL+eAFtGHKXVWMHaqi=3mGO9H1CfE4e=yZCekE9UzPR6A@mail.gmail.com>
User-Agent: Mutt/1.4.2.2i
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ycMH5ZzaJalP24dyV_qAhaNjR5c>
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: Fri, 18 Dec 2015 17:16:59 -0000

On Thu, Dec 17, 2015 at 06:10:04PM +0000, Warren Kumari wrote:
> Yup. I have been to a number of IEEE meetings and stayed in the IEEE hotel
> in order to get the discount - the next 802 Plenary is at the Venetian in
> Macau. The registration page (
> http://802world.org/plenary/ieee-802-group-hotel/ ) says:
> -------------------------------
> Group Hotel Registration Policy
> The combined hotel room stays of attendees are used to offset the cost of
> the meeting. For this reason, anyone who is not a registered guest at the
> Sands Venetian Macao Hotel for three (3) or more nights is not eligible for
> the registration discount ($US 450.00).
> ------------------------------
> 
> The room rate starts at 1,550.00MOP (~$180USD). The discounted registration
> fee is $600USD.
> The non-discounted fee is $1050USD.

3000 rooms there. If every attendee could get a room at the $180 rate,
then this wouldn't be such a bad deal. Seems like the opposite of the current 
IETF problem: Large hotel with too many rooms that need to be filled. And
several other competing hotels in walking distance.

WOuld be interesting to know if IETF ever ran into the problem
of not filling up blocked rooms... 

> The IEEE seems to have many fewer requirements / expectations from their
> attendees.
> For example, one of the recent meetings was in the Estrel in Berlin, a
> hotel which would not suit the IETF at all.

Why not ? 1150 room would be perfect size. Probably because IETF wouldn't
reserve enough of the conference space, so we wouldn't get a good deal with them ?

> Perhaps if IETF attendees didn't demand everything that we do (lots of
> breakout rooms, walking distance to bars and restaurants, no trains, the
> ability to install and run our own network, not being in Minneapolis, large
> cookies, specific price points, a willingness to keep going back to the
> same N locations) we wouldn't have so much kvetching.

+1 on almost everything. I think inexpensive helps diversity, and
number of breakout rooms is just at the core of our work.

And ++1 on Minneapolis in November again.

Cheers
    Toerless
> 
> W
> 
> 
> 
> 
> > Behcet
> > >
> > >
> > > -glenn
> > >
> > >
> > >
> > > On 12/16/15, 3:24 PM, "Ray Pelletier" <rpelletier@isoc.org> wrote:
> > >
> > >>Glenn,
> > >>
> > >>> On Dec 16, 2015, at 12:54 PM, Deen, Glenn (NBCUniversal)
> > >>><glenn.deen@nbcuni.com> wrote:
> > >>>
> > >>>    Q- What??s the room block size we are getting at the recent venues
> > >>> compared to what we got at previous ones like Vancouver, or Berlin?
> > >>
> > >>There are many hotels in Buenos Aires but they do not have many rooms.
> > >>
> > >>When we announced on 10 December that registration would open on 16
> > >>December
> > >>we said:
> > >>
> > >>Registration and hotel reservations for IETF 95 in Buenos Aires will
> > >>open at 1500 UTC Wednesday, December 16. Hotel reservations will include
> > >>the headquarters hotel and the contracted overflow hotels available
> > >>at that time.
> > >>
> > >>Because hotels in Buenos Aires have a limited number of guest rooms,
> > >>the IETF has been negotiating contracts with ten hotels.  Hotels not
> > >>available on December 16 will be announced when available.
> > >>
> > >>On 16 December we said:
> > >>
> > >>1. Hilton Buenos Aires (Headquarters Hotel, block of 300 rooms)
> > >>2. Holiday Inn Express Puerto Madero (30 rooms)
> > >>3. Sheraton Buenos Aires (140 rooms available)
> > >>4. InterContinental Buenos Aires (150 rooms)
> > >>5. Sheraton Libertador Hotel (70 rooms)
> > >>
> > >>Buenos Aires is not Vancouver, Berlin, London, Paris or San Francisco.
> > >>It's more like Dublin, if you recently attended the ICANN conference
> > >>there.
> > >>
> > >>>
> > >>>    Q - Are hotels artificially limiting availability of the IETF block
> > >>>by
> > >>> only releasing parts of it to the web booking?
> > >>>        I??ve seen hotels do this for other events.  While the whole
> > block
> > >>> maybe 500 rooms, they release them in 50 room blocks as the
> > >>>        reservation block fills.  This creates the lucky 10th caller
> > >>> scenario, where if you hit it at just the right time you win.
> > >>
> > >>That's not the case here, or anywhere we have negotiated agreements.
> > >>
> > >>We strive to contract for 600 on a peak night at the so-called
> > >>headquarter's hotel,
> > >>but it depends on where we are. If we are in an area surrounded by
> > >>hotels, and
> > >>at lower price points, we might contract for 400 on a peak night, and
> > >>overflow
> > >>hotels for another 200 - 300 rooms on peak to get 780 rooms on peak.
> > >>
> > >>Typically if we don't get our target room block it's because there's
> > >>another group
> > >>at the hotel, or sometimes it's because the hotel is concerned about the
> > >>risk
> > >>of setting aside 70 - 90% for a group they've never done business with.
> > >>This concern
> > >>is also typically reflected in the cancellation provisions for guest
> > >>rooms they will
> > >>sign up to, and/or when they start cutting back the number of rooms in
> > >>the block.
> > >>All of which is evident in our first meeting in Latin America and Buenos
> > >>Aires.
> > >>
> > >>For those who managed to make a reservation outside the IETF block, but
> > >>at a
> > >>higher price, we are trying to get you in the block at the IETF rate.
> > >>
> > >>Another 4 or so IETF contracted hotels are in the works and will be
> > >>announced
> > >>as soon as they are ready.
> > >>
> > >>Ray
> > >>
> > >>
> > >>>
> > >>> -glenn
> > >>>
> > >>>
> > >>
> > >
> >
> >

-- 
---
Toerless Eckert, eckert@cisco.com