[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.."
- [Mtgvenue] comments on draft-ietf-mtgvenue-iaoc-v… Stephen Farrell
- [Mtgvenue] Not a nit: comments on draft-ietf-mtgv… Brian E Carpenter
- Re: [Mtgvenue] Not a nit: comments on draft-ietf-… Dave Crocker
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Eliot Lear
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Eliot Lear
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Lou Berger
- Re: [Mtgvenue] Not a nit: comments on draft-ietf-… Stephen Farrell
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Lou Berger
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Eliot Lear
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Dave Crocker
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- [Mtgvenue] Accessibility: (was Re: comments on dr… Dave Crocker
- [Mtgvenue] Priority order: (was: Re: comments on … Dave Crocker
- [Mtgvenue] business travel: (was: Re: comments on… Dave Crocker
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- Re: [Mtgvenue] business travel: and Accessibility: Stephen Farrell
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Dave Crocker
- Re: [Mtgvenue] Priority order: Eliot Lear
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- Re: [Mtgvenue] Priority order: Dave Crocker
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Mary Barnes
- Re: [Mtgvenue] Priority order: Eliot Lear
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Dave Crocker
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Stephen Farrell
- Re: [Mtgvenue] business travel: Brian E Carpenter
- [Mtgvenue] Food (was: Re: comments on draft-ietf-… Dave Crocker
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Ted Lemon
- Re: [Mtgvenue] Food Brian E Carpenter
- Re: [Mtgvenue] Food Dave Crocker
- Re: [Mtgvenue] Food Mary Barnes
- [Mtgvenue] Emergency cancellation [was: comments … Brian E Carpenter
- Re: [Mtgvenue] Emergency cancellation [was: comme… Melinda Shore
- Re: [Mtgvenue] comments on draft-ietf-mtgvenue-ia… Eliot Lear
- [Mtgvenue] Closing on comments to section 5 (was:… Lou Berger
- Re: [Mtgvenue] Closing on comments to section 5 Stephen Farrell
- Re: [Mtgvenue] Closing on comments to section 5 Charles Eckel (eckelcu)