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

Ted Hardie <ted.ietf@gmail.com> Wed, 19 April 2017 16:08 UTC

Return-Path: <ted.ietf@gmail.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 BEDA8129436 for <mtgvenue@ietfa.amsl.com>; Wed, 19 Apr 2017 09:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 u8vaWJFV6YFG for <mtgvenue@ietfa.amsl.com>; Wed, 19 Apr 2017 09:08:39 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D08129A9F for <mtgvenue@ietf.org>; Wed, 19 Apr 2017 09:08:38 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id m36so23025964qtb.0 for <mtgvenue@ietf.org>; Wed, 19 Apr 2017 09:08:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QvaamVogG8EfZ1MxGrn4oJ+gMv3EarmrIeRnuJWUREQ=; b=e0nOtvlmqNIC7FtudtL1FTqMwfOg1G8AH82u0pKdUGwSwdEiqxYf57u6aSrfhExRig x8TvV59ESVyqbHhFgQvpaG8LxbkN6ev/IjTZsU9uB1sJRSohlliSt9RdLCBCUE88/Tlh kprW+LfnNDHtvE4edU8j3+81PgnMeukAafE9Eqxu2fL3wkYn48cxMIcWBku8qpCOax5T gOZAa5E9ZYuJxwOiI5y2epOpg4LOXnqIPzkQyBW52/wSc2doZTJJ/zRRDXwex8Ez/mbu XF7L8i5xDJEZoC7/TXwYtB9vMhkG9kW61tfIBTexiWt1MsrCLnAXL4FTygiAylQpObMG N68w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QvaamVogG8EfZ1MxGrn4oJ+gMv3EarmrIeRnuJWUREQ=; b=sdSH+88L4jFWgpU//1WAlsTehCJNdbCJXQ5OQzKwBhe0TT+RBqaogCL9V+y8msmmAW CBwQiLNXR8Gbb6gX8rRVswRMDinwnu0ZV2SS2CfSBpDlmtrnsfKe/qN2jJA3C5BV6SIQ 7DbTFpa2NB8NXEZSi3RWhLWLmW9ZX1b8GOCDI4t7pL9weEvYIb7/LhDDQAXptm2+DDGr uPmkVKsq/bvi2qyprEVwlEX1vUCXM2j4LTZZ1aE6z+D/GJfWcXgm6NlQO+MJU5+7yUVq 2ObzoIpFK0VFXCx6wD29gSqeFBSSlTxLI98+0VowWS9wcl5vT9W96FEae+Ldj6KWqxtS YdNQ==
X-Gm-Message-State: AN3rC/58RBhEECVydf9qRikiLeC9lrnVYS6oIff1gnWOwaqz/nx+EBTK VMzJoysH8Sd5Hl/Y/+JRLP6WXN2qqQ==
X-Received: by 10.200.58.231 with SMTP id x94mr3172592qte.139.1492618117690; Wed, 19 Apr 2017 09:08:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.56.157 with HTTP; Wed, 19 Apr 2017 09:08:07 -0700 (PDT)
In-Reply-To: <66423faa-16ae-49a6-5703-e4021c198b76@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> <CA+9kkMDa4rQfwW=-M4nEgd2GPSmB_2NbT0owZA7yhHdU3AuS7A@mail.gmail.com> <66423faa-16ae-49a6-5703-e4021c198b76@cisco.com>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 19 Apr 2017 09:08:07 -0700
Message-ID: <CA+9kkMBS=sQpN5YHRCmVE2ygKzUe+7pr4d0+TF33UcxySvFfdQ@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Cc: Yoav Nir <ynir.ietf@gmail.com>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>, Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary="94eb2c1254c8b0c30c054d873c1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/7rGcjUZrtBVC8HNKD89SHkN_Htk>
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 16:08:42 -0000

Hi Eliot,

On Tue, Apr 18, 2017 at 11:05 PM, Eliot Lear <lear@cisco.com> wrote:

> To me, whether the venue is doing the filtering based on government
> mandate or whether the government has a Great Firewall matters very
> little.
>
I would class both of these as implementations of the government mandate.
There are quite a few venues, though, that impose limitations based on
their own understanding of security, acceptable traffic patterns, or the
like.  One hotel I stayed in recently, for example, blocked a well-known
consumer video service because the traffic competed with its own on-demand
service.  Many, many others don't permit traffic on ports that they don't
recognize.   In those cases the service is not unfiltered or unmodified by
the venue; they are curating it in ways that hinder the IETF doing its
work.  Making avoiding this a mandatory requirement makes sense to me.

The government mandates are harder to manage, especially when some of them
are crafted to be responses to other social ills (bans on child
pornography, nazi symbolism, etc).  I would put these into a separate
category so that they can be considered during site selection without a
blanket ban.  There is an obvious risk to that (once the machinery in
place, it can be turned to many uses), but it seems like one that has to be
managed with other concerns about the host country or territory.

Just my two cents,

Ted

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