Re: [DNSOP] More after onion? was Re: Some distinctions and a request

Suzanne Woolf <suzworldwide@gmail.com> Wed, 01 July 2015 14:08 UTC

Return-Path: <suzworldwide@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E53C41A89C6 for <dnsop@ietfa.amsl.com>; Wed, 1 Jul 2015 07:08:37 -0700 (PDT)
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 tfRBfLe4ZKK0 for <dnsop@ietfa.amsl.com>; Wed, 1 Jul 2015 07:08:35 -0700 (PDT)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 CC6091A89F0 for <dnsop@ietf.org>; Wed, 1 Jul 2015 07:08:30 -0700 (PDT)
Received: by qgat90 with SMTP id t90so13561qga.0 for <dnsop@ietf.org>; Wed, 01 Jul 2015 07:08:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2EBLHhVsoKQMwKCyMnKc5S9VifeMRfJVrdYKrReTfQE=; b=S3XaRKf78l4PetTPGEosLq9BO6jHODcTEpeeYfotuQr9Co4fK9dC/X06qkPZRx9t98 mMavwwswg/syhUmiojJAXLrJZDPkGNQwywMNY5FkLclGFbGqth5/ZVI0Ts5Gc+z7y3Ju c4AsE7rzQJvAXpk0ZWVxI6Qfd4UJS7y96WxiGN5ucO1MpGvip68FHAw7rDBVRPbQIE++ t88G5mBPYRAUyOquZy+NwQWMskqoGuJu2iLRpJeHmv9R72a/Iit5MqjTrfx7oOdwF8/o LSECu2aKER3bG9pkb1HHlQK++mX+8bhKPrEIlUnCsH1+gcKhsbmQcSaADv1eOA+b3akq jCMg==
X-Received: by 10.140.133.199 with SMTP id 190mr35672045qhf.17.1435759710014; Wed, 01 Jul 2015 07:08:30 -0700 (PDT)
Received: from ?IPv6:2601:181:c002:25ee:a16a:d0ae:a880:4188? ([2601:181:c002:25ee:a16a:d0ae:a880:4188]) by mx.google.com with ESMTPSA id p85sm1008564qkh.10.2015.07.01.07.08.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 Jul 2015 07:08:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <D1B966DB.C9AC%edward.lewis@icann.org>
Date: Wed, 01 Jul 2015 10:08:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF014EDF-819B-47BB-817D-AB13D57A57E9@gmail.com>
References: <D1B951E7.C996%edward.lewis@icann.org> <B26365D7-11B3-441D-BED3-5FEFB671B0FA@gmail.com> <D1B966DB.C9AC%edward.lewis@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/uq5VeyDJ9OJHwcwmiyKrcXgRVpQ>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>, str4d <str4d@i2pmail.org>
Subject: Re: [DNSOP] More after onion? was Re: Some distinctions and a request
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2015 14:08:38 -0000

Ed,

First-- apologies for the misunderstanding.

On Jul 1, 2015, at 9:53 AM, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> Trying to be more clear, I have in the past imagined that today someone is
> inventing a new communications technology, in 6 months will need to cobble
> an identifier space and in 2 years the IETF-connected crowd detects
> significant deployment of this and needs to decide whether to register a
> TLD to avoid name collisions.  I've been told that this wouldn't happen
> because the IETF will have rules - which I am skeptical would "prevent"
> the situation from happening.

I don't think we have "rules" or even guidelines now that have any chance of preventing it. 

I agree we'll never prevent it completely; it's the nature of the DNS and the internet that people can do things with names and they don't have to ask the IETF first.

But I don't think it's impossible that we'll be able to provide guidance, such that developers who follow it are reasonably sure of avoiding the various types of collisions and ambiguities we're concerned about-- and such that there's a clear basis for saying "You're doing something outside of the guidance we can provide about how names work in the internet, you're on your own." 

> To underscore - I am not against the innovation.  I am urging that the
> processes put in place are future proof by being "reactionary" - reacting
> to the new names, not trying to fend off the situation.  I.e., in
> agreement with the words below "trying to apply RFC 6761 and finding that
> it remains subjective".

This supports the initial suggestion that we need to get serious about a 6761bis, am I correct?


thanks,
Suzanne

> 
> On 7/1/15, 9:05, "Suzanne Woolf" <suzworldwide@gmail.com> wrote:
> 
>> (no hats, for the moment)
>> 
>> Ed,
>> 
>> It seems to me that this is exactly the issue: we've already had multiple
>> drafts requesting new entries in the special use names registry, and
>> expect more. Your note sounds as if you're fairly sanguine about "a
>> stream of unpredictable requests"; however, based on what we've seen so
>> far, I admit I'm not.
>> 
>> I'm still re-immersing in DNSOP after being entirely absorbed in other
>> work the last couple of weeks, but I want to support us continuing this
>> discussion, because it seems to me that the point Andrew started the
>> thread to make is valid: we don't have a coherent view of how the
>> relevant namespaces (based on DNS protocol, compatible with DNS protocol
>> but intended for different protocol use, or otherwise) interact.
>> 
>> The painful immediate consequence is that we're trying to apply RFC 6761
>> and finding that it remains subjective to do so, with an element of
>> "beauty contest" in the deliberations that means outcomes are
>> unpredictable. There's no meaningful guidance we can give developers on
>> what names it's "safe" for them to use in new protocols, or even for
>> specific uses in-protocol, and as Andrew and others have pointed out,
>> there may even be ambiguity about what our own registries mean in
>> protocol or operational terms.
>> 
>> Longer term, this lack of clarity has implications for both architecture
>> and policy for the DNS, including our ability to support innovation and
>> to coordinate with other groups in the IETF and beyond.
>> 
>> 
>> best,
>> Suzanne
>> 
>> 
>> On Jul 1, 2015, at 8:26 AM, Edward Lewis <edward.lewis@icann.org> wrote:
>> 
>>> On 7/1/15, 1:47, "DNSOP on behalf of str4d" <dnsop-bounces@ietf.org on
>>> behalf of str4d@i2pmail.org> wrote:
>>>> .onion and .i2p (and to my knowledge, the other proposed P2P-Names
>>>> TLDs too) have to conform to DNS rules in order to be usable in legacy
>>>> applications that expect domain names.
>>> 
>>> I'd been told that "onion." was a one-time thing, that in the future
>>> conflicts wouldn't happen.  What I read in the quoted message is that
>>> "onion."'s request isn't a one-time thing but a sign of things to come.
>>> 
>>> I'm sympathetic to the use the path of least resistance - e.g., use
>>> names
>>> that syntactically are DNS names - instead of building a separate
>>> application base.  I expect innovation to be free-form and thus a stream
>>> of unpredictable requests to reserve names for special purposes,
>>> including
>>> DNS-like names.
>>> 
>>> What DNSOP can comment on is how the DNS "reacts" to names, whether in
>>> protocol or operational convention, once they are known before they
>>> achieve some degree of widespread adoption. To what extent is an effort
>>> made (by whomever) to detect these budding namespaces, is this
>>> proactive?
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>