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

str4d <str4d@i2pmail.org> Thu, 02 July 2015 04:17 UTC

Return-Path: <str4d@i2pmail.org>
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 DF23D1B2E02 for <dnsop@ietfa.amsl.com>; Wed, 1 Jul 2015 21:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.59
X-Spam-Level: *
X-Spam-Status: No, score=1.59 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001] 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 ozKUw5XV1Sp8 for <dnsop@ietfa.amsl.com>; Wed, 1 Jul 2015 21:17:54 -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 9C1851B2DFC for <dnsop@ietf.org>; Wed, 1 Jul 2015 21:17:53 -0700 (PDT)
Received: by mail01.sigterm.no (Postfix, from userid 1006) id AE9B52E340D; Thu, 2 Jul 2015 06:17:51 +0200 (CEST)
Received: from smtp.postman.i2p (i2p-outproxy01.privacysolutions.no [193.150.121.66]) by mail01.sigterm.no (Postfix) with ESMTP id 798B62E3426 for <dnsop@ietf.org>; Thu, 2 Jul 2015 06:17:40 +0200 (CEST)
X-Virus-Scanned: clamav-milter 0.97 on milter.postman.i2p
X-Mailer: smtp.postman.i2p - Official I2P Mailer
From: str4d <str4d@i2pmail.org>
MIME-Version: 1.0
To: dnsop@ietf.org
References: <D1B951E7.C996%edward.lewis@icann.org> <B26365D7-11B3-441D-BED3-5FEFB671B0FA@gmail.com> <D1B966DB.C9AC%edward.lewis@icann.org> <DF014EDF-819B-47BB-817D-AB13D57A57E9@gmail.com> <CAHw9_iJQ+Ydu4m-dd8cMOvVtYkKdEYMO_bx1Z5GBX3jLVgq=Jg@mail.gmail.com> <CAL02cgQYxFq7C0mWbs92RzoELU-Di9juKc5Dg16SP_ze=BzXxw@mail.gmail.com> <20150701185537.768A3AE447@smtp.postman.i2p>
In-Reply-To: <20150701185537.768A3AE447@smtp.postman.i2p>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Message-Id: <20150701223712.84403AE444@smtp.postman.i2p>
Date: Wed, 01 Jul 2015 22:37:12 +0000
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/g4QWfzmiVigeLOXT0ElaC-uTXm0>
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: Thu, 02 Jul 2015 04:17:56 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Edward Lewis wrote:
> On 7/1/15, 14:26, "Richard Barnes" <rlb@ipv.sx> wrote:
> 
>> We do our best work when we do engineering, not rule-making.
>> Let's engineer a solution here that's more appealing than
>> squatting.  For my money, alt-TLD looks about right.
> 
> How does that help this:
> 
>>>>>>> On 7/1/15, 1:47, 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.
> 
> Having a alt-TLD is fine.  But what if names are proposed,
> experimented and deployed outside the sphere of influence of the
> IETF and/or working group?  Writing this as someone who is
> unfamiliar with "other proposed P2P-Names" efforts and whether they
> want to engage with "standards bodies" before deploying.

I admit to being highly surprised that you are unfamiliar with the
P2P-Names draft[0], given that it pre-dates the later .onion-only
draft. To save you trawling through the archives, the P2P-Names draft
was proposed to bring the TLDs contained within onto the SUN registry
under RFC 6761. However, neither I2P nor Tor (I cannot speak for the
others) engaged with any standards body before deploying, because
(IMHO, I was not around at the time)

a) there was no clear indication that the floodgates would (or could)
be opened for TLDs, and therefore no obvious reason for concern, and
b) RFC 6761 did not exist at the time. I2P deployed .i2p in 2003[1],
and Tor deployed .onion in 2004[2]; RFC 6761 was published in 2013.

> I've gotten the impression that members of those efforts dislike
> standards processes - I may be wrong but that's the impression I've
> gotten from the discussion on this list.

I certainly don't dislike standards processes. What I _do_ dislike is
inconsistency and poor documentation/education. If DNSOP / IETF wants
to ensure that future applications root their name spaces in .alt or
wherever else instead of choosing a .TLD to add to the SUN registry,
then developers _need to know about it_. I personally agree with
Richard that .alt is far more appealing than the struggle to get a
.TLD added to the SUN registry, but the longer it took me to discover
.alt, the harder it would be to justify switching. (It's for this
reason that .i2p is as unlikely as .onion to be moved into .alt, with
well over a decade of use, and .alt not even in existence yet.)

Having it stated in an RFC is definitely better than the status quo,
but IMHO it would be much better to have an FAQ page that clearly
outlines the IETF's / working group's position, itself backed by
references to RFCs. Then use SEO to get it near the top of any related
search query. It wouldn't take much work, and the IETF's / working
group's sphere of influence would be far wider as a result. Developers
love bullet points :P

str4d

[0]
https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-nam
es/
[1] https://geti2p.net/en/meetings/059
[2]
https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#cite_ref-or-lo
cating_85-0
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVlGuMAAoJEBO17ljAn7PgOesQAKjnyUJAceWnEgPTKWzb/LXU
LkcJ1cZPQsRAilfM1h3GNJ6tg7ZYDZcr16nwNzfbSfYhI/LQpLOhGm1VxM7vVjB0
01hBaOZnJoehlTmSO/6H+lPfwE2GnMrtM3LMbytPIFSYKtnTqU6pgZcA2StvPr0P
eoXpNofJ8hMX31FB117D7glzOycuUqm3GN/aurKj13B1uXjLGQxFAYwQxyfc1JB5
VYD2q7WtacJSJPGC7orgBu+LI6GYg9Cjb7+Bj6BLjT+NZ/6c46kvZ2KOnoFI/7Hg
jgtM9Z1FmWGEnbKwsb3LdctOWU1FtWrSeepp2f4Sg3NVJM0FdYTE5N2zyKWP0nPc
EMosnJRDOLsCL324sbj5HIZ1vL46OO+HWZWur3gRGgDBUmqjIBfONfu3qnXmL7UG
3JRtdM83FLht2xI+iYdbY059LQsU9t3LR5BUJnv9IVuz6ELHi1i5pEF1bTY2AvGl
taZax7lhB+jhQgcfITIzx3rlxOMv8wdsSq0L/ynJqm9afqGTU/G5S9k1vJaXunnU
IULAvouQ4iERufzrUwKHh94Vd/HhbrOF/Oc5z7ObtTPSjBvmLPIRoxYl2c8xV7WR
73+K3L6rxifqP1ITMo8MiFO4+sr70c7oyqS+gRSdWLRoh2xkNTNIAXoahyegSk8F
WdHJBvBnvbByyyatoHu5
=/8p1
-----END PGP SIGNATURE-----