Re: [DNSOP] moving forward on special use names

[avri doria <[e-mail]>]

On 12-Sep-16 16:19, Suzanne Woolf wrote:
> It seems unlikely that they can be combined, so we simply have to ask
> the WG to choose.

I do not understand this point.  Having now read both IDs, I see
relevant points for the ongoing discussion in both of them.   I see them
as complementary where both contribute to defining the problem in a
comprehensive way.

I think it would make sense to ask the authors to combine their efforts,
that being a first step in finding consensus on how to proceed -
otherwise the back and forth continues once a winner is picked.  Perhaps
enlist the help of one of the neutral knowledgeable people in the group
to bring the two groups of authors together in a base draft that
discusses the issues in language both groups can live with with a strict
focus on problems and their explanation.  I may be misreading the 2 IDs,
but I do not think there should be that many sticking points once there
is a decision to work it out.

I think trying to pick a winner from these two documents, both useful
expositions of the issues, is not the best way to produce a problem
statement.


Some individual comments on the drafts.

---

Some specific comments on TLDR Special-Use Names Problem

> Although IETF and ICANN nominally have authority over this
> namespace, neither organization can enforce that authority over
> any third party who wants to just start using a subset of the
> namespace. Reasons for doing this may include:

I would recommend also including something like "ignorance of there
being procedures, or lack of knowledge that the IETF & ICANN have
processes"as one of the bullets.

> this process is
> likely to be slow and difficult, with an uncertain outcome.
>
I am not sure how this differentiates from other IETF processes.  They
all take longer than one would expect and always have an uncertain
outcome.   This makes it seem like this problem is somehow special in
that respect.

> There is demand for more than one name resolution protocol for
> Internet Names, but Internet Names contain no metadata to indicate
> which protocol to use to resolve them.

probably worth indicating that one DNS mechanism that exists is broken
and that others are offering non standard methods of adding metadata or
treating existing data as metadata.

> More than one name resolution protocol is bad, in the sense
> that a single protocol is less complicated to implement and
> deploy.

This would seem contingent on there being no way to differentiate
applicability


> However, the MoU specifically exempts domain names
> assigned for technical use, and uses the example of ’IN-ADDR.ARPA’
> and ’IP6.ARPA’ to illustrate.

I think the issue here is the breadth of the definition for 'technical
use'. Most any names issue can be defined in such a way so as to have a
technical use. 

> 4.2.1. Multicast DNS

This section seems to be arguing a case as much as explaining an issue.

> 4.2.2. The .onion Special-Use TLD

Need to also look at the precedent this has set and whether the IETF
wishes to reinforce this as a precedent.

> 4.2.4. Name Collision in the DNS
> Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by
> ICANN that attempts to characterize the potential risk to the
> Internet of adding global DNS delegations for names that were not
> previously delegated in the DNS, not reserved under any RFC, but also
> known to be (.local) or surmised to be (.corp) in significant use for
> special-use-type reasons (local scope DNS, or other resolution
> protocols altogether).

This study is from before the new gTLD program.  The assumption in the
report need to be tested against what actually happened in the round of
new gTLDs before it can be included as part of the fact basis for this
work.  We also need information on the degree of success that the
various mitigation strategies had in overcoming possible problems to
have a full picture of the problem as it has been shown in practice.

----

re Problem Statement for the Reservation of Special-Use Domain Names
using RFC6761

> The applicants for [RFC6761] status cannot be guaranteed that
> leakage will not occur and will need to take this into account
> in their protocol design.

This seems an example of a statement that includes both a problem and a
possible solution.

Additionally I think that putting the names pictures in the broader
context is important, even though dnsop WG will be restricted to
solutions based on DNS. Seems important to understand the larger system
DNS is part of these days and moving into the future.

avri


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus