ietf
[Top] [All Lists]

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

2015-07-23 18:53:13
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.

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 will observe that the latter is a right which the IETF has
already reserved for itself, ceding to ICANN the general purpose assignments,
i.e. that which "present policy issues” (at least as described in the 
IETF/ICANN
MOU [RFC2860])

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.

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.

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.

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.

Regards,
-drc


Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

<Prev in Thread] Current Thread [Next in Thread>