Re: [84attendees] YVR Checkin Counter Opening Hours (for US)

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 06 August 2012 17:24 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: 84attendees@ietfa.amsl.com
Delivered-To: 84attendees@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCDD21F85FC for <84attendees@ietfa.amsl.com>; Mon, 6 Aug 2012 10:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.216
X-Spam-Level:
X-Spam-Status: No, score=-1.216 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuuEP8rrxnwY for <84attendees@ietfa.amsl.com>; Mon, 6 Aug 2012 10:24:18 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15221F85EF for <84attendees@ietf.org>; Mon, 6 Aug 2012 10:24:18 -0700 (PDT)
Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 6EE2E8A031 for <84attendees@ietf.org>; Mon, 6 Aug 2012 17:24:17 +0000 (UTC)
Date: Mon, 06 Aug 2012 13:24:15 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: 84attendees@ietf.org
Message-ID: <20120806172415.GF53917@mail.yitter.info>
References: <alpine.BSF.2.00.1208042329370.4918@joyce.lan> <CC441360.14564%dblumenthal@pir.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CC441360.14564%dblumenthal@pir.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [84attendees] YVR Checkin Counter Opening Hours (for US)
X-BeenThere: 84attendees@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF 84 attendees mailing list <84attendees.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/84attendees>, <mailto:84attendees-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/84attendees>
List-Post: <mailto:84attendees@ietf.org>
List-Help: <mailto:84attendees-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/84attendees>, <mailto:84attendees-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2012 17:24:19 -0000

On Sun, Aug 05, 2012 at 12:24:31PM -0400, Don Blumenthal wrote:
> You need to choose your security lines better. I haven't filled a US
> Customs form out since I started using Global Entry.

No, he doesn't.  He needs to avoid US transit in Canadian airports.

Canadian security people don't know the difference between GE and
NEXUS and don't care.  They check that you have the paperwork all
signed when you enter the US Immigration area (what I call
"Americaland" when I tell my wife I am hanging up) in any Canadian
airport with pre-screening.  They won't let you into Americaland
without your blue paper.

To haul this onto something vaguely IETF-related, it is an excellent
example of why having more than one protocol solving the same or
closely related problems is a bad idea.  The real issue here is that
both NEXUS and GE allow you to be handled specially, but the NEXUS and
GE systems have different modes of operation.  Also, some NEXUS people
are not GE people and conversely.  Low-level paperwork-checking
door-guarding bureaucrats cannot be expected to keep track of all
these differences and filter correctly, so they've adopted a different
filter: blue paper card.  Teaching them "blue paper card or else this
special plastic card" is likely possible.  "Blue paper card or special
plastic card if it says GE BUT NOT if it doesn't OR if it's this other
card" probably isn't a possible configuration.  The protocols are
different because GE was a thing for US-bound immigration only and
NEXUS was a transborder initiative.  This is like a case of two
vendors solving the same problem differently and the resulting
protocol having the union of all their options.  (Therefore, we should
shut down BEHAVE, QED. ;-)

Best,

A


-- 
Andrew Sullivan
ajs@anvilwalrusden.com