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
signature.asc
Description: Message signed with OpenPGP using GPGMail