Re: A couple of meta points -- IETF 100, Singapore, onwards

"Leslie Daigle" <ldaigle@thinkingcat.com> Tue, 24 May 2016 13:25 UTC

Return-Path: <ldaigle@thinkingcat.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A8C12D7D2 for <ietf@ietfa.amsl.com>; Tue, 24 May 2016 06:25:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=thinkingcat.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 5NfuJh2zbMGl for <ietf@ietfa.amsl.com>; Tue, 24 May 2016 06:25:28 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB36712D74F for <ietf@ietf.org>; Tue, 24 May 2016 06:20:16 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 77D735980B9; Tue, 24 May 2016 06:20:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :cc:subject:date:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=thinkingcat.com; bh=p Ka0gr2RZfQAWPAkwmyPb1X0Ilw=; b=SPKXQGmhtgwjTTVuj38GvsdXmxsydftqL Rrr9fglYMG8DerzpwGbNzWgzBLE7rC8KSsmXnNPZ59QPvuLOiaXSVqVcAeeQlMAT cGCNn709L0GgU+mmh/h21V1huwlOsuy9l9uUg2Kr9FQND5woAxiM5psT0fR79t2y Zer9vD4Hu8=
Received: from [172.30.181.125] (unknown [91.143.127.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 824885980B8; Tue, 24 May 2016 06:20:15 -0700 (PDT)
From: Leslie Daigle <ldaigle@thinkingcat.com>
To: Alissa Cooper <alissa@cooperw.in>
Subject: Re: A couple of meta points -- IETF 100, Singapore, onwards
Date: Tue, 24 May 2016 09:20:13 -0400
Message-ID: <D95B9AE8-5B5A-4882-A371-3C5825179FC8@thinkingcat.com>
In-Reply-To: <D7078B9A-AF4B-4D40-A8D7-CD7C42DE3218@cooperw.in>
References: <58598992-449C-4E2B-867D-12D04236AB3A@thinkingcat.com> <D7078B9A-AF4B-4D40-A8D7-CD7C42DE3218@cooperw.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
X-Mailer: MailMate (1.9.4r5234)
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/BuBjFnxqOntYCPMfHPdTUYRB-5k>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 13:25:34 -0000

Hi,

(Still speaking for myself)

When the IAOC put together the follow up message with its proposal to 
keep IETF 100 in Singapore, we did have some internal back-and-forth 
about how much detail to put into the reasoning section.  We had a few 
of reasons for that:

+ it’s hard to share the specific data in a way that will communicate 
information usefully to a cast of thousands who mostly aren’t thinking 
in terms of, for example:  an IETF meeting that is 18 months away is 
actually an IETF meeting NOW for planning purposes.  We can talk about 
the details and options for taking different approaches, and this 
community will, but they aren’t really options for taking different 
approaches unless you are talking about a meeting that is a few years 
out, and we’re not.

+ the data is entangled and some of it is conditional 
(if-this-then-maybe-that) — I don’t believe we can present it 
crisply and clearly

+ we are told, on many occasions, just how much this community does not 
want to hear the inner workings of the IASA, and some people physically 
recoil from the prospect of actually being on the IAOC.  You (the 
community) populate the IAOC to track these details and get the work 
done.  Let us do that.


All that having been said, and to give a preview of an answer to the 
question of where/how to discuss IETF 100, I am asking the IAOC to share 
more detail about the specifics of how we see the tradeoffs for IETF 100 
in Singapore/not (from the practical level, only, and with the caveat 
that it will be messy), and to present it in a way that we can hope to 
get feedback from a much broader set of our community than is currently 
engaging in this topic on the IETF@ mailing list.

On that last point — I’d like to be sure that, if we are asking the 
community, we are doing our best to hear from all of our community, 
including a broad spectrum of people from minority groups that have been 
challenged by previous venue selections.

For at least some people, the sort of all-in discussion free for all 
we’re engaging in here is not the most comfortable way to share those 
experiences, and we’re not hearing all of those voices.

I hope to be able to share that, shortly — but it will be an IAOC 
message, not on personal title, and, like any group of more than .5 
IETFers, the IAOC needs some time to find its internal consensus.

Leslie.


-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises LLC
ldaigle@thinkingcat.com
-------------------------------------------------------------------
On 23 May 2016, at 17:13, Alissa Cooper wrote:

> Thank you Leslie. I agree with the strategy of pursuing two lines of 
> discussion, one about IETF 100 and one about the principles used to 
> guide meeting selection. I think it is clear just from the recent 
> thread that the principles discussion will take some time, in 
> particular because the principles are inter-related in different ways. 
> I don’t think it makes sense to rush that discussion to resolution 
> for the expediency of making a decision about IETF 100. In my personal 
> view I’d like to see some version of the inclusivity principle that 
> currently exists in Fred’s draft adopted as a rule for the road 
> going forward, and feel some shame that this was not done long ago 
> (same goes for the accessibility principle) but I’ll take that 
> opinion over to mtgvenue.
>
> Now, about IETF 100.
>
> After the plenary at IETF 95, the IAOC said that it was "gathering 
> information about the situation — including the full cost of 
> canceling existing contracts, so that the IETF community can have a 
> fuller picture from which to provide guidance for our next steps.” 
> But I don’t feel that our picture is much fuller than the picture we 
> had during IETF 95. Thus far the community hasn’t heard anything to 
> characterize the costs of moving IETF 100, nor the opportunities the 
> IAOC investigated for covering those costs, nor the possibilities for 
> other meeting options, nor the criteria that the IAOC used to evaluate 
> those other options given the unique circumstances of potentially 
> needing to relocate a meeting on short order (e.g., “relaxing" the 
> 1:1:1* guideline for 2017, dealing with higher hotel room costs, 
> moving to different dates, etc.).  We have heard some non-IAOC folks 
> make claims about some of those things, but we haven’t received any 
> specific insight from the IAOC about those things that could form the 
> basis from which the community can “provide guidance” on the 
> IAOC’s next steps. This is information the IAOC is exclusively 
> positioned to provide (unlike country-specific information from 
> travel.state.gov).
>
> I realize that there are some details directly implicated by contract 
> negotiations that the IAOC may consider unwise to share on a public 
> mailing list. But it would seem that there is a good amount of detail 
> about each of the items above that can be shared with the community if 
> the point is to get well-informed feedback.
>
> I raise this in particular because Cisco happens to be the host for 
> IETF 100. In chatting with folks around the company, it didn't seem to 
> me that anyone had been contacted by the IAOC about the possibility of 
> helping to offset costs associated with relocating the meeting, prior 
> to you sending your mail last week. This causes me to wonder about 
> exactly what the IAOC considered under the banner of "costs and 
> possibilities of moving the meeting to a different location" in coming 
> to its current decision.
>
> I think it’s obvious that some folks have a clear-cut opinion about 
> whether Singapore is or is not a suitable venue for IETF 100 even in 
> the absence of this information. I would put myself in that camp — 
> having thought about this a lot recently and considered my own 
> participation and the potential impact on other participants, I 
> can’t support the decision to have the meeting there. But I would 
> still like to understand the implications if that decision is made, 
> and for others this may well be key information they need to ground 
> their input to the IAOC.
>
> Thanks,
> Alissa
>
>> On May 23, 2016, at 8:14 AM, Leslie Daigle <ldaigle@thinkingcat.com> 
>> wrote:
>>
>>
>> (Not speaking for the IAOC, which does owe Ted a response, but 
>> offering some of my own perspective of the meta issues in this 
>> discussion).
>>
>> Again, I see 2 burning issues here:
>>
>> 1/ what do we want to consider appropriate meeting sites going 
>> forward, and
>>
>> 2/ what to do with IETF 100/Singapore
>>
>> We’re separating these two because the second has to get decided 
>> pretty much instantly, and in separating them we have to say that the 
>> outcome on “2/“ has to be a one-off, and might not be suitable 
>> under updated policies after we settle out “1/“.
>>
>> Spelling it out a little bit:
>>
>> What the IAOC does is make site selections based on (our 
>> understanding of) the community’s requirements.  To date, our 
>> understanding has been that we should find sites that allow the 
>> greatest proportion of our participants to attend the meeting and get 
>> the work done.   We expect that people make their own choices about 
>> attending or not attending a meeting, and recognize that is gated on 
>> personal choices and beliefs.
>>
>> If the IETF community wants to shift the focus of requirements and 
>> make requirements include other things — such as suitability for 
>> family attendance,  selecting for absence of laws or other policies 
>> that make the experience more difficult or uncomfortable for some 
>> part of our community — that’s fine as long as its a consensus 
>> position.  And, the IAOC needs to have the resultant requirements 
>> spelled out[1].   I argue that discussion should take place on the 
>> aforementioned mtgvenue@ietf.org mailing list, where the meeting 
>> venue selection requirements document is being discussed.
>>
>> I don’t believe we can have that discussion quickly, with the 
>> attention to detail that it needs in order to ensure an outcome that 
>> fits everyone (especially including those who have been more 
>> comfortable suffering in silence than putting their challenges out 
>> for discussion).
>>
>> And, we need to make a decision about IETF 100 quickly.
>>
>> So, to be clear, whatever we decided to do with Singapore for IETF 
>> 100 will NOT be a statement about whether we ever meet in Singapore 
>> again, or never meet in Singapore again (depending on which way the 
>> decision goes).
>>
>> Leslie.
>>
>>
>> [1] Not all requirements are necessarily feasibly implemented, and/or 
>> there are cost implications, but we can all have that discussion as 
>> part of the mtgvenue dialog.
>>
>>
>> -- 
>>
>> -------------------------------------------------------------------
>> Leslie Daigle
>> Principal, ThinkingCat Enterprises LLC
>> ldaigle@thinkingcat.com
>> -------------------------------------------------------------------
>>