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
>
>