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

John C Klensin <john-ietf@jck.com> Fri, 12 August 2016 17:55 UTC

Return-Path: <john-ietf@jck.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 171F512DA50 for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 10:55:47 -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 g5_JckZuPivg for <ietf@ietfa.amsl.com>; Fri, 12 Aug 2016 10:55:46 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.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 D452D12DA45 for <ietf@ietf.org>; Fri, 12 Aug 2016 10:55:45 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1bYGgJ-0005o0-M7; Fri, 12 Aug 2016 13:55:43 -0400
Date: Fri, 12 Aug 2016 13:55:38 -0400
From: John C Klensin <john-ietf@jck.com>
To: Jari Arkko <jari.arkko@piuha.net>, IETF discussion list <ietf@ietf.org>
Subject: Re: IETF 97 - Registration and Hotel Reservations Open Now!
Message-ID: <82A17B2FC06D1F8BD216D229@JcK-HP8200>
In-Reply-To: <42234065-1C6E-4224-A48C-1186F536E02F@piuha.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>
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: <https://mailarchive.ietf.org/arch/msg/ietf/BUXFZVZRP6RHKrUR5WsEaLivjMg>
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 17:55:47 -0000


--On Friday, August 12, 2016 15:51 +0200 Jari Arkko
<jari.arkko@piuha.net> wrote:

> Folks,
> 
> Secretariat is looking onto the status of our blocks. Stay
> tuned.
> 
> FWIW, some people have succeeded in booking in smaller
> increments, a friend of mine just booked 11-12th and 12-18th
> separately even if 11-18th was unavailable. But for the
> 18-19th he would have gotten a price hike.

Jari,

If this were the first time something equivalent to "the hotel
block and advertised IETF rates are not actually available, at
least without gaming the reservation system by, e.g., creating
one or more separate reservations" had occurred, your comment
above would be not only reasonable and appropriate but all that
should be necessary.  However, this (or close approximations to
it) seems to occur over and over again.  

That suggests to me that something is wrong with our hotel
contracts, allowing the hotels to try to get away with behavior
that the community considers unreasonable.   It also suggests to
me that either 

(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 

(ii) the community is entitled to an effective way to hold the
IAOC (and, in particular the IAD) accountable when problems like
this occur, no matter how effective the Secretariat is about
negotiating more reasonable arrangements after the fact.

I intend this as an accusation of ineffectualness or inattention
to details that the community might reasonable consider
important, not any sort of malice, but the issue that this keeps
recurring, we keep having to notice and discuss it, and the
Secretariat keeps needing to try to come to the rescue, seems to
be worth attention.  

I do, however, suspect some malice (or at least deceptive
dealings) on the part of the hotel(s).  Not only does this keep
recurring, but, when I regularly got into the meeting planning
business many years ago, I was told that two members of the
"oldest tricks in the book" list for lodging properties were to
come up with an attractive promotion or conference rather and
either make sure that almost no one could take advantage of it
or to create sufficient barriers to its use that anyone who was
not truly price-sensitive would simply pay the higher rates to
avoid spending the time and energy to jump through the required
hoops.    With regard to the IAOC and this situation, there is
an old says in parts of the US that I believe has analogies in
other cultures.  The local version is "fool me once, shame on
you; fool me twice, shame on me".


Finally, I find one or two comments on this thread even more
troubling than the particular issue with the meeting hotel,
especially in the light of IETF's growing emphasis on
anti-bullying, anti-harrassment, and anti-discriminatory
policies.    I prefer to treat it as an educational opportunity
rather than lodging complaints but a statement like "If anyone
considers not staying at the primary hotel as a basic reason not
to attend an IETF meeting, there almost certainly are deeper
issues to worry about" can reasonably be interpreted in either
of two ways (I am sure there are other interpretations as well,
but our various policies appear to be intended to deal with
these sorts of interpretations):

(a) A vaguely-disguised way to assert that something is
mentally, emotionally, or otherwise wrong with whomever raised
the issue.   As far as I know, we don't allow such assertions,
even in disguise, on IETF lists any more.

(b) A demand that the person who raised the issue explain (and
perhaps justify) his or her criteria for attending meetings, or
the role of the conference hotel in that decision, to the
community in order for the issue/concern to be taken seriously.
I actually find that more troubling than mere name-calling
because it seems to me to cross some important privacy and
related lines.  It would be, IMO, unfortunate indeed if the
ability to raise an issue in the IETF became tied up with what
our lawyer friends call "standing" -- being required to explain
why and how one was personally affected by an issue in order to
start a discussion about that issue.  Any of us should be able
to say "that may be an issue for people with a particular food
allergy" without disclosing whether we have that allergy, "that
may be an issue for people with a particular perceived
disability or medical problem" without disclosing whether we
have that particular issue, and even "this situation with the
conference hotel affects my decision about whether to come to
the meeting" without having to disclose exactly why or to
justify why my decision process is rational.  

Others may, of course, choose to ignore my concerns.  I might
choose to disclose those things as a way to convince others to
take the concerns seriously.  But I suggest that no one gets to
tell me there is something wrong with me for having the concerns
or to force me to defend against that claim by disclosing the
details that motivate my criteria and decisions.

     best,
       john