[Arcing] A bit more on the problem statement

Ted Hardie <ted.ietf@gmail.com> Wed, 03 February 2016 18:56 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: arcing@ietfa.amsl.com
Delivered-To: arcing@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A27FB1B2B0C for <arcing@ietfa.amsl.com>; Wed, 3 Feb 2016 10:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.599
X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pqVETb_emdSQ for <arcing@ietfa.amsl.com>; Wed, 3 Feb 2016 10:56:31 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78A41B2B11 for <arcing@ietf.org>; Wed, 3 Feb 2016 10:56:30 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id s5so11718621qkd.0 for <arcing@ietf.org>; Wed, 03 Feb 2016 10:56:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=LMLqI4numzA7hlCtIn3LaHl2Rw/vA5gwIUxdUj/60Mc=; b=RfjnTTd3mJ8YQf+ys6D7Uc76AsaDiqdq5iNzQ3DBeZSKrqckmSKhakCcDn5aVY1jWO 6S2tPONxb5r4kY5faSnJmpQYhZDk9XptIklO0EvsvzGHm3mgVNKuRiJDEJ+YuU67IbG6 QprnsWiJougspGB55X4/pxJMpAy3faLDHqW2nXaBWCLG1TJw9y6wTPNb6yEYBRhbn6uo AlULkb9PtRPoxxj60Rr92ornY4qA+UKxeIOwvUaGe543kV7NOEUTU3iTDQuCls8dzBAp 9ubwE0bNeApLJb58ci+c3cu8ALOfYwu0gQNndefbEap+QvX3tVItFM2zh+lmmneMtIMX jFPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=LMLqI4numzA7hlCtIn3LaHl2Rw/vA5gwIUxdUj/60Mc=; b=QCVlX1tacJOUzri1QwR0imbm22SFXeYqmBulBMOehZuzrXzwB8hBRquyXRFrN9HJJ3 JSG3qdE+PtamXJub/CnZasPFWQEtsX/R1993ZPH3GEPgcUWL/OnozKp8Ext6lSRuTBxZ jxjdSoOPxDG/Mhgef7zezMhAp/RmUYDALkaz5kEyeMdzTW3eLNvxgnlv0Lexi7UDrBjr jXCp/YaFfcbjOqklszf+hgP2rLWLnhbgy6eBADBTNSmEQdSsSk8u71MYH085BiqGZYAC gNi6aB/WTS2rfBtWfwKGPuEVEkg19lcBZtLHEI64j2W8l/FFej6cOgPS3sDdrrpr3ZV+ oajA==
X-Gm-Message-State: AG10YOTwHDLzw5ge3AD7uG2KnEBrVSPAUIJaCJ0jON9vBofieNF5Gd3MP/75KoZV0CZkWYpVvor3K2YdlugK7Q==
X-Received: by with SMTP id o7mr3524598qki.93.1454525789925; Wed, 03 Feb 2016 10:56:29 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Feb 2016 10:56:10 -0800 (PST)
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 3 Feb 2016 10:56:10 -0800
Message-ID: <CA+9kkMDBPHYg3ENofdZ2jQxh=Wjv3KZXK+gw=5nYT0B=VL87Qg@mail.gmail.com>
To: arcing@ietf.org
Content-Type: multipart/alternative; boundary=001a1149e40a0692d4052ae22dda
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/StFMERX7Spj2Hlp5bADABpovSwE>
Subject: [Arcing] A bit more on the problem statement
X-BeenThere: arcing@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: This list will discuss different architectural approaches to signalling alternative resolution contexts for Internet names <arcing.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/arcing>, <mailto:arcing-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/arcing/>
List-Post: <mailto:arcing@ietf.org>
List-Help: <mailto:arcing-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/arcing>, <mailto:arcing-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Feb 2016 18:56:33 -0000

In the draft I posted on resolution contexts, I called the overarching set
of names "Internet names", following RFC 891.  Clearly things have moved on
from then no little, but I wanted to get back to that terminology because I
wanted to stress the internetworking aspect of the problem.

For names or identifiers to be meaningful in multiple contexts (like
different networks or administrative domains), those contexts have to see
them as part of the same namespace.  That doesn't mean that there must be
one unitary namespace for every use, but it does mean that each context
that uses a name must share the same idea of what the namespace context

You can resolve that problem by having all names in a single namespace
context.  You can also resolve that by having context markers.

The issue with the first approach is that it is trivial for people to mint
new names.  If those are presumed to be within a single context, that also
means that it is trivial for those new names to conflict either with each
other or established names.  The only available point of control we have at
the moment is in resolution using a specific set of resolution protocols.
That is, a policy body may decline to allow a particular name to be
resolved with the DNS, but anything that doesn't use that set of resolution
protocols can still conflict.  I don't personally see any way to create a
point of control on the minting of the names themselves without a complete
architectural re-write of the entire Internet, so I don't think we can
change the point of control.  That leaves this approach with a pretty big
gap--any name that doesn't use the DNS as a resolution protocol is subject
to squatting, collision, or confusion.

The second approach, using context markers, is approximately where we are
today, but we are using an implicit set of context marker rather than an
explicit one.  But we're not using it particularly well.  As it stands, the
context marker (pseudo-gTLDs) requires a priori knowledge to establish
resolution context *and it doesn't allow you to mark namespaces that don't
share the syntax of the DNS*.  If what we want is a single Internet
namespace, with a marker for which resolution protocol is meant, this could
be refined a bit to work. But every single name delegation in any of the
resolution contexts will remain a source of potential collision, squatting
or confusion, because we still won't control the ability to mint names.

If we shift to an explicit set of markers, we get the following
advantages:  we can use syntax different from the syntax of the DNS; we can
avoid collision at the level of the tuple of namespace, name; we can avoid
conflating resolution context and namespace.  (Note that resolution context
is not a one-to-one mapping with protocol.  As David Conrad has been
pointing out for years, having a cryptographically signed DNS root (or
other zone) means the distribution channel for the information can change;
the resolution context does not).

The disadvantage is that every protocol that works across namespaces must
now be updated to recognize both the explicit markers and the namespaces
themselves.  That's a lot of work and, as IPv6 taught us, the network
effects run against you the whole way.  It may, however, be something that
is significantly easier to deploy incrementally than the core IP layer is.

My first question to this group is:  do folks agree with this
characterization?  If not, what's wrong?

If they do agree with the characterization of the problem, does this sketch
of solution spaces look right?

And, most importantly, which level of the problem do we think we can
solve:  the multiple namespaces one or the unitary namespace/multiple
resolution contexts one?