Re: IETF hotel selection mode and a proposal (was" Re: Hilton BA is Booked already?)

John C Klensin <john-ietf@jck.com> Wed, 13 January 2016 00:27 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 20D151A911F for <ietf@ietfa.amsl.com>; Tue, 12 Jan 2016 16:27:45 -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 Nut82pXJpIyH for <ietf@ietfa.amsl.com>; Tue, 12 Jan 2016 16:27:43 -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 94A8A1A911D for <ietf@ietf.org>; Tue, 12 Jan 2016 16:27:43 -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 1aJ9Ho-000Fkd-JR; Tue, 12 Jan 2016 19:27:40 -0500
Date: Tue, 12 Jan 2016 19:27:35 -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: <D93CF3292E287317A11ACB1F@JcK-HP8200.jck.com>
In-Reply-To: <p06240602d2baf1b32bc7@[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]> <04902D3FAB4E2A56D0D2F985@JcK-HP8200.jck.com> <p06240602d2baf1b32bc7@[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/M4W5uLIGbdwHXkCKMtS8zAqhUJA>
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: Wed, 13 Jan 2016 00:27:45 -0000


--On Tuesday, January 12, 2016 10:16 -0800 Randall Gellens
<rg+ietf@randy.pensive.org> wrote:

>...
>>  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.
> 
> I'm not fond of hard rules, and would be fine if we had some
> clear information as to why this city was chosen despite the
> room block issue.

I think Ole, Fred, and others have already answered that
question.  The IESG decided that we should go to South America
(whether they or IAOC came up with the idea seems to be in
dispute).  The community was asked if that would be ok (without
mentioning the implications for the hotel situation), came up
with answers the IESG interpreted as "yes', and then the
Meetings Committee moved ahead to make the best arrangements
possible given that the decision to go to Buenos Aires had
already been made.

Now, you probably see some problems with that sequence of events
(and I do too), but it seems to me that, if the Meetings
Committee is given what it reasonably construes as instructions
from the IAOC and/or IESG to hold a meeting in a particular
place at a particular time, then what we ended up with is
exactly what one should expect unless there are definite rules
that say "either these conditions MUST be met or you need to
come back to the community for explicit approval with the rule
for which an exception is proposed explicitly identified".
Noting comments from Ole, Bob Hinden, and others, there also
better be _very_ few such rules because the various systems are
easily overconstrained.

> Which of course is an example of your calls
> for transparency. Maybe a semi-rigid rule that can be
> overridden with good cause (sort of a SHOULD rather than a
> MUST)?

See above.

    john