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

Eliot Lear <lear@cisco.com> Wed, 19 April 2017 06:05 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 5F20513151E for <mtgvenue@ietfa.amsl.com>; Tue, 18 Apr 2017 23:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 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, 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 SabMHXIFHVV6 for <mtgvenue@ietfa.amsl.com>; Tue, 18 Apr 2017 23:05:56 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57529131519 for <mtgvenue@ietf.org>; Tue, 18 Apr 2017 23:05:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9277; q=dns/txt; s=iport; t=1492581955; x=1493791555; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=dN9ZlKgUI0V/xZrOcLlrdV0Mit31k7O02cymianv7ik=; b=HSFevigl3V36hEMNi0mJYarfDSnc5p1EqQKe5dcTRlkBfRkkS2EbR1N5 I+hdq2AppDla4PF8UVeJzInZhvMeq/3J6s4dPVNNQ5lVNHPyFkir5UepD 86Wov62I491/oq+SEcjriqEtHkKACyJGi8t0MoXupP6NDXIax8bePMUHQ I=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AnAQB4/fZY/xbLJq1cGQEBAQEBAQEBAQEBBwEBAQEBhT+DZ4oVc5BOIYgeiA+FNIIPB4YdAoQ3GAECAQEBAQEBAWsohRYBBSNWEAsYJwMCAiElEQYBDAYCAQEQiW0DFat3giYrhxANg2kBAQEBAQEBAQEBAQEBAQEBAQEBAQEOD4gvKwqBWQGBCYJRhQyCXwEEnGc7g36CEIgWhEaKa4ZdiwuJAx84gQUmHQgYFYUvF4FlPjWJFQEBAQ
X-IronPort-AV: E=Sophos;i="5.37,219,1488844800"; d="asc'?scan'208,217";a="654085782"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Apr 2017 06:05:52 +0000
Received: from [10.61.217.35] ([10.61.217.35]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3J65pX4026800; Wed, 19 Apr 2017 06:05:52 GMT
To: Ted Hardie <ted.ietf@gmail.com>, 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> <CA+9kkMDa4rQfwW=-M4nEgd2GPSmB_2NbT0owZA7yhHdU3AuS7A@mail.gmail.com>
Cc: "mtgvenue@ietf.org" <mtgvenue@ietf.org>, Alissa Cooper <alissa@cooperw.in>
From: Eliot Lear <lear@cisco.com>
Message-ID: <66423faa-16ae-49a6-5703-e4021c198b76@cisco.com>
Date: Wed, 19 Apr 2017 08:05:51 +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: <CA+9kkMDa4rQfwW=-M4nEgd2GPSmB_2NbT0owZA7yhHdU3AuS7A@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="NWWNbnqeFt4XxJlwamJSk2fFLfrijmNDA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/V22REJUlohtcrQwDvxsuIE5rPLc>
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: Wed, 19 Apr 2017 06:05:57 -0000

To me, whether the venue is doing the filtering based on government
mandate or whether the government has a Great Firewall matters very
little.  The fundamental point is this: I don't think the IETF could
have a successful meeting if we cannot hold private communications with
our home offices or customers.  Putting this into context in the current
wording, that would mean that the IAOC should seek out venues in places
where this wouldn't be a problem.  If the situation changes after
contracts are signed, then the IAOC would be required to consult the
community, and then they would have to make a decision.

Maybe we can get around this by crafting the requirement to allow
unfettered VPN access both from hotel rooms and the facility, but I
think that comes pretty close to just unfettered access to everything.

But I guess my question to experienced IAOC and meeting folk is this:
just how hard would this have hit us in the past?  Fred and Ole have
already discussed one venue.  Are there others?  Is there a way to
circumscribe the requirement, such as what Ole mentioned with regard to
how it was handled in that particular case?

Eliot


On 4/18/17 9:58 PM, Ted Hardie wrote:
> On Tue, Apr 18, 2017 at 7:54 AM, Yoav Nir <ynir.ietf@gmail.com
> <mailto:ynir.ietf@gmail.com>> wrote:
>
>     Both of those points assume we need some kind of Internet access
>     that others people on business travel don’t.
>
>
> I think this varies a good bit.  Some of our communication back to our
> companies is bog standard business traveler stuff; some of our
> communications among ourselves or our devices is not.  A network that
> allows WebRTC media and data channels to flow without TURN servers is
> better for our remote participants, for example, and that may be a
> consideration for the typical business traveler.  We also have IETF
> network users who are more likely to engage in direct network
> management (or management of network devices) than would be common.  A
> tight firewall will hinder their ability to do that, and result in
> them spending time on fiddling with that rather than contributing.
>
> I agree that  "unfiltered and unmodified" may be difficult to assure
> when nation states may change their laws, but I think it is reasonable
> for us to require that this be unfiltered and unmodified *by the
> venue's own actions*.  The larger question of what to do when meeting
> in a place all of whose facilities are required to implement such
> filtering likely belongs in a different requirement.
>
> Just my two cents,
>
> Ted