Re: [EXTERNAL] Re: IETF 104 Registration and Hotel Reservations Openo
Christian Hopps <chopps@chopps.org> Tue, 15 January 2019 15:28 UTC
Return-Path: <chopps@chopps.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0569130EC8 for <ietf@ietfa.amsl.com>; Tue, 15 Jan 2019 07:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 ESsXIj9bq0D8 for <ietf@ietfa.amsl.com>; Tue, 15 Jan 2019 07:28:36 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B83D2130EBC for <ietf@ietf.org>; Tue, 15 Jan 2019 07:28:36 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2A12960466; Tue, 15 Jan 2019 10:28:36 -0500 (EST)
References: <20181220194742.39286200BC3F9B@ary.qy> <C4C3E99E-7FDF-42AD-8AAF-BA9A7BF9DF62@soton.ac.uk> <alpine.OSX.2.21.1812211147590.48467@ary.qy> <E0B84494-6B60-4AEB-B8E9-8C6F673624FA@tzi.org> <E73FC76E-6CD5-4543-A189-D51ACC7EAEBE@amsl.com> <167d262e9c8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <23396A80-F252-4FFB-B0D0-B17D86F1C73E@amsl.com> <44640168-deb7-c613-3420-ad5df95b1736@labn.net> <956E76FA5156981CD09F5C1F@PSB> <098ecda6-b344-7cb7-5943-d6279ee89108@labn.net> <7C9DD929-2301-4993-9B03-A15B41B8D664@nbcuni.com> <sa6va2qotld.fsf@chopps.org> <CAPt1N1n7=eZqABbejLCuURMpJCQJE8WL3xuOrMTzCG5mSW9vhw@mail.gmail.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Ted Lemon <mellon@fugue.com>
Cc: Christian Hopps <chopps@chopps.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: [EXTERNAL] Re: IETF 104 Registration and Hotel Reservations Openo
In-reply-to: <CAPt1N1n7=eZqABbejLCuURMpJCQJE8WL3xuOrMTzCG5mSW9vhw@mail.gmail.com>
Date: Tue, 15 Jan 2019 10:28:35 -0500
Message-ID: <sa6tviaos7w.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/V_zXuzWM7fmWgnQroyz-lvYYlTI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 15 Jan 2019 15:28:46 -0000
OK, so why not have the requirement that the hotel must lower the IETF rate for all attendees to any lower rate they subsequently advertise? Thanks, Chris. Ted Lemon <mellon@fugue.com> writes: > It might help to re-frame it. What's going on here is that the hotel is > trying (intentionally or accidentally) to sweeten their deal. They get > the IETF to agree to a room rate, and agree to hold the price in the > presence of market fluctuation. Effectively the IETF has now purchased > some futures at a particular price, and the hotel is now competing against > the IETF on that price, and they have nothing to lose because if the IETF > doesn't sell all its rooms, the IETF takes the loss, not the hotel. This > is particularly exacerbated by the fact that the hotel was selling > different rooms at different prices, whereas if you take the IETF rate you > just get whatever room you get, which is probably what's left over after > all the premium rooms are sold, since those rooms were being sold at about > the IETF rate. > > So yeah, it looks like you're losing out, but you really aren't the victim > here. > > On Tue, Jan 15, 2019 at 9:59 AM Christian Hopps <chopps@chopps.org> wrote: > >> >> Why not KISS? IETF should negotiate a fair rate that is worth what we will >> be paying *upfront*, and leave it at that. >> >> Notwithstanding the complex turns of logic presented on this thread, it >> just feels wrong for me to find a better deal only to have IETF come in >> take it away from me. >> >> Thanks, >> Chris. >> >> Deen, Glenn (NBCUniversal) <Glenn.Deen@nbcuni.com> writes: >> >> >> On Jan 6, 2019, at 12:24 PM, Lou Berger <lberger@labn.net> wrote: >> >> >> >> Obviously we can't change existing contracts, but we can stop asking >> that the "no lower rates offered" clause be inserted in future contracts -- >> again, it is my understanding (which of course can simply be wrong) that >> this clause was first added to hotel contracts by the IETF, specifically >> the IAD at that time. >> >> >> >> Lou >> > >> > I’m not sure I agree with you in this. The purpose of the clause is to >> say “the IETF negotiated rate is the lowest that the hotel will offer >> during the meeting window.” In other words they are agreeing negotiate one >> rate with the IETF as part of our overall meeting contract and agreeing to >> also not then go and negotiate a undercutting rate with some travel web >> site for instance. >> > >> > One big part of this is intended to make sure the ietf rate is the best >> rate across its whole block. Another big part related to the first is that >> ietf attendees do not need to worry they there was a better deal that they >> missed because they didn’t spend a couple >> > of hours on other travel sites, or a better deal because the booker >> early or waited. >> > >> > Being consistent for the whole IETF room block is an important part of >> this negotiation. While a hotel may offer a couple of rooms at a discount >> they certainly aren’t doing that for any number of rooms as big as the ietf >> block which can be (simplified general numbers here) 600 rooms at say 6 >> nights for a total of 3600 room nights that are available to IETF attendees >> all for the same price. >> > >> > This is as opposed to what I’ve seen on many hotel booking sights where >> the price changes up or down each night and you are >> > competing against every other customer to grab the cheapest rates before >> they are gone. Or you get a cheap first or last night and pay more for all >> the others. >> > >> > This is very different to the ietf rate which is the same for every room >> night for every attendees and is the same if you book as soon as >> registration opens or if you book just before arriving. >> > >> > The ietf gets a consistent and good rate for all its rooms and all times >> of booking. That’s a huge benefit for ietf participants, especially those >> that have to wait to get approval before booking their travel. >> > >> > Opposed to that consistency is the kind of room pricing that places like >> PriceLine engage in. Sure some individuals can get some deals occasionally, >> but it’s one thing to compete against the open market especially if you >> don’t have a particular goal of staying in a specific meeting hotel - it is >> an entirely different thing to pit IETF attendees against one another to >> edge out each other for a better room rate while leaving the scraps to >> those willing to pay the full rack rate when the supply gets low (which is >> a real and painful part of playing the hotel pricing market place). >> > >> > So I don’t agree removing the clause is in the best interest of the ietf >> community. It requires the hotel to act consistently with all IETFers who >> book a room at the hotel and it says that they do not need to waste time >> > hunting across the hotel discount sites looking for a better deal - >> because they have already got the best deal to be found on those sites. >> > >> > I will add that the IETF main mailing list is not the place to debate >> ietf meeting hotel practices. That belongs on mtgvenue@ietf.org which is >> the working group for meeting venue stuff. >> > >> > >> > Regards >> > Glenn >> >>
- IETF 104 Registration and Hotel Reservations Openo IETF Secretariat
- Re: IETF 104 Registration and Hotel Reservations … Paul Wouters
- Re: IETF 104 Registration and Hotel Reservations … Alexa Morris
- RE: IETF 104 Registration and Hotel Reservations … Jeffrey (Zhaohui) Zhang
- Re: IETF 104 Registration and Hotel Reservations … Chown T.
- Re: IETF 104 Registration and Hotel Reservations … Andrew G. Malis
- Re: IETF 104 Registration and Hotel Reservations … Chown T.
- Re: IETF 104 Registration and Hotel Reservations … John Levine
- Re: IETF 104 Registration and Hotel Reservations … Giovane Moura
- Re: IETF 104 Registration and Hotel Reservations … Chown T.
- Re: IETF 104 Registration and Hotel Reservations … Andrew G. Malis
- Re: IETF 104 Registration and Hotel Reservations … John R Levine
- Re: IETF 104 Registration and Hotel Reservations … Carsten Bormann
- Re: IETF 104 Registration and Hotel Reservations … Alexa Morris
- Re: IETF 104 Registration and Hotel Reservations … Lou Berger
- Re: IETF 104 Registration and Hotel Reservations … Alexa Morris
- Re: IETF 104 Registration and Hotel Reservations … Udeme Ukutt
- Re: IETF 104 Registration and Hotel Reservations … Lou Berger
- Re: IETF 104 Registration and Hotel Reservations … John C Klensin
- Re: IETF 104 Registration and Hotel Reservations … Lou Berger
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Deen, Glenn (NBCUniversal)
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Lou Berger
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Mary B
- Re: [EXTERNAL] IETF 104 Registration and Hotel Re… Eric Burger
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Christian Hopps
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Ted Lemon
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Christian Hopps
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Ted Lemon
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Michael Richardson
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Andrew G. Malis
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Ted Lemon
- Re: [EXTERNAL] Re: IETF 104 Registration and Hote… Mary B
- RE: [EXTERNAL] Re: IETF 104 Registration and Hote… Belotti, Sergio (Nokia - IT/Vimercate)
- Re: [EXTERNAL] IETF 104 Registration and Hotel Re… Yoav Nir