Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

str4d <str4d@i2pmail.org> Sat, 02 April 2016 07:45 UTC

Return-Path: <str4d@i2pmail.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF59D12D567 for <dnsop@ietfa.amsl.com>; Sat, 2 Apr 2016 00:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.091
X-Spam-Level: *
X-Spam-Status: No, score=1.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_BRBL_LASTEXT=1.449, SPF_PASS=-0.001] autolearn=no autolearn_force=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 pc6X6natZTri for <dnsop@ietfa.amsl.com>; Sat, 2 Apr 2016 00:45:28 -0700 (PDT)
Received: from mail01.sigterm.no (mail01.sigterm.no [193.150.121.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73DA912D54E for <dnsop@ietf.org>; Sat, 2 Apr 2016 00:45:28 -0700 (PDT)
Received: by mail01.sigterm.no (Postfix, from userid 1006) id 331942E10A6; Sat, 2 Apr 2016 09:45:26 +0200 (CEST)
Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by mail01.sigterm.no (Postfix) with ESMTP id 38C9E2E0FFA for <dnsop@ietf.org>; Sat, 2 Apr 2016 09:45:13 +0200 (CEST)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
To: George Michaelson <ggm@algebras.org>
References: <20160328185353.685C5AE51A@smtp.postman.i2p> <20160401104034.2A6E4AE52E@smtp.postman.i2p> <20160401195345.B3DB3AE528@smtp.postman.i2p>
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d <str4d@i2pmail.org>
MIME-Version: 1.0
In-Reply-To: <20160401195345.B3DB3AE528@smtp.postman.i2p>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="QV5PQVFPBkAcbEXUvB8WsNmStkqEfVmwp"
Message-Id: <20160401230345.D5225AE528@smtp.postman.i2p>
Date: Fri, 01 Apr 2016 23:03:45 +0000
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/YVWSEz8M-iw7h1-9vX8uFysNZts>
Cc: dnsop WG <dnsop@ietf.org>
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 02 Apr 2016 07:45:31 -0000

On 02/04/16 08:53, George Michaelson wrote:
> Whats your reaction going to be, to a closed 6761 because if you come
> to the microphone with a "but we built to the userbase, we have
> millions" and make bambi eyes, I feel a bit like saying "you were
> warned"

When and where? In this discussion?

As has been stated long ago in this discussion, I2P has been using .i2p
since 2005 (long before my time), for exactly the same reasons as Tor
used .onion. Using the current discussion as an attempt to retroactively
alter how the IETF has done outreach regarding TLDs in the past is
disingenuous.

> 
> ie, squatting a domain, is squatting a domain, no  matter how much you
> believe in your own process. If you populate code to the label, a
> specific label, you're in moral hazard.

As I have also stated long ago in this discussion, I did in fact look
into an alternate avenue which would be a much better technical fit:
defining an AF_I2P. I could find *no way* to achieve this without
requiring patches to the kernels of every OS that we wanted to release
on. So given the choice between "impossible or indefinitely-blocked
solution" and "solution that works", is it surprising that the Tor and
I2P developers went the way they did?

> 
> You cannot predict what label (if any) you will get. You need to code
> agile, to a label being in another space (eg .alt) which is also
> unknown. it has to be in a .conf or other runtime option, not hard
> coded.

If that's the case, why can't everyone using .home or .mail or .corp
also switch? Answer: legacy software. We have tens of thousands of I2P
routers out there, in use right now. We do have some level of control
over *some* of them via updates (but only if the users accept the
update), but we have zero control over all the client software that has
been written over the last decade that expects to see a .i2p address. At
this point, switching .tld is not an option, which leaves us blocked in
the same position as Tor was regarding non-self-signed SSL certificates.

str4d

> 
> forever.
> 
> -G
> 
> On Fri, Apr 1, 2016 at 7:40 AM, str4d <str4d@i2pmail.org> wrote:
>> On 29/03/16 07:53, John Levine wrote:
>>> Finally, no matter what we do, at some point someone will come by with
>>> .GARLIC which is like .ONION but stronger and they will say (with some
>>> justification) that it's used by a zillion people around the world.
>>> "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
>>> sorry."  Then we'll have to deal with it one way or the other.  I hope
>>> that .alt will push that day off farther into the future but it's
>>> unlikely to push it to infinity.
>>
>> Injecting a little levity: I2P does in fact use a variant of onion
>> routing called garlic routing! But we are already in the 6761 process
>> for .I2P, and have absolutely no desire to take garlic any further than
>> a technical metaphor :)
>>
>> str4d
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>