John, On Jul 23, 2015, at 11:45 PM, John Curran <jcurran@xxxxxxxxxx> wrote: > On Jul 22, 2015, at 6:28 AM, George Michaelson <ggm@xxxxxxxxxxxx> 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