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

Brian Haberman <brian@innovationslab.net> Tue, 03 December 2013 12:53 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 C7C0F1AE141 for <dns-dir@ietfa.amsl.com>; Tue, 3 Dec 2013 04:53:58 -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 8n2ugXMSeIwB for <dns-dir@ietfa.amsl.com>; Tue, 3 Dec 2013 04:53:57 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 444501AE13E for <dns-dir@ietf.org>; Tue, 3 Dec 2013 04:53:57 -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 ED2818809F for <dns-dir@ietf.org>; Tue, 3 Dec 2013 04:53:54 -0800 (PST)
Received: from clemson.local (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 8C81E136813E for <dns-dir@ietf.org>; Tue, 3 Dec 2013 04:53:54 -0800 (PST)
Message-ID: <529DD458.7050506@innovationslab.net>
Date: Tue, 03 Dec 2013 07:53:44 -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> <529D1323.7010001@innovationslab.net> <2B0DE7F7-B808-4760-B8A6-F58E766D78A6@gmail.com>
In-Reply-To: <2B0DE7F7-B808-4760-B8A6-F58E766D78A6@gmail.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="peowK1kTGMmKvNei0F40h3Qvxv5W5w4g6"
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: Tue, 03 Dec 2013 12:53:59 -0000


On 12/2/13 10:02 PM, Ralph Droms wrote:
> 
> On Dec 2, 2013, at 6:09 PM 12/2/13, Brian Haberman
> <brian@innovationslab.net> wrote:
> 
>> 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.
> 
> By "use of an appendix", do you mean citing the appendix as support
> for marking the strings in the list as "do not delegate"?

Correct.  To me, it seems like Appendix G is simply saying "don't
overload .local, but you may be able to use these strings for private
use".  Since there is no explicit statement that those suggested strings
should not be delegated, I don't see how the appendix could be viewed as
giving ICANN any direction.

>> 
>> The INT ADs can take an action item to address this issue as a part
>> of the special-use domain name question.
> 
> Is there more to the "special-use domain name question" than that
> list of strings?

Sure.  It seems that we need to figure out how we are going to
coordinate this request and any future requests with ICANN.

>> 
>> 
>>> 
>>> 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.
> 
> Is the data from Interisle publicly available?
> 

I don't know.

>> 
>>>> 
>>>> 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).
> 
> Why would it update the RFC 6762?  Appendix G is non-normative.
> Perhaps a note clarifying that Appendix 6762 is, indeed,
> non-normative and only advisory?
> 

Given that a few people are questioning the state of Appendix G, I could
see one way of clarifying that would be a short RFC that says the
appendix is advisory only.  To make sure future readers of 6762 see that
statement, an "Updates" tag would be useful.

>> 
>>>> 
>>>> 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.
> 
> OK.

And we will see how that goes.

Brian