Re: IETF 104 Registration and Hotel Reservations Openo

Lou Berger <lberger@labn.net> Sun, 06 January 2019 20:24 UTC

Return-Path: <lberger@labn.net>
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 C1327130E33 for <ietf@ietfa.amsl.com>; Sun, 6 Jan 2019 12:24:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 h2M-N0nipZEs for <ietf@ietfa.amsl.com>; Sun, 6 Jan 2019 12:24:17 -0800 (PST)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE59130E30 for <ietf@ietf.org>; Sun, 6 Jan 2019 12:24:13 -0800 (PST)
Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 28F3B175DD3 for <ietf@ietf.org>; Sun, 6 Jan 2019 13:24:13 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id gExwgnvndqZYcgExxgtm97; Sun, 06 Jan 2019 13:24:13 -0700
X-Authority-Reason: nr=8
X-Authority-Analysis: $(_cmae_reason
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KDoIbrwqKDtI1VNIZoVOJ1pSdTuFUCg3dlbF07yKhJk=; b=VC6fnJ+Jz1WtfPptSifl024w+a 9Mheya6N8S3oSjPm3StEXdOIH3v/Nqt8jYsNUdVGMz8qsEQz3AlWvg92x4MqnQtUlF3NIQ1d0iKJu CLqC3lg96LhA1VuZrqwTr2h31;
Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:36584 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1ggExw-002EnB-Qi; Sun, 06 Jan 2019 13:24:12 -0700
Subject: Re: IETF 104 Registration and Hotel Reservations Openo
To: John C Klensin <john-ietf@jck.com>, Alexa Morris <amorris@amsl.com>
Cc: ietf@ietf.org
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>
From: Lou Berger <lberger@labn.net>
Message-ID: <098ecda6-b344-7cb7-5943-d6279ee89108@labn.net>
Date: Sun, 06 Jan 2019 15:24:11 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1
MIME-Version: 1.0
In-Reply-To: <956E76FA5156981CD09F5C1F@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 72.66.11.201
X-Source-L: No
X-Exim-ID: 1ggExw-002EnB-Qi
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:36584
X-Source-Auth: lberger@labn.net
X-Email-Count: 7
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/q_QezI5fGWVo_rMLnMojzygmtgE>
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: Sun, 06 Jan 2019 20:24:27 -0000

Hi John,

On 1/5/2019 4:00 PM, John C Klensin wrote:
> Lou,
>
> I know even less about the details of IETF hotel contracts than
> I used to, but let me suggest a consideration about this that
> you seem to be skipping over and that is an issue with typical
> hotel contracts for meeting attendees.  In return for whatever
> price people pay and for making representations about how many
> people the meeting will bring to the hotel, the body holding the
> meeting usually gets a number of things that don't show up in
> the rooms themselves.  That list often includes a few free (or
> significantly upgraded or reduced cost) guest rooms, free or
> discounted meeting rooms or other facilities, etc.  The deals
> are often contingent on the meeting organization filling a
> certain number of rooms at the agreed rate.

agreed.  As I thought I mentioned in an earlier message, it is my 
understanding that we receive credit for anyone who stays in the hotel 
who is also registered for the meeting.  This covers the case that I 
believe Alexa mentioned of attendees who are required to book other rates.

FWIW I'm a big fan of the way the IEEE handles this; they give you a 
break on registration iff you register in the hotel block. This seems 
like a far more rational way to police/enforce usage of the meeting 
block if that is your priority.

> Now, given that our contracts are in place years in advance,
> suppose that a hotel decides to advertise rooms at well below
> the IETF rate, perhaps to help fill the part of the house the
> IETF hasn't promised to sell.  One of us notices, takes one of
> the cheaper rooms, and announces their availability on the list.
> Unless the hotel notices (how would they?) and adjusts the
> number of rooms available at the lower rate very quickly, we
> could end up with a lot of IETF participant registrations that
> are not counted in the IETF block, potentially putting the
> IETF's guarantee of how many rooms we would fill at risk and
> imposing costs that would need to come out of the IETF budget.

right. Per the above, this is a non-risk.

> Similarly, suppose AMS manages to negotiate a rate based on the
> 24 hour cancellation policy that, judging from discussions on
> this list, many of us seem to want or need.  Then suppose the
> hotel decides that policy causes excessive uncertainty and
> offers a rate ten or 20% lower in return for a "no refunds" or
> "cancel with penalties that rise as the meeting gets closer"
> policy.

Sure -- and my hope is that our very decent (i.e., well negotiated) rate 
for this meeting is somewhat due to the 21-day cancellation clause.  
Generally nothing comes for free in these deals.  But this is really a 
different topic.

> I understand your point, but it seems to me to be very
> risky for us to go there, especially because, if the changed
> policy hurts us or make it harder for us to make guarantees
> about room blocks, other hotels could figure that out and take
> advantage of it a lot more quickly than we could change
> policies, especially about contracts already signed.

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

>     john
>
>
>
> --On Friday, January 4, 2019 12:20 -0500 Lou Berger
> <lberger@labn.net> wrote:
>
>> Hi Alexa,
>>
>> Happy new year
>>
>> Cutting to the key point:
>>> One might make the case then that we should not point out
>>> such  instances to the hotel, when they occur. However it's
>>> important that  the hotel understand that we take our
>>> contract seriously, and that we  are indeed vigilant about
>>> ensuring that the IETF guest room rate is  the best rate we
>>> can secure. This vigilance helps us in future  negotiations.
>>>
>> I think getting the hotel to remove lower rate's available
>> during the IETF week is simply counter to the interest of both
>> attendees and the IETF.  I furthermore think that any clause
>> that precludes a hotel from offering lower rates is a
>> *mistake* to include in the contract.  Having the hotel offer
>> lower rates during the IETF helps attendees immediately  and
>> the IETF in the longer term by being able to negotiate the
>> fact that lower rates were offered show that our rates were
>> too high*.  FWIW I remember when Ray instituted this practice
>> and had the obviously wrong understanding that the practice
>> had since stopped.
>>
>> I really hope AMS changes both such rate "enforcement" and
>> removes the related clause from future hotel contracts.
>
>
>