Re: [Mtgvenue] IETF: Mtg Venue Doc

Ted Lemon <mellon@fugue.com> Sat, 11 February 2017 01:09 UTC

Return-Path: <mellon@fugue.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 22B841294EE for <mtgvenue@ietfa.amsl.com>; Fri, 10 Feb 2017 17:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 j7SUsnXjSMTb for <mtgvenue@ietfa.amsl.com>; Fri, 10 Feb 2017 17:09:52 -0800 (PST)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6383B1295C7 for <mtgvenue@ietf.org>; Fri, 10 Feb 2017 17:09:51 -0800 (PST)
Received: by mail-qt0-x22e.google.com with SMTP id x49so50584583qtc.2 for <mtgvenue@ietf.org>; Fri, 10 Feb 2017 17:09:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=iAWEzEUgw30PATHY8zvUT88iIo5jOjQOZRosDbyOj08=; b=EDXSglx/HcmnJhXSDS7PMzo+CZH8Trzpcuy/eEMCibWCQjmvz1QSLfsEDq0mFqYM3g HEjnX+2ytdoZRb0zcX+HR7FNOPMsp33qz1MDGdHcO1euWubZaekvlIsevTwZj4+pWBZ6 Xx0Ye3Kf+UOJWBzDx/I+N0vo9hlZFWiqdUX/MW8dJk95ScNMFvFvOOt/O6YzoPk7MlKy 1K5UgcYZDipUytKsDpwcJfa5ad1Nz+cZ0rb1X1zmXCWQUREgXkc8GzhFNVHj7DZL2+c4 gCgGjMyZ77PO4kC3qw0gWxeMaccJg1yt++fsvVZUh8v59r6KebctL8io5ZPQQNjZRsIn iqmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=iAWEzEUgw30PATHY8zvUT88iIo5jOjQOZRosDbyOj08=; b=KoKZ/BTNu7xiuEnvtG6lTj9kmKhuPxct19mEK3xHdpHzv0Afi+yX9TF2ULaGFRO99q Pz70gtA29w85Lj0zwjeZqE1LXpJmqPDOpP7GhRex4QwZBOqG8Cwivc6+PtihoKtesBce x4TcHSKar2cl4TWZk2jovwcNPxGt2fZiH3zHgqbEIB38/asFOo6vAZwrRRAVlbSNx992 V68nGGy17Nkp3gCKJmgx8Js37OEJlrdp13uOf23tZMv4gKNMKpsQYmnkXeJLTM+gvNEC bUk2xSwFTWQ33MA8Jl/7qspgdEBnbVzkQ59hLZ3SM6q/+TIo/Ldpo1qltK2xppH0AIcG nYUQ==
X-Gm-Message-State: AMke39kmt5ZcOPNIL0/gpe6IE+V3pC2ZIbJblUIWpg2ehO66HpJruI4dTVBixULNSop92g==
X-Received: by 10.237.41.99 with SMTP id s90mr11946460qtd.4.1486775390355; Fri, 10 Feb 2017 17:09:50 -0800 (PST)
Received: from [192.168.1.228] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id m62sm2761750qkf.31.2017.02.10.17.09.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Feb 2017 17:09:49 -0800 (PST)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <F0DECF50-5AB9-4073-A051-4AF326A1FB34@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0AB85867-9D63-4470-B93A-32EC5AA8F53A"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Date: Fri, 10 Feb 2017 20:09:47 -0500
In-Reply-To: <A739489D-BAF5-4B4A-855A-5C63BD339F16@amsl.com>
To: Laura Nugent <lnugent@amsl.com>
References: <A739489D-BAF5-4B4A-855A-5C63BD339F16@amsl.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/9Q35wFs6UfTM6wAyohEiOQxNdtQ>
Cc: mtgvenue@ietf.org
Subject: Re: [Mtgvenue] IETF: Mtg Venue Doc
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: Sat, 11 Feb 2017 01:09:55 -0000

On Feb 10, 2017, at 2:20 PM, Laura Nugent <lnugent@amsl.com> wrote:
> 2.  Criteria -  There are a number of items included as criteria that I would eliminate or modify for a variety of reasons, explained below:
> 	a.  "Available travel issue assessments…"  I believe this should be eliminated as it is not a criteria but part of a process.
> 
> 	b.  "The facility permits easy wheelchair access” 
> 	c.  “The Facility is accessible by people with disabilities”
> 	d.  “The IETF Hotel(s) permit easy wheelchair access”	
> 	e.  “The IETF Hotel(s) are accessible by people with disabilities”
> There are laws which govern accommodations for disabilities, which laws vary from location to location.  We are legally bound to comply with local disability laws.  Singling out these four items is misleading, in my mind, as it appears to limit our obligation and to exclude some disabilities.  I suggest, in place of these four items, we instead borrow the introductory text as the criteria to govern this concern:
> 	“Facilities selected for IETF meetings conform with local health, safety and accessibility laws and regulations.”

The problem with this is that what we want is to make sure that if local regulations do not require the accommodations described in the document, that we check to see if such accommodations are present; if not, that venue is disqualified.

