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

John C Klensin <john-ietf@jck.com> Thu, 23 July 2015 11:30 UTC

Return-Path: <john-ietf@jck.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 31FFC1A710C; Thu, 23 Jul 2015 04:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 yF3iF-k59fru; Thu, 23 Jul 2015 04:30:02 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BFF81A0370; Thu, 23 Jul 2015 04:30:02 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ZIEhK-000GJy-Ip; Thu, 23 Jul 2015 07:29:58 -0400
Date: Thu, 23 Jul 2015 07:29:51 -0400
From: John C Klensin <john-ietf@jck.com>
To: Bob Harold <rharolde@umich.edu>, Eliot Lear <lear@cisco.com>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard
Message-ID: <2B2A64C2C8A96A347F4F210D@JcK-HP8200.jck.com>
In-Reply-To: <CA+nkc8Bwj-RGRSZk1_GYi8kS+n_iWAFOGcaEit+LiMgb53zRFg@mail.gmail.com>
References: <20150714192438.1138.96059.idtracker@ietfa.amsl.com> <55A90F34.4010901@cisco.com> <CAL02cgTJM1FxTHfaQb_x5=7MExOd3YumQbrAEE487a2+Ax0i=w@mail.gmail.com> <55A91C90.1050201@cisco.com> <49481ED5-52CA-470D-8B0E-895F11A1BA46@difference.com.au> <55ACA123.7020803@cisco.com> <04F3F38A-097E-4DCF-9295-273F0C4B4651@fb.com> <55ACF8C8.90303@cisco.com> <CA+nkc8Bwj-RGRSZk1_GYi8kS+n_iWAFOGcaEit+LiMgb53zRFg@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/CAiBKgkOqs05-rgviriQ7FByRjo>
Cc: dnsop <dnsop@ietf.org>, 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: Thu, 23 Jul 2015 11:30:04 -0000


--On Monday, July 20, 2015 13:50 -0400 Bob Harold
<rharolde@umich.edu> wrote:

> This thread has taught me more about the .onion names - thanks
> for that. But I would have to agree with those that think this
> bit of explanation is unnecessary to the RFC and should be
> excluded, rather than attempting to clarify it.  The RFC only
> needs to deal with ".onion".  No need to explain the other
> parts of the name.

FWIW, I tend to agree.  If the purpose of the document is to try
to lock down the name, it should explain what ONION. is and how
it is deployed to the extent needed to justify that and
incorporate explanations of how the hierarchical structure is
used and accessed, as well as the nature of the protocol itself,
by reference if at all.    If the intent is to incorporate
and/or explain the latter, how TOR works, etc., that is a rather
different sort of document.  The latter might still try to
reserve the top-level name as an "IANA Considerations" effect,
but is one over which the IETF would typically want change
control as a condition for IETF Stream publication.

    john