Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

Edward Lewis <edward.lewis@icann.org> Thu, 10 December 2015 20:41 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B661B2A66 for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2015 12:41:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.431
X-Spam-Level:
X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 9bx7K3qvk-6a for <dnsop@ietfa.amsl.com>; Thu, 10 Dec 2015 12:41:07 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93B551A0636 for <dnsop@ietf.org>; Thu, 10 Dec 2015 12:41:07 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 10 Dec 2015 12:41:05 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1044.021; Thu, 10 Dec 2015 12:41:05 -0800
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
Thread-Index: AQHRJ0PSuzLkRYFda02G/+vzplx2/J68VjCAgAijuYA=
Date: Thu, 10 Dec 2015 20:41:05 +0000
Message-ID: <D28F49CE.11F44%edward.lewis@icann.org>
References: <EB6AB6D0-8808-49C2-90DE-F4E6E146BDE8@frobbit.se> <20151205034455.41869.qmail@ary.lan>
In-Reply-To: <20151205034455.41869.qmail@ary.lan>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.8.151023
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3532606859_2847151"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/jS4Ycl8Se2nRHZou1kGUokjT1gU>
Cc: John Levine <johnl@taugh.com>
Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 20:41:09 -0000

On 12/4/15, 22:44, "DNSOP on behalf of John Levine"
<dnsop-bounces@ietf.org on behalf of johnl@taugh.com> wrote:

>It occurs to me that there's a difference between local and localhost
>on the one hand and onion on the other.  With local and localhost, you
>still something like an A or AAAA record with an an IP address that
>you can use in the normal way to open a connection.
>
>With onion you get a rather different thing that looks like an open
>TCP connection, a couple of levels up the protocol stack.  So if the
>theory is that these special names are doing a protocol switch, it's
>not one switch, it's potentially a switch per name.  I suppose you
>could say there's yet another switch for test, example, and invalid
>that returns failure at whatever level of the stack you try.
>
>I'm not sure if that makes the discussion notably more complicated
>but it certainly doesn't make it any simpler.

I think this slices the problem space in two incorrect ways.

First, given an identifier, it's not always an address you want.

Second, the purpose of an identifier is access information about an
object.  If the information is an address, how that address is reached is
beyond the scope of the identifier within the context of resolving then
name.

What I'm leading to is, it doesn't matter to a naming system that Tor will
route packets one way or another, that's up to the forwarding code to
determine.  I might get a 32 bit numeric value understood to be a IPv4
address for a mDNS name or for a Tor name when I am done resolving the
name.  The code that used the mDNS name will then open a channel to that
address for the purposes of doing what it wants to do, the code that
accessed the Tor name will, well, do the same.

This isn't all about addresses though.  Identifiers can be used to refer
to an object in physical space to grab stored data about it, stored in a
database.

There's talk about protocol switches.  I think that's a misnomer.  There
are resolution switches.  I see a lot of utility in it being the top-level
name in a Domain Name.  (I'm not ready to say that's the best way to go.)
The alternative is to have the resolution method identified in meta- or
ancillary- information, like the schema of a URL (http://).  Doesn't the
HTTP:// definition though allow the "authority name" to be anything that
looks like a host or domain name but doesn't have to be a DNS name?
That's what makes me prefer the in-name implicit way of identifying the
resolution method.

(Sorry for handwaving while trying to work on a detailed document to
prevent the need from handwaving.  But it seems more convenient to respond
this way.)

Every name/identifer space has to live in a context.  There are way more
identifiers than objects because of differing perspectives or contexts.
Contexts can overlap, e.g., one context could be all protocols (and
applications built on them) related to the IETF.  A list of IETF protocols
would be rather impossible to make, too long, too many gray areas, etc.,
but then again, the list doesn't have to be a firm boundary for what uses
a set of identifiers.  So long as the "client/initiator" and the
"server/recevier" of the identifier agree on the context, they'll get by.