[Mtgvenue] Comments on -04

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 31 January 2017 01:05 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: mtgvenue@ietfa.amsl.com
Delivered-To: mtgvenue@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D756A1297A7 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 17:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SnjyPWT5PR0H for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 17:05:52 -0800 (PST)
Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id 34E211294AD for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 17:05:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 4536C11625 for <mtgvenue@ietf.org>; Tue, 31 Jan 2017 01:05:55 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vj1GYVguK6vE for <mtgvenue@ietf.org>; Tue, 31 Jan 2017 01:05:54 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 4582B11621 for <mtgvenue@ietf.org>; Tue, 31 Jan 2017 01:05:54 +0000 (UTC)
Date: Mon, 30 Jan 2017 20:05:48 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: mtgvenue@ietf.org
Message-ID: <20170131010548.GL47762@mx2.yitter.info>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/fxvvMRsSI0hzyc-SeFShA2xqNeA>
Subject: [Mtgvenue] Comments on -04
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "List for email discussion of the IAOC meeting venue selection process." <mtgvenue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mtgvenue/>
List-Post: <mailto:mtgvenue@ietf.org>
List-Help: <mailto:mtgvenue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mtgvenue>, <mailto:mtgvenue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jan 2017 01:05:54 -0000

Dear colleagues,

I have reviewed -04.  I appreciate the work that has gone into this.
I think this is better, though some of my basic concerns remain.  This
note is unreasonably long.  Sorry.  Didn't have time to write a short
one &c.

As background and for disclosure to those who may not have followed
this before, I am not now and have never been a member of the meetings
committee (MC), but until March I'll be a member of the IAOC and
therefore one of the stuckees to defend IAOC decisions with respect to
meetings -- mostly, to defend decisions I didn't make and responsible
to make decisions that others will be stuck defending.  Therefore, I
look at this draft through the lens of, "How would I use this guidance
in voting for or against a recommendation from the MC?"

I remain concerned about a couple large issues.  I am alert to the
complaint that I do not offer these in the OLD: <text> NEW:
<othertext> form.  That's because I still don't feel the text is at
the point where that sort of small adjustment is possible.  (Had I
understood how much resistance there'd be to large changes, I never
would have supported adoption of this draft in the first place.)  I
nevertheless attempt to offer text changes where I can below.  I list
some other smaller issues later, but I think they're subordinate to
the three biggies.

Large issue 1: many categories
====================

The first issue is the splitting of the criteria into so many
categories.  I don't understand the utility.  In terms of actually
making decisions, there are basically three divisions.  Criteria that
are mandatory cannot be traded no matter what, and therefore they
ought to be listed together.  Criteria that need to be traded off
need, well, to be traded off; so they ought to be listed together too.
All other criteria literally don't matter except as tie-breakers, so
the only reason to list them is to emphasise that certain things are
nicer to have than other ones.  The decision tree is a simple tree,
not a multidimensional one, so the additional dimension obscures
matters while adding nothing at all to decision-making.

A solution to this might be either to add another section that lists
the entire decision-rules in one place, or else to recast the category
listing as a single decision-rule table and then provide a
category-based breakout as an appendix or another section.

For instance, here are the criteria listed in decision-rule form (I
_think_ I got it all):

Mandatory: No Venue failure from community consultation, Venue
acceptable travel, Venue host and sponsors, Venue low barriers to
entry, Venue travel issue assessments, Facility size and layout,
Facility costs, Venue cash positive, Facility easy for wheelchairs,
Facility-techno support ok, Facility-techno network ok, Hotels-techno
network ok, Hotels proximity ok, Hotels number ok, Hotels contracts &
costs ok, Venue cheap hotels poss, Hotels wheelchairs ok, Venue
environs meal choices ok, Venue food restrictions ok.

Important: Venue disabilities ok, Hotels disabilities ok, HQ Hotel
lounge, Venue environs groceries.

Desired: Venue Multi-event contract, Facility one roof, Hotels
Internet ok.

Large issue 2: Too much mandatory & in the passive voice
=====================================

The above list has an enormous number of "Mandatory" and not very many
things that can be traded off, let alone things that are just nice to
have.  (It's also interesting that one of the "nice to haves" has been
the reason given to me not even to look at a number of places in the
explanations, so I'm not convinced that reflects actual practice.
That's a separate problem.) But if you look carefully at the Mandatory
cases, I think they're not all really Mandatory.  For instance (I'm
picking just one at random, so that this is the example isn't
significant):

   Travel to the Venue is acceptable based on cost,
   time, and burden for participants traveling from
   multiple regions. It is anticipated that the burden
   borne will be generally shared over the course of 
   multiple years. 

The problem is, if I am evaluating that, I don't know what "is
acceptable" means.  It's either empty (because, by definition, if
people show up the cost was acceptable) or else it's waving away the
contentiousness around "acceptable".  More importantly, since this
explicitly says that it's to be shared over the course of years, it's
actually an Important, and not Mandatory, item.

