Re: [Mtgvenue] issue #3: Too many mandatory

Ted Hardie <ted.ietf@gmail.com> Wed, 05 April 2017 20:50 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 D6CA712945E for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 13:50:47 -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 4S0d61G_7jYl for <mtgvenue@ietfa.amsl.com>; Wed, 5 Apr 2017 13:50:45 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 75027127275 for <mtgvenue@ietf.org>; Wed, 5 Apr 2017 13:50:44 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id i34so21465909qtc.0 for <mtgvenue@ietf.org>; Wed, 05 Apr 2017 13:50:44 -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=QfUu9FXHvf09N6BztbLY/C/jjeFU2sJsHPO8CXMcl6A=; b=M2pBIeSUEs3koi58xzteBrvJICKm558WFcDsRglE3RHEyrXZNGubhfV94RnoubeIwS 5nw+t+DKJJKZYQDv/duIRXYV5r71b+++JfhHmtXKMgdV/D8Ay9DxH4FSS7uLn9Fz+jXh 3iTDiLE9QOolbSYtp1zZu/MRlOERV1V/ys6qSfvX1db1R4DoXwT3aiF8jsgLVFFYS0f7 jM5a1mgefK6oDINfTl2qy+VWyyGGKnsPkEcV4J9IUtnhSx6Yn8do72moDXEWkLtCH/98 i5cO6lzMYuK41CVOpRVvyk88u2g1oRYfv403SLaPVE6eLZOkg1H0/tvFFW7D2lr3ILOB 0rjQ==
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=QfUu9FXHvf09N6BztbLY/C/jjeFU2sJsHPO8CXMcl6A=; b=SgxV1V6jYR9fi5Rk/hAWzaVY9ss0x+fjeseNErRtyoc7/u3c0vlg7pUBXx0m8xSO0d fSukZdTDg+eCb2aNfJ5nOvyyDMmhaBxg0/2HpoHcOW7w4GRLAKq8qNI5dPxS7FMuV/b4 PByxyndvObr4DJfpfhxr3eHJHezafZraCFKNJk3kLap70RwDJ+0sABJsEHQc0kXoBHsj W5pLrgxzacVaqAOpouGDHMW1sb+c00hNJcVIPGBuIApM5Qa1sGpiqbDAJhCsoVI/d9Ht rVqyTs+ZQmM5Gb3cVVB5Z/oWQfCg8bcXZIZLaZKQQHC/4Q+iWjgebzdhgeoyXg7+QwRu n73w==
X-Gm-Message-State: AFeK/H2ouIAl2q5sdS3dJREzocegAeXSb/s2Y+OYf9O3wng5NEjoEgAQcf8op60TPxWPmpchXiV2a6Q9l1Oazg==
X-Received: by 10.200.39.194 with SMTP id x2mr30078644qtx.139.1491425443354; Wed, 05 Apr 2017 13:50:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.54.2 with HTTP; Wed, 5 Apr 2017 13:50:12 -0700 (PDT)
In-Reply-To: <86de8a9c-3de3-dc35-b4e3-42553b91a53a@dcrocker.net>
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> <CA+9kkMA7iQrMg2y6g5=i96HL3-_8X04BsQjZEhzWe++uZzJvmQ@mail.gmail.com> <86de8a9c-3de3-dc35-b4e3-42553b91a53a@dcrocker.net>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 05 Apr 2017 13:50:12 -0700
Message-ID: <CA+9kkMDgwgHd0-THd_eENrCf0GfLjQaMSivx3phX5Bkgyb=fiA@mail.gmail.com>
To: Dave Crocker <dcrocker@bbiw.net>
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "mtgvenue@ietf.org" <mtgvenue@ietf.org>, Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="001a11410188c2a0ef054c718b8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/Kr2nmX-C_50j4LyfhG78QEEmHGo>
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:50:48 -0000

Howdy,

On Wed, Apr 5, 2017 at 1:24 PM, Dave Crocker <dhc@dcrocker.net> wrote:

> On 4/5/2017 1:12 PM, Ted Hardie wrote:
>
>> move or cancel the meeting.
>>
>
>
> BTW, folk seem to have mostly missed that the title of the draft refers to
> 'selection', which is a particular step in the overall process. And the wg
> charter concerns "specification of the venue selection process."
>
>
In each of the categories I put forwarding, I used "scheduling", but I am
fine with replacing it with "selecting".  I've put language for that below,
shifting all of the things post-"selecting" into new sentences.  If those
sentences/instructions don't go in this draft, that's fine by me, provided
they are clear in the directions somewhere.

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.
>
Mandatory:  Do not select this site for a meeting.  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.
>
Exception-required: Confirm that these are met while considering a site for
selection or get community confirmation of the exception.  If they cease to
be met and will not be met at the time scheduled for the meeting, confirm
the exception with the community.

> Important:  Things we care about but which can be traded off if the
balance
> of requirements is met without confirmation by the full community.
>
Important:  Things we care about when selecting site but which can be
traded off if the balance of requirements is met without confirmation by
the full community.  If these cease to be met after selection, these is no
need for community confirmation unless the balance of requirements is no
longer met.

> Desired:  Things we like, but which can be dropped without having an
impact
> on the meeting's effectiveness.

Desired:  Things we like in sites, but which do not have an impact on a
meetings effectiveness and thus can be considered in site selection without
being true requirements.


> All sorts of things happen after a venue is 'selected'.  These things are
> quite distinct form 'selection'.
>
> Contracting is one of those steps.  Another is monitoring and
> re-evaluating if conditions change.  Those are, of course, essential.
>
>
The draft as currently constructed covers those as venue selection steps,
at least as I read Section 5.  If each of those steps needs a new document,
we may be here a while.

Ted



> They are also outside the formal scope of this effort, though everyone
> seems to prefer to conflate them, which is having the predictable effect of
> making discussion and wording considerably more complicated.
>
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>