Re: [HT-rt] HR-RT Review of draft-ietf-mtgvenue-iaoc-venue-selection-process

Eliot Lear <lear@cisco.com> Fri, 20 April 2018 16:44 UTC

Return-Path: <lear@cisco.com>
X-Original-To: hr-rt@ietfa.amsl.com
Delivered-To: hr-rt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBB612D883 for <hr-rt@ietfa.amsl.com>; Fri, 20 Apr 2018 09:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.511
X-Spam-Level:
X-Spam-Status: No, score=-13.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 uGKzcaNV5FYs for <hr-rt@ietfa.amsl.com>; Fri, 20 Apr 2018 09:44:42 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3391A12D876 for <hr-rt@irtf.org>; Fri, 20 Apr 2018 09:44:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11750; q=dns/txt; s=iport; t=1524242682; x=1525452282; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=+3aP1fTIMjfVEKU/QzGdplLE5k1aaxGmIk6Ku8OXJH8=; b=M93Ihote3S6lCxy/y7bouf2gH2MHiED810yS45qEf2Cvq/OA12cnyEfa 2R+8OOye1ni0Rf36OCphlzQdIBUzoCO0QiF2uSnOmKnUHLZKMZ4T/9GoK r8aQfcudYQ4D80ZqPhNEXNxvrFwS4kGNbtAbq7gDvFA0jMa8Vl+ZaVQvs 8=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AuBADkF9pa/xbLJq1bGQEBAQEBAQEBAQEBAQcBAQEBAYMTBIEMeiyDZohgjWwhgQ+UcAgDI4RGAoJmNxUBAgEBAQEBAQJsHAyFIwEFI1YQCQIOCioCAlcGAQwIAQEXgkwBgiUPix6bQIIciD+CGg+KGYEOASMMYXx/gwaEbYJUAodGCpAhCIM8gVBPglCGDgYCgTI7gyKCOYUEiTSGdYElMiKBUjMaCBsVGoJlCIIXF4NFilEDPZAXAQE
X-IronPort-AV: E=Sophos; i="5.49,302,1520899200"; d="asc'?scan'208"; a="3317926"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Apr 2018 16:44:39 +0000
Received: from [10.61.210.190] ([10.61.210.190]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w3KGidqJ015030; Fri, 20 Apr 2018 16:44:39 GMT
To: Pete Resnick <presnick@qti.qualcomm.com>, Niels ten Oever <lists@digitaldissidents.org>
Cc: hr-rt@irtf.org, ietf@ietf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process@ietf.org
References: <d0739bb2-626e-8aa3-f22f-d51b07dfdacf@digitaldissidents.org> <21952.1524157167@obiwan.sandelman.ca> <7B17FF2E-4393-4644-998B-16462F71A00F@qti.qualcomm.com>
From: Eliot Lear <lear@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwHsEEwECACUCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheABQJTHtXCAhkBAAoJEIe2a0bZ0nozBNoH/j0Mdnyg CgNNmI4DyL9mGfTJ/+XiTxWXMK4TTszwwn/tsXjyPQWjoO6nYqz5i96ItmSpkelSGVpzU+LK LQxSjFeUvKw23bp1rVecfGR+OENSE1m6KfFj3vtzQOZ2/FgK210MWnlYNNyAHX6Pf6hKInTP v6LbZiAQMCmf0aPvRbk/aPSNJAuIKrLrrCgAlwelrTavFsSwnKI3dhSG8DJ9+z/uiXDiHYra Ub3BKp5K/x71Zd8hUsWm2simnE/6HvZaZz7CC29JSZ/5gGtNB3OMNKLzLWUbQacF3IKxpW66 ZFYFYnlBV4jRnKlmb40YcEXWVJkkVC8g+/J9Qo6R8BdmSTXOwE0EUx7VRAEIALRZXth1u/3n FgY+G2FN0KEEik+2Xsk8JX9zr/eISa+Ol8a4U1orgxpyP2V7bQQDkDUEfs+Asagc6I8zrk3K xGln3pFFVfdM18uaEYwWvmE84Y12r7FwYdW62bA9X1Ttsp5Q1GI8XHdh0SQTF12pXYTwWW1P THYVIp7bGzM88cHqBW0xyRflu4j2nUrd9tWFd28SRxhj+MHQkQkbKFLloRty3lwdS8MCRPzX 9gUrkl+DxFHC7WrW3Vi4glI5YBlD0n2hSyDoP1GkKVT60gUGh7eJOnUBR8lzKm5wYqAtgq2m 79rKBylA40diRhbnTTeY+ytqMWFF5UXm97Jwxsezi7kAEQEAAcLAXwQYAQIACQUCUx7VRAIb DAAKCRCHtmtG2dJ6M5K5CADbunatgHsqHbR3KbpXxzralakEcdODGv/fbN6/EdKJeXrG9QKD lPxZTB9STw6+ANwESsr9uUMAxdDNKDeynjnQmFHxGdcdcXlnPZPThfseeUhUkbB/YKOfDIQA kKozNoKYj6Dcia+D/wvifIEW+GUUcO/6Qi8yK6PLJyM8C7vHEqmUGzX8gTCYOgAyOd4WZrC9 95CfB0yFIorw+MpK7MZTm5SbGPcYF9Gq9MzSqmaEw8U6YOElKYfnkcsCTLYyWaolhck+3/0R 9ISEWK5rUzqAuK40S4+Sn7yNycdCoqvQh4e3xSpzAu3aYZ8jKXQVV0X2G9Y+M1HMZuCqhPUO LTdF
Message-ID: <22946590-de79-a2ab-9cf8-be9bcec50b73@cisco.com>
Date: Fri, 20 Apr 2018 18:44:38 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <7B17FF2E-4393-4644-998B-16462F71A00F@qti.qualcomm.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="arOkZ3KN4aAoptwzId4rOwpPvfCHrtjR1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hr-rt/8LUktf-TACBZEvwxAz5ciJVLpA4>
Subject: Re: [HT-rt] HR-RT Review of draft-ietf-mtgvenue-iaoc-venue-selection-process
X-BeenThere: hr-rt@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Human Rights Protocol Considerations Review Team <hr-rt.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hr-rt/>
List-Post: <mailto:hr-rt@irtf.org>
List-Help: <mailto:hr-rt-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hr-rt>, <mailto:hr-rt-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Apr 2018 16:44:45 -0000

Hi Pete, Niels, and Michael,

Please see below:


On 19.04.18 23:08, Pete Resnick wrote:
>> I suggest you reword your suggestion to:
>>    "We would like to facilitate the onsite or remote participation of
>>    anyone who wants to be involved.  Widespread participation
>>    contributes to the diversity of perspectives represented in the
>> working sessions"
>>
>> the problem with the "and" in the sentence is that the sentence can
>> otherwise be parsed
>> to say that we only want to facilitate partition from those who
>> contribute to
>> increased diversity.
>
> I have to agree with Michael's suggestion. In addition to the possible
> ambiguity, there was pretty explicit consensus in the WG that the
> objective was to facilitate people who participants that want to
> participate, and explicitly not to use venue selection for purposes of
> outreach. Michael's reformulation makes that a bit clearer. Does that
> satisfy your concern?

Propose to include the second sentence based on Niels' concurrence.

>
>>> 2)
>>> We find that the current draft is not totally consistent in regards to
>>> the affordability of participation.
>>
>> This is my intepretation.
>>
>>> Initially, it acknowledges that many participants are self-funded, and
>>> that budget solutions should be available. That's great.
>>
>>> From Section 2.  Venue Selection Objectives/ 2.1. Core Values:
>>> "Economics:
>>> Meeting attendees participate as individuals. While many are
>>> underwritten by employers or sponsors, many are self-funded.  In order
>>> to reduce participation costs and travel effort, we therefore seek
>>> locations that provide convenient budget alternatives for food and
>>> lodging, and which minimize travel segments from major airports to the
>>> Venue.  Within reason, budget should not be a barrier to
>>> accommodation."
>>
>>> But then, in Section 3.2.2, things sounds less affordable.
>>
>>> From Section 3.2.2 Basic Venue Criteria:
>>> "The cost of guest rooms, meeting space, meeting food and beverage is
>>> affordable, within the norms of business travel."
>>
>>> "Business travel" has commonly a higher cost than "self-funded budget
>>> travel".
>>
>> The intention is that the *venue* (primary hotel) should not be so
>> expensive as to be prohibitively expensive to even those on "business
>> travel".  There are locations (resorts in really exotic locations) where
>> the nightly price of room is like $500/night.  The intention is to rule
>> those out.
>> As a self-funded individual, I accept that I can't often afford to
>> stay at
>> the primary hotel, but I will find something acceptable within a few
>> blocks.  So that's how section 2 and 3.2.2 are reconciled.
>
> Michael's explanation is correct, but I take your point that "guest
> rooms" in the second bullet of 3.2.2 sounds like the combination of
> rooms in the IETF Hotels, Overflow Hotels, and other nearby local
> accommodations. Perhaps we can clarify. Let's see if Eliot has any
> thoughts.

