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

Douglas Otis <doug.mtview@gmail.com> Fri, 05 February 2016 04:39 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 665981B34FA for <arcing@ietfa.amsl.com>; Thu, 4 Feb 2016 20:39:39 -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 2JX042YQd5Vo for <arcing@ietfa.amsl.com>; Thu, 4 Feb 2016 20:39:37 -0800 (PST)
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (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 918EB1B34FB for <arcing@ietf.org>; Thu, 4 Feb 2016 20:39:37 -0800 (PST)
Received: by mail-pa0-x236.google.com with SMTP id ho8so27426906pac.2 for <arcing@ietf.org>; Thu, 04 Feb 2016 20:39:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=+5/EwDAm3jjqytZ6zniCQwrecJ1+/Lhygz1nCxBFD9M=; b=PckUKE/xfyiX213iTAJYcUctKtVn76ts08CmSw4vrPfTgmBJymcgz1KESdrXvyLtOh utrG82zbHvsdXzjm0oXTggU8KUAoDWJk+Uquas/CBxtPp3Qxm+08FHxloZZyH4FG7YCA Q/5heP3ewKCikUBdnI0A92b+qXe+zFrHMQt/P3EcPXu1n8uXpuTRWfJ6bNn9aNvwCOBs 8zAA3u+gtaT3fiUWVnax4m3Qg0ViGKQH4++MCeujhrfMYREEf2eDn6JBtj1Sn7DnTJE0 8mF9lDS9RqeZrc/OgpIiW0GcNNhmw82YlmhCFaRsCQffhjrs7XJ2Z+Fj8NatdKU2KKWU E9Dg==
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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=+5/EwDAm3jjqytZ6zniCQwrecJ1+/Lhygz1nCxBFD9M=; b=irCuLl9oWuBJqBd1YVlwCJ4vYs8iCasK/mlj2e8T518sBSPxI+Z+iZ7uwSEufeKbKC DsYooL5m9CFYGNGyvA7isTzkqwj1uS1If3WO2/Q8OVKIzIpYTMFM4yjuh1K3rWQ1l2pt vbxrfhdXxP0A7joKT+2p82dtqAZ4oX4KuvVHwWXxFoyNL0fgC5DxH6By6TVMporUHbvh mme1KxA6vrs/EBDDSfZLh+4lFBPJSNmeuRR6rhEh8ODGqxd8xDMm2BCCDlNnrK2GUzkm 0OWtLLvszTkvRxyTxzrFNSwpSkL0IXn8X7c3AtKmG8Etu4daqJJzvM0uAMWud/cRsCPe kG6g==
X-Gm-Message-State: AG10YOTr7JT51vT47bpc6JcIuuiYpwgUvwhTE/3yUTKctgnYF6LPchgor/B/R0DWF4OqGg==
X-Received: by 10.66.90.133 with SMTP id bw5mr16743131pab.22.1454647177255; Thu, 04 Feb 2016 20:39:37 -0800 (PST)
Received: from US-DOUGO-MAC.local (c-76-21-122-217.hsd1.ca.comcast.net. [76.21.122.217]) by smtp.googlemail.com with ESMTPSA id z3sm20641979par.17.2016.02.04.20.39.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 04 Feb 2016 20:39:36 -0800 (PST)
To: Ted Hardie <ted.ietf@gmail.com>
References: <CA+9kkMDBPHYg3ENofdZ2jQxh=Wjv3KZXK+gw=5nYT0B=VL87Qg@mail.gmail.com> <524E4EBB-DB02-4091-9F5D-14F103A81178@mnot.net> <CA+9kkMBP1EBe7Bc0nh-DJoJaFNzSofPyuO2NOR+BDjJtFt_WZA@mail.gmail.com> <56B3D81C.9050609@gmail.com> <CA+9kkMBspy_mKummQDvBcaSC3PXX4-cLde=Qpfi9y8Ey31_BdQ@mail.gmail.com> <CA+9kkMArYF5=oYx8U78hZM-7uOyQVZ-YrA55oV+6pPFPfic6fw@mail.gmail.com>
From: Douglas Otis <doug.mtview@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56B427FD.8050400@gmail.com>
Date: Thu, 04 Feb 2016 20:41:33 -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: <CA+9kkMArYF5=oYx8U78hZM-7uOyQVZ-YrA55oV+6pPFPfic6fw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/81diSBVEjnPsV3UYATdJmPrYvsI>
Cc: arcing@ietf.org
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: Fri, 05 Feb 2016 04:39:39 -0000

On 2/4/16 3:15 PM, Ted Hardie wrote:
> For what it is worth, I think you missed the fact I was 
> citing someone else's work, not advocating .alt myself. 
> That said, I believe the draft you cite has a method that
> covers this:

Dear Ted,

The draft
https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02
describes a Special-Use domain but it does not overcome the
need for a domain. There are no valid justifications not to
allow .home as a Special-Use domain. Homenet protocols
require a domain to publish DNS-SD resources to avoid
multicast normally blocked by typical router bridges.

To avoid multicast, DNS-SD resources must not be published
below the Special-Use domain .local. Unfortunately, there
are no Special-Use local non-multicast defined domains where
access can be safely constrained. The alternative use of an
Internet domain necessitates administration of services
exposed to the Internet. Such exposure will necessitate far
greater resources defending against Internet access. Such
increased exposure may also cause private and possibly
critical resources needed locally to become compromised or
made inaccessible.

>> Open-ended FCFS registration will encourage an 
>> explosion of variant namespaces having any number of 
>> resolution methods and context.
> 
> ​This is possible, but unless these are deemed a valuable
> commodity, it seems somewhat unlikely.  Registry policy
> can certainly be tweaked to "expert review" or something
> so that a dictionary attack on .alt fails.

Why impose the burden of needing to support public domains
on home networks as an aspect of an array of .alt
definitions? A direct singular definition prefaced at the
outset as offering only a private namespace greatly
simplifies and advances homenet development.

This is not advocating for a new TLD.  Rather this is
advocating for the elimination of a Special-Use TLD from DNS
altogether to simplify much needed protection of information.

Regards,
Douglas Otis