Re: [Mtgvenue] [admin-discuss] Consultation on IETF Meeting venue assessment

Jay Daley <jay@ietf.org> Thu, 04 February 2021 18:48 UTC

Return-Path: <jay@ietf.org>
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 5F24E3A170E; Thu, 4 Feb 2021 10:48:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 ecyDU_q0ulMI; Thu, 4 Feb 2021 10:48:20 -0800 (PST)
Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 6CBCA3A170C; Thu, 4 Feb 2021 10:48:19 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Jay Daley <jay@ietf.org>
In-Reply-To: <BL0PR14MB3779879BC3FD101D51261A13C3B39@BL0PR14MB3779.namprd14.prod.outlook.com>
Date: Fri, 5 Feb 2021 07:48:17 +1300
Cc: "mtgvenue@ietf.org" <mtgvenue@ietf.org>, "admin-discuss@ietf.org" <admin-discuss@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C2F94173-167B-459B-8550-BC13CFEDED64@ietf.org>
References: <CAB75xn4N3zrfiHAdh_djQxui2-U5CutcN2sLzBE6DiWTm33QYQ@mail.gmail.com> <7A39E361-6EED-4157-82BB-B56E7921FECB@ietf.org> <0AB6B02A-B917-4C8B-867E-F20DEF2FED2C@cisco.com> <BL0PR14MB3779879BC3FD101D51261A13C3B39@BL0PR14MB3779.namprd14.prod.outlook.com>
To: Lou Berger <lberger@labn.net>, Eliot Lear <lear=40cisco.com@dmarc.ietf.org>, Dhruv Dhody <dhruv.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/tiF9yzE1xScHsIvW44ljX3v9bCo>
Subject: Re: [Mtgvenue] [admin-discuss] Consultation on IETF Meeting venue assessment
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 04 Feb 2021 18:48:23 -0000

I’ve also re-read the RFC and I’m still not clear:

First, just a reminder that this assessment is conducted remotely before we visit the site, and site visits only take place if it passes this stage.  With that in mind, the various mentions of Internet access in RFC 8718 are:

> Core values (non-normative?):
> 
>       As an organization, we write specifications for the Internet, and
>       we use it heavily.  Meeting attendees need unfiltered access to
>       the general Internet and their corporate networks.  "Unfiltered
>       access", in this case, means that all forms of communication are
>       allowed.  This includes, but is not limited to, access to
>       corporate networks via encrypted VPNs from the meeting Facility
>       and Hotels, including Overflow Hotels.  We also need open network
>       access available at high enough data rates, at the meeting
>       Facility, to support our work, which includes support of remote
>       participation.  Beyond this, we are the first users of our own
>       technology.  Any filtering may cause a problem with that
>       technology development.  In some cases, local laws may require
>       some filtering.  We seek to avoid such locales without reducing
>       the pool of cities to an unacceptable level by stating a number of
>       criteria below, one mandatory and others important, to allow for
>       the case where local laws may require filtering in some
>       circumstances.
> 
> Mandatory criteria:
> 
>       It MUST be possible to provision Internet Access to the Facility
>       and IETF Hotels that allows those attending in person to utilize
>       the Internet for all their IETF, business, and day-to-day needs;
>       in addition, there must be sufficient bandwidth and access for
>       remote attendees.  Provisions include, but are not limited to,
>       native and unmodified IPv4 and IPv6 connectivity, and global
>       reachability; there may be no additional limitation that would
>       materially impact their Internet use.  To ensure availability, it
>       MUST be possible to provision redundant paths to the Internet.
> 
> Important criteria:
> 
>       The IETF Hotels directly provide, or else permit and facilitate,
>       the delivery of a high performance, robust, unfiltered, and
>       unmodified Internet service for the public areas and guest rooms;
>       this service is to be included in the cost of the room.


Do we take it that this means that if all the hotels support VPN access and the venue itself supports unfiltered access (i.e. no need to use a VPN for access) then that is acceptable, even if VPNs are blocked or are illegal outside of the hotels and venue?

There do appear to be data sources on the blocking and legality of VPNs, but that generate two more questions:

- in countries where many VPNs are blocked but VPNs per se are not illegal then does that count as filtered or unfiltered?

- if the local situation is that VPNs are blocked or illegal then can we work with that (i.e. it fails the assessment) or do we somehow need to contact every possible satellite hotel to see if they will support VPN access as an exception to local law?


Jay


