Re: [Recentattendees] IETF 100, Singapore -- proposed path forward and request for input

Eliot Lear <> Mon, 23 May 2016 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C91BF12B039; Mon, 23 May 2016 03:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 81yIlnfLG4Sj; Mon, 23 May 2016 03:08:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9C4C12B025; Mon, 23 May 2016 03:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6603; q=dns/txt; s=iport; t=1463998084; x=1465207684; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=wpFtnG3eyWWC09b2UFDmOuRB36oo+HmLHalcPHkXQkU=; b=PAYO56IdHyXTkkmY1ve+o8rnrWtXlvdh3qltiDzW2iIUJs6zWXImCTLA 30iQbsIvKvZwXYq5jhYhOZ94W5qCmHSvIFGDNs2U4RdOgGOZBGF7/Q15L UStgtlq2jLg8GpAxkk6bTqXsW6qE9GK+dpl1JzPY/5ed89m+pH2iCRpRG 0=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.26,355,1459814400"; d="asc'?scan'208,217";a="637604964"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 May 2016 10:08:01 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id u4NA81Mh007529; Mon, 23 May 2016 10:08:01 GMT
Subject: Re: [Recentattendees] IETF 100, Singapore -- proposed path forward and request for input
To: Ted Hardie <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
From: Eliot Lear <>
Message-ID: <>
Date: Mon, 23 May 2016 12:08:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="gVSFeHVW0UJJ3tuTVVL1CtFXRb7l7TkXn"
Archived-At: <>
Cc:, IETF list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 May 2016 10:08:07 -0000

Hi Ted,

Just on your question and one small nit:

On 5/23/16 11:57 AM, Ted Hardie wrote:

> One issue that your and others' analyses seems to imply is that the
> 1-1-1-* formulation is not sufficient.  If it were, finding a small
> number of venues that suited us and shuttling among them would
> generate the fairness required.  If the pure 1-1-1-* were sufficient,
> knowing one venue worked (as a strawman, Yokohama) would mean would
> not have to investigate other places.  But your analysis suggests that
> you believe that this is not enough, and that we need to also go to
> South Korea, China, Taiwan, etc., to be fair.
> Or am I misreading you?

Partially.  You're right to raise the 1-1-1-* model as a key question to
inclusiveness.  We have been to places that would impinge on LGBT
parental rights, most notably in Asia, and we will do so again shortly. 
The point is that the 1-1-1-* becomes increasingly difficult to satisfy
from a logistical standpoint if our criteria are too strict.  My
understanding is that the IAOC has a difficult enough time as it is
finding venues, especially in Asia.

On the nit: what you see as hyperbole I see as a shorthand for the crux
of this debate.  If, on the whole, those in Europe and the United States
enjoy easier access to venues than others, different development and
standardization avenues will be used, just as they have in the past, and
that will lead to fundamentally different technical approaches.  That's
the fragmentation to which I refer to.