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>
- [DNSOP] Post-Interim considering the 4 proposals Hugo Maxwell Connery
- Re: [DNSOP] Post-Interim considering the 4 propos… hellekin
- Re: [DNSOP] Post-Interim considering the 4 propos… str4d
- Re: [DNSOP] Post-Interim considering the 4 propos… joel jaeggli