Re: the names that aren't DNS names problem, was Last Call: <draft-ietf-

On Jul 23, 2015, at 7:52 PM, David Conrad <drc(_at_)virtualized(_dot_)org> 
wrote:
> John,
>
> On Jul 23, 2015, at 11:45 PM, John Curran <jcurran(_at_)istaff(_dot_)org> 
> wrote:
> > On Jul 22, 2015, at 6:28 AM, George Michaelson <ggm(_at_)algebras(_dot_)org> 
> > 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)

signature.asc
Description: Message signed with OpenPGP using GPGMail