Re: [RTG-DIR] [Mtgvenue] Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12

Stewart Bryant <stewart.bryant@gmail.com> Mon, 05 February 2018 16:43 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07B7127201; Mon, 5 Feb 2018 08:43:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 GXyJQ8qv0xHY; Mon, 5 Feb 2018 08:43:43 -0800 (PST)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 7A011127077; Mon, 5 Feb 2018 08:43:43 -0800 (PST)
Received: by mail-wr0-x22b.google.com with SMTP id v31so30285709wrc.11; Mon, 05 Feb 2018 08:43:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=jv22dAMA8cIdqZD2SNcRdNUtY132vnogfr0n59MXAX4=; b=LYHJN+ci0QMQx8yje9o7pKcMFb96grD4wNM/wbLPvRwahApYFmsMpQBcp4lXMwmedQ od7CVTuvgBQZOmHlXDqW5cElAwT5j9PbDKaw+dOIjGLyYEKGcJLAF6oBD34gxAdpOcl7 lxe0jHpu9M6cHAcbdzBMPiQ9J8vKDMgNoYUG//088v5qWX2f96IOJc4ljQGF5XDAfusr q2chH9Qsn8mXr4D/5ms76Gf5GQFDhuVHigluRiaKlcuHw0rYvSTG8kHobil5I+iAVKre EffAS4T3k5bJG3//J6zVtaCWi1+2KbjO+Oqf8EWmc0wExza8QJZpHLShzDkHDi7qj338 PAMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=jv22dAMA8cIdqZD2SNcRdNUtY132vnogfr0n59MXAX4=; b=sVm7upAPP7ZI0bWx/LTP0q01gdoJxauJExLG3AtgENXDaJqvy71Znwjr2nO2NMSZDh s8+3ARo7O7kAN2GyhI0ctGekykVJvzlJXo5W9GOBatO8KJQBqyZHtijkgXR9FaZNVAfG LtKc5i/IFTnamEEGjJN0btMa/LL0o62gYVdc/Qq5x6gcTJq/UDssBgKueazj5WDRREBn KrKhLlxtdOsU2wIRrNQgZDJhlFJdLyZsJQofeL/7l6J3w+vkVobqmAp6qvElQ0MfKDt/ HMtzgxf+J/T0ajjIzYbxk3VAcsPcZXx6uBTxa+CxaZdpi+NflzbsN5eWe4dTFXMzeGvS i/Iw==
X-Gm-Message-State: AKwxyteAfiuyGZ5Tjrk+T+SuSw8+DKsyQHMjUoci9hV4pubcjiR/EaWT B0DhM4Ty/ANNb12vChsbCp8bWDOu
X-Google-Smtp-Source: AH8x227LNryQnYi88rmRt/fCh3WpKeqQ+/pLjfIWImzZ4fXIQYZ97sWggf157onjeqM3Ayzl0vsriw==
X-Received: by 10.223.136.197 with SMTP id g5mr26271080wrg.3.1517849021716; Mon, 05 Feb 2018 08:43:41 -0800 (PST)
Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id u194sm11319006wmd.8.2018.02.05.08.43.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 08:43:41 -0800 (PST)
To: Pete Resnick <presnick@qti.qualcomm.com>, Stewart Bryant <stewart@g3ysx.org.uk>
Cc: mtgvenue@ietf.org, rtg-dir@ietf.org, ietf@ietf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process.all@ietf.org
References: <151782868264.5731.15496399706573021777@ietfa.amsl.com> <15F0E669-0195-4315-AAA5-AED71CD6C5B3@qti.qualcomm.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <ce5c3e3b-fb8a-0a29-3569-ab61f5de7da0@gmail.com>
Date: Mon, 05 Feb 2018 16:43:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <15F0E669-0195-4315-AAA5-AED71CD6C5B3@qti.qualcomm.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/6Bos1MO5q3ojeU7y5TGlpJnNO5Q>
Subject: Re: [RTG-DIR] [Mtgvenue] Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Feb 2018 16:43:46 -0000


