Re: [Arcing] A bit more on the problem statement

Douglas Otis <> Thu, 04 February 2016 00:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2D8091B35B5 for <>; Wed, 3 Feb 2016 16:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sfjEBazMVzY2 for <>; Wed, 3 Feb 2016 16:45:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D983B1B2BF7 for <>; Wed, 3 Feb 2016 16:45:00 -0800 (PST)
Received: by with SMTP id n128so24217597pfn.3 for <>; Wed, 03 Feb 2016 16:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=G7oMkpNDNoqE51RLL+jvAD/SvfECCgc0NsHoBRs15LE=; b=Cy2xDhSpPzYfjHQXzmAvRQQHfhmPnHgvi6hfU9Yjkj9kPNccE2qmCILZE9hO/udZP7 z4Z32ddiZhdaaM2/as/eR2lSR1CA1ZKV1fWqtVutV0DKkGT6L6bFRRV7s9IyilqjFYDE mbkZ0jwmNnRjHgh8DKEkU9cdr2cDm/rXHLACnsre9Bbyw7ZjlgU21eu3GM8+HGX+rWbS K6tNiZMAU90IeYbJpCAjJyaoYYB2WNy93bGf3O3Cm2TishknB/+BymTvjgGJ+iZDMkAX gz1jZ4azfGBeWzu+/o7U7IJwA9E8vRXqhcQPyiqakP40k85z81nsqvKFqiJMPpjMywUi Xr+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=G7oMkpNDNoqE51RLL+jvAD/SvfECCgc0NsHoBRs15LE=; b=Kz+gPtw5/OG4wjDqQCNHB2F/Hy284zY7DnKJnOIhrHQGViEhyk7a1E4fWohxRzgGq7 8HCKkjY7iorR6o92YChqorSU+2webfhIr9iEm4tytmsqs7j+K9mYlrwtq92ZbMQXYrh7 umOzruio0D+Jkavt8bEBJ2fPJSMb7ZC4OCVh7cYjmCq2mCUIEKXstPQC9wyM1+ULrJXS BSRgAsO7uwo2qhhRrwhPFf0jSxNw/lcZfVPmMgSDk13OxQEiVyzYb/MOBgG0WP/fs7jw moljQizL7hfDob/Gl51uRf4sgqNOxGAQPX2z8MdSh8D/yHXdy564gyFnuk6rNcy4T6Kh /XsA==
X-Gm-Message-State: AG10YOQOuxD/lz94E9xrZawBtSgAh8a24Jy2Jvvt2fZOQtsSu/WUEsoAqKjbey834OvA1A==
X-Received: by with SMTP id va2mr6869920pac.87.1454546700601; Wed, 03 Feb 2016 16:45:00 -0800 (PST)
Received: from US-DOUGO-MAC.local ([2601:646:8800:9378:709f:899e:df8b:885c]) by with ESMTPSA id 3sm12382119pfp.96.2016. for <> (version=TLSv1/SSLv3 cipher=OTHER); Wed, 03 Feb 2016 16:44:59 -0800 (PST)
References: <>
From: Douglas Otis <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 3 Feb 2016 16:46:52 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Arcing] A bit more on the problem statement
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 <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Feb 2016 00:45:02 -0000

On 2/3/16 10:56 AM, Ted Hardie wrote:
> 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.

Dear Ted,

A practical approach would carefully consider name overlays
carved out using specific “Special Use” TLDs generated
locally by resolvers able to access both DNS and local
namespace. This avoids creation of subtly different
namespaces based on protocol selectors such as
<proto-foo>://<domain-name> versus
<proto>://<domain-name>.<foo> that can make use of differing
cryptographic assurances.

The latter maps into current security and url practices and
only requires pro-active standards bodies to insure
available “Special Use” TLDs are made available to fulfill
essential needs. Otherwise users would then need to
carefully examine hffp://<domain-name> as opposed to

.home is already being usurped and should be excluded from
DNS as representing “Special Use” for local non-multicast
naming. TLD carve-outs have been working fairly well until
debates about whether basically money should determine TLDs use.

Douglas Otis