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

Eliot Lear <lear@cisco.com> Tue, 18 April 2017 15:02 UTC

Return-Path: <lear@cisco.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 514DA128D40 for <mtgvenue@ietfa.amsl.com>; Tue, 18 Apr 2017 08:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hwFFq6TCzFcu for <mtgvenue@ietfa.amsl.com>; Tue, 18 Apr 2017 08:02:34 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7581A12EABC for <mtgvenue@ietf.org>; Tue, 18 Apr 2017 08:02:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8288; q=dns/txt; s=iport; t=1492527750; x=1493737350; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=bUYcmUBMvKbXPoMlmHnvJTP4mWnDKVhdm0H1HFTz1wo=; b=WGc/aNR2Le4FMqgeYj9enHCkwC7jre0YeNXTI9Jn3TEqEheqlMrxyeZn 4sTGYLGvIlZrAqfsIZSGPuv0Aho6X9lIjiGt1jX6wyagCbx01L7lQRXoK 4HDjeXSR1kuZEHoAWozXtlVPQ7bU2NhSye3kqDgv+Io2vcANC5a1j9M/I Y=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AmAQC3JfZY/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBiSWKFXOQcJAthTSCDweGHQKEMxgBAgEBAQEBAQFrKIUWAQQBI0UKBwULCw40AgJXBg0IAQGKDQiqcYImK4p3AQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+IWoJth12CXwEEnSKDfoIQhCOIOYIAhTGDOoZdlA4fOIEFJh0IGBWHKz6JQAEBAQ
X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="asc'?scan'208,217";a="651231169"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Apr 2017 15:02:27 +0000
Received: from [10.61.229.234] ([10.61.229.234]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3IF2RT8017992; Tue, 18 Apr 2017 15:02:27 GMT
To: Yoav Nir <ynir.ietf@gmail.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>
Cc: Alissa Cooper <alissa@cooperw.in>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>
From: Eliot Lear <lear@cisco.com>
Message-ID: <b8adeb34-ab01-b846-9d10-0d6414749e2f@cisco.com>
Date: Tue, 18 Apr 2017 17:02:26 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <D6DA3121-3365-4409-9DF1-8B761608DA11@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="f0paD6dlLBsW55NqaNaui33dWuvlTp8IL"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/C1GESO6erfCwSKdWXfLRIa307tc>
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 15:02:36 -0000

Hi Yoav,

I'm happy that you don't disagree with the conclusion (is that the same
as agreeing?).  Please see below.


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.

>>   * 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.
  * Enforcement of local laws in relation to our use of the network. 
    Here, I wonder if we can word the requirement such that this happens
    in a passive form.

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

Eliot