my summary of discussion regarding IETF #100

Jari Arkko <jari.arkko@piuha.net> Sat, 28 May 2016 17:49 UTC

Return-Path: <jari.arkko@piuha.net>
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 8DAC912D0C3 for <ietf@ietfa.amsl.com>; Sat, 28 May 2016 10:49:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 Yuog2JSIaT70 for <ietf@ietfa.amsl.com>; Sat, 28 May 2016 10:49:45 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2A12B046 for <ietf@ietf.org>; Sat, 28 May 2016 10:49:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D71C92CCAE for <ietf@ietf.org>; Sat, 28 May 2016 20:49:42 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id at_lJJqRgWra for <ietf@ietf.org>; Sat, 28 May 2016 20:49:42 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 05F5C2CC64 for <ietf@ietf.org>; Sat, 28 May 2016 20:49:41 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
From: Jari Arkko <jari.arkko@piuha.net>
X-Pgp-Agent: GPGMail 2.5.2
Content-Type: multipart/signed; boundary="Apple-Mail=_27F1FAB6-1DF2-4FD3-8FED-5E00C1769396"; protocol="application/pgp-signature"; micalg=pgp-sha512
Subject: my summary of discussion regarding IETF #100
Date: Sat, 28 May 2016 20:49:39 +0300
Message-Id: <AB5E1CF9-52C7-46E1-A430-C0E65793728E@piuha.net>
To: "ietf@ietf.org Discussion" <ietf@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/rXNNSmbEmE0sxoFApafxEZBZuec>
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: Sat, 28 May 2016 17:49:47 -0000

Folks,

There’s been a lot of email on this topic. This is my summary of the main take-aways. I am writing it as an AD responsible for tracking general discussions. This is my opinion only, not the IESG's or IAOC's, though I'm grateful for help from both. This is also not a suggestion on what we should do, but rather observations on where the discussion is. I think you'll hear from the IAOC or me more next week.

As Jamie noted recently, it is a good thing when a community can discuss its sensitivity to various issues, approach to diversity, expectations on meeting sites, and so on. I'm proud that the IETF can do that, and do that in the open. The situation is not the same in all organisations.

That being said, any discussion that becomes long, repetitive, and starts to frame various interests in terms of pitting different participants against each other, is in danger of creating divisions that will be difficult to repair. Not to mention burning out various community and committee members. I know I am stressed by this discussion, and I suspect a lot of other people are too. I think Stephen was right in calling for a cool-off period.

I also feel that we have a situation where any binary decision will end up with some set of people feeling that their concerns are not appreciated.

I wanted to make some observations about the discussion, however. There have been some lessons that are hopefully helpful in thinking about this topic.

To begin with a concrete issue that was at the beginning of the discussion: Families and companions have generally not factored into the meeting site selection process in any way in the past. However, during this discussion I believe understanding of the issues related to situations where families sometimes need to travel with a participant has increased. This recognition has been a useful lesson, and can be applied in future. The relevant discussion of this issue should find its way into the meeting venue selection criteria draft.

Also, I certainly think we all respect the need to have a welcoming environment for LGBT community, where the IETF meets. As we respect many other things, mentioned in the discussion.

But beyond that it gets more difficult. It is of course true that the IETF cannot solve all issues. Please do not expect that there can be *any* meeting that has no issues of some sort. However, it is fair to expect us to do two things: first, look for venues that maximize our collective ability to work to make the Internet better. And second, vary our meeting locations because we know that no venue is issue-free.

Several people have pointed out that it is very important that the IETF treats everyone's issues the same. I'd point out though that not everyone reacts in the same fashion, e.g., we need to be aware of people who are or have been silent about their issues, attempt to identify such issues, and consider those as well, fairly, *while* still needing to find a reasonable set of real-world venues.

This thread has also struggled with agreeing on the specific situation on the ground in Singapore. I suppose part of the difficulty is whether one looks at the practical situation or considers the consequences should the risks be realised. In any case, there is disagreement, though it is to be expected that different people would hold different views about the situation. Bridging those differences is, perhaps, not a reasonable goal.

There has been some discussion of positions of principle, topics where we feel strongly about something but that do not have a direct impact on our (+ possibly families) ability to participate. I think most of us agree that making explicit statements of principle about social issues writ large is outside the scope of organisations such as the IETF.

MEETING STRATEGIES FOR THE IETF

The detailed meeting selection criteria have been seen by all as important. Work on a draft is proceeding.

I’m aware that we've not met in Asia too often even after establishing the 1-1-1* policy. Based on my recollection of various venue decisions, there are at least some practical reasons behind (cost and availability of venues) but the results are surprising. We've met in Asia for IETFs only four times in the last ten years (IETFs #94, #82, #79, and #76). We are not following 1-1-1-* very strictly!

Speaking of 1-1-1-*, the best reference for this policy resides in IAOC minutes of a decision that the IESG made many years ago. This seems like an issue that needs to be fixed with proper documentation.

IAOC

Early on in the discussion, we all obviously realised that any small set of people are unlikely to spot as many problems as a broader community. The IAOC has started a practice of releasing lists of potential future meeting sites in an effort to "crowd-source" observations. This is not a solution to all problems, but certainly seems like a useful step. Some diversity can also be added internally, e.g., the meetings committee is planning to ask for additional volunteers.

The question of a more general transparency of what the IAOC is doing has been repeatedly raised and I think the community and the IAOC largely support going in this direction. Obviously a reasonable policy is needed with regards to what information can or can not be exposed to protect contracting; there's clearly more work here for the IAOC.

WHERE ARE WE?

But to finish this email, I wanted to say that IETF #100 is just one aspect both in the problem and solution. The IETF needs a way forward for #100, but it also seems like our community needs time to properly design the criteria, probably some external help in learning more about issues of diverse groups globally, some assurances that the IETF *does* indeed care about various issues that our diverse group has, and so on.