Re: [dns-dir] Draft requesting reservation of special-use domain names

Brian Haberman <brian@innovationslab.net> Mon, 02 December 2013 23:09 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: dns-dir@ietfa.amsl.com
Delivered-To: dns-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B7C1ADFB6 for <dns-dir@ietfa.amsl.com>; Mon, 2 Dec 2013 15:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, LOTS_OF_MONEY=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 bFyPgM_VupLq for <dns-dir@ietfa.amsl.com>; Mon, 2 Dec 2013 15:09:33 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id B4FB41ADF9B for <dns-dir@ietf.org>; Mon, 2 Dec 2013 15:09:33 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 930C4880ED for <dns-dir@ietf.org>; Mon, 2 Dec 2013 15:09:31 -0800 (PST)
Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 314C8130003 for <dns-dir@ietf.org>; Mon, 2 Dec 2013 15:09:31 -0800 (PST)
Message-ID: <529D1323.7010001@innovationslab.net>
Date: Mon, 02 Dec 2013 18:09:23 -0500
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: dns-dir@ietf.org
References: <5286231D.4030104@innovationslab.net> <52863898.5080100@innovationslab.net> <8F0B436C-85D2-4566-A80B-40710DF9D476@ogud.com> <B6B47E1A-678D-4856-BE54-E34ADC7E98F8@townsley.net> <73C44405-6048-4031-9FA5-BCDFA70160A4@frobbit.se> <84D57F70-CCA3-4412-989E-0FAB089ECEEF@gmail.com> <31C42EE0-8D1F-4D7C-8E8C-43ACE5F61B04@frobbit.se> <528D2782.4070208@sonic.net> <B42C50EA-39CE-415E-9CBA-0F0471CAC519@NLnetLabs.nl> <F7DEECA9-5E88-4888-986B-D63DC66FA8B9@gmail.com> <3387707A-201E-490C-9B65-3EB6B35DA8E1@NLnetLabs.nl> <7DCFF968-AEF2-4BF0-83AC-FAA7B2630D71@frobbit.se> <DA83292F-6CDA-4968-8811-1D834FE859F6@gmail.com>
In-Reply-To: <DA83292F-6CDA-4968-8811-1D834FE859F6@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="J50PimRNls6lwkTrffLWqIIqJmqBsPXMT"
Subject: Re: [dns-dir] Draft requesting reservation of special-use domain names
X-BeenThere: dns-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNS directorate discussion list <dns-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dns-dir/>
List-Post: <mailto:dns-dir@ietf.org>
List-Help: <mailto:dns-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-dir>, <mailto:dns-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 23:09:35 -0000

Just to level set...

On 12/2/13 2:46 PM, Ralph Droms wrote:
> 
> On Nov 28, 2013, at 5:45 AM 11/28/13, Patrik Fältström
> <paf@frobbit.se> wrote:
> 
>> 
>> On 28 nov 2013, at 10:46, Olaf Kolkman <olaf@nlnetlabs.nl> wrote:
>> 
>>> On 28 nov. 2013, at 01:57, Ralph Droms <rdroms.ietf@gmail.com>
>>> wrote:
>>> 
>>>> Is there some reason to think those names might be delegated
>>>> from the root?  My understanding is that the review process for
>>>> name delegation would identify such names as "not to be
>>>> delegated" if there is significant use now, otherwise, they are
>>>> safe to delegate.
>>> 
>>> At this moment .corp and .home are ‘on-hold’ (indefinitely?).
>>> 
>>> There is also an SSAC recommendation to have some of these
>>> strings permanently reserved, and SSAC is looking towards the
>>> IETF (correct Patrik?)
>> 
>> A few details here:
>> 
>> 1. SSAC do not say exactly what strings are "high risk". .HOME and
>> .CORP can be viewed as "easy", but what about ".MAIL" etc?
> 
> OK.  Presumably SSAC has data on which it has based its
> classification of the various strings?
> 
>> 
>> 2. SSAC do say that "not delegate" is not enough, we do believe
>> some strings should explicitly be for "private use". Which matches
>> quite well what 6762 says.
> 
> OK.
>> 
>> 3. SSAC could have directly pointed at the Appendix G, if it was
>> clear that that was normative, and so could ICANN. But what I heard
>> from at least one person cc:ed is that that is _not_ normative.
>> 
>> Question: Can IESG/IAB make a decision on the appendix "due to
>> widespread use, misunderstanding and unclear situations etc etc we
>> do believe those strings should not be allocated as TLDs"?

Normally, an appendix is not normative unless it explicitly states that
it is so or contains a critical component of the RFC.  I think the use
of an appendix in this case is confusing and unwarranted.

The INT ADs can take an action item to address this issue as a part of
the special-use domain name question.

> 
> I think it would be better to generate a list based on the data from
> SSAC.  The list in Appendix G could be used, but I don't know if the
> evidence supporting the strings on that list is sufficient to mark
> them as "special use".
> 

I would be very interested in seeing a list from SSAC.

>> 
>> Can IESG/IAB even say yes/no to such a question without an appeal?
> 
> I don't think an appeal would be needed.
>> 
>> Is an I-D and RFC needed that clarifies status of Appendix G?
> 
> An RFC is probably the right vehicle to make the designation.  That
> RFC doesn't need to be restricted to just the list in Appendix G.
> 

Correct, but that RFC may want to be tied to 6762 in some way (e.g.,
Updates).

>> 
>> I.e. I think some IETF action is needed. Having ICANN do "too much"
>> instead of referring to IETF -- specifically if we go down the path
>> of "defining some strings to be TLDs for private use" -- would be
>> dangerous.
>> 
>> I think personally IETF is the body that should say not only what
>> subset of IP address space RIRs can allocate things out of but also
>> what subset of the available bitstring space ICANN can use. Which
>> IETF has done with "hostname" definition (cough, cough,...) and
>> IDN2008.
>> 
>> So, $10.000 question: What is the path forward for "allocation of
>> some strings for private use"?
>> 
>> Do IETF need a formal question from ICANN? Would that really help?
> 
> Would it be useful to have a teleconf with the appropriate people
> from ICANN towork through the details?  I don't fully understand what
> ICANN is trying to achieve.

Ted is in the process of discussing with the IAB how to liaise with
ICANN on this issue.

Regards,
Brian