How about the following:

          <t>The cost of guest rooms, meeting space, meeting food and
beverage
            is affordable, within the norms of business travel,    and
             there are at least some inexpensive and safe
            alternative  accommodations within easy reach to the Facility.


>
>>> 3)
>>> We invite to consider the addition of a few items to Section 3.2.2.
>>> Basic Venue Criteria.
>>
>>> 3.1)
>>> "All Meeting Venues should have at least one gender neutral restroom
>>> with stalls on each floor."
>>
>> I'd like to support adding this as aspirational, but it's gonna be two
>> hotel renovation cycles before it can be found often enough to be a
>> reasonable criteria.
>
> Given that the 3.1 criteria are those for which IASA MUST NOT enter
> into a contract if they are missing, I don't see how we can make this
> mandatory at this point, unless IASA can tell us that a sufficient
> number of Facilities meet this criterion already. Perhaps something
> along these lines could be added to 3.2.2, but even there I think we'd
> want input that there are such Facilities available, lest the criteria
> simply be ignored.
>
>> On the topic of being family friendly,  the major thing we can do to
>> support families is to outside of the mtgvenue, and is with the nomcom
>> eligibility criteria.
>
> Agreed Michael. :-)
>
> On to the rest of your comments, Niels:
>
>>> 3.2)
>>> "The Meeting Venue should have at least one dedicated infant feeding
>>> room and one family restroom."
>
> I presume you mean "Facility" here and not "Meeting Venue", correct?
> Like the gender neutral restrooms, I think we probably want to hear
> from IASA that this is going to be satisfiable by a reasonable number
> of Facilities.
>
>>> 3.3)
>>> "The event should be accessible to non-smokers and those with
>>> respiratory conditions. Therefore all meeting spaces during daytime and
>>> nighttime should make it possible to fully participate in the scheduled
>>> activities without being exposed to second-hand smoke."
>
> I have no particular concerns about adding this in section 3.3,
> barring objections.

