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

John C Klensin <john-ietf@jck.com> Mon, 06 August 2012 17:55 UTC

Return-Path: <john-ietf@jck.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 CB4ED21F853B for <84attendees@ietfa.amsl.com>; Mon, 6 Aug 2012 10:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.583
X-Spam-Level:
X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 kulTIfoG0kTP for <84attendees@ietfa.amsl.com>; Mon, 6 Aug 2012 10:55:43 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8CF21F8539 for <84attendees@ietf.org>; Mon, 6 Aug 2012 10:55:43 -0700 (PDT)
Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1SyRQu-000CJF-11; Mon, 06 Aug 2012 13:49:36 -0400
Date: Mon, 06 Aug 2012 13:55:28 -0400
From: John C Klensin <john-ietf@jck.com>
To: Andrew Sullivan <ajs@anvilwalrusden.com>, 84attendees@ietf.org
Message-ID: <B2E0071C14A16E0E70785A49@JcK-HP8200.jck.com>
In-Reply-To: <20120806172415.GF53917@mail.yitter.info>
References: <alpine.BSF.2.00.1208042329370.4918@joyce.lan> <CC441360.14564%dblumenthal@pir.org> <20120806172415.GF53917@mail.yitter.info>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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:55:43 -0000

--On Monday, August 06, 2012 13:24 -0400 Andrew Sullivan
<ajs@anvilwalrusden.com> wrote:

>...
> 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.

The example is even a little worse.  There is no little plastic
card for GE.  There is, at most, an unobtrusive little sticker
on the back of the passport.   I've never asked, but suspected
that this is a security-by-obscurity to prevent issues with GE
participants or making some passports special targets that might
occur if GE participants were prominently identified.  Teaching
those door bureaucrats to identify a GE participant would be
really hard since, essentially, only the traveler and the
machine and its databases really know.

>  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. ;-)

And perhaps most of the WGs working on IPv6 transition.  If you
were to point out that they should not be shut down because
claim they are solving different problems, the analogy might get
even closer.  :-(

    john