Re: [Mtgvenue] I-D Action: draft-ietf-mtgvenue-iaoc-venue-selection-process-14.txt

Adam Roach <adam@nostrum.com> Thu, 10 May 2018 02:21 UTC

Return-Path: <adam@nostrum.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 AE614129C70; Wed, 9 May 2018 19:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 njnI7Qx69W-4; Wed, 9 May 2018 19:21:07 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5A44B12708C; Wed, 9 May 2018 19:21:07 -0700 (PDT)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w4A2KsXe054888 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 9 May 2018 21:20:55 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Andrew Sullivan <ajs@anvilwalrusden.com>, mtgvenue@ietf.org, ietf <IETF@ietf.org>
References: <152584638193.2839.7801870228413280951@ietfa.amsl.com> <c30fd21a-85ee-734c-771c-00ff65490acb@cisco.com> <CABmDk8=HKLR89dvDTuO4eguPE5LCV-YPmcbBr1WdUuFNi+NsBw@mail.gmail.com> <20180510021428.GG9500@mx4.yitter.info>
From: Adam Roach <adam@nostrum.com>
Message-ID: <536fd661-ea33-2eb9-19c6-87af88bc33a2@nostrum.com>
Date: Wed, 09 May 2018 21:20:49 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <20180510021428.GG9500@mx4.yitter.info>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/-OIB9jNVzHFh-ZIH6Cry2ciJ_84>
Subject: Re: [Mtgvenue] I-D Action: draft-ietf-mtgvenue-iaoc-venue-selection-process-14.txt
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: Thu, 10 May 2018 02:21:09 -0000

I agree with Andrew's rationale, and wholeheartedly second his proposal.

/a

On 5/9/18 9:14 PM, Andrew Sullivan wrote:
> Dear colleagues,
>
> Mary's, Ted's, and Ole's discussion of particulars of environmental
> contaminents (in this case, smoking and mo[u]ld) makes me again wish
> to suggest the position I held before the specific change was made to
> draft-ietf-mtgvenue-iaoc-venue-selection-process-14.  My position at
> the time was that the Important criterion
>
>     o  Economic, safety, and health risks associated with this Venue are
>        acceptable.
>
> was what we needed.  It was pretty unlikely to be traded off with any
> kind of regularity, since "risk" and "acceptable" were sufficiently
> flexible that we'd need to call out things that were in stark contrast
> to what we normally dealt with.  In any case, I thought, further
> specification would be a problem.  Therefore, I claimed, the above
> criterion was as good as anyone could reasonably expect and it seemed
> that the details needed to be left to meeting planners.  (I didn't
> support it becoming Mandatory because the "are acceptable" language
> means that there's no test, so no way to know whether the Venue
> necessarily fails.)
>
> We are now in the situation where we have a Mandatory criterion about
> smoking in various parts of the Venue, and at least one person who
> claims that such a Mandatory criterion requires site-visiting staff to
> do some kinds of spot checks.  It's totally unclear to me what that
> would mean or what we would do if, 2 or more years later when we
> actually show up, the spot checks turn out to have been wrong.
>
> We are now also faced with the suggestion that the same staff are
> supposed to do mo[u]ld tests without having the requisite training or
> hazardous materials equipment.  If in fact we are demanding staff do
> such things, it seems to me at least plausible that staff would have a
> future complaint if we did not provide them with appropriate equipment
> to undertake the tests.  This is, I think, an important reason why we
> cannot realistically mandate such tests.
>
> Moreover, once we begin requiring such tests by staff, there are other
> pollutants that (1) could be required to be tested and (2) are not yet
> mentioned in the document, either because we haven't yet thought of
> (or discovered) them or because someone who is affected wasn't
> involved in all this.
>
> Therefore, I would like again to propose that we go back to the
> previous text -- which had the nice advantage too of having had
> consensus in the WG -- and drop the new Mandatory criterion in section
> 3.1, relying on staff to do their level best (as they ever have done)
> to address health issues that are likely to affect IETF participants
> at meetings.
>
> None of this, please note, is in any way intended to minimise or
> denigrate the health issues (or even discomforts, for all that) people
> have talked about.  But we need a document that establishes
> principles, not rules.  If one's particular concern cannot be covered
> under the principles laid out, then I think it would be most important
> to raise that.  But this particular change seems to me to be the
> addition of a specific rule where an exising principle in the document
> was already adequate to the purpose.
>
> Best regards,
>
> A
>