Re: Concerns about Singapore

John C Klensin <> Sat, 09 April 2016 23:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16F8612D1E5 for <>; Sat, 9 Apr 2016 16:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id syMZkgKZyJdg for <>; Sat, 9 Apr 2016 16:03:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A977D12D1E1 for <>; Sat, 9 Apr 2016 16:03:12 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1ap1uH-000D0v-5R; Sat, 09 Apr 2016 19:03:09 -0400
Date: Sat, 09 Apr 2016 19:03:04 -0400
From: John C Klensin <>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <>, Ole Jacobsen <>
Subject: Re: Concerns about Singapore
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <alpine.OSX.2.01.1604091401420.42313@rabdullah.local> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
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: Sat, 09 Apr 2016 23:03:14 -0000

--On Sunday, April 10, 2016 00:36 +0200 Patrik Fältström
<> wrote:

> On 9 Apr 2016, at 23:05, Ole Jacobsen wrote:
>> There are several sources online for this information,
>> including the US State Department, but we are also actively
>> seeking clarification from contacts in Singapore about these
>> issues. So far, I am fairly certain that our attendees won't
>> notice any issues at all, but stay tuned as we gather the
>> facts.
> FWIW, ICANN has met in Singapore a few times recently and I
> have not heard about any issues what so ever.


This has been mentioned several times.  Let me make an
observation about ICANN meetings.  Especially in recent years,
they are very political.  Especially in smaller or less
developed countries, they usually occur at the invitation of the
government or with the fairly explicit permission and
involvement of the government.  Part of selective enforcement
(see Melinda's recent note) is that attendees at such meetings
are rarely messed with unless their behavior is impossible to
ignore and sometimes not then.  ICANN is further down that scale
than actual UN or diplomatic meetings: I've been in countries
where, had I come (to tried to come) as, e.g., a tourist or
random meeting attendee, I would have been a prohibited person
but, because I was traveling on UN papers, I had great
confidence that no one was going to interfere with me.

Singapore, for better or worse, has a well-established
reputation as a rather pragmatic place.  Because of the above,
an attendee at an ICANN meeting is less likely to be interfered
with than, e.g., one at an APNIC or Apricot one.   I suspect the
latter are less likely to be interfered with than an IETF
attendee just because of different relationships between the
organizations and their members and the long-term interests of
the country.  An IETF attendee is less likely to be interfered
with than a permanent resident of the country.  But the laws are
there, they are apparently intermittently enforced, and no IETF
participant should need to worry about whether they or their
families are going to be in the wrong place at a time when a
hotel staff member or law enforcement official is having a bad
day (or an attack of religious or other zeal) and looking for
someone to take it out on.

I could also note that ICANN, given the view of its role by some
of its leadership in recent years, had found it desirable or
necessary to cozy up to some of the world's more problematic
autocratic regimes.  Whether side deals are made with those
regimes or not, that behavior certainly should not set a
standard for the IETF to follow.