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

Alissa Cooper <alissa@cooperw.in> Mon, 23 May 2016 21:13 UTC

Return-Path: <alissa@cooperw.in>
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 4009C12DBD3 for <ietf@ietfa.amsl.com>; Mon, 23 May 2016 14:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=chOSOfzm; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=fg2mjuIo
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 lxmGqcXTIuY8 for <ietf@ietfa.amsl.com>; Mon, 23 May 2016 14:13:22 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9BAD12DBD2 for <ietf@ietf.org>; Mon, 23 May 2016 14:13:22 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 28EAC207C6; Mon, 23 May 2016 17:13:22 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Mon, 23 May 2016 17:13:22 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=vyYE5/CiMSMAJaVbCikyxOjTmhY=; b=chOSOf zmvKqanS0UAt4kMIB2OiGdsgojlPxMN1ir8phSW9a17qjaazwZwSxgzjVHzgxpqc WRPm6ebTmt/KqiCsk1cmxQV5N8Sbpt1OrvgnPy80VnjPpO2i+CtffiOcGHaMKYgu AYvAkLaQavTDnH/blgrOyQUbTDhPHA4UwZLhw=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=vyYE5/CiMSMAJaV bCikyxOjTmhY=; b=fg2mjuIoGtSxfLM+8KJHEuxRJ+VBUWR3L2fWlK+up+Vwyho G0z/MDkJefOnnpj+vsiaIOPlQK2ZP3JEyDUFTLN+oVmqxFWEJjcBsj3xbQBhaBhq +phlzxJfVCcqPW79uMjQJDDKhF0fYOJ/aNZgA9EbrvIjkSPBRCQt7ahGp41w=
X-Sasl-enc: biFxk9OI1VpISpFSzHSH6XN1gdrNcYqJdb+0TzW18xDJ 1464038001
Received: from [192.168.1.82] (c-24-6-61-198.hsd1.ca.comcast.net [24.6.61.198]) by mail.messagingengine.com (Postfix) with ESMTPA id 79906F29F3; Mon, 23 May 2016 17:13:21 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: A couple of meta points -- IETF 100, Singapore, onwards
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <58598992-449C-4E2B-867D-12D04236AB3A@thinkingcat.com>
Date: Mon, 23 May 2016 14:13:19 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D7078B9A-AF4B-4D40-A8D7-CD7C42DE3218@cooperw.in>
References: <58598992-449C-4E2B-867D-12D04236AB3A@thinkingcat.com>
To: Leslie Daigle <ldaigle@thinkingcat.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/b7G9hqrT-19Gg89idomL7YhAGgk>
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: Mon, 23 May 2016 21:13:25 -0000

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