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

Ted Lemon <ted.lemon@nominum.com> Wed, 15 July 2015 17:32 UTC

Return-Path: <Ted.Lemon@nominum.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 F293D1A87B3 for <ietf@ietfa.amsl.com>; Wed, 15 Jul 2015 10:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6QhwZnjXaG1d for <ietf@ietfa.amsl.com>; Wed, 15 Jul 2015 10:32:24 -0700 (PDT)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 00A2E1A21C0 for <ietf@ietf.org>; Wed, 15 Jul 2015 10:32:24 -0700 (PDT)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id DC245DA007D; Wed, 15 Jul 2015 17:32:23 +0000 (UTC)
Received: from [64.89.225.79] (64.89.225.79) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 15 Jul 2015 10:32:23 -0700
Message-ID: <55A69927.7060306@nominum.com>
Date: Wed, 15 Jul 2015 10:32:23 -0700
From: Ted Lemon <ted.lemon@nominum.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
Subject: Re: [DNSOP] Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard
References: <20150714192438.1138.96059.idtracker@ietfa.amsl.com> <55A591D7.3040309@nominum.com> <CA+9kkMDj8s9GTAF=MSZgWzD3rorKsT3viarY96GZCH4gp=0UvQ@mail.gmail.com>
In-Reply-To: <CA+9kkMDj8s9GTAF=MSZgWzD3rorKsT3viarY96GZCH4gp=0UvQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.89.225.79]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Fz52F62D1WIeTJH8J7AJs9IuKrM>
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: Wed, 15 Jul 2015 17:32:25 -0000

On 07/15/2015 10:17 AM, Ted Hardie wrote:
> ​But I think the possibility of other reasons for this highlights the 
> point Ted Lemon was making:  to make this work correctly is actually 
> more in the bailiwick of the root operators than ours.  I think that 
> means we should tread more carefully than the trend lines appear to be.​
I think "tread carefully" is the wrong way to think about it.   We 
understand who has change control for the root zone, and it is not us.   
We also have RFC 6761, which establishes a process for things that look 
like they belong in the root zone, but are to be reserved for special 
uses.   I have not heard any pushback from ICANN about 6761, and we did 
ask them about it.   They are in fact aware of the use of .onion, and as 
I understand it have no intention of allocating it.   So there is no 
conflict here, and hence no need to tread carefully.

So what I would say instead of "tread carefully" is "understand what 
role we have."   The role we have is to communicate with ICANN about 
this, and come to an agreement about what should happen.   This document 
is us saying what we think should happen.   In a sense it is only part 
of the conversation, although in practice I think the rest of the 
conversation will be fairly simple, because I am fairly certain that 
there is no disagreement between IETF and ICANN about what to do.