Re: [Mtgvenue] issue #3: Too many mandatory
Ted Hardie <ted.ietf@gmail.com> Wed, 05 April 2017 20:12 UTC
Return-Path: <ted.ietf@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 04108129496 for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 13:12:50 -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, HTML_MESSAGE=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 Cl29q7IyVxnk for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 13:12:46 -0700 (PDT)
Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 5658A129439 for <mtgvenue@ietf.org>; Wed, 5 Apr 2017 13:12:46 -0700 (PDT)
Received: by mail-qt0-x234.google.com with SMTP id i34so20644450qtc.0 for <mtgvenue@ietf.org>; Wed, 05 Apr 2017 13:12:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2CdpjWzcvYLlvTXcuxpkr+GjT3uu8RlSnus2Un/BKQk=; b=QN9SgUNNpBSxPD9SGC/q9QuI6E+hq+ar+u6FcopVIv+bDRhNVEB9lqC3iGA6ZMZWd9 lbgFmNGe1WaM/2hkdI154KZ6CzMskF8zp/l53FkUqqXMZ9z4hDZ5jxs3eOHmM5/4FVVP fcK6ltWLYb2F4GKm+2rlH7pT6Zridc8R8DHeVdMIFYW8kobll27jyxOe9rIYMTN2MZmu zQAM7Zv2+LrLDK0Q6RM1RjwiiERVJTmtjYr+iI0uNFMFDz1CQyoPcki4nHlok8ks4eEj RrpnptL4XXWXvLw8YQslIQ1kj0E2Zy2kNFICd1v3eNNWCE7f25bbEPftm7EC5sE1XUNg h45Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2CdpjWzcvYLlvTXcuxpkr+GjT3uu8RlSnus2Un/BKQk=; b=YXy1PO+WmyIIN3V5jZombC4AooPYNZftwBOBT+PFKpigOPqRE/30vW44vdX9vftKx0 6bF4DiJujzI6v9qioPseAye64F2B6Ss6CYANDaB2NGHP+3UI5UMBssVBU4KbGjTPWYNg JItN9fXpCE7SKWri4SDAf+0TtKqlcKaTrBDTNdwAL5mcwCPbGeh/3zeJ45Q+n35PHl9N jAir8JehU0sR+sS7MUUTzd1TGb3g82evfOmsiUUCk+eQsN0ChIHbBC/x4cZaaFT8qs2G o5rQrnan9cue8NRE+qrFN+LuKqCNqiayMKwkZ6uRcHavxnQatxGG3i5o2jRIqvEjLa31 2PxA==
X-Gm-Message-State: AFeK/H2RUAn+5u5HHemPFLEym6ZU1HJ+B1PsZCimWl0e2Z6oihsgOOhmSC25xtUZ59+DaKr/YlncGq/JvdZ8hg==
X-Received: by 10.200.42.213 with SMTP id c21mr34290012qta.257.1491423164999; Wed, 05 Apr 2017 13:12:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.54.2 with HTTP; Wed, 5 Apr 2017 13:12:14 -0700 (PDT)
In-Reply-To: <c57adf52-3db7-5cfc-d301-3135010e17c6@cs.tcd.ie>
References: <37de22dc-04a4-f868-698e-cf03cd791957@cisco.com> <7add7c4a-032f-6b78-5b5f-861835a64f9a@dcrocker.net> <006325a5-83e7-9295-71a1-67c0125aa7cb@cisco.com> <c57adf52-3db7-5cfc-d301-3135010e17c6@cs.tcd.ie>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 05 Apr 2017 13:12:14 -0700
Message-ID: <CA+9kkMA7iQrMg2y6g5=i96HL3-_8X04BsQjZEhzWe++uZzJvmQ@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: Eliot Lear <lear@cisco.com>, Dave Crocker <dcrocker@bbiw.net>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>
Content-Type: multipart/alternative; boundary="001a11370ed4f5c309054c71035b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/9b1TwXw6n67t76UmCnV7y9FhFlU>
Subject: Re: [Mtgvenue] issue #3: Too many mandatory
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: Wed, 05 Apr 2017 20:12:50 -0000
On Wed, Apr 5, 2017 at 12:18 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Dave, Eliot, > > Seems to me like you're using different semantics for the same > label. > > A: Eliot: ""mandatory" means "it's impossible to have a successful; > meeting unless the criterion is met." > > > B: Dave: "What dropping this item does is to move it from being an > exception requiring community review to something the IAOC can decide > without community review. " which I think is equivalent to saying > that "mandatory" means "MUST unless community informed and ok with > not meeting the criterion." > > I question the utility of (A). I think "mandatory" could be useful, were it actually used the way Eliot describes it. The community could decide, for example, that we cannot have a successful meeting where access to the Internet is not available (e.g. parts of Cameroon at the moment and 55 other places during the course of last yea <https://www.internetsociety.org/sites/default/files/Rights%20Con%202017%20Press%20Release%20March28.pdf>r). We can define that pretty crisply( e.g. "At least N of the K root servers") for the purposes of the requirement. And the marching orders for mandatory can be crisp too: if this isn't met, move or cancel the meeting. If a natural disaster has eliminated the local air transit hub(s): move or cancel the meeting. If an armed conflict has erupted: move or cancel the meeting. It may seem silly to state those and put in the marching orders, but I think it actually helps distinguish between those and the category below which I interpret as "confirm exception is okay". So if the local currency skyrockets and the costs go up 40% over night (hello, CHF), we might have marching orders to confirm the exception to our usual cost basis with the community. I personally hope that the categories end up somewhere along the lines: Mandatory: If not met, don't schedule the meeting here and move or cancel the meeting if the requirement ceases to be met. Exception-required: Confirm that these are met during scheduling or get community confirmation of the exception. Important: Things we care about but which can be traded off if the balance of requirements is met without confirmation by the full community. Desired: Things we like, but which can be dropped without having an impact on the meeting's effectiveness. No hats, Ted (B) might be good actually but > in that case a better label could be defined as meaning that. > > Cheers, > S. > > PS: Apologies if this was discussed on the list before or in the > meeting in Chicago. > > > On 05/04/17 18:51, Eliot Lear wrote: > > Dave, > > > > I think this goes to the heart of what "mandatory" means. Editorially, > > the sense I got of the room (or at least the implication) that matches > > the directive to downgrade was that "mandatory" means "it's impossible > > to have a successful; meeting unless the criteria is met." Thus the > > agreement on the need to argue the reverse of what you listed: what is > > the justification for this requirement being mandatory? > > > > Eliot > > > > > > On 4/5/17 7:42 PM, Dave Crocker wrote: > >> On 4/5/2017 6:40 AM, Eliot Lear wrote: > >>> As mentioned by the chair, I am downgrading requirements based on > >>> working group discussion, mostly from Mandatory to Important. As a > >>> reminder, the words are intended to be used consistent with their > >>> plain meaning. That is- just because something is now Important > >>> specifically does not mean that it is UNimportant. > >> > >> While it's understandable to wish for a shorter list, the realities of > >> what this community keeps insisting on is what produced the current set. > >> > >> For each item that folk propose to drop, we should carefully discuss > >> the history that produced it and the likely community reaction if the > >> requirement is not met, going forward. > >> > >> > >>> From Mandatory to Important: > >> > >> So this means that any of these items can be traded-off against some > >> other item. That means that for each one, it can be acceptable not to > >> satisfy the 'requirement'. > >> > >> Note that there is always the ability to seek exceptions to any > >> requirement. What dropping this item does is to move it from being an > >> exception requiring community review to something the IAOC can decide > >> without community review. > >> > >> > >> Consider... > >> > >> > >>> * Travel to venue is acceptable based on cost... > >> > >> So, it's tolerable to have the travel costs, time and/or effort be > >> prohibitively high and/or difficult? > >> > >> > >>> * The venue is assessed as favorable for obtaining... > >> > >> The challenge in downgrading this has already been noted. > >> > >> > >>> * Travel barriers and visa requirements... > >> > >> So, it's tolerable to have travel barriers and visa requirements be > >> UNacceptable? > >> > >> > >>> * Economic, safety, health... > >> > >> So, going to dangerous, horribly expensive environments, rife with > >> outbreaks of pandemics is tolerable? > >> > >> > >>> * Facility support technology and services... > >> > >> How, exactly, are we doing to have a successful meeting if this is not > >> a mandatory requirement? > >> > >> > >>> * Facility directly provides or permits... > >> > >> Same question. > >> > >> > >>> * The IETF Hotel(s) directly provide, or else permit... > >> > >> Same question. > >> > >> > >>> * The guest rooms at the IETF Hotel(s) are sufficient... > >> > >> Same question. > >> > >> > >>> * The Venue environs, which includes both onsite, as... > >> > >> Sam question. > >> > >> > >>> * A range of attendee's health-related and religion... > >> > >> So we are back to deciding that it's acceptable to have folk with > >> special dietary requirements have to bring a week's worth of food with > >> them to the meeting (or to have to travel long distances from the > >> venue, in order to eat)? > >> > >> > >>> * Overflow Hotels can be placed under contract... > >> > >> It will be tolerable to have no overflow hotels under contract or to > >> have them be a long way away from the meeting venue? > >> > >> > >>> * The Venue environs include budget hotels within... > >> > >> The goal of inclusivity will not be significantly damaged if there are > >> not budget hotels or they are distant from the venue (meaning long and > >> maybe expensive transit both ways)? > >> > >> > >>> * There are sufficient places (e.g., a mix of hallways, bars, meeting > >>> rooms, and restaurants) for people to hold ad hoc conversations and > >>> group discussions. > >>> (This last one is split out from a Mandatory) > >> > >> Given how often and vigorously complains when this is not satisfied, > >> what will make it tolerable, going forward? > >> > >> > >> > >> d/ > >> > > > > > > > > > > _______________________________________________ > > Mtgvenue mailing list > > Mtgvenue@ietf.org > > https://www.ietf.org/mailman/listinfo/mtgvenue > > > > > _______________________________________________ > Mtgvenue mailing list > Mtgvenue@ietf.org > https://www.ietf.org/mailman/listinfo/mtgvenue > >
- Re: [Mtgvenue] issue #3: Too many mandatory Andrew Sullivan
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Fred Baker
- Re: [Mtgvenue] issue #3: Too many mandatory Brian E Carpenter
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Andrew Sullivan
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Brian E Carpenter
- Re: [Mtgvenue] issue #3: Too many mandatory Pete Resnick
- Re: [Mtgvenue] issue #3: Too many mandatory Pete Resnick
- Re: [Mtgvenue] issue #3: Too many mandatory Deen, Glenn (NBCUniversal)
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- [Mtgvenue] Issue #21: unfiltered should be mandat… Eliot Lear
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Eliot Lear
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Yoav Nir
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Jim Martin
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Ted Hardie
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Fred Baker
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Tobias Gondrom
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Charles Eckel (eckelcu)
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Yoav Nir
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Ole Jacobsen
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Eliot Lear
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Eliot Lear
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Ted Hardie
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Ole Jacobsen
- Re: [Mtgvenue] Issue #21: unfiltered should be ma… Fred Baker
- [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Brian E Carpenter
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Stephen Farrell
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Pete Resnick
- Re: [Mtgvenue] issue #3: Too many mandatory Stephen Farrell
- Re: [Mtgvenue] issue #3: Too many mandatory Ted Hardie
- Re: [Mtgvenue] issue #3: Too many mandatory Andrew Sullivan
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Ted Hardie
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Warren Kumari
- Re: [Mtgvenue] issue #3: Too many mandatory Ted Hardie
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Pete Resnick
- Re: [Mtgvenue] issue #3: Too many mandatory Ted Hardie
- Re: [Mtgvenue] issue #3: Too many mandatory Lou Berger
- Re: [Mtgvenue] issue #3: Too many mandatory Pete Resnick
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Andrew Sullivan
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Andrew Sullivan
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Pete Resnick
- Re: [Mtgvenue] issue #3: Too many mandatory Dave Crocker
- Re: [Mtgvenue] issue #3: Too many mandatory Stephen Farrell
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Eliot Lear
- Re: [Mtgvenue] issue #3: Too many mandatory Brian E Carpenter
- Re: [Mtgvenue] issue #3: Too many mandatory Alissa Cooper
- Re: [Mtgvenue] issue #3: Too many mandatory Alissa Cooper
- Re: [Mtgvenue] issue #3: Too many mandatory Fred Baker