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

Eliot Lear <lear@cisco.com> Mon, 30 January 2017 14:14 UTC

Return-Path: <lear@cisco.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 DB0441294A5 for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 06:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.721
X-Spam-Level:
X-Spam-Status: No, score=-17.721 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 YkskHH3NiNsc for <mtgvenue@ietfa.amsl.com>; Mon, 30 Jan 2017 06:14:11 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF8B128874 for <mtgvenue@ietf.org>; Mon, 30 Jan 2017 06:14:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9051; q=dns/txt; s=iport; t=1485785651; x=1486995251; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=N0/GdHsTMiyBHPFarGiR+jpWdTN45QtVAXCCjpGyFks=; b=QY4WXNRTksWxuQxEa5hEtXCIc9l9YWEcZ7TvrtEwYBFpApSEQxWmDVl0 7ajaX0yMu6BDtSXIP5eugNbyRQagf/8uHrNdXsNHDu8/Q3j7vbGidmsvJ RQnwPjA/aFVen6z1AqL6gHSfieA3FLhUAFPcAI8++lL9ktgAtMflAO+Ic Q=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3AwD2SY9Y/xbLJq1dGQEBAQEBAQEBAQEBBwEBAQEBhF6ENIoJcpBzlVGCDIYiAoJcGAECAQEBAQEBAWIohGoGI04YC0ICAlcGAQwIAQEQiVCqY4IlinIBAQEBAQUBAQEBAQETD4hQCIFZgQmHT4JfBZtUg2+CA4QPh3qKOIY/kn8fOIEbEwgVFTuEPByBYj+GKwSCOAEBAQ
X-IronPort-AV: E=Sophos;i="5.33,311,1477958400"; d="asc'?scan'208";a="691806944"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Jan 2017 14:14:08 +0000
Received: from [10.61.104.16] (dhcp-10-61-104-16.cisco.com [10.61.104.16]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0UEE8nD020166; Mon, 30 Jan 2017 14:14:08 GMT
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, 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>
From: Eliot Lear <lear@cisco.com>
Message-ID: <24c2e78e-97ab-9642-f067-1da4fc82d9b6@cisco.com>
Date: Mon, 30 Jan 2017 15:14:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <43126aa9-5bc1-fae5-ff76-3ad288e37340@cs.tcd.ie>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="gj883BKFaSTb17Rx54TBOMFgKGcvXDn8o"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mtgvenue/0xcssP2gCjWwPlF39EsAjTjBRBU>
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 14:14:13 -0000

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.


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.

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

>>> - 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...

>
>>> - 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?


>
>>> - 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...

Eliot