Re: [RTG-DIR] Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12

Eliot Lear <lear@cisco.com> Tue, 06 February 2018 10:17 UTC

Return-Path: <lear@cisco.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186AF129516; Tue, 6 Feb 2018 02:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DbqHX0OXkfFU; Tue, 6 Feb 2018 02:17:32 -0800 (PST)
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 B4F7C1241F5; Tue, 6 Feb 2018 02:17:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4800; q=dns/txt; s=iport; t=1517912249; x=1519121849; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=ORAGSWYQrD2hDNz5ufa22BIF3v4TSZfs9tnOb7GW0Tw=; b=QKi9kBkSO9mfjAHUOaUwq7Pu6Ub//CjQd9gmXn5s6C0hVjMQgYjx+qsG lDq/sj8gb8U0g1AiR75geU/wUxlcc+a/obP0mwEcSo0L0QNREAfnzGY3n 3FivnQirMNy34OiaI6PlMpdHDRZj+jkv0tlnJ5TJAO0B9HWk2SzwtTH6A Q=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0B+AQCVf3la/xbLJq1cGQEBAQEBAQEBAQEBAQcBAQEBAYUnhA2LGI8YJ3yYZAcDhTsCgy0VAQEBAQEBAQECayiFJAEFIwRSEAsYKgICVwYBDAgBARCKIbhPgW06gUKDPoN+gXgBAQEBAQEBAQEBAQEBAQEBAQEBEA+EaoVUKQyCQzaEe4M+gmUFimmZRIRjgjKOX4w3iASXfoE8NSOBUDMaCBsVgwSCVBwZgW1BjRKCSwEBAQ
X-IronPort-AV: E=Sophos; i="5.46,468,1511827200"; d="asc'?scan'208"; a="1837898"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 10:17:26 +0000
Received: from [10.61.160.141] ([10.61.160.141]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w16AHQpm017309; Tue, 6 Feb 2018 10:17:26 GMT
To: adrian@olddog.co.uk, 'Alissa Cooper' <alissa@cooperw.in>, 'Stewart Bryant' <stewart@g3ysx.org.uk>
Cc: mtgvenue@ietf.org, rtg-dir@ietf.org, 'IETF' <ietf@ietf.org>, draft-ietf-mtgvenue-iaoc-venue-selection-process.all@ietf.org
References: <151782868264.5731.15496399706573021777@ietfa.amsl.com> <F3AE809A-C4A2-4FCE-91BF-3C64D80E6ACF@cooperw.in> <02b801d39f2d$ee76e3b0$cb64ab10$@olddog.co.uk>
From: Eliot Lear <lear@cisco.com>
Message-ID: <8d31d21e-9e9f-38d5-3898-cb5c0d69a33d@cisco.com>
Date: Tue, 06 Feb 2018 10:17:25 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <02b801d39f2d$ee76e3b0$cb64ab10$@olddog.co.uk>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="8EP7e0nudq6rAQOJqeUjSeEq8FUSoEdvC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/jgBJ0RQ4S38hVbYyiSfPHfU6x9E>
Subject: Re: [RTG-DIR] Rtgdir telechat review of draft-ietf-mtgvenue-iaoc-venue-selection-process-12
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Feb 2018 10:17:35 -0000

Hi Adrian,

<editor hat on; you can relate ;-)>


On 06.02.18 09:36, Adrian Farrel wrote:
> ==
> Physical and remote participants at IETF meetings should be aware that privacy
> norms vary considerably from country to country. Participants with a concern for
> their personal or work-related privacy are advised to familiarise themselves
> with the privacy risks associated with a venue before attending. Concerns may
> include privacy of Internet communications, record of having travelled, and
> freedom of association. Some people may have particular concern for the privacy
> of information stored on electronic devices when they cross specific national
> borders. 
>
> Participants are responsible for taking their own measures in mitigation.
>
> In general, the meeting selection process will not take privacy concerns into
> consideration and will not seek to report on them to the community for any
> chosen venue. However, it is expected that the selection process will exclude
> venues where privacy of attendees is known to be particularly at risk. Such
> exclusions might include (although not be limited to) venues where attendees
> cannot use VPNs or other security mechanisms to access their home networks and
> the Internet in general.
> ==
>
> ...I'm not wedded to that - I only had 4 hours sleep  :-)
>
>

I think you would agree that that text is a bit verbose, and some of
this is well covered in the networking requirements above.  On the other
hand, that text hasn't really changed since Fred created a placeholder
(good that he did), and it seems like we can and should at least provide
some guidance to the IASA (that is to say, your humble editor is
embarrassed that he didn't propose the below earlier).  I also think we
have to be careful how much responsibility to place on the IASA in this
regard.  Here then is my suggestion:

<--snip-->

Privacy Considerations
----------------------------
Different places have different constraints on individual privacy.  The
requirements in this memo are intended to provide for some limited
protections that attendees can apply.  As meetings are announced, IASA
SHALL provide the IETF with any limitations to privacy they have become
aware of in their investigations.  For example, participants would be
informed of any regulatory authentication or logging requirements.

<--snip-->

This provides some transparency without demanding more than a small
increment of work from the IASA (we don't want this to become a huge
legal exercise and expense).

<Editor hat off; now head exposed>

I do want to reinforce something that Alissa pointed out: it is
extremely easy for this organization to require itself out of all
venues.  We need to be very careful of that.

Thanks to you and Stewart, and Jordi earlier, for hammering on this point.

Eliot