[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 10.55.192.7 with SMTP id o7mr3524598qki.93.1454525789925; Wed, 03 Feb 2016 10:56:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.14.211 with HTTP; Wed, 3 Feb 2016 10:56:10 -0800 (PST)
From: Ted Hardie <ted.ietf@gmail.com>
Date: Wed, 03 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 is. 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? regards, Ted
- [Arcing] A bit more on the problem statement Ted Hardie
- Re: [Arcing] A bit more on the problem statement Douglas Otis
- Re: [Arcing] A bit more on the problem statement Dan York
- Re: [Arcing] A bit more on the problem statement Mark Nottingham
- Re: [Arcing] A bit more on the problem statement Ted Hardie
- Re: [Arcing] A bit more on the problem statement Ted Hardie
- Re: [Arcing] A bit more on the problem statement Douglas Otis
- Re: [Arcing] A bit more on the problem statement Ted Hardie
- Re: [Arcing] A bit more on the problem statement Ted Hardie
- Re: [Arcing] A bit more on the problem statement Douglas Otis
- Re: [Arcing] A bit more on the problem statement Edward Lewis
- Re: [Arcing] A bit more on the problem statement Douglas Otis
- Re: [Arcing] A bit more on the problem statement Edward Lewis
- Re: [Arcing] A bit more on the problem statement Douglas Otis