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

Ted Lemon <mellon@fugue.com> Fri, 12 August 2016 18:20 UTC

Return-Path: <mellon@fugue.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 A616812D8BE for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 11:20:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 gVsZn_Fmvegb for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 11:20:33 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 4AF9512D7D0 for <ietf@ietf.org>; Fri, 12 Aug 2016 11:20:33 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id o80so50430309wme.1 for <ietf@ietf.org>; Fri, 12 Aug 2016 11:20:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jv0k0BtaWLPkOXbVvN1P/MOEKe3+gOq1xc/uRxu04aM=; b=er6/n0kOmehUZePSPMLCK6gNZbGzhFW2QKMvHhWyvpKjVtjzCChEEPUPRwC6JNzihY kmSnQKxlPW3fdvlapR07QPm6qxYtyB0LVtLfPPKYmOxE04c6uZeXmEYcZU4JZaKMTdBw ic6f0m4EItptqs1HIFQBq7+xF2nlOmZU/z+Q/6cEIinJ7VfeZbpgUV0oimScT/hICNYf olNVjziGB2IHGUb0U8Ngm4xWN65FSqvzks982xWTiIdiu4QA6GtV09nYOM8GUuoHpiWn qpM36KNuMMFvor5cDjKoe/lswSwm645wp2GTQrg0tlxZyxZbndyeHSK28RLM5RF58dUr 7EaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jv0k0BtaWLPkOXbVvN1P/MOEKe3+gOq1xc/uRxu04aM=; b=Zkj9RGBySIRlIY+iRFw+u2j6WoXJILhhBtmQktJAPskcrK+aFG4kY1AAPt2nL2sjF7 2FeSmlJBfXeWOVFgrayoVQ6p6F62t/V0zmrxvWVuMA0nk+iPsyCLyZr9ZjIH5AIMBfmC wk+eFKkK61Jh7aLls/33Hay/cOKbR3jVtpKZ4I9ubfjC2fliOsKMHjwrH3F9QN1r3onz d7Zr84GgmIz7rSG05UDhOw4Hdj3EddmHY8opoy+Pl/W+8sAXjZLzQuEu0jHhjwWxl8rs 4p+wVk+d95HQTCQPoRZoinP006agxD78BahDD+spBXBJ8XzyPmT+34JP+vopvcmxL1+L hgLQ==
X-Gm-Message-State: AEkoouvbYhd8zJv9Pjrej+s8Qn7VQ3wZrQC3rYQjkypglzPl9vH90diy2WO8hSIl1/cFWbLnLUzPaJx+YB5IOw==
X-Received: by 10.25.131.150 with SMTP id f144mr2791380lfd.53.1471026029632; Fri, 12 Aug 2016 11:20:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Fri, 12 Aug 2016 11:19:48 -0700 (PDT)
In-Reply-To: <58ceaef5-77fc-5833-a7a0-c5eae8ed21a3@dcrocker.net>
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: Ted Lemon <mellon@fugue.com>
Date: Fri, 12 Aug 2016 14:19:48 -0400
Message-ID: <CAPt1N1kVak0rR9t06pC-GmVXLY3MCCgv1Ld-gC40NrAR43-VpA@mail.gmail.com>
Subject: Re: IETF 97 - Registration and Hotel Reservations Open Now!
To: IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f20b8f3cc7c0539e3ef42"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/GHWzSI4lrF5oyKH6I-PDNq1ZGQI>
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 18:20:35 -0000

FWIW, I got a Saturday-to-Saturday booking on the first try, about a half
hour after the announcement came out--at that point a lot of rooms were
already gone, including all of the executive rooms.  I suspect what's going
on is that the reservation system isn't handling fragmentation very well.
We can complain about that all we want, but it's simply out of the scope of
something that the IETF can get in a contract with a hotel to try to fix
their IT infrastructure.   The fact that we see this a lot is most likely
because we are interacting with the same system the same way a lot.

The only way to make this work better would be for the IETF to set up a
system where people could bid in advance on what they want, and contention
could be resolved with a random number generator rather than who got there
first.   This would be a lot fairer for people in non-US time zones, and
would probably generate a _lot_ more discussion on the IETF mailing list. :)

On Fri, Aug 12, 2016 at 2:12 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 8/12/2016 10:55 AM, John C Klensin wrote:
>
>> (i) the IAOC should be making the hotel contracts public (at
>> least in redacted form) so that the community can review them
>> and make suggestions about the importance of situations like
>> this, how to avoid them, and how important it is to do so or
>>
>
>
> I'm on the Meetings Committee, so I get to participate in the lengthy
> process of selecting venues.  The committee does not, however, have
> anything to do with the contracting process and it has few direct
> discussions about contract details.  The committee is pretty diligent, but
> I don't remember actually seeing a contract or even believing it would be
> helpful.  (And I'm sure folk will be surprised to learn that I suspect I
> generate the most questions and suggestions about meeting details of anyone
> on the committee...)
>
>
> Here's why the above suggestion is exactly wrong:
>
>    The IETF community is a customer to the IAOC process.  It needs to be
> very clear about its functional/cost/etc. requirements about venues and it
> needs to press to have them satisfied.
>
>    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.
>
>    Decide what geographic, cost, access, and other functional issues have
> to be resolve.  Resolve them.  Then let the folk who have to make it happen
> figure out how.
>
> In the current case, my guess is that what should be debated is how large
> a room block is needed at the main hotel.  (That probably should be in
> terms of percentage of estimated total attendance.)  You don't need to see
> a contract to settle on that choice.
>
>
> d/
>
> --
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
>
>