Re: IETF hotel selection mode and a proposal (was" Re: Hilton BA is Booked already?)
John C Klensin <john-ietf@jck.com> Tue, 12 January 2016 14:24 UTC
Return-Path: <john-ietf@jck.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 017881B2A4B for <ietf@ietfa.amsl.com>; Tue, 12 Jan 2016 06:24:52 -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, RP_MATCHES_RCVD=-0.001] 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 KrkwAS-2RLZp for <ietf@ietfa.amsl.com>; Tue, 12 Jan 2016 06:24:50 -0800 (PST)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65451B2A43 for <ietf@ietf.org>; Tue, 12 Jan 2016 06:24:50 -0800 (PST)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1aIzsP-000Eag-6Y; Tue, 12 Jan 2016 09:24:49 -0500
Date: Tue, 12 Jan 2016 09:24:44 -0500
From: John C Klensin <john-ietf@jck.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>, ietf@ietf.org
Subject: Re: IETF hotel selection mode and a proposal (was" Re: Hilton BA is Booked already?)
Message-ID: <04902D3FAB4E2A56D0D2F985@JcK-HP8200.jck.com>
In-Reply-To: <p06240602d2ba0deec939@[99.111.97.136]>
References: <076c01d138e7$0a68dba0$1f3a92e0$@olddog.co.uk> <5672E4BB.2050702@dcrocker.net> <FA905E0564B6E47B70076F92@JcK-HP8200.jck.com> <p06240602d2ba0deec939@[99.111.97.136]>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/D6-hXvWkij-TpeMimcfUbdaNwaw>
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: Tue, 12 Jan 2016 14:24:52 -0000
--On Monday, January 11, 2016 18:01 -0800 Randall Gellens <rg+ietf@randy.pensive.org> wrote: >... > I'd like to point out the obvious, which is that there are two > parts to the hold-back number. Expanding the IETF room block > from 400 to, say, 800 or 900, would be a way to shrink the > percent and cut way back on the "how can the hotel be sold out > within an hour of the announcement" complaints. But that gets back to an example of the same old set of tradeoffs --and my desire that those involved in the process be a lot more transparent about it. Your comment above is reasonable and even obvious. But there are cities (apparently including Buenos Aires) where there are approximately zero hotels that have enough rooms to give us an 800 or 900 room block. So, would you propose a hard rule of "stop considering any city unless we could got a room block of at least N rooms", with N somewhere in the range of 800 or 900? Unlike the variety of more subjective rules, it would be very clear and easy to interpret. My assumption about IETF 95 is that, despite understanding and considering the disadvantages of smaller hotels, the decision-makers believed they had a sufficient "go to Buenos Aires" mandate to override hotel or room block size considerations. I presume that, for the future, we could change that if we had consensus that, e.g., minimum room block size was a firm requirement. john
- RE: IETF hotel selection mode and a proposal (was… Adrian Farrel
- Re: IETF hotel selection mode and a proposal (was… Stephen Farrell
- Re: IETF hotel selection mode and a proposal (was… Dave Crocker
- Re: IETF hotel selection mode and a proposal (was… Kathleen Moriarty
- Re: IETF hotel selection mode and a proposal (was… Alia Atlas
- RE: IETF hotel selection mode and a proposal (was… Christian Huitema
- Re: IETF hotel selection mode and a proposal (was… Alia Atlas
- Re: IETF hotel selection mode and a proposal (was… John C Klensin
- Re: IETF hotel selection mode and a proposal (was… Ole Jacobsen
- Re: IETF hotel selection mode and a proposal (was… Dave Crocker
- Re: IETF hotel selection mode and a proposal (was… John Levine
- Re: IETF hotel selection mode and a proposal (was… Christian Hopps
- RE: IETF hotel selection mode and a proposal (was… MAISONNEUVE, JULIEN (JULIEN)
- RE: IETF hotel selection mode and a proposal (was… Ole Jacobsen
- Re: IETF hotel selection mode and a proposal (was… Behcet Sarikaya
- Re: IETF hotel selection mode and a proposal (was… Lou Berger
- Re: IETF hotel selection mode and a proposal (was… Randall Gellens
- Re: IETF hotel selection mode and a proposal (was… John Levine
- Re: IETF hotel selection mode and a proposal (was… John C Klensin
- Re: IETF hotel selection mode and a proposal (was… Eliot Lear
- Re: IETF hotel selection mode and a proposal (was… Randall Gellens
- Re: IETF hotel selection mode and a proposal (was… John C Klensin
- Re: IETF hotel selection mode and a proposal (was… Randall Gellens