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

Edward Lewis <> Sat, 13 February 2016 20:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6D511A70FD for <>; Sat, 13 Feb 2016 12:31:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.308
X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QigZdPMQe2gA for <>; Sat, 13 Feb 2016 12:31:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A9AF1A7034 for <>; Sat, 13 Feb 2016 12:31:37 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sat, 13 Feb 2016 12:31:34 -0800
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.1130.005; Sat, 13 Feb 2016 12:31:34 -0800
From: Edward Lewis <>
To: "" <>
Thread-Topic: [Arcing] A bit more on the problem statement
Thread-Index: AQHRXrSospMxlWD/SE6NYkDkHw/LNp8qfaAA
Date: Sat, 13 Feb 2016 20:31:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3538211490_34123425"
MIME-Version: 1.0
Archived-At: <>
Cc: Ted Hardie <>
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: Sat, 13 Feb 2016 20:31:39 -0000

Replying to this, having at least skimmed, if not read the followups...

On 2/3/16, 13:56, "Arcing on behalf of Ted Hardie"
< on behalf of> wrote:

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

I agree fully, FWIW.

>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?

One solution is to define a single namespace, complimentary to as much
de-jure use that now exists.  Defining what protocols "support" the
namespace can be left to the protocol's discretion.  What I mean is, I
tried for a while to define the scope of protocols that I wanted to have
Domain Names apply to, but calling the set something like "IETF protocols"
turned out to be inaccurate.  So I began to think of - just define a name
space and see what protocols "come" to it.

There's a lot to discuss.  I think markers approach is currently the most
appealing, but, you never can tell at this stage.