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.
- [DNSOP] Fwd: New Version Notification for draft-a… Joe Abley
- Re: [DNSOP] New Version Notification for draft-ad… Patrik Fältström
- Re: [DNSOP] New Version Notification for draft-ad… Paul Hoffman
- Re: [DNSOP] New Version Notification for draft-ad… Joe Abley
- Re: [DNSOP] New Version Notification for draft-ad… Patrik Fältström
- Re: [DNSOP] Fwd: New Version Notification for dra… Warren Kumari
- Re: [DNSOP] New Version Notification for draft-ad… John Levine
- Re: [DNSOP] New Version Notification for draft-ad… Alec Muffett
- Re: [DNSOP] New Version Notification for draft-ad… John R Levine
- Re: [DNSOP] New Version Notification for draft-ad… George Michaelson
- Re: [DNSOP] New Version Notification for draft-ad… Alec Muffett
- Re: [DNSOP] New Version Notification for draft-ad… Edward Lewis
- Re: [DNSOP] New Version Notification for draft-ad… John R Levine
- Re: [DNSOP] Fwd: New Version Notification for dra… Warren Kumari
- Re: [DNSOP] New Version Notification for draft-ad… Stuart Cheshire
- Re: [DNSOP] New Version Notification for draft-ad… Donald Eastlake
- Re: [DNSOP] New Version Notification for draft-ad… David Conrad