[Mtgvenue] comments on draft-ietf-mtgvenue-iaoc-venue-selection-process-04

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 January 2017 04:10 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C460B1293EB for <mtgvenue@ietfa.amsl.com>; Sun, 29 Jan 2017 20:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.5
X-Spam-Level:
X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 rofsamgitgC5 for <mtgvenue@ietfa.amsl.com>; Sun, 29 Jan 2017 20:10:44 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3DD1293E4 for <mtgvenue@ietf.org>; Sun, 29 Jan 2017 20:10:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2C49BE2E for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 04:10:41 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me8IRSECuiGx for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 04:10:40 +0000 (GMT)
Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A678CBE2C for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 04:10:39 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485749440; bh=/3b9vg1CWmd0j8gddK/RWBHIFXiJVk/PQnQMIchHNkU=; h=To:From:Subject:Date:From; b=d7A0koY+0RiMkJsQ2pDuqo8a+0xV0Vzk2gxrxEqrwqyBPI+blqOeyJlZMWiZ9/7lJ WlIRbyi9BmgcUcKuRcMQrC4RpSCpvYucKF9x5eNIXMheugS0XbASMW6Nsc5Fhpf4P4 FQIoh3zuac/ggjC5F6YpP7MYjYZa/FeyVI1Bepns=
To: mtgvenue@ietf.org
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <9139334c-9c5e-814d-4299-c6f5950039b8@cs.tcd.ie>
Date: Mon, 30 Jan 2017 04:10:39 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000000070305070103090803"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/Gh_VaS4-5UFXMmP9TUMqWG0V5k8>
Subject: [Mtgvenue] comments on draft-ietf-mtgvenue-iaoc-venue-selection-process-04
X-BeenThere: mtgvenue@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 30 Jan 2017 04:10:47 -0000

Thanks for developing this document, I'm sure it'll help us
avoid some repeated discussions when done.

My apologies for not having participated until now but please
find a bunch of comments below.

Please feel free to ignore any that have already been
discussed - I only had time for a quick peek at the archive.

Cheers,
S.

- general: I think there's a statement missing, viz: "The
IETF's meeting venue selection process, as with all IETF
processes, should be as open as possible." Could we add
that or similar to the intro?

- 1.2, mandatory: Do we somewhere address the temporal
aspect of this where a venue used to be (un)acceptable but
that changes? I'm not clear how such changes on the ground
impact on the process described in section 5. (Nor do I
have a good suggestion to offer sorry;-)

- 1.2, important: While I get the good intention here, I
don't know how I would evaluate this, were I ever on the
IAOC. Is that just me? Despite it being hard to do, I
suspect 2119 terms might work better here, with the
definition of SHOULD (as always) being "MUST except when
<X>" for some X that ought be documenntable at the time of
a meeting venue decision. The meat of that change would I
think be that, "Important"/SHOULD requirements would be
treated as Mandatory/MUST requirements in all cases except
when there is a specific stated (or can-be-stated) reason.

- 1.2, inclusiveness, bullet 1: as has become apparent this
week, "entry" is not the only barrier to consider.  We need
somehow to consider "going home" as well and maybe even
(though with lower probability) issues that might arise
in-transit, if route selections are v. limited. That might
be better done in it's own sub-section, not sure.

- 1.2, "unfiltered" - do we need to define that a little
better? I'd suggest we define it as whatever at the time
constitutes IETF consensus on the level of access that is
considered acceptable for typical home/office use for any
non-negligibly-sized subset of IETF participants. It may be
worth noting that a BCP could be a good way to document
that consensus, but is not needed for this document. Such a
BCP would be a moving target, but it's correct that it
ought be.  (Same term occurs in 3.3 btw)

- 2.2, politics: I'd argue that we ought add to the end of
this "... except where such issues significantly impinge on
the ability of IETF participants to work effectively."

- section 3, 2nd para: ought we require the IAOC to be able
to publicly justify its reasoning after it has made a venue
selection decision? I'd like that that be possible and that
IAOC members work on that basis, but there's a risk that
some of us might abuse such a requirement. So I'm not sure
what's right here.

- really a nit, but best stated here: it'd be better if
the rows in the tables had a unique number, to make it
easier to discuss 'em now and later (when folks talk about
why criterion-foo is/isn't met).

- 3.1, consultation: There's a missing temporal aspect here
and elsewhere. I think in this case what's meant to be
mandatory is that the community has been consulted
sufficiently far ahead that changes are still possible.
But we also need to recognise that situations may change,
and even close to a meeting so that there's no real
alternative but to stick with the now-bad plan. (Or to not
meet at all.)

- 3.1, host/sponsors: I don't think this ought be mandatory
as we may move from a sposor-related-to-venue model to some
other ways in which sponsors help out.  It might be better
to cast this as a negative, i.e. to say that it is
mandatory to ensure that a venue is not sponsor-unfriendly
to a significant degree and I'd also s/mandatory/important/

- 3.2, "within the norms of business travel": I don't like
that characterisation - IETF participation might in future
not live up to that budget. Ought we say "acceptable to IETF
participants in general" maybe.

- 3.2, "net cash positive": a question wrt "allow the
meeting to be" - does that mean "has to be" or "could be"?

- 3.2: I don't get the distinction with "wheelchair" being
mandatory and "accessible to people with disabilities"
being only important. That seems like a contradiction to
me. (Same in 3.4) Can you explain?

- 3.5, "health/religion related diets": I think this ought
only be important and not mandatory. I fully understand why
those affected would disagree but IMO promoting this to
mandatory would be paying too much attention to reasonable
people who are noisier than other reasonable people.

- section 4: I think this ought be deleted. There is no need
for tutorial material and what's here could be invalidated
by a re-org of IASA, which has been mooted for this year.
Sections 4.6 and 4.7 are the worst in that respect, in that
they could be a barrier to some changes in IASA that the
IETF may or may not wish to explore.

- section 5: this overall seems too prescriptive to me.  Do
we really think we'll need to follow this process *exactly*
in say 2027? I'd say making this all less prescriptive
would be better.

- 5.3 & 5.5: the links aren't a good idea (and are access
controlled which is unacceptable if not fixed).

nits

- abstract: to me, "IETF plenary" means Wednesday night fun
(currently:-) and not the full week. Suggest rewording
that.

- section 1: does this really describe thought processes?
I doubt it. Perhaps you mean reasoning?

- 1.2, desired: I'm not clear that this definition does not
overlap with "Important"

- 1.2, why do we meet: I think it'd be worth stating that
we also meet so that in-person interaction smoothes later
virtual interactions. There is agenda-independent (and
dinner-independent:-) value in meeting f2f at least
sometimes, if not regularly. That point could be noted
below under "Focus" but would be better in the "Why do we
meet" headline bit I think.

- 1.2: " Within reason, budget should not be a barrier to
accommodation." Huh? I don't get what's meant there, and it
could be ambiguous.  Maybe better deleted as the para as a
whole seems to state the concept well enough?

- 2.2, tourism: I think we ought recognise that people do
work better and do better work when happy. And people are
happier in some venues than others, often for the same
reasons that cause tourists to like a particular venue.
I'd still leave tourism in this section but I'd argue to
qualify it along the above lines - while we don't want to
travel for tourist reasons, we equally do not need to avoid
nice locations and seek out the horrendous:-)

- section 3: I'm not sure that "IETF hotel" and SSIDs are
that closely related.

- 3.2: I'm not sure the IETF is an "internaltion
organisation" and I'd prefer we not call ourselves that.

- 5.1: I don't get why we need to be as prescriptive as
"four years out.."