[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
- Re: [Mtgvenue] Comments on -04 Brian E Carpenter
- Re: [Mtgvenue] Comments on -04 Stephen Farrell
- [Mtgvenue] Comments on -04 Andrew Sullivan
- Re: [Mtgvenue] Comments on -04 Brian E Carpenter
- Re: [Mtgvenue] Comments on -04 Andrew Sullivan
- Re: [Mtgvenue] Comments on -04 Dave Crocker
- Re: [Mtgvenue] Comments on -04 Jari Arkko
- Re: [Mtgvenue] Comments on -04 Andrew Sullivan
- Re: [Mtgvenue] Comments on -04 Dave Crocker
- Re: [Mtgvenue] Comments on -04 Andrew Sullivan
- [Mtgvenue] What does "mandatory mean?" Melinda Shore
- Re: [Mtgvenue] Comments on -04 Dave Crocker
- Re: [Mtgvenue] Comments on -04 Andrew Sullivan
- Re: [Mtgvenue] Comments on -04 Brian E Carpenter
- Re: [Mtgvenue] What does "mandatory mean?" Brian E Carpenter
- Re: [Mtgvenue] What does "mandatory mean?" Melinda Shore
- Re: [Mtgvenue] What does "mandatory mean?" Brian E Carpenter
- Re: [Mtgvenue] What does "mandatory mean?" Fred Baker
- Re: [Mtgvenue] What does "mandatory mean?" Fred Baker
- Re: [Mtgvenue] What does "mandatory mean?" Fred Baker