</editor hat>
I would go further.  I cannot remember a time when there was smoking at
an IETF meeting, except perhaps in a bar.  Therefore, I would claim that
this is an oversight by the working group and an example of a
requirement that was well understood by the Secretariat long before
someone came up with the term "mtgvenue".

Therefore, I would reformulate this as follows:

   "The Facility MUST be prohibit indoor smoking.  IETF Hotels and
Overflow Hotels MUST offer "No Smoking" rooms
     attendees.

>
>>> 3.4)
>
> There is no section 3.4 in the document. Did you mean for this to go
> in 3.3?
>
>>> We believe that supporting parents with small children attending events
>>> is a great step forward towards inclusivity.
>>>
>>> We would like the document to address this aspect in regards to venue
>>> requirements.
>>>
>>> In particular, it would be helpful for the document to provide
>>> information about the following:
>>>
>>> * Can participants feel comfortable and welcome to have their kid(s)
>>> with them at the event? If so, are kids under a certain age not allowed
>>> to be in session rooms?
>>>
>>> * Would the venue provide a childcare space and service, like a
>>> play/activity room managed by a licensed childcare professional? See
>>> further information about childcare at events at:
>>> http://geekfeminism.wikia.com/wiki/Childcare
>>>
>>> If the organization determines that children should not be allowed to
>>> access meetings, and/or no childcare space and service can be provided,
>>> it would anyway be important for the document to acknowledge that the
>>> organization is aware of the limitation that this would constitute and
>>> that this might hinder the participation of some attendees.
>
> Whether children can be present in meeting rooms sounds like a policy
> issue beyond the question of venue selection, so I believe is out of
> scope for the document.
>
> As for whether having childcare services available at the Facility or
> Hotels should go in 3.3, I have no particular concerns about adding
> it, again, barring objections.

(still no editor hat)


My only question is whether these services are commonly offered.

If so,

<editor>

It is desirable that preferably the Facility, or failing that the IETF
Hotel(s), offer childcare services.



>
>>> 4)
>>> We invite to consider the addition of one item to Section 3.3 Other
>>> Considerations.
>>>
>>> Section 3.2.2 Basic Venue Criteria says:
>>> "The Facility is accessible or reasonable accommodations can be made to
>>> allow access by people with disabilities."
>>>
>>> This is great!
>>> At the same time, sometimes one person's required accommodation might
>>> create a barrier for someone else. For example, the same session could
>>> be attended by one participant with a guide dog, and another
>>> participant
>>> with a severe allergy to dogs.
>>>
>>> It would be ideal if the document could mention a consideration on this
>>> type of conflicting requirements that might occur. For example, it
>>> could
>>> say that, in the full respect of everyone's needs, the organizing team
>>> will aim to find the most suitable solution on a case by case basis.
>>>
>>> This statement should also include information about who / what team
>>> can
>>> be contacted to ask for information in case of need.
>
> I think adding a short informational note to that bullet in 3.2.2
> makes sense. I'll again leave it to Eliot to see if he can come up
> with something.

<editor>

I am not clear on whether this text should go into this draft or into
the IASA's documentation.  The question I have is  this: is this a venue
selection criterion?  If so, and if IASA is reasonably aware of the
conflict, then I think it goes in this document.  I would suggest an
example would help us understand that.  If not, then I think what is
being asked for is a directive to IASA in this document to provide
attendees information about the above.

Is that about right?

Eliot




>
>>> 5)
>>> Correct typo in the title: "3.3. Other Consideraitons"
>>>
>>> Edit: "3.3. Other Considerations"
>
> Of course.
>
> Thanks again for the great comments.
>
> pr
>