Re: [Mtgvenue] Issue #21: unfiltered should be mandatory

Jim Martin <jim@daedelus.com> Tue, 18 April 2017 16:33 UTC

Return-Path: <jim@daedelus.com>
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 90AC012EC9D for <mtgvenue@ietfa.amsl.com>; Tue, 18 Apr 2017 09:33:56 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 rc59lophEp3v for <mtgvenue@ietfa.amsl.com>; Tue, 18 Apr 2017 09:33:55 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA56128E19 for <mtgvenue@ietf.org>; Tue, 18 Apr 2017 09:33:55 -0700 (PDT)
Received: from imladris.daedelus.com (imladris.daedelus.com [206.197.161.143]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C20DC880F5; Tue, 18 Apr 2017 09:33:54 -0700 (PDT)
Received: from 204-14-225-180.inoc.com (unknown [204.14.225.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by imladris.daedelus.com (Postfix) with ESMTP id 214DC13083C6; Tue, 18 Apr 2017 09:33:54 -0700 (PDT)
From: Jim Martin <jim@daedelus.com>
Message-Id: <1CA5B535-33C3-4F3A-9AD4-0003CA2D07FB@daedelus.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_102415E9-3449-4F9A-92AA-6838B2C6EE05"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 18 Apr 2017 11:33:51 -0500
In-Reply-To: <b8adeb34-ab01-b846-9d10-0d6414749e2f@cisco.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>, Alissa Cooper <alissa@cooperw.in>
To: Eliot Lear <lear@cisco.com>
References: <37de22dc-04a4-f868-698e-cf03cd791957@cisco.com> <5CF8C201-00C4-4E07-BAB6-8CC5A30B54F5@cooperw.in> <7aba8a44-f1b8-b368-2b9a-91ad4bccfbcc@cisco.com> <D6DA3121-3365-4409-9DF1-8B761608DA11@gmail.com> <b8adeb34-ab01-b846-9d10-0d6414749e2f@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/xmwTuj_pMOKCbH_ldCa4FCZjye4>
Subject: Re: [Mtgvenue] Issue #21: unfiltered should be mandatory
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 18 Apr 2017 16:33:56 -0000

> 
> On 4/18/17 4:54 PM, Yoav Nir wrote:
> 
>> We get to determine whether the network is filtered or not two days before the meeting starts. By then participants are in the city, in the air or packing. Measurement cannot affect venue selection. Only promises can.
> 
> There is a site visit at some point, and the contract can build on that.  If the network is filtered to begin with, then at least we know what we're up against before we sign.

	During the site visit, we always ask about (and do some non-exhaustive testing for) filtering, as what is published and what is “real” often differ. Our greatest challenge is that the provider for the venue when we visit is generally different from the providers we’ll be getting the IETF circuits from. Also, venue selection thus far has not required a firm commitment from circuit providers, hence clarity on the providers and their limitations (self imposed or otherwise) come into play well after contracting is complete.

> 
>>> As a matter of course, people working at the IETF have to communicate with both their companies and their customers in confidence, and they could be anywhere.  In this sense, I don't think we can run a successful meeting without such unfettered access.
>>> We tend to eat our own dog food, and as such need necessary network access to conduct experiments.
>> Both of those points assume we need some kind of Internet access that others people on business travel don’t. European countries (not just the UK) are constantly toying with mandatory filtering to prevent copyright infringement, child pornography and hate speech. See the below links in no particular order. Countries in other parts of the world either filter more or plan to filter more. 
> I think there are two aspects here:
> Protection of IETF participants from outside threats.  By requiring unfiltered access, we the IETF participants would be taking on some risks.  We could conceivably demand transparency instead, but I don't think that works for us as a functional requirement.
	At the current time, this is a non-goal. Our networks are as wide open as we can make them, with the exception of BCP-38 and some limited protections for our management networks.

>> 
>> Our use of the Internet is no different from that of any conference of doctors or insurance salespeople.
> 
> Very few doctors and lawyers experiment with Internet technology the way we do.  Consider this: I remember Paul Traina coding up and deploying code from the back of the room with some operators.

	We keep this very much in mind in our design and operations. Our goal is to facilitate not just unencumbered Internet access, but also to allow new work to take place.

	- Jim