Re: Venue Announcement for IETFs 98, 99, 102 and 111

John C Klensin <> Fri, 08 January 2016 08:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8E881ACEAC for <>; Fri, 8 Jan 2016 00:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TXt0bAZMbZkt for <>; Fri, 8 Jan 2016 00:26:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4B5B1ACEAB for <>; Fri, 8 Jan 2016 00:26:28 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1aHSNK-0004e4-JQ; Fri, 08 Jan 2016 03:26:22 -0500
Date: Fri, 08 Jan 2016 03:26:17 -0500
From: John C Klensin <>
To: Ole Jacobsen <>
Subject: Re: Venue Announcement for IETFs 98, 99, 102 and 111
Message-ID: <>
In-Reply-To: <alpine.OSX.2.01.1601071125550.21147@rabdullah.local>
References: <> <> <> <> <alpine.OSX.2.01.1601071125550.21147@rabdullah.local>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Cc: IETF Discussion <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jan 2016 08:26:31 -0000

--On Thursday, January 07, 2016 11:41 -0800 Ole Jacobsen
<> wrote:

>> Independent of the specific concerns, complaints, and general
>> whining about particular venues or choices, the thing I, and
>> apparently others, have heard most consistently in recent
>> years involves people in the community saying "we should
>> reprioritize so-and-so" and the IAOC or meetings committee
>> responding "can't do that because we are working three years
>> out".
> No, I hope not. What you have heard (or should have heard) is
> that  there are incompatible requirements, kind of like the
> "cheap, fast,  reliable, pick two!" joke. So every choice has
> a set of consequences  and there is no such thing as a perfect
> choice.

Speaking personally, I'm less upset about the particular choices
than many others seem to be.  That is in part because, as you
have perhaps noticed, I am increasingly weighing how much I
really need to go to a particular meeting and deciding against
it.  As an example, an implication of that is that I can look at
the specifics of the BA hotel debate and handling from the safe
distance of knowing that the odds of my making that trip were
very low before that situation made the aggravation and/or costs
higher.  Maybe that is good for the IETF on balance, even (or
especially) if it makes me less likely to volunteer for roles
that would require me to show up f2f.

I also understand the special circumstances, but, while 1-1-1
has been repeated several times lately, Honolulu is not "North
America" (especially in an environment in which Vancouver has
been presented as "Asia-Pacific") and Honolulu, Dallas, Prague,
Yokohama, Buenos Aires, Berlin, Seoul doesn't look a lot like
1-1-1.   So maybe 1-1-1 is now interpreted as "Western
Hemisphere, Europe, East Asia" but, when I compare the airfares
I can use (remember I've got some special requirements in that
area) to BA to those to Tokyo, there is a less than 10%
difference so one of the goals of 1-1-1, to balance the costs
becomes meaningless, at least over that 2+ year period.

What I am concerned about is accountability and responsiveness
to the community.  I've seen Fred's note that says the IAOC
really is in charge and making the decisions.  You have said
similar things and I believe both of you.  At the same time,
I've heard recent IAOC members respond to questions by
attributing decisions to the meetings committee and being really
out of the IAOC's control.  I've also heard the "three years as
an excuse" claim made, not just by us whiners in the community
but by recent IESG members.   I presume all of you are being
truthful but that leads to a conclusion that things are a little
out of the control of the community somewhere... and it is
_that_ which concerns me.

One of those accountability issues is that I think the community
has made it extremely clear that alternate hotel arrangements
should be in place and announced concurrent with the
announcement of the primary hotel and opening of registrations.
We used to be able to do that, even with less than three years
lead time.  Of late, we haven't been, in spite of, presumably,
nearly three years to prepare.  I think the community is
entitled to understand why (or what is wrong with my logic) and
who is responsible and/or what is being done to fix it... in
less than three years.

Coming back to the "cheap, fast, reliable, pick two!" joke, to
which I'm very sensitive, that joke has another side, which it
that it ought to be possible, at least after the fact, to ask
"ok, which two did you pick?" and get a straight answer.  That
is what accountability is all about because the community needs
that information to provide informed advice on the choices.  It
also needs that advice to be effective it is is provided.  If
what it hears in response to advice is that there is no point
giving it because circumstances and priorities will change
enough by the time (in, e.g., three or 5 1/2 or 12 years), there
is a different, but closely related, problem (bringing me back
to the specific cause of my note and question to Ray).    But,
instead, what we get is a longer list of criteria than three, an
indication that different priorities are used under different
circumstances and perhaps from meeting to meeting, and that is
all -- a situation that is indistinguishable from the
information available to the community from "we are going to
make those decisions in secret and feel no obligation to tell

