IETF Logo Mail Archive

Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>

Ted Lemon <ted.lemon@nominum.com> Fri, 24 July 2015 17:29 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 8036C1A1ADF for <ietf@ietfa.amsl.com>; Fri, 24 Jul 2015 10:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 jFEMW1HqgeQl for <ietf@ietfa.amsl.com>; Fri, 24 Jul 2015 10:29:28 -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 70F3D1A1AFB for <IETF@ietf.org>; Fri, 24 Jul 2015 10:29:28 -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 2ABB8DA0085; Fri, 24 Jul 2015 17:29:28 +0000 (UTC)
Received: from [10.0.20.218] (71.233.41.235) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 24 Jul 2015 10:29:27 -0700
Content-Type: multipart/alternative; boundary="Apple-Mail=_80357E65-5E42-4BAC-AD39-A35A94CA4E8B"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Subject: Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-dnsop-onion-tld-00.txt>
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <5A72A128-78D0-47A5-A962-5DB39E84E640@virtualized.org>
Date: Fri, 24 Jul 2015 13:29:25 -0400
Message-ID: <FD0EDA24-CA10-49F8-B633-438747A61AEF@nominum.com>
References: <20150720192219.53802.qmail@ary.lan> <55ADF2A7.3080403@cisco.com> <A0418F96-1D79-4BE9-A72A-7A47641E4AF3@gmail.com> <CAKr6gn1apWx2M7V-O6ea2kvor7Di6=jYMh-uY2ouTsgjkV6vLw@mail.gmail.com> <20150722084204.GA15378@laperouse.bortzmeyer.org> <CAKr6gn2413-2XW8d_stw0dTmP-KsmGgFgQ3tVXEgXrXmnCiQow@mail.gmail.com> <6E97605B-C11E-4349-90FC-109E4983112C@istaff.org> <45F6578D-BA19-4333-8935-C954BBD9AEE8@nominum.com> <F8B1240553F1ED877E42F66D@JcK-HP8200.jck.com> <5A72A128-78D0-47A5-A962-5DB39E84E640@virtualized.org>
To: David Conrad <drc@virtualized.org>
X-Mailer: Apple Mail (2.2102)
X-Originating-IP: [71.233.41.235]
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ug_vK9QsO0b8sFshankuvbm_kpo>
Cc: John C Klensin <john-ietf@jck.com>, 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: Fri, 24 Jul 2015 17:29:29 -0000

On Jul 24, 2015, at 3:21 AM, David Conrad <drc@virtualized.org> wrote:
> Yep. In addition, it would probably result in the non-trivial political and economic forces endemic to ICANN interested in blocking a name (for whatever reason) redirecting their energies to the IESG (or whoever the IETF decides "we" are). After all, if they can't legitimately block a name through the ICANN processes, they'd get one last bite at the apple at the IETF.

Yup, and after I went to bed last night I realized that the problem with asking the IETF first is that we take forever to decide anything, and the IESG shouldn’t be held responsible for that.  The bottom line is that this is a really hard problem to solve.   It may be that RFC 6761 got it as right as we can manage under the circumstances.

v2.23.0 | Report a Bug | By Email