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

Douglas Otis <doug.mtview@gmail.com> Sat, 20 February 2016 00:21 UTC

Return-Path: <doug.mtview@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 A6E521ACE2C for <arcing@ietfa.amsl.com>; Fri, 19 Feb 2016 16:21:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7zzxMLMTX76 for <arcing@ietfa.amsl.com>; Fri, 19 Feb 2016 16:21:52 -0800 (PST)
Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 AB99C1B2D51 for <arcing@ietf.org>; Fri, 19 Feb 2016 16:21:51 -0800 (PST)
Received: by mail-ob0-x22d.google.com with SMTP id xk3so124884652obc.2 for <arcing@ietf.org>; Fri, 19 Feb 2016 16:21:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=nLdcz1S9Nd+w1WBvcYPQkes8ZAiPpBZU3DizOIJNNYs=; b=1DKvZ5/vscjV0kFquS9SF/Zkel0tPGiXLAlqIWJXvqA72a/MJrQA/S6A+fNWXWQ464 x7FCDaorKIcPeFhBB7qAEklycnYnV6A4VtMiRXuFEXsKT0JvhwD/joXZaioj/dHALW40 pSCX/ssMXPTWEJ72puZFCgtlx5RRx/jQ95QAS5qD6pi98rOn9t1jPH5i71c3+zx8KPct c6ezc69Yhvl5s3BYLabqjg7ymCbNzKcco97amDMME1uncr/LWMLp0YejsyaiLXltdpNV yf4Dr3LzyM+PMroNtUu85qoGPMXeCq1qwLkadxiGVjazZPCaB9P5wFnVkGIKP+6UpnL9 Y+Wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=nLdcz1S9Nd+w1WBvcYPQkes8ZAiPpBZU3DizOIJNNYs=; b=EgxZ0OyzsaEenrJyf1ED0GGgwdyTvfemUzI9Lvcoi8sNwyJR4vLJfiFiFMguz9xxeh 3JrDX3Q6+iEtNf0L/8FlYzvvTzwuQIuY+efI/bjUl27iMKNAag3UmRPcPI58XZN414/U wJZf6o4Igol0MUBHP9YXTi1o9pDq0bkflmqVsG/nwFmwTWmoH/s3aVZHlb4tJmpzD5n0 8asJqLPCwtQJFESWvlH9un8ufiF3cJhk/OmoCzQo1UvXcc2KhStJM7s0m2OZZ1W4wMHx SKjL0hTshmUg7g+S458LC2VvXlVhaNncy/6Dukp7LpOgqS3fb/FdFIxiFo/WajwGw+5T hGCg==
X-Gm-Message-State: AG10YOT9mC5utzU32o3RTo6soNTPhuZcNItLLuZdecuH8raR0ckbw/2iW7erPEV6UkJeag==
X-Received: by 10.60.97.233 with SMTP id ed9mr13794851oeb.17.1455927710956; Fri, 19 Feb 2016 16:21:50 -0800 (PST)
Received: from US-DOUGO-MAC.local ([2601:647:4280:238b:acd2:2449:3d16:7bff]) by smtp.googlemail.com with ESMTPSA id k5sm8724925oed.1.2016.02.19.16.21.49 for <arcing@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 16:21:50 -0800 (PST)
To: arcing@ietf.org
References: <CA+9kkMDBPHYg3ENofdZ2jQxh=Wjv3KZXK+gw=5nYT0B=VL87Qg@mail.gmail.com> <D2E4D163.13877%edward.lewis@icann.org>
From: Douglas Otis <doug.mtview@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56C7B243.3020004@gmail.com>
Date: Fri, 19 Feb 2016 16:24:35 -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: <D2E4D163.13877%edward.lewis@icann.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/xjDIDxa1g-tGrD11aAgL2cjbpM0>
Subject: Re: [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: Sat, 20 Feb 2016 00:21:53 -0000


On 2/13/16 12:31 PM, Edward Lewis wrote:
> Replying to this, having at least skimmed, if not read
> the followups...
> 
> On 2/3/16, 13:56, "Arcing on behalf of Ted Hardie" 
> <arcing-bounces@ietf.org on behalf of ted.ietf@gmail.com>
> 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?
> 
> Yep.
> 
>> 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.

Dear Edward,

This is likely my last comment.

Developing a grand scheme to identify how future namespace
resolution is to be handled should be balanced against the
specific solution of a non-global .home TLD offering a
concise and safe method made available early in the homenet
process as a means to avoid delay and security risks
incumbent with any future grand multipurpose scheme.

Homenet offers homes multi-router environments based on IPv6
with services found using DNS-SD. In nearly every possible
deployment of typical home networks generally lacking key
security components, publishing DNS-SD within global DNS
namespace will expose a tremendous level of device
vulnerabilities likely to include those discovered over the
last few years or more.

Don't insist adoption of draft-cheshire-homenet-dot-home-02
must follow some grander scheme that might make use of an
alternate root or URL modification. Any such approach
doubtlessly precludes essential compatibilities needing
consideration for Homenet deployment.

Regards,
Douglas Otis