Re: IETF 97 - Registration and Hotel Reservations Open Now!

Adam Roach <adam@nostrum.com> Fri, 12 August 2016 22:32 UTC

Return-Path: <adam@nostrum.com>
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 8B1D912D501 for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 15:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 2eTfWx6IcIyc for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 15:32:53 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5670C12D0DB for <ietf@ietf.org>; Fri, 12 Aug 2016 15:32:53 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7CMWm1h075393 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Aug 2016 17:32:49 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Subject: Re: IETF 97 - Registration and Hotel Reservations Open Now!
To: dcrocker@bbiw.net, John C Klensin <john-ietf@jck.com>, Jari Arkko <jari.arkko@piuha.net>, IETF discussion list <ietf@ietf.org>
References: <147094744424.21281.7915555432277043072.idtracker@ietfa.amsl.com> <57AD2730.8050602@swin.edu.au> <9916BCD4DBD65FB7D44A6F88@JcK-HP8200> <953016d5-6f64-bd94-c221-95d96f693c2c@dcrocker.net> <7594FB04B1934943A5C02806D1A2204B4BBDEDF4@ESESSMB208.ericsson.se> <036801d1f464$aaf1df20$00d59d60$@gmail.com> <42234065-1C6E-4224-A48C-1186F536E02F@piuha.net> <82A17B2FC06D1F8BD216D229@JcK-HP8200> <58ceaef5-77fc-5833-a7a0-c5eae8ed21a3@dcrocker.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <0f1532ed-8bcc-3b8f-e33d-7f361ee33065@nostrum.com>
Date: Fri, 12 Aug 2016 17:32:47 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <58ceaef5-77fc-5833-a7a0-c5eae8ed21a3@dcrocker.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/egtzYwjbHg1S-apIR5L_4xZYVcU>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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, 12 Aug 2016 22:32:54 -0000

On 8/12/16 13:12, Dave Crocker wrote:
>    What it does /not/need to do is emulate administrative and legal 
> staff tasks of implementing those requirements.  To have the general 
> IETF community pore over contract details is to have invite 
> non-experts to debate about details rather than debate about 
> requirements. 


So, there's probably a balance to be struck here. Many of the provisions 
of these contracts are written for the benefit of the attendees. In lots 
of cases, these protections go against a hotel's interests, which means 
that the hotel will not be very motivated to spend a lot of energy 
making sure they're being satisfied.

However, if the people protected by these provisions don't know about 
them *either*, then they are effectively useless: neither party to the 
transaction will take action. I sent the following example to the 
meeting venue list some while back, but it bears repeating here, as it 
demonstrates the point quite vividly.

Flash back to IETF 86 in Orlando. Late Sunday, the venue hotel -- which 
had apparently overbooked quite severely -- began displacing attendees 
with valid reservations to a nearby, and significantly lower-quality, hotel:

https://mailarchive.ietf.org/arch/msg/86attendees/m_udMZ-e75GxfW_qe45c8E6ZanU

The thing is, the contract had specific provisions to make sure that 
overbooking was handled in a certain way; and the provisions that the 
hotel had agreed to in writing were far superior to what actually 
happened. But because the impacted attendees didn't know about these 
provisions, and because (absent any challenge) the hotel had no 
incentive to proactively honor them, people had a thoroughly crappy 
experience.

After things started to go sideways, Ray posted the relevant contract 
provisions 
(https://mailarchive.ietf.org/arch/msg/86all/iuQ4Q3xC4BgEPHuUUix7nrk4BXs), 
which actually look pretty good. Kudos to whomever set this up on our 
side. It's a shame that such nicely crafted contract clauses went to 
utter waste.

This kind of contractual information -- attendees' negotiated rights 
when hotels overbook -- should be in the hands of people before they 
arrive at the hotel. Had such been the case in Orlando, displaced 
attendees could have insisted that the hotel honor their agreement. Far 
from being withheld from attendees, these provisions should be published 
quite prominently.

/a