> 	f.  “The Facility environs include grocery shopping that will accommodate a wide variety…”  I suggest that this be combined with the other criteria related to dietary requirements for simplicity and to avoid redundancy:
> 	“A range of dietary requirements can be satisfied through onsite service or through access to an adequate grocery within a reasonable walking distance or conveniently accessible by a short taxi, bus or subway ride."

This is quite weak.   Requiring participants to take a "short taxi ride" from and to the venue three times a day basically means that they are going to miss meals or else miss important meetings.   The idea that this is adequate is one of the main reasons why people who can't eat everything tend to express frustration with venue selections.   It's particularly a problem at lunch time—I have often missed meals at IETF because I didn't have time to go to a restaurant, get served, and get back between meetings.  It can be very stressful if your schedule doesn't have any pre- or post-lunch gaps most days.

The amount of food that was available in easy walking distance near our recent Atlanta and Vancouver IETFs is what I would consider adequate.  Yokohama was not ideal, but the nice grocery store in walking distance saved me.   If the nearest store had been a bus ride or a taxi ride away, I simply wouldn't have had lunch several days, because there was nothing suitable in the venue.

> 	i.  “The IETF Hotell(s) directly provide, or else permit and facilitate…” 
> 	j.  “The overflow hotels provide reasonable, reliable, unfiltered…”
> Reference to the inclusion of Internet in the guest room rate should be eliminated.  Assessment of costs is addressed in another criteria (“The cost of guest rooms, meeting space…”).

"Evalutation of room rates should take into account any additional cost for Internet service?"

> 	k.  “The IETF Headquarters Hotel has a space for use as a lounge…”  I suggest the description of this criteria be made more concise and implmenetable, as follows:
> 	“The IETF Headquarters Hotel has a space for use as a lounge to facilitate casual IETF attendee interactions.  This lounge can be the hotel bar or casual restaurant.”

Can't be a restaurant.   The hotel restaurant often has no edible food, and you generally have to order food in order to meet there.   This is _typical_.   On many occasions when I've been at IETF I've desperately searched the lunch menu at the restaurant for something to eat and come up empty.

> 3.  Level of requirement - As you will see when you look at the attached spreadsheet, the current document identifies almost all the criteria as mandatory.  I believe we need to re-examine the classifications.  If a criteria has any room to “bend”, either for the current meeting or in combination with future meetings, I believe it must be listed as “desired”.  I understand that this creates some challenges because some criteria may be only “desired” as they relate to one meeting but are “mandatory” as they relate to a year or more of meetings.  Balancing these criteria, as has been stated over and over again, remains the challenge of the IAOC.

I would personally prefer that rather than bending, we choose venues that have worked in the past.

A number of changes from "mandatory" to "desired" in your spreadsheet seem odd to me:

4

The cost of guest rooms, meeting space and meeting food and beverage is affordable, within the norms of business travel
Desired
Mandatory

Does this mean that in some cases we will go to a venue that is way out of line with what people normally pay for business travel?   How will that affect attendance?


Anticipated meeting revenues are greater than anticipated meeting expensess
Desired
Mandatory

This makes sense, if we consider Buenos Aires, for example, or Korea, both of which IIRC were not expected to break even.   So for this criterion to be mandatory would represent a significant change.

The IETF Hotels are in close proximity to each other and the Facility
Desired
Mandatory

I have mixed feelings about this.   This criterion would have excluded Taipei, which for me was a very convenient location.   But I suspect that there were quite a few people for whom it was not so convenient, because the venue could not be quickly reached on foot or motorized wheelchair from the hotel.   So I think that this should be mandatory—if not, could you explain why?

The guest rooms at the IETF Hotel(s) are sufficient in number to house 1/3 or more of the projected meeting attendees
Desired
Mandatory

Here again, the motivation for this is to make it at least somewhat possible for people who want to stay at the main hotel to do so.   The 1/3 number might have excluded some recent venues—is that where this is coming from?

Overflow Hotels can be contracted and are within convenient travel time of the Facility
Desired
Mandatory

How can this not be mandatory? 

The Facility environs, which include both onsite and areas within a reasonable walking distance or conveniently accessible by a short taxi, bus or subway ride, have choices for meals that can accommodate a wide range of dietary requirements
Desired
Mandatory

As I mentioned earlier, if this weak criterion is not even mandatory, I expect repeats of the Kissimmee fiasco.   I had to rent a car for that IETF.

A range of dietary requirements can be satisfied through onsite service or through access to an adequate grocery within a reasonable walking distance or conveniently accessible by a short taxi, bus or subway ride
Desired
Mandatory

Same comment

Travel to the venue is acceptable based on cost, time and burden for participants traveling from multiple regions, balanced among regions over multiple years.
Desired
Mandatory

Given the use of the phrase "is acceptable," it seems like there's no problem here: by definition, it was acceptable to everybody who showed up.   It's not clear to me that changing this from mandatory to desired actually makes any difference, since "is acceptable" is so vague.

The Facility environs include budget hotels within convenient travel time, cost and effort
Desired
Mandatory

A lot of the IETF participants I meet with on a regular basis stay in the budget hotels because their travel allowances are not as generous as mine.   If we made this optional, I think we would see a substantial drop-off in attendance for those IETFs where this criteria was not met.