That problem is somewhat exacerbated by the observation that the
IAOC has chosen to not post hotel contracts, even redacted
versions, for many years (if ever, and despite promises at
various times) in what seems to me to be aclear violation of the
transparency requirement of Section 7 of RFC 4071.  The
community almost certainly does not need to know dollar amounts
and other arrangements that would fall under "reasonable
confidentiality obligations", but, precisely in line with the
above comments about choices of priorities, the community should
be able to understand specific guarantees and tradeoffs.    

In particular, almost everyone who has ever negotiated a hotel
contract for a moderately large (or larger) meeting knows that
relationships among meeting room costs (including the
differences between meeting room charges to someone with a block
of rooms in the hotel and someone coming in "off the street" and
wanting to rent/use the meeting rooms alone), guarantees about
guest room revenue (or equivalent), guest room discounts from
"rack rate", guarantees about use of hotel catering services and
other add-on costs/ profit items, and arrangements about
"complementary" rooms or upgrades are all part of the
negotiation.  Such things as the ratio between the number of
rooms the hotel guarantees to have available for the group
(i.e., the "room block size") and the number of rooms (or room
revenue) the group guarantees to fill also often go into the
mix.  That is all complicated and most of us know it is
complicated, but that doesn't seem to me to be an excuse for
systematically leaving the community in the dark about what is
going on and what priorities are being used.

I can remember times and places when the IETF got meeting rooms
(sometimes all but the plenary ballrooms, sometimes those but
not the smaller spaces) for nearly free in return for other
commitments, commitments that sometimes increased costs
(relative to what might otherwise have been possible) to
individual participants.  Maybe a good tradeoff, maybe not, but,
in the IASA model, a subject on which the IAOC (or the meetings
committee, or the IAD specifically) ought to be able to be open
and candid with the community.  Again, I'm not asking for
violations of reasonable confidentiality, only that the
community be told what the powers-that-be are trying to optimize
and that we have reasonable input into those choices.

We are not getting it now.


>> Even without believing that, if working three years ahead 
>> effectively suppresses priority determination by the
>> community by  making any such efforts ineffective within any
>> reasonable time, then  5 1/2 is much worse.
> What specific priority, related to this announcement, is it
> that you  think could, should or would change? That we start
> meeting at  university campuses again, radically reduce the
> number of paralell  sessions, have more or fewer meetings per
> year, radically change  remote participation options? Those
> are all things that COULD happen  and SHOULD happen if the
> community agrees, but given how slow anything  moves in the
> IETF, would it not make sense to at least assume things  will
> continue more or less as currently when making deals for 
> resources that are decidedly limited and time sensitive?

First, I hope we can keep this discussion as positive and
focused as possible, specifically without introducing strawman
options like university campuses.  We seem to be working on
"radically changing remote participation options" and making
some progress -- not as much or as rapidly as I would like --
but progress nonetheless.  If some comments in these threads are
indicative, BA may strain those arrangements more than some
prior meetings and, as a likely remote participant (see above),
I'm personally significantly more concerned about them working
at least as well as they have in the last few meetings than I am
about how close together hotels are in that city.  In any event,
it would be very disappointing if those efforts did not bring
about some measurable changes within the three year window.

More broadly and just as an example, the number of meeting rooms
we need has been cited repeatedly as a constraint on meeting
hotels and facilities.   A sampling of agendas from Yokohama and
a few meetings circa 5 and 10 years earlier indicates that the
number of parallel WG sessions is holding constant at about
eight.  That is up from six around IETF 56, but March 2003 was a
long time ago, pre-IASA but still after the expansion to include
Friday morning sessions.  So, if that is the constraint, it
isn't changing much.   

What appears to have changed in the meeting room requirements is
that number of smaller rooms needed to accommodate
organizational requirements of the IETF and related bodies.
That is anecdotal, derived from walking down the halls of small
meeting/ conference room areas of the last few meetings I'm been
too, because I haven't been able to get any data.    I (and
others) have asked for those numbers, who is using those spaces,
and what the trends look like several times and haven't gotten
them.  The utilization ratios -- the amount of time those rooms
are actually used for IETF-critical meetings versus as private
work or conversation areas -- would also be good to know if the
community is to make informed decisions.  Certainly the number
of "small" meeting (and similar) rooms we require to qualify a
venue is not confidential commercial information.  It is
relevant to your questions above because I believe that, if the
community were asked whether we required all of those rooms if
the cost was venues that are less attractive along some of the
other selection dimensions, the answer might well be some
differences in priorities from what they are if demands or
requests for all-day availability of conference room-sized
spaces are taken as hard constraints.

Again, more information would help a lot.

> I do agree that a deeper analysis of the priorities should be 
> undertaken and discussed with the community of course. 

And that is the core of my disquiet and request.  It isn't as if
no one had asked before.