On 05/02/2018 15:40, Pete Resnick wrote:
> Hi Stewart,
>
> Thanks for the review. Just on the things that Eliot hasn't already 
> covered
>
> On 5 Feb 2018, at 5:04, Stewart Bryant wrote:
>
>> Major Issues:
>>
>>    o  The Facility and IETF Hotels MUST provide wheelchair access to
>>       accommodate the number of people who are anticipated to require
>>       it.
>>
>> and
>>
>>    o  The Facility is accessible or reasonable accommodations can be
>>       made to allow access by people with disabilities.
>>
>> SB> I am not an expert but I think more than just simple wheelchair
>> SB> access is required, also you need a set of suitable facilities in 
>> the
>> meeting SB> facility and in at least one hotel and its environs. SB> 
>> SB> I
>> assume that there is some code of practice that can and should SB> be
>> referenced here.
>
> There was considerable discussion on this issue; perhaps I should have 
> included this specifically in the shepherd report. Here's what I last 
> posted to a question about this:
>
> -
> The way I have thought about the distinction is that things in 3.1 are 
> things for which IASA (or the secretariat for most practical purposes) 
> would have to come to the community and get consensus to do something 
> different before they contract. Things in 3.2 they can use their 
> expertise and best judgement and make the contract, but even so they 
> must notify the community that they are doing so.
>
> So in the case of accessibility, the inability to have wheelchair 
> access at the Facility or Hotels is a showstopper; there is no 
> reasonable accommodation that can be made for wheelchair users that 
> involves not being able to access a location with their wheelchair. If 
> IASA thinks that such a facility is still acceptable, they have to 
> make their case to the IETF community first and get consensus. For 
> other disabilities, IASA is supposed to use their expertise (or that 
> of others they enlist) to make sure that the facility is accessible or 
> that reasonable accommodations can be made, and might judge that, 
> while a particular normal accommodation for a particular disability is 
> not available, a facility is nonetheless acceptable. They still must 
> notify the community in this case, and bad things might happen if the 
> community finds that they have made a poor judgement, but they are not 
> expected clear a given lack of accommodation with the community every 
> time.

Actually it is more than the facility itself, it is the venue and 
transport to the venue, and there are a range of disabilities beyond 
mobility that we need to take into account.

If you want a high-level requirement it is presumably something like 
"that there is no reasonable impediment to a participant with mobility 
or sensory disability travelling to and from the venue, obtaining 
suitable accommodation at the venue, or being able to fully participate 
in all aspects of the meeting"

>
> -
>
> So with regard to referencing a "code of practice", the assumption in 
> this document is that, beyond wheelchair access, it is the IASA's 
> responsibility to choose the correct set of accessibility 
> requirements, which could of course change over time, and inform the 
> community if there is a departure from their expectations.
>
>> Where we meet?
>>       We meet in different locations globally, in order to spread the
>>       difficulty and cost of travel among active participants, balancing
>>       travel time and expense across the regions in which IETF
>>       participants are based.
>>
>> SB> Given the support and encouragement of remote participants, there 
>> ought to
>> be a note about sharing unreasonable time zone difference pain across 
>> the
>> spectrum of remote participants.
>
> I don't believe we currently do take that into account in location 
> selection (perhaps others can chime in), so this would be a new 
> requirement. We could bring this back to the WG to try and get 
> consensus around it, but that doesn't excite me. :-) I'll leave it to 
> my fearless AD to advise.

I suppose location is a proxy for this, but if we are trying to be 
inclusive we ought to be inclusive to both groups of participant.

>
>> 8.  Privacy Considerations
>>
>>    This note reveals no personally identifying information apart from
>>    its authorship.
>>
>> SB> This is true, but does spawn the question of whether privacy should
>> be a meeting location selection criteria?
>
> "I refer my Right Honourable Friend to the answer I gave some moments 
> ago." ;-) This sounds like a can of worms. I'll again wait for AD 
> direction.

Hm, I doubt that I will ever advice the Queen :)

- Stewart

>
> pr