> On 4/02/2021, at 11:47 PM, Lou Berger <lberger@labn.net> wrote:
> 
> Eliot, Dhruv,
> 
> Thank you so much for your comments, I completely agree with them. I had to go reread the RFC to verify my memory was not wrong given the degree of differences in announcement and what I thought had been agreed to.
> 
> Lou
> 
> On February 4, 2021 3:18:35 AM Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:
> 
>> To add, one of the requirements is wheelchair accessibility.  Now… perhaps this is a given, these days, and so it’s not worth mentioning, but I did note its absence.  Personally I wouldn’t complain if you applied a more general ADA-like requirement, but that isn’t what the doc says, for reasons quite honestly I don’t remember.
>> 
>> Also, on human rights, there was a strong consensus at the time to not choose venues based on such a matter.  
>> 
>> This is captured in the following non-objective:
>> 
>>    Politics:
>>       Endorsing or condemning particular countries, political paradigms,
>>       laws, regulations, or policies.
>> 
>> 
>> Our requirements are stated in terms of safety and/or security of the attendees, the likelihood of the ability of people to get to and from the venue, and the ability of attendees to have unimpeded Internet access. This may seem like a subtle difference, but the language of our requirements excludes HR so that it is clear we are not making a political statement by including or excluding a venue.  To do otherwise has implications for how the IETF is perceived, which itself might limit support for, and participation in, our community in ways we would wish it hadn’t.  
>> 
>> Eliot
>> 
>> 
>>> On 4 Feb 2021, at 07:55, Jay Daley <jay@ietf.org> wrote:
>>> 
>>> Thank you Dhruv, I understand the error now. I will log this as an issue and amend the assessment form. 
>>> 
>>> Jay
>>> 
>>> -- 
>>> Jay Daley
>>> IETF Executive Director
>>> 
>>> 
>>>> On 4/02/2021, at 6:36 PM, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:
>>>> 
>>>> 
>>>> Hi Jay, 
>>>> 
>>>> I agree with Stephen/Eliot. IMHO the "Internet Access" in RFC 8718 is not fully aligned with the "Internet Freedom Score" at freedomhouse.org. For one, RFC 8718 focuses on filtering on means of communication whereas freedomhouse seems to focus on content filtering. 
>>>> 
>>>> Looking at the map link - https://freedomhouse.org/explore-the-map?type=fotn&year=20192019, we don't have any country but Japan that meets the criteria in Asia. So, no Bangkok, Singapore, or Seoul! And not sure how the city/venue exception may override the mandatory criteria! Maybe that can be clarified. We should look for sources that focus more on the means of Internet Access more closely aligned to RFC 8718? In the absence of which, perhaps this should be a subjective judgment call. 
>>>> 
>>>> Thanks! 
>>>> Dhruv
>>>> 
>>>> On Thu, Feb 4, 2021 at 4:32 AM Jay Daley <jay@ietf.org> wrote:
>>>> Hi Eliot
>>>> 
>>>>> On 3/02/2021, at 9:47 AM, Eliot Lear <lear=40cisco.com@dmarc.ietf.org> wrote:
>>>>> 
>>>>> Signed PGP part
>>>>> Hi Jay,
>>>>> 
>>>>> I am uncomfortable with what I am reading.  The criteria you have listed don’t seem to me to be well correlated to RFC 8718.
>>>> 
>>>> Each of the criteria is taken directly from RFC 8718, though with simplified language, and is marked as to whether that is a mandatory or important criteria in RFC 8718.  If the language simplification is a problem then please let me know.
>>>> 
>>>>>  Is it your intent to update 8718?
>>>> 
>>>> No.  The intent is that RFC 8718 contains such requirements as that for "Internet Access", which we need to turn into an objective, fair and repeatable assessment process.  This is attempting to do that.  If you think we have misinterpreted the criteria then please let me know.
>>>> 
>>>>>  The goal is to have a successful meeting.  We have done so at two venues that your assessment criteria would reject, and conceivably do so in India and Mexico, which your criteria would also reject.
>>>> 
>>>> In order to address any issue here I need detail - can you please specify why you think India and Mexico would be rejected using this assessment and how that indicates failings in the assessment? 
>>>> 
>>>> cheers
>>>> Jay
>>>> 
>>>>> 
>>>>> Eliot
>>>>> 
>>>>> 
>>>> 
>>>> -- 
>>>> Jay Daley
>>>> IETF Executive Director
>>>> jay@ietf.org
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> admin-discuss mailing list
>>>> admin-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/admin-discuss
>>>> -- 
>>>> admin-discuss mailing list
>>>> admin-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/admin-discuss
>> 

-- 
Jay Daley
IETF Executive Director
jay@ietf.org