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

Jay Daley <jay@ietf.org> Thu, 04 February 2021 19:28 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 49DE33A1755; Thu, 4 Feb 2021 11:28:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 x1gAjBCYqNI4; Thu, 4 Feb 2021 11:27:59 -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 06E113A174F; Thu, 4 Feb 2021 11:27:58 -0800 (PST)
From: Jay Daley <jay@ietf.org>
Message-Id: <8701A8FC-4A35-423B-A2CC-8D7493A3D1F9@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1AD61266-BF3B-41BE-8316-0DADEDAB0AC0"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Fri, 05 Feb 2021 08:27:56 +1300
In-Reply-To: <20210204192605.jcqgxzrrubtl3u72@crankycanuck.ca>
Cc: mtgvenue@ietf.org, admin-discuss@ietf.org
To: Andrew Sullivan <ajs@anvilwalrusden.com>
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> <C2F94173-167B-459B-8550-BC13CFEDED64@ietf.org> <20210204192605.jcqgxzrrubtl3u72@crankycanuck.ca>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/W6thzQZ9BHTcna35zonmwHLooog>
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 19:28:01 -0000

Thank you Andrew, that’s very clear.

> On 5/02/2021, at 8:26 AM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> 
> (ObDisclaimer: I work for the Internet Society but this is just my opinion.)
> 
> On Fri, Feb 05, 2021 at 07:48:17AM +1300, Jay Daley wrote:
>> 
>> 
>> 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?
>> 
> 
> That was my impression of the WG view at the time: such cases were not
> automatically off the table, as long as the _venue_ could support
> getting work done. My impression is that everyone recognized it was
> entirely possible that there'd turn out to be unacceptable
> restrictions anyway, but the only way to sort that out would be to try
> to see whether the unfettered access was possible.  There seemed to be
> a general preference for cases where the Internet was mostly broadly
> open, too, but I seem to recall someone pointing out in at least one
> venue that that city and country would fail the criteria if absolutely
> unfiltered access on mobile networks with prepaid cards were a
> precondition of holding a meeting there. (It was apparently a
> largely successful meeting).
> 
>> - in countries where many VPNs are blocked but VPNs per se are not illegal then does that count as filtered or unfiltered?
>> 
> 
> I believe the general point about VPNs was being able to get work
> done.  So if, for instance, VPNs are legal but only if they're
> controlled by $domestic_carrier, that won't work, because many IETF
> participants need to be able to use their corporate VPN in order to
> get work done.  I think the "can we get work done?" filter is the
> ruling one.
> 
>> - 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?
>> 
> 
> The point of writing the conditions was not to be onerous,
> particularly in the first pass, so if a country has a law or factual
> state of affairs that makes VPNs simply impossible to use it doesn't
> seem reasonable to try to work around that when doing the first pass.
> It is also plainly not ok for the IETF to ask anyone to flout local
> laws in order to attend or support IETF meetings, so in the case of
> actual laws on the books I think your answer just has to be that the
> target location can't meet the requirements, and stop there.
> 
> Best regards,
> 
> A
> 
> 
> -- 
> Andrew Sullivan
> ajs@anvilwalrusden.com
> 
> -- 
> admin-discuss mailing list
> admin-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/admin-discuss
> 

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