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

Pete Resnick <presnick@qti.qualcomm.com> Mon, 05 February 2018 15:41 UTC

Return-Path: <presnick@qti.qualcomm.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 5F6FE12D84B; Mon, 5 Feb 2018 07:41:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.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 G_mBw0k8h56m; Mon, 5 Feb 2018 07:41:56 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D89C12D848; Mon, 5 Feb 2018 07:41:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1517845316; x=1549381316; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version; bh=p0/wZiVSKgc24tZucIXeIzU2Y70aUVXYd52IJS/NUf4=; b=Q86KStyJ6H/YBILYt7nfOeKz397NHJb0QnzYNZeyk2aYMCOfvT/9d4xz WsCgcK64tt7Ns/Xqjtx2vZDAR7nlMYUX7q4aRNZADoXG+cKC38EJTIC/b AY+pzeqEgpz+fJ6H5qCWyXIiJtBbuwtexZfNJOQtePLk6xeWitG1Mh6jn 4=;
X-IronPort-AV: E=Sophos;i="5.46,465,1511856000"; d="scan'208";a="324406356"
Received: from unknown (HELO ironmsg01-sd.qualcomm.com) ([10.53.140.141]) by wolverine01.qualcomm.com with ESMTP; 05 Feb 2018 07:41:55 -0800
X-MGA-submission: MDFMh3vSFqg7RrAmru2BA9DllGGy360fCUre3Q+wkDhGV9PGp2s77gkCKyr5/ofvoAQebxQRWuAtXI8H5M7c9assdNIA2cl6IyvbAmb01HjbU5NvYhd2lYhSFZdQkGVkfh1R11s+Lo3Jnh9WDxtvO/W4
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg01-sd.qualcomm.com with ESMTP/TLS/AES256-SHA; 05 Feb 2018 07:41:24 -0800
Received: from [10.110.50.170] (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 5 Feb 2018 07:40:59 -0800
From: Pete Resnick <presnick@qti.qualcomm.com>
To: Stewart Bryant <stewart@g3ysx.org.uk>
CC: rtg-dir@ietf.org, mtgvenue@ietf.org, ietf@ietf.org, draft-ietf-mtgvenue-iaoc-venue-selection-process.all@ietf.org
Date: Mon, 05 Feb 2018 09:40:58 -0600
X-Mailer: MailMate (1.10r5443)
Message-ID: <15F0E669-0195-4315-AAA5-AED71CD6C5B3@qti.qualcomm.com>
In-Reply-To: <151782868264.5731.15496399706573021777@ietfa.amsl.com>
References: <151782868264.5731.15496399706573021777@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/v-Uqf1Cg_cHd9dtdGBwySaZmexY>
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 15:41:58 -0000

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.

-

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.

> 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.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478