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

[John Curran <[e-mail]>]

On Jul 23, 2015, at 7:52 PM, David Conrad <[e-mail]> wrote:
> 
> John,
> 
> On Jul 23, 2015, at 11:45 PM, John Curran <[e-mail]> wrote:
>> On Jul 22, 2015, at 6:28 AM, George Michaelson <[e-mail]> wrote:
>>> I merely noted that there are voices (myself included) who think a revision might be most useful if it abnegated the right to make these decisions and said "the root zone vests with other people: ask other people to do things”
>> A interesting assertion, given that the root zone is the entire top-level of the
>> identifier space and would specifically include "assignments of domain names
>> for technical uses”.
> 
> The root zone is NOT the entire top-level of the identifier space. It is the top-level of the subset of the identifier space that is comprised of (a) strings that are valid in the DNS protocol and (b) have been permitted by policies defined by (at least some portion of) the IETF community as documented in RFC 1591 and, later (post RFC 2860), the ICANN community through the various bottom-up, consensus-based processes that ultimately led to the Applicant's Guide Book.

Acknowledged, but will point out that there is a difference between the
technical requirements on those strings and the policy constraints that
ICANN places upon its policies.

> Even if you meant "what could potentially be placed in the root zone", this would still be limited by (a) by the simple fact that the root zone is a DNS protocol implementation artifact, not a namespace artifact, and is thus constrained by the limitations of the DNS protocol.

I was referring to what could potentially _not_ be placed in the root zone”;
i.e. including entries such as .localhost are part of the namespace, but not
part of the DNS root zone.

> Sure. Please define "technical uses". Or, more specifically, please describe how the IETF determines which string out of the universe that may potentially be placed into the root zone should be reserved and which shouldn't. That, AFAICT, is the key issue here.

It’s a technical matter within the IETF’s purview; one would hope that there
is at least some consultation with the DNS community over in ICANN so as
to minimize/mitigate any fallout.

> Some are arguing that this should be done by ICANN (whether this means the ICANN community or ICANN staff is unclear). This seems a bit surprising to me, since the same folks are typically often highly critical of ICANN's technical competence but they are implicitly demanding the ICANN community make a determination as to what is a technical use and what is not. However, I'm sure I'm misunderstanding something.

I am also surprised by such, but at the end of day, I still believe it is the IETF’s
call to make.

> Regardless, as Stephane points out, RFC 6761 is what we have now. That RFC has laid out a set of criteria by which, in most cases, the IESG (not ICANN) gets to choose whether a string should be removed from the potential universe of strings that may be eligible for allocation via the ICANN community defined processes. Given the 10+ years that it has taken the ICANN community to come up with the 300+ pages of policies detailing what are and are not eligible, I don't envy the IESG in their deliberations. However, perhaps the politics and economics that impacted the ICANN processes will be avoidable in this case.

It is possible that determining what string is _not_ eligible to appear in DNS and will be
assigned to the IETF to be used for technical purposes is a tad easier than determining
what is eligible and the process by which one party (often for commercial benefit) among
many others will receive it...

>> That’s not to say that the IETF can’t revise this position as desired, only that
>> it should be recognized as a change from documented state.
> 
> My reading of RFC 6761 is that a change of state has already occurred and people are just now realizing the implications, prompted by ONION and other non-DNS names.


It would be nice to agree or reconfirm some clear rules for how this should work (in general)
before turning the crank and executing the process for a particular instance (.e.g.   .onion)

/John

Disclaimer: my views alone.  This message will self-destruct (at heat death of the universe)