[Arcing] ARCING BoF and mailing list
Douglas Otis <doug.mtview@gmail.com> Sat, 30 January 2016 02:25 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 8F0C31B2E2E; Fri, 29 Jan 2016 18:25:07 -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 bdGp3CCp0KUM; Fri, 29 Jan 2016 18:25:05 -0800 (PST)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (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 F1ABA1B2E30; Fri, 29 Jan 2016 18:25:04 -0800 (PST)
Received: by mail-pa0-x233.google.com with SMTP id yy13so50272907pab.3; Fri, 29 Jan 2016 18:25:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=cc:from:subject:to:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=cvhSWLuP83s7vpDq+nYXyjNQDsjAOvuDOf4RKscKk4A=; b=jkCfmcrpv7NIX6P5YTaX+5eGKszm/A+D2ZFQtOmlmK4BLsLeT82I3T5E2UbZfEu49/ UOybCEZK6T6pdieF18UpacCvEYUfMzZ3SQO04J2p/kniaaERJ1jnmEtz/OUgRvTbDXiF nMxt4tOMtlhnV7k38jKiXCiB8wHoj8UzVMPnzarsx0Ce/5m0PkMEJiaLBYn5rS5Kq6Ne itjgElsCwwCKo7e6/QL5LLmmG54q7rwbAGcY9rylhUcv25mjGpgEK/Kr2Hx/4Et1x6vQ 7R1WufoyZ/oUNgLfdr9lvttJvwjVO/0UJugjdrWcdkRqokPJBUbdc6iaF9bAynYRnWA/ cGIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:cc:from:subject:to:message-id:date:user-agent :mime-version:content-type:content-transfer-encoding; bh=cvhSWLuP83s7vpDq+nYXyjNQDsjAOvuDOf4RKscKk4A=; b=AG0fFVUK4Rt2GfR3v4Lil40IQ6Utu9waMQcGkeEh+EXUATN1dsp7K13wtxbW3YEPDs A9C0q8sOLxH7wzSinfA9wz+Ayua+WbHzzFrkZnr1O2eiURqCMacwnoABQjf/duOchHhS kzt4PEY+brxQSxkXruLw+ccHdqDC4cBhvZUGrw+651wIQY/NeMcF/6hk7u13axPeRPA4 tZbc4iXJsNzXLnogL24wbDM2cagWc3fL43F2ySAulmi4Zaq9jMe+Y6U9ygiQx2KxcvWB b/15entl47lXTdJDZR9HArScrSRDjsq3ufOIoaIoF9CyCuiM7sKCpZHtIXP91i7+Lka5 kFBQ==
X-Gm-Message-State: AG10YOQ6ijxdMrCBX0EdjdXWTnLhW4VfcccDbz7gH6Fxr+jYA/emXfZC4qd/oaw81+mvWQ==
X-Received: by 10.67.6.67 with SMTP id cs3mr18591125pad.143.1454120704663; Fri, 29 Jan 2016 18:25:04 -0800 (PST)
Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by smtp.googlemail.com with ESMTPSA id 76sm14145121pft.44.2016.01.29.18.25.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jan 2016 18:25:04 -0800 (PST)
From: Douglas Otis <doug.mtview@gmail.com>
X-Enigmail-Draft-Status: N1110
To: "arcing@ietf.org" <arcing@ietf.org>
Message-ID: <56AC1F60.6060803@gmail.com>
Date: Fri, 29 Jan 2016 18:26:40 -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
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/arcing/p0T5sOb7k66-_j1szBJ5xP5sFGc>
X-Mailman-Approved-At: Sat, 30 Jan 2016 00:31:49 -0800
Cc: Ray Bellis <ray@bellis.me.uk>, Andrew Sullivan <ajs@shinkuro.com>, ietf dnssd <dnssd@ietf.org>, mark@townsley.net, suzworldwide@gmail.com, Warren Kumari <warren@kumari.net>
Subject: [Arcing] ARCING BoF and mailing list
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, 30 Jan 2016 02:25:07 -0000
Dear Ted, https://tools.ietf.org/html/draft-cheshire-homenet-dot-home-02 https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf ,-- Lacking clear RFC 1918-like guidance directing operators to DNS namespaces safe for internal use, several such namespaces have been “appropriated” for this purpose over the years. While the etiology is subtly different, the .corp and .home TLDs are clear outliers in this respect; the use of .corp and .home for internal namespaces/networks is so overwhelming that the inertia created by such a large “installed base” and prevalent use is not likely reversible. We also note that RFC 6762 suggests that .corp and .home are safe for use on internal networks. '-- Reservation of Special-Use Domain Names will not circumvent normal domain name registration processes. Reservation as a Special-Use Name can however ensure it is NOT part of the DNS global namespace and returns NXDOMAIN. In the case of .corp or .home, a responsible agency is irrelevant due to conventions established by those meeting obvious necessities. Registering a domain should not be considered a necessary expense for resolving hosts contained in homenet realms. A home network may consist of multiple links interconnected using IP-layer routing rather than link-layer bridging where multicast might be impractical or poorly supported. Homenet routers should not forward link-local IPv6 packets to exclude traffic forwarded from the global Internet and may not forward some multicast traffic (especially that of non-diffused mDNS). A Special-Use Domain Name can anchor DNS-SD resources without being mistaken for an organizational domain. Otherwise devices made by many vendors are likely to make use of non-registered names nevertheless. Adopting a Special-Use Domain Name better ensures against future name collisions and resulting confusion that might otherwise occur. The URI domain is normally assessed from a security standpoint and used to illicit user feedback of potential threats where changing the URI form would be counter productive since this would require needless widespread change. Special-Use Domain Names of Peer-to-Peer Name Systems GNU Name System (GNS), for example, defines a decentralized and censorship-resistant overlay able to operate within mesh network topology as a bootstrap replacement. Special zone relative names based on a distributed hash offer DNS-free access for Friend-to-Friend networks. Relative names end in '.+' which indicates names resolved relative to the current local authoritative zone. Replacing the '.+' with the delegation chain to the authoritative zone produces a valid GNS name. Swapping .home for .gnu reduces the burden seen at root servers, and offers interesting techniques for handling local name space that can be differentiated by GNS specific Resource Records. Perhaps an I-D should be written to further extend the potential use of a DNS overlay and how to make its use locally safe. Perhaps use of GNS Resource records as an extension could eliminate a need for the resources and administration otherwise necessary to support Internet accessed DNS just to establish local names not published below the .local TLD. Currently there is no site-local scope naming conventions available and this should be changed without impacting URI conventions where examination of the entire name is most often used to assess any need for caution. Regards, Douglas Otis
- [Arcing] ARCING BoF and mailing list Douglas Otis