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

[Ralph Droms <[e-mail]>]

On Dec 3, 2013, at 7:53 AM 12/3/13, Brian Haberman <[e-mail]> wrote:

> 
> 
> On 12/2/13 10:02 PM, Ralph Droms wrote:
>> 
>> On Dec 2, 2013, at 6:09 PM 12/2/13, Brian Haberman
>> <[e-mail]> 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 
>>>> <[e-mail]> wrote:
>>>> 
>>>>> 
>>>>> On 28 nov 2013, at 10:46, Olaf Kolkman <[e-mail]>
>>>>> wrote:
>>>>> 
>>>>>> On 28 nov. 2013, at 01:57, Ralph Droms
>>>>>> <[e-mail]> 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.

I agree.  Nor does it give IETF any direction for designating those strings as "special use".

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

OK, so we need to figure out the process - e.g., identifying some more strings to be designated as special use, publishing an RFC to request that designation in accordance with RFC 6761, (perhaps) updating RFC 6762 in that RFC - and document it for future re-use.

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

Agreed - a clarifying, informal update would be helpful.

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

Let me know if I can help in any way...

- Ralph

> 
> Brian
> 
> 
> _______________________________________________
> dns-dir mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-dir