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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 January 2017 12:40 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 34B1C129462 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 04:40:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.499
X-Spam-Level:
X-Spam-Status: No, score=-7.499 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, URIBL_BLOCKED=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 MRw74MaV4Go6 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 04:40:14 -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 AD9D61293D9 for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 04:40:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 25044BE47; Mon, 30 Jan 2017 12:40:11 +0000 (GMT)
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 lAkjKCUkKg0t; Mon, 30 Jan 2017 12:40:11 +0000 (GMT)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E36EBE3E; Mon, 30 Jan 2017 12:40:09 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485780009; bh=kaWHYT4dVooXcckkvKx92B/lWTMeKWxe046I2OWLezk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=G1Y/DxCRX1Izd6u/CSU7OhTV3ni+jwB6X2PM5a9stWOD0RTEkZnCJSQcW+M6NUy+s UNzsAIFBdZYPRLFqc2e/BW9mgA27VEjdowl6JDeP2jSK+eW/cumHaEBbDdTrIr++bc pjk2+b6ht2z2old52UegpxE/fVNmA4Oe5O/k9y/w=
To: Eliot Lear <lear@cisco.com>, mtgvenue@ietf.org
References: <9139334c-9c5e-814d-4299-c6f5950039b8@cs.tcd.ie> <2dcdf5d1-4e93-7476-79ba-0369e41af1c0@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <43126aa9-5bc1-fae5-ff76-3ad288e37340@cs.tcd.ie>
Date: Mon, 30 Jan 2017 12:40:08 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <2dcdf5d1-4e93-7476-79ba-0369e41af1c0@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Ch4Hn74ClnD0aMcgEfAjuFI0V1EvBGFoS"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/Tg3TJvtw6MJ0oMgfiBLGvpHNBWA>
Subject: Re: [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 12:40:17 -0000

Hiya,

On 30/01/17 09:17, Eliot Lear wrote:
> Hi Stephen,
> 
> 
> On 1/30/17 5:10 AM, Stephen Farrell wrote:
>> 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?
> 
> What do you practically have in mind? 

What I said above - adding a sentence like the above to e.g.
the intro.

> One could go too far with regard
> to certain aspects of contract negotiations.  What's possible and what's
> advisable?

I didn't ask to go too far though, I suggested "as open as
possible."

My reason for suggesting this is that relative lack of
openness has been a cause of IAOC hiccups in the past,
including wrt venue selection, so while it'd not be
right to try fully define here how the IAOC ought in
future be open, (hopefully the IASA2.0 activity will
tackle that), I do think it'd be useful to have that
reminder here. And as I think the community and IAOC
seem to have accepted that more openness here would be
good, acking that in text seems like a good plan to
me.

> 
>>
>> - 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.
> 
> We need to disentangle the two issues you are raising here.  One is how
> to evaluate tradeoffs and the other is the "normative" language.  Let's
> start with the 2nd first, because I think it's easier to address.  The
> good about 2119 language is that we all know what it means.  The bad is
> that in this case, it doesn't really apply.  In particular, MUST's use
> is constrained in an inapplicable way in Section 6 of RFC 2119.  In
> addition,  the authors have made clear "important" may involve a
> tradeoff.  From a transparency perspective, that should be made clear.
> 
> As to how you evaluate what to trade off, this is where your judgment
> comes in.  Which of these "important" things is more important at a
> given moment?  That's why you'd get the big bucks ;-)

I fully accept that tradeoffs will be required and that judgement
wrt those is needed. Saying so would be a good improvement if it's
not there already.

However, I'm still unclear about how one would evaluate what
"important" means. (But if the rest of the wg are fine with
this, then ignoring my doubts is probably right.)

> 
>>
>> - 1.2, 

oops, it's in 2.1

>> 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.
> 
> I think in the instant circumstances, what you're suggesting would be
> unworkable for three  reasons.  First, we can only control where the
> conference is, and not where people come from (and therefore would be
> returning to).  Second, probably we don't want to meet in countries that
> are causing such strife, but, third, if we attempted to hold all
> conferences in venues where exiting were not a problem, probably
> entering would be.

It's a fair point that some of this is not related to
venue selection, though I do think route availability
ought be in scope - say for example we decided to not
meet in the US for a while, then that could (if transit
becomes problematic) presumably also rule out some .ca
venues for which travel via the US is more or less
required for many non-US participants.

>> - 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)
> Got text?

"Not that 'unfiltered' here is meant to mean whatever it
is that IETF participants at the time of a meeting would
consider it to mean - as technology develops our concepts
relating to such technical requirements will change."

