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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 10 May 2018 02:25 UTC

Return-Path: <brian.e.carpenter@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 175D912D86B; Wed, 9 May 2018 19:25:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 OvpyW-gSXvGd; Wed, 9 May 2018 19:25:27 -0700 (PDT)
Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) (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 B45EB12D7F9; Wed, 9 May 2018 19:25:25 -0700 (PDT)
Received: by mail-pl0-x22b.google.com with SMTP id az12-v6so374412plb.8; Wed, 09 May 2018 19:25:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=UDyc+axqB07unwpdwcivSuVl4gd6uz/zmKe4Ugl42EU=; b=VfneuUhf0wolh97DK8u8FT/lOsplJ2oXfy+s4pYf9EwyQC6FVn62WM3/Ka26OI6u/d CsxnXLf3Rt2Rt4DAMZog1PyyYwlHkqqA0VSJgwrXVdVIi6Hg51exBsM/T4R6pM9lXvBt 38Av9//g/Nbz9JOAfeGo+CjW2Un47JirY6xMSAH1mWhecDCsIN2ez+lKxoFkSthb/wfp W3AF1F2a7NnjtuXij5vsQJifx3q2WkHC9/3GvLb8e3uR3UobTGn8GXIO5ewe98GTdnMs bZxkTZj+7rjw25LKBOuvQpOXVOZoPLXI6sY9sfQDZAl0muEg/OlhcZ3JHY59PJrMi86N IFKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UDyc+axqB07unwpdwcivSuVl4gd6uz/zmKe4Ugl42EU=; b=Fg1jz/QASPHxQCVtZiCeTLqaAyHuJWLAlHHHBfZ9QfdPCJ9VNfCAZUAm8ldnCWfv/j 7b7OZ9jLQ0n/g4wl5SnWWd0xeDK5Gqu1MFOx0KIqQYbYJHdE7WJrdtYgad+4LDRcOS/M 3Php2/P+fC+Hbycncw3axvEtz3VAk256XjhpeWfsz5kJQm7/SHNjkGirUsYfMwTNDskB 07V2pV9kEIZP0Tsw3cLh0Osmz32u/nmlyHEASpiU5xWdRPISAT/2P+h9WuPb5NlbG7Hl 5eqZxISRS4pmf6oFj9IELLMoK26RURrlflqAm7NiU+VfuYyf47kbcr8QoCQ19Tn/5+N0 EZaA==
X-Gm-Message-State: ALQs6tCl75uZbCXsx/eG3CkJ2B9qo4Tf3GY6eOBtckjG53Yuowxrkzui BmEvKnD84sx+g2ozqSaYnSXOmg==
X-Google-Smtp-Source: AB8JxZpY/UPzefhGXrf8p31D3pBgCyq75Is9VWCtKwhKmiR1ptPMAfsAFOO7Yx8FEbm/JHJYHn/21g==
X-Received: by 2002:a17:902:7841:: with SMTP id e1-v6mr48287358pln.197.1525919124962; Wed, 09 May 2018 19:25:24 -0700 (PDT)
Received: from [130.216.38.35] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.38.35]) by smtp.gmail.com with ESMTPSA id p84sm32025911pfi.66.2018.05.09.19.25.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 19:25:24 -0700 (PDT)
Sender: Brian Carpenter <becarpenter46@gmail.com>
To: Adam Roach <adam@nostrum.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> <536fd661-ea33-2eb9-19c6-87af88bc33a2@nostrum.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <85ed96ec-6cb5-fca9-0a5d-1275e5153c5a@gmail.com>
Date: Thu, 10 May 2018 14:25:26 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <536fd661-ea33-2eb9-19c6-87af88bc33a2@nostrum.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/_1nxm5KXsST6RAs3SXAZlTWqWrc>
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:25:29 -0000

On 10/05/2018 14:20, Adam Roach wrote:
> I agree with Andrew's rationale, and wholeheartedly second his proposal.

Agreed.

    Brian
> 
> /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
>>
> 
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>