Re: [DNSOP] Post-Interim considering the 4 proposals

joel jaeggli <joelja@bogus.com> Mon, 18 May 2015 15:33 UTC

Return-Path: <joelja@bogus.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 DFAA41A924C for <dnsop@ietfa.amsl.com>; Mon, 18 May 2015 08:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.39
X-Spam-Level: *
X-Spam-Status: No, score=1.39 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_31=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 SRjAK_-I8dXY for <dnsop@ietfa.amsl.com>; Mon, 18 May 2015 08:33:56 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05D1B1A923D for <dnsop@ietf.org>; Mon, 18 May 2015 08:33:56 -0700 (PDT)
Received: from mb-aye.local ([8.18.217.2]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t4IFXmBj009628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 18 May 2015 15:33:49 GMT (envelope-from joelja@bogus.com)
To: str4d <str4d@i2pmail.org>, dnsop@ietf.org
References: <20150515112911.F0FBFAE40D@smtp.postman.i2p> <20150515154841.CCD20AE408@smtp.postman.i2p>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <555A0656.7020307@bogus.com>
Date: Mon, 18 May 2015 08:33:42 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
MIME-Version: 1.0
In-Reply-To: <20150515154841.CCD20AE408@smtp.postman.i2p>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/jiFMh5P--9yY4wX9scrv0kQ3qB4>
Subject: Re: [DNSOP] Post-Interim considering the 4 proposals
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: <http://www.ietf.org/mail-archive/web/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: Mon, 18 May 2015 15:33:58 -0000

On 5/15/15 8:48 AM, str4d wrote:
> Hugo Maxwell Connery wrote:
>> Hi,
> 

<snip>

>> I believe that the grothoff and appelbaum drafts are the first 
>> cases of testing the mechanism for the use of the special names 
>> registry.  I also assume that the registry was created to be used 
>> for more than its initial propulation with things like .local and 
>> .invalid.

.local  is really the first (poster child) case. these proposals are
really the second.


>> Additionally, I agree with some members of the DNSOP community
>> that names matter.  "my-product.invalid" is not a good way to start
>> a venture.  Should .alt be available "my-product.alt" is far 
>> preferrable as confirmed by a member of the I2P community both at 
>> the Interim meeting and in later mailing list communication 
>> (str4d).

we shouldn't be in the business of setting up incentives for a behavior
we want to encourage by making them look like penalties.

> You are right in saying that .TLD.alt is preferable to .TLD.invalid
> from a user's perspective. But that does not automatically imply that
> .TLD.alt is preferable to .TLD.

agree.

I would expect that an future allocations of the form .tld would account
for the availability of alternative methods.

> What I said was, if I were writing a new I2P-like application
> requiring a non-DNS .TLD _after_ .alt had been accepted and publicized
> as the accepted way of establishing non-DNS domain structures, then I
> would use .TLD.alt instead of .TLD, because it would be far less
> hassle (to get it reserved, as I expect having .alt would enable IETF
> to more easily evaluate and accept reservations under it) for not much
> additional work educating users. I would of course _prefer_ to use
> .TLD on its own, but as an app developer I would take the path of
> least resistance. Right now, that is to register .TLD under RFC 6761.
> If .alt is accepted, it would be that.
> 
>> Indeed, that person claims that .alt would have been used if it
>> was both available and understood.
> 
> I said that I2P would _probably_ have used it, had .alt existed at the
> time as the accepted way of establishing non-DNS domain structures.
> However, I want to ensure that these two points are abundantly clear:
> 
> * I am not one of the original developers of I2P. I was not involved
> with I2P until years after .i2p had already been chosen and
> established, so I cannot speak for what they would actually have done.
> 
> * Even if .alt does become available, I2P will not be transitioning to
> it. (This has already been thoroughly discussed previously on this ML
> around the P2PNames draft in general, and the .onion and .i2p TLDs in
> particular.)

The question of what to do about the existing practice seems orthogional
to the question of what to do about future ones.

<snip>