Re: Concerns about Singapore

Michael StJohns <mstjohns@comcast.net> Sat, 09 April 2016 21:13 UTC

Return-Path: <mstjohns@comcast.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 A1BE312D150 for <ietf@ietfa.amsl.com>; Sat, 9 Apr 2016 14:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Level:
X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 s7wrM86tJ0eW for <ietf@ietfa.amsl.com>; Sat, 9 Apr 2016 14:13:43 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 295FA12D191 for <ietf@ietf.org>; Sat, 9 Apr 2016 14:13:43 -0700 (PDT)
Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by comcast with SMTP id p0BQa5rlspUrhp0CMaT57X; Sat, 09 Apr 2016 21:13:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1460236422; bh=itluTk9iWM3snSICCWqqLHdWNmpRMvb6gM0RGVQrlww=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=poyPiPMhrTp0deUDO7u0TdQq6ttu4Dg5Xj7LXSCh9QMh2of4yV1gBVfu5INzKpSDl FGC91j0stiZrV8beCQCd70KdaMPPFBr2ThqOCe2IlZzDkmcDM9BP3nBTrvNdQ9mwxn u3NNbylirrw316vbpaiQqocCs5+lfF8r0+TwPSplRZmEgyZA1jRFyNX4bM1pT5XnQU 6HyfA3lTN6TSPKSlhf2yYeZAb/u4h7STsBPFId8xtpgyIJr1AIYVdqKVDLFV5G4JZk CNfXEu+Dl75WMUTygrdGIBvj8JbaiMIQBv1dVpcMEFSRXcQ47K/RUv2heX7rWsZwW2 Yzm+clqKtpyjA==
Received: from [192.168.1.113] ([69.255.115.150]) by resomta-ch2-03v.sys.comcast.net with comcast id gMDi1s0043Em2Kp01MDiY2; Sat, 09 Apr 2016 21:13:42 +0000
Subject: Re: Concerns about Singapore
To: ietf@ietf.org
References: <0D914666-C3D4-4CCE-AD5E-4E5B34EA1A73@piuha.net> <20160407182936.GA21340@pfrc.org> <CAB75xn780nNDjGa_Cc222J20-+1CCHt09Xp8KHzaK=n0xx51pg@mail.gmail.com> <5706B100.9040509@mnt.se> <CAB75xn6fmj84ROUtG5eUB3GerHx83hrEr3w5vSADY_g=BRg5FA@mail.gmail.com> <5706BA40.3060005@mnt.se> <alpine.DEB.2.02.1604072157240.31096@uplift.swm.pp.se> <A9B63A6D-3102-482F-8FFC-2E57A5FD8336@nic.cz> <16925.1460122349@obiwan.sandelman.ca> <m27fg77zst.wl%randy@psg.com>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <57097077.7040703@comcast.net>
Date: Sat, 09 Apr 2016 17:13:27 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <m27fg77zst.wl%randy@psg.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/GnS2dUewJ17phRqBTiXJ7dnDpYM>
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, 09 Apr 2016 21:13:44 -0000

On 4/9/2016 8:05 AM, Randy Bush wrote:
>> yes, we tried that.  My impression is that there were two changes we
>> made, one was known in advance (closed network)
> the ietf network in beijing was open as normal, thanks to the work of
> many.  it had registration, as had maastricht.  and we have passwording
> now.
Most of these things are not like the others:

We have ietf/ietf now - mainly for the benefit of the individual users 
(per client encryption keys), not the per user userid/password that we 
had in Beijing that was only available to registered attendees.

Calling the Beijing meeting network open isn't really correct - we had a 
reverse VPN to the Internet as it exists outside of the PRC.

We did registration in Maastricht simply to figure out the details 
before we got to Beijing - I'm fairly confident that Maastricht wouldn't 
have been different from the previous IETF's without the upcoming 
Beijing meeting.
>
>> the other was unknown (badges being checked)
> cf. rfid discussion in hiroshima.  checking badges has a varied history.
> beijing was conservative.
>
> randy
>

Beijing was the first and only time I can think of where the hotel/host 
provided us with guards (excepting watchmen for the terminal room).  It 
was also the first time that said guards actually kept out someone with 
a valid conference badge. Granted, the badge did not have the holders 
name on it, but it's really never been the IETF's policy to be overly 
concerned about who shows up as long as they are minimally dressed, not 
disruptive to the process and have attained reasonable standards of 
hygiene.  And even those standards have been waived at times.

I'll also note that we neither asked for the guards nor were asked for 
consent for the guards to be placed.  [I believe the previous statement 
to be true, but its possible that I was misinformed.]

It's a little late for this, but I'm suddenly wondering what percentage 
of the on-site registrants  in Beijing were local, and how that 
percentage compares with other meetings.

In any event, each location we've been to has had a challenge or two 
that we've either ignored or overcome.  Some candidate places will have 
challenges that we can neither ignore or overcome and should hopefully 
be down-selected in the meeting planning process.

Later, Mike