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

Stewart Bryant <stewart.bryant@gmail.com> Thu, 10 May 2018 10:43 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFE412EAC4; Thu, 10 May 2018 03:43:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 PTR1hIEeN5LS; Thu, 10 May 2018 03:43:20 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 931D0126CD6; Thu, 10 May 2018 03:43:19 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id y15-v6so1507122wrg.11; Thu, 10 May 2018 03:43:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=BnIBLrQbEdJj7pDYglhJ4gDbVg70ZsKaubzxIPA2pcc=; b=E20xpLFR7kbGxZhMXNPLqnfhZATQYzvH09brwhuGPLc3uWKXfJcgEmMfyEjHnHCa4m rE8SIDmh20PrH1U4xgiZsIGwlWqxZ8Kw23+s866me8vyKKjvjItbHjvSY/71lyn3XRJ7 a/G5fp+bVvsXHhWyJzQB24OWHvMOXGYqzBWVVT6YE8Hfrwj3oJw/2zwlUjtMIJx6e4xc E4fVF0+qnOzBtwam14XfOBBhkIGZrt3htz3SPwEntfwECrJqqA3Cdz898BHZPAySfIo4 W9GJqIP0xq9I4SfazFWeTbNE/YIrKHzPZD4o8qefh1evbWJB9DuAhZZnCfziIL+lGfFd BFTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=BnIBLrQbEdJj7pDYglhJ4gDbVg70ZsKaubzxIPA2pcc=; b=NaqHkb+oVY44RNl4vESQfsyCop/26J8LQYJel2qb4bayksLZLyko0VsPxcF2dceHJp f1UoMs3ltBK2zX1xrf95GSiuRV+nLctaZlxD6GTgKdsuMkQGt68iIWCvO20kx8E9TMfg Zwqo2ZFvYB6udB/V/UulG2NeGrVfQYHZW/sDKUqepmJkz4NbJwmPoZ4kzYDuO2zEXDv1 eqJ1qUs+Dyj8Go/ZCCcX3RC1CiTko1RPSfyOz+9Vfn3vcwjOl+b5pX5SeuIDRMBtbOy9 8qrHJaPMehniuM4wPF57YJb5khxHfr36e5v8VSVajyJv5T58+CAsvUAmPsorX73Bp4qF MvDQ==
X-Gm-Message-State: ALKqPwf01kgiN7ynVej2n70FAJUqkTYEoaZrIwdKvX02PvD9+OQvfnRC boHK8UixBnZRAyOx+Kfb2HhqSKkJ
X-Google-Smtp-Source: AB8JxZrCCFXHY86+34IdJjV3d69wUOq6HJ4sAWHqphiIa935508EiNuNDUcb7U4lrZg9N5+0GgY9HQ==
X-Received: by 2002:adf:8ac5:: with SMTP id z5-v6mr857223wrz.22.1525948997865; Thu, 10 May 2018 03:43:17 -0700 (PDT)
Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id h12-v6sm684422wmc.7.2018.05.10.03.43.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 May 2018 03:43:17 -0700 (PDT)
Subject: Re: [Mtgvenue] I-D Action: draft-ietf-mtgvenue-iaoc-venue-selection-process-14.txt
To: Eliot Lear <lear@cisco.com>, 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> <e28339ff-0046-02c7-b711-92bdc57e9ec3@cisco.com>
From: Stewart Bryant <stewart.bryant@gmail.com>
Message-ID: <2cda6e85-593b-0151-54e0-1e00823fb5e4@gmail.com>
Date: Thu, 10 May 2018 11:43:16 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <e28339ff-0046-02c7-b711-92bdc57e9ec3@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/qEVCNAcSM9kloVIlYsddFmLc1rQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 10:43:21 -0000

It seems to me that "no-smoking" is a pretty standard policy and 
relatively simple to include and to police.

Beyond that, unless a more practical assessment method can be proposed, 
best effort is all we can do.

- Stewart


On 10/05/2018 09:25, Eliot Lear wrote:
> Hi,
>
> <editor hat firmly OFF>
>
> As the person who caused this stink by adding supporting the no smoking
> requirement (again with editor hat off), I think Andrew's way forward is
> the best.
>
> Eliot
>
>
> On 10.05.18 04:14, 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
>>
>