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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 30 January 2017 15:07 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 DC09C1299C2 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 07:07:38 -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 DXNrycyn2vYi for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 07:07:36 -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 32E301299C5 for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 07:07:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C44A5BE47; Mon, 30 Jan 2017 15:07:33 +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 6Acc3Yd6gOFq; Mon, 30 Jan 2017 15:07:33 +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 2CFC6BE3E; Mon, 30 Jan 2017 15:07:33 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1485788853; bh=fAYEsD1bYRxFuHpyNOB1H3SpPnxRXffV01R/oG77CuE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dL2MDLXCDSs9puKQRsdI55njFsP+bJA9JdTCwkYqKpmGapPM274KuOL3+YM3NDaae Az1sjq8Kh3/Psvy3erEWGCAMfMwIsGOgx4TeusJpW/rJU7WpNtLDRG7Pbh/qGDPQ/V AKNsdQYx8gCfgn4m08nZCrylHlPuM9qO6x+BTGGQ=
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> <43126aa9-5bc1-fae5-ff76-3ad288e37340@cs.tcd.ie> <24c2e78e-97ab-9642-f067-1da4fc82d9b6@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <092a25ac-ed8f-98a3-a421-6bc6af9d90a2@cs.tcd.ie>
Date: Mon, 30 Jan 2017 15:07:32 +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: <24c2e78e-97ab-9642-f067-1da4fc82d9b6@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="bh3AVj1xvxXbKavmAh3VMHhNqu5hcp3wA"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/cw-DsMQassKLgJqDcvlpko_rrH4>
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 15:07:39 -0000

Hiya,,

On 30/01/17 14:14, Eliot Lear wrote:
> 
> Hi Stephen,
> 
> On 1/30/17 1:40 PM, Stephen Farrell wrote:
> 
>>>> - 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.
> 
> I suggest, then, a one word change:
> 
> OLD:
> 
> The IETF's meeting venue selection process, as with all IETF
> processes, should be as open as possible.
> 
> 
> NEW:
> 
> The IETF's meeting venue selection process, as with all IETF
> processes, should be as open as practicable.

That'd be fine.

> 
> 
> I realize it's a nit.  That's for the literal among us.
> 
> <snip>
>>>> - 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?
>> "[Note] 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."
> 
> I like the concept.  I think it needs just a bit of elaboration so that
> potential hosts understand what is meant:
> 
> Note that "unfiltered" in this context is meant to allow for all
> manner of forms of communications, as the IETF often makes first use
> of its own technologies at our meetings.  In addition, to facilitate
> the business of the IETF it is also necessary for participants to
> hold confidential discussions with their businesses, customers, and
> partners.
> 

I like the above. I'd add though that it's a moving target as well,
e.g. via "As Internet technologies evolve, so do the technical
requirements for the IETF meeting network."

> At the same time, IETF participants are expected to make use of the
> network in a manner consistent with local laws and customs.

Did you mean to include that in the draft? If so, I'd be
against. I think the situation's a bit more subtle than
can be captured here. If one assumes that we might again
meet in .cn then I would not want the above para quoted
at the NOC folks as the reason why we have to put up with
the GFW. Capturing the subtly involved in handling that
in this draft would be too hard I think.

> 
>>>> - 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;-)
> 
> What I meant is that after the Singapore announcement in BA there was an
> uproar that prompted an introspective review on the part of the IAOC. 
> It seems to me that, apart from personnel,  all the  I* groups should be
> prepared to defend ALL of their decisions (not just this one).  That
> doesn't necessarily mean that the IAOC should have to preemptively lay
> out their logic for a given venue.  And in some cases, the answers will
> begin with, “In our judgment...” at which point one either accepts that
> or takes a walk to the NOMCOM...

Ah grand. Fully agree.

> 
>>
>>>> - 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."
>>
> 
> Just a question: if a meeting were to be canceled today, say due to a
> natural catastrophe, who would make that call?

My guess is a combination of IESG/IAOC with help from
folks involved in meeting arrangements (hosts, locals,
ams, NOC).

Ultimately, I'd say it'd be the IESG's responsibility but
that any sane IESG would want the IAOC to agree with them
or to have asked that the IESG make the call. Equally
though if a sane IAOC came to the IESG and said "we really
need to cancel" I can't see it'd be likely an IESG would
disagree, though there'd be a fairly interesting Q&A I'm
sure.

All that said, I've not gone looking anywhere to check
so the above could be wrong. Maybe the contingency plan
behind those URLs has answers?

> 
> 
>>
>>>> - 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.
> 
> I get it.  Just want to avoid consensus calls on what people think is
> reasonable.  Maybe spelling out what is meant by "norms of business
> travel" is best...

I'd avoid the phrase "business travel" entirely. While IETF
travel is business for almost all of us, that phrase has
connotations of more comfort than some of us can afford, at
least for me when I play the poor-mouth:-)

Cheers,
S.

> 
> Eliot
> 
> 
> 
> 
> 
> _______________________________________________
> Mtgvenue mailing list
> Mtgvenue@ietf.org
> https://www.ietf.org/mailman/listinfo/mtgvenue
>