[Mtgvenue] resolution of IESG comments for draft-ietf-mtgvenue-iaoc-venue-selection-process-15

Eliot Lear <lear@cisco.com> Tue, 12 June 2018 12:42 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 21947130E27; Tue, 12 Jun 2018 05:42:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 S7mljjWEgHpn; Tue, 12 Jun 2018 05:42:49 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CD0B130E9C; Tue, 12 Jun 2018 05:42:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18104; q=dns/txt; s=iport; t=1528807369; x=1530016969; h=from:to:subject:message-id:date:mime-version; bh=KJOaui92lEi+O9yYSQZgWtjiR9unysoLlC9iVIwI7hs=; b=UgWEttb23GMTZ3/pL/oPC4mDmO4TzaYCuuo1RGNyqTSDr2yMYXys6A4F SzckEER79Kd+USMwxbDruCBYp/c2XnP7EJEX9iOFkxJdJ2FgBeZX0+pH5 LmoX+938G4/XxBznHXQB43XboeEFqCgZ5MT05lUQSAKrCxRqd/ueIyZNv g=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAwBWvx9b/5hdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDgWGEH5RsgVaDTYw8hnMIA4ceITcVAQIBAQEBAQECbSi?= =?us-ascii?q?FKgQkMR4MFEQCXwEMCAEBEIMOAoF3CI8Mm0eCHB+IKIFZD4hIghOBDySCaIR?= =?us-ascii?q?MgyeCVQKRNodQCYNKgVaDMIYjBoE/g36CRCOFDpE4gVcigVIzGggbFTuCRIJ?= =?us-ascii?q?IjgUdI44SgkgBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,214,1526342400"; d="asc'?scan'208,217";a="398784598"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jun 2018 12:42:48 +0000
Received: from [10.82.217.15] (rtp-vpn3-269.cisco.com [10.82.217.15]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w5CCglWa013607; Tue, 12 Jun 2018 12:42:47 GMT
From: Eliot Lear <lear@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ==
To: "'IESG'" <iesg@ietf.org>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>, ietf <IETF@ietf.org>
Message-ID: <e9f6f6f5-f2af-6a89-09df-d423386c4af7@cisco.com>
Date: Tue, 12 Jun 2018 08:42:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8IJvjV5MGQ06qCfEPuowysUWyBFhQWXg7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/KjQVJ1uAAWDqsc-59c1VbEcQ92E>
Subject: [Mtgvenue] resolution of IESG comments for draft-ietf-mtgvenue-iaoc-venue-selection-process-15
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.26
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, 12 Jun 2018 12:42:56 -0000

Here are the edits that I have tallied, based on IESG comments.  Barring
objections, I will issue a new draft in a day or so.

From Spencer:

Move reference to end; slight grammatical cleanup to match:

OLD:

>       We meet to have focused technical discussions.  These are not
>       limited to scheduled breakout sessions, although of course those
>       are important.  They also happen over meals or drinks -- including
>       a specific type of non-session that we call a "Bar BOF" [RFC6771]
>       - or in side meetings.  Environments that are noisy or distracting
>       prevent that or reduce its effectiveness, and are therefore less
>       desirable as a meeting Facility.

NEW:

>       We meet to have focused technical discussions.  These are not
>       limited to scheduled breakout sessions, although of course those
>       are important.  They also happen over meals or drinks, a specific
>       type of non-session that we call a "Bar BOF", or in side meetings.
>       Environments that are noisy or distracting prevent that or reduce
>       its effectiveness, and are therefore less desirable as a meeting
>       Facility.[RFC6771]


From Ben Kaduk:


Section 3.3, sentence fix:

OLD:

>    o  It is desirable for Overflow Hotels provide reasonable, reliable,
>       unfiltered Internet service for the public areas and guest rooms;
>       this service is included in the cost of the room.


NEW:

>    o  It is desirable for Overflow Hotels to  provide reasonable,
> reliable,
>       unfiltered Internet service for the public areas and guest rooms,
>       and that this service be included in the cost of the room.


Section 4:

> Section 4
>
>    Therefore, the IASA SHALL publicly document and keep
>    current both a list of roles and responsibilities relating to IETF
>    meetings, as well as the selection processes they use in order to
>    fulfill the requirements of the community.
>
> Are the first two (roles and responsibilities)
> qualitatively different from the process used, in terms of
> visibility requirements?  It may make sense to just list all three
> together, without an "as well as".


I propose no change, for fear of it becoming substantial, and the text
is not that bad.


> Section 7
>
>    The requirements in this memo are intended to provide for some
>    limited protections that attendees can apply.
>
> This reads oddly to me -- we provide for limited
> privacy protections that attendees can choose to apply but are not
> universally applied without explicit action?  What are they?
> The text would read more naturally to me as "to provide for some
> limited protections that apply to attendees", though that does of
> course have a different meaning.


I propose the following:


> 7.  Privacy Considerations
>
>    Different places have different constraints on individual privacy.
>    The requirements in this memo are intended to provide for some
>    limited protections. 


Adam's comments:

Abstract:

> I'm having a really hard time parsing this sentence. It seems to make sense if you remove "around".


Indeed.

> §2.1:
>
>>     criteria below, one mandatory and others important, to allow for
>>     the case where local laws may require filtering in some
>>     circumstances.[MeetingNet]
> It's not clear what "[MeetingNet]" is doing here. Perhaps some explanatory text about what the reader can expect to find at that reference would be useful.


I propose to remove this reference, as we do not require it to be
maintained in any way, and Jim warned us that it was out of date.


Ben Campbell's comments:

> §3.2.3 and §3.3: The first section says that the cost of "open and unfiltered
> internet" in public spaces and guest rooms in "typically" included in the room
> price. But the latter simply says they are included.  Is that the intenti? It
> seems odd for the overflow hotels to be held to a higher standard than the
> meeting hotel.

I propose the following edit in accordance with the previous (note this
is a slightly stronger statement, but not out of line with existing
practice):

OLD:

>    o  The IETF Hotel(s) directly provide, or else permit and facilitate,
>       the delivery of a high performance, robust, unfiltered and
>       unmodified Internet service for the public areas and guest rooms;
>       this service is typically included in the cost of the room.

NEW:

>    o  The IETF Hotel(s) directly provide, or else permit and facilitate,
>       the delivery of a high performance, robust, unfiltered and
>       unmodified Internet service for the public areas and guest rooms,
>       and that this service be included in the cost of the room.

> §1, 2nd paragraph: " the IASA to apply their " - Plural disagreement. (It looks
> like a mix of the US English tendency to treat organizations as singular
> entities and the British English tendency to treat them as plural collectives ).

Corrected to "its".


> §7: The last sentence seems disconnected from the rest of the paragraph; I
> suggest a separate paragraph.

Ok.


Martin's comment:

> please forgive me for raising the following point, especially because I haven't
> participated in nor followed the discussions on that draft, but I would much
> prefer if "ethnicity" was used instead of "race".

Term "ethnicity" added.

Alexey's comment:

> I am wondering what is the relationship between the section "2.1.  Core Values"
> and Section 3? I don't think all of core values are expressed as requirements.
> Is section 2 (and 2.1) Informative?
The document already uses appropriate normative language.

Alvaro's comments:

Regarding "participants", s/IETF participants/participants/.  More than
that seems more than editorial.

Correction of "?" to ":"

Regarding the grouping of the BCP, I leave that to the IESG.

Eliot