>>
>> - 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."
> 
> I thought that was implicit, but I'm personally okay with this addition.
>>
>> - 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.
> 
> Did that not happen in BA and thereafter?

Not sure what "that" you mean, nor whether you're
(dis)agreeing with me;-)

> 
>>
>> - 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).
> 
> My nit is slightly different.  I'd suggest the list be ordered from
> mandatory downward.

I'm fine that the order could be fixed anytime betweeen now
and auth-48.

>>
>> - 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.)
> 
> We have to be rather careful about this, lest the organization take big
> financial hit.  What do you have in mind?

If the IAOC ask the community about a venue N years ahead
of time, with a view to signing a contract M years ahead
of time, that venue's acceptability can change in between.
I think we need to recognise that aspect of a lot of the
criteria, and also say something about this in section 5,
e.g. maybe at the top of section 5 add something like
"The evaluation of the criteria set out in section 3 can
change over time for any venue. Clearly, the closer it
gets to a planned meeting date, the harder it is to make
changes, but the IAOC should be willing to consider
re-evaluating the criteria and their overall conclusions
about venues even quite close to the meeting date. It
is possible, and regrettable, that that causes us to have
to meet in a venue that would not meet our evaluation at
the time of the meeting. Avoiding that is a goal, but may
not always be possible, given the cost issues involved
in late changes."



> 
>>
>> - 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.
> 
> Didn't we just get away from having to evaluate what that means?

Not sure what you mean. My point is that for some IETF
participants (some of the time;-) "business travel" means the
front of the plane and no problems with expensive hotels.
Others are more constrained. I'd prefer we ground the acceptable
costs on the "average" meeting-attending IETFers ability to pay.

>> - 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?
> 
> Funnily enough I wondered about the distinction as well, even what it
> meant.  And so I went and asked a well known accessibility expert
> (Andrea Saks) about this.  She pointed out that this would have to do
> with whether elevators have braille, whether there are bedrooms are set
> up for deaf people (doorbell lights, and such).  I'm going to hazard a
> guess that many venues outside the US are in some way partial compliance
> with what we Americans would call the ADA.  I'm guessing that's what
> this is about.  A good # of UN buildings (including the ITU) have some
> limitations along these lines, for instance.

You may be right, but given it's confusing to both of us, that
suggests a re-write is needed I think, but I also think that all
criteria related to disability logically need to be at the same
level, whether that's mandatory or important.

> 
>>
>> - 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.
> 
> Keep in mind the text of the full requirement (which I'll note with
> tables in text is hard to cut and paste):
> 
>    A range of attendee's health-related and religion- 
>    related dietary requirements can be satisfied with
>    robust and flexible onsite service or through access
>    to an adequate grocery.
> 
> 
> And so the text doesn't REQUIRE on prem accommodation, but something
> nearby.  Also note that it specifies "a range".  That is subject to
> judgment.

I don't disagree with you but still conclude that making this
"mandatory" is us listening a little too much to some of our
loudest voices. (Again, I think those are reasonable voices.)
I am also uncomfortable with us having personal choices (e.g.
dietary or religious) impose mandatory criteria. (I figure
that medical dietary constraints are not the same as personal
choices.) Given the range of personal choices that people
can make that would for those people but just as important
as religion or dietary preferences, I think it'd be an error
to make this mandatory.

> 
>>
>> - 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.
> 
> I think I agree.  If this updates or clarifies those roles, we should be
> clear on how it does so, and we should note that with "Updates:".
>>
>> - 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.
> 
> Yes, I like the idea of it being DEscriptive.
> 
>> - 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:-)
> 
> require_once "MinneapolisDiscussion.php";

Heh. As it happens I think MSP was an ok place to meet
given all the tradeoffs. So two points:

- if someone does have a succinct description of those
repeated discussions, including that in an appendix might
save us from having to do it again
- for me the point remains that while I agree with the
conclusion that tourism is a non-goal, I do think we ought
also say that IETF participants do sometimes prefer nicer
places over crappier (to visit) places and happier people
might in fact do better work.

Cheers,
S.

> 
> 
>>
>> - 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.
> 
> There are words we can probably pull from our IANA response or from the
> Tao as to how we describe ourselves.  I agree that we have to be careful
> about how we characterize ourselves here, and it's perhaps a little more
> than a nit.
>>
>> - 5.1: I don't get why we need to be as prescriptive as
>> "four years out.."
>>
>>
> 
> Regards,
> 
> Eliot
> 
> 
> 
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>