This is part of the reason I noted the other day that I just couldn't
tell whether the distinction Alissa and I had previously tried to make
is captured in the draft.  I believe that the various inconveniences
of informal travel restrictions that make visa-granting a crapshoot
are to be traded off, because we need to be prepared for the
possibility that people of one country or another are going to get
jerked around in any Venue.  At the same time, I believe that formal
bans against some class of people where that ban is not empirically
founded ought to be complete disqualifiers.  Legal restrictions on
(say) Upper Slobbovians or L-chromosome carriers are not ok and we
should eschew such sites.  Informal restrictions that turn out this
year to be capriciously applied against Lower Sobbovians and
M-chromosome carriers are not ok and are to be deplored, but are
predictable consequences of going from country to country.

I therefore think that a very serious look at what is Mandatory vs
Somethingelse is needed, with a view to reducing the Mandatory list.
Anything that has tradeoffs in it is automatically not Mandatory.
Anything else that seems to have room for wiggle is similarly not
really "Mandatory" except in the sense that there is some floor below
which the IAOC's judgement should say, "This is too onerous."

At bottom, that latter issue may be my real concern, because the
"Mandatory" list seems to offer a false objectivity.  The items are
all Mandatory, but since many of them involve descriptions that invoke
an enormous amount of judgement they're not really mandatory in the
English sense of the word at all.  They're important, and they're also
Important in the sense this draft describes.  They can be balanced
against one another, in a way that (for instance) a Venue actually having
enough meeting rooms and having them close enough to each other to
permit a meeting just cannot.  We _can't_ have a meeting without this
one:

    The Facility is adequate in size and layout to
    accommodate the meeting and foster participant
    interaction.

We maybe _could_ have a meeting without this one, but it might be
smaller:

    The cost of guest rooms, meeting space, meeting
    food and beverage is affordable, within the norms
    of business travel.
    
And we totally could have a meeting without this one, because we've in
fact done it (unless "allow" here is construed to mean "logically
possible):

    The economics of the Venue allow the meeting to be
    net cash positive.

Note that I'm particularly worried about all these Mandatories because
of §5.4 a.

Large issue 3: Process innovation
======================

I don't know whether I've just not made this clear, or whether the
editors really disagree with me, but §4.1 appears to me to suggest
that we have a standard IETF consensus call about many issues related
to venues, and combined with the "is acceptable" language in §3 looks
to me like an enormous potential burden with possibly appealable
consequences.  I think this is a terrible idea.

It's this ¶ in particular that makes me worried:

   IETF consensus, with respect to this meeting Venue selection process
   is judged via standard IETF process and not by any other means, e.g.,
   surveys.  Surveys are used to gather information related to meeting
   venues, but not to measure consensus or to be reported as
   consensus.

If the below is what's meant instead, I can live with it (though I
think it could in that case be removed as it is already determined
elsewhere):

   IETF consensus, with respect to the meeting venue selection process
   herein outlined, is judged according to standard IETF process and
   not by any other means, e.g., surveys.  Surveys are used to gather
   information related to Venues, but not to measure consensus
   or to be reported as consensus.  By the same token, Venue decisions
   are not themselves subject to IETF consensus, and are instead
   decisions taken by the IAOC.

Smaller issues
==========

I'm not sure what to make of the definition in §3 where hotel rooms
might or might not be part of Facility.  This seems strange, though I
guess it's probably because of the IETF network?  If so, say that.
(But given that IETF Hotels and HQ Hotel are defined, this seems
wrong.)

More generally, there are some tricky bits of the definitions because
they seem gappy.  We have a requirement of the Venue under the
Facility division, a notion of "Venue environs" that is a little
tricky given the meaning of Venue (maybe that's Facility environs?
Something else?), and a "Venue contract" which is probably a Facility
or Hotel or something contract.  I don't have a lot more to say here
because I still want to be sure we're in agreement about the large
before I tackle the middlin'.  But the terminology is hard to follow,
which might be partly because of the two-dimensional categories.  I
_think_ another problem might be that we need to define separately
Location, maybe City?, and maybe something else -- Greater
Neighbourhood is all I can come up with -- to make this work
reasonably.  (This becomes obvious in 5.1 where the tension between
Venue and city is most stark.)

I think that §§4.4 and 4.7 could be a whole lot clearer that the
responsibility for Venue selection rests ultimately with the IAOC and
that it's those people about whom IETF participants should complain to
the nomcom, if and when needed.

In §5.1b, what if the target list is not known?  Is there something to
do in that case?

In §5.2, should we provide a period for a concurrent objection to the
posted list?  That is, it'd be nice if there were a way for people to
say, "I know you're already investigating this place.  I still have
concerns, so please look into…"  I am of two minds about this, so
that's why this is a question and not a claim that we should.

There seems an enormous gulf between 5.4 and 5.5.  What happens if
(just for instance) the country in which the Venue is found suddenly
changes its immigration policy in the interim.  Are there instructions
for this?

I hope these remarks are useful to the editors.  In my opinion, this
document needs at least one more round before it is ready for last
call.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com