Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

Ted Hardie <ted.ietf@gmail.com> Tue, 14 July 2015 21:24 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038F61B2D95 for <ietf@ietfa.amsl.com>; Tue, 14 Jul 2015 14:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 2kWknqFzImGK for <ietf@ietfa.amsl.com>; Tue, 14 Jul 2015 14:24:46 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (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 562821B2D7A for <ietf@ietf.org>; Tue, 14 Jul 2015 14:24:46 -0700 (PDT)
Received: by wiga1 with SMTP id a1so111080196wig.0 for <ietf@ietf.org>; Tue, 14 Jul 2015 14:24:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PsYUFLzvC1XPAnm4XSTzrngFButoUeBbwcrZmrrBdLo=; b=Q13ZXMOkk7hADnP/x8ibhARKPPk15FrRoo5fcGmXM+0LWx8ZjF5Nw22UULrplbfgGz aX5KvjpEaZdVSJkfhXnb+jdonbZXLAeTiEd0qwLRO23000/2IyMP/3Z8eKo1CWxFxfL+ kQahWKoXYpGnf5CG6dbZLO6bcECzZnP+H6RJE4DtHcMqavPRDp70TKdug7s6ZCPq7WYd MnhAiCNa5+bxFWihdzQ85k/PO2k3SIant+D1U+sRCCB6Opk2TsfVp+QqUg4d0nQbWvX0 NnHzCG3KoH5n7twi+ElaR51Nz2UJHxZ6uXzuXP2xPR+BaSUU5tGjfPxu/GG+zWqeZRlh KXMw==
MIME-Version: 1.0
X-Received: by 10.194.85.116 with SMTP id g20mr1169029wjz.154.1436909085071; Tue, 14 Jul 2015 14:24:45 -0700 (PDT)
Received: by 10.194.17.68 with HTTP; Tue, 14 Jul 2015 14:24:44 -0700 (PDT)
In-Reply-To: <55A576AF.9080800@nominum.com>
References: <20150714192438.1138.96059.idtracker@ietfa.amsl.com> <55A56C59.2090700@nominum.com> <CA+9kkMA__9t2NLRZ07ypxd3+vCFd3133N1c5a94U1=NhFskFRA@mail.gmail.com> <55A576AF.9080800@nominum.com>
Date: Tue, 14 Jul 2015 14:24:45 -0700
Message-ID: <CA+9kkMAJ+Pu00GHd9iTxVYcoR5p+cfpBv9cyebHAp7UgSRw7yw@mail.gmail.com>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard
From: Ted Hardie <ted.ietf@gmail.com>
To: Ted Lemon <ted.lemon@nominum.com>
Content-Type: multipart/alternative; boundary="047d7bfcfd50971f71051adc776c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/FsHQ4oFicq8Z8bVqO7_g7_mETYQ>
Cc: IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2015 21:24:49 -0000

On Tue, Jul 14, 2015 at 1:53 PM, Ted Lemon <ted.lemon@nominum.com> wrote:

> On 07/14/2015 01:28 PM, Ted Hardie wrote:
>
>> ​Given that the point of IETF Last Call is to determine if there is IETF
>> consensus on the working group's analysis and proposal, I find
>> "inappropriate" an odd choice of words here.  The IETF as a whole may have
>> a different sense of the trade-offs here.​
>>
> It's certainly appropriate for people who aren't DNSOP participants to
> weigh in here, and for DNSOP participants to raise new issues that the
> working group missed.   But it seems bogus to me for DNSOP participants to
> raise the same issue here that they raised in DNSOP and that didn't get
> consensus.   I  believe you are a DNSOP participant,


​Not generally, no.  I have commented on specific issues in the past, but I
certainly did not on this issue.​


> but perhaps I am mistaken.   I think you and at least one other person
> read my comment as saying that once the working group has consensus, that's
> the end of it, but that wasn't my point.   My point is simply that it would
> be useless and harmful to the IETF for DNSOP participants to waste the
> collective attention of the IETF re-arguing points that already got
> consensus in DNSOP.


​I think George's post, assuming he is a DNSOP participant, was along the
lines "In the working group, I am in the rough, and I am not appealing
that.  Here, however, is my reasoning so that the broader IETF understands
it".

If we didn't allow that, we would never allow positions that were discussed
in the working group to be aired on the IETF list, which requires
non-participants to discover them independently.  While that would be a
great signal when it happened, I think saying only the consensus position
should be represented to the IETF is wrong.  It just should not claim to be
either un-addressed by the working group if has been or to be the consensus
when it is not.​


> This is a perennial problem in the IETF.   Of course, now we will have a
> long argument about the appropriateness of my interjection here instead,
> but I'm not convinced that that's worse.
>
>  ​I have a great deal of respect for the folks in DNSOP, and a similar
>> amount for those who created and TOR.  But I believe that this approach to
>> segmenting the namespace for protocol resolution does not scale well.  I
>> would far prefer a notation that onion addresses can appear in the
>> authority section of URIs without them being DNS names, something that RFC
>> 3986 allows with the registered name syntax.
>>
> I don't see how that helps: if they can appear in URIs, then we still need
> to mark that special-use TLD as in use.
>
>
​Not necessarily; if you minted a URI scheme for them, you could use
something like the overlay-node-id​
<https://www.ietf.org/archive/id/draft-hardie-p2psip-p2p-pointers-01.txt>
 proposal​ (forgive me for posting an expired draft that I authored, but
it's the quickest example for me to find).   I'm not arguing for that,
though; I'm saying that using the TLD slot for protocol processing
instructions scales badly and we should not do it.

Stephane argues that we did once, with .local, and the die is thus cast,
but I don't think that was the Rubicon, and I know we are not Caesar.

Ted