[dns-operations] When TLDs have apex A records
David Conrad
drc at virtualized.org
Mon Jul 6 21:49:41 UTC 2009
kc,
On Jul 6, 2009, at 12:42 PM, k claffy wrote:
> As you're aware, there is a study currently underway regarding root
> zone scalability.
>
> and unfortunately here we have the opposite. essentially all public
> commentary has spoken out against the originally proposed (unlimited)
> TLD expansion,
I don't recall anyone ever proposing unlimited expansion. If you read
the new gTLD Draft Application Guide, you'll see that there are a
tremendous number of limitations, some of which are (IMHO insanely)
ill-defined ("morality and public order"?). It is true that there is
no arbitrary upper bound on the number of potential TLDs, however I'm
sure you're aware of the problems associated with picking constraints
out of bodily orifices -- you'll instantly get into rathole debates
regarding whether one arbitrary value is better or worse than
another. ICANN has been criticized quite intensely in the past for
picking arbitrary limits on the number of new TLDs, so now the other
side gets their chance to criticize.
> and the demand for additional research has been overwhelming,
> but ICANN has responded by putting a gag order (NDA) on anyone they
> fund
> to study it, leaving ICANN with complete control over what is
> published
> (otherwise CAIDA could have helped OARC w their study.)
I do not know the rationale for choosing to place that study effort
under NDA. I do however suspect that some parties that have been
interviewed for the study would likely have not responded (or not
responded fully) unless they were assured some level of
confidentiality. Since I was not at ICANN during the initial
SiteFinder/wildcarding analyses, I do not know what sort of
confidentiality was required.
More generally, I was under the impression that many (most?)
researchers preferred not to release data associated with studies in
progress because people can make rash judgements based on partial
information, particularly in an environment that can be reasonably
assumed to be hostile.
> obviously this
> will create the perception that ICANN is holding itself to much lower
> standards of transparency and accountability than it holds others.
> a role model of bad governance.
You imply that there would've been a perception of anything other than
ICANN being evil or incompetent.
I would observe that if ICANN is funding the study, the outcome is
generally presupposed to be in ICANN's interest (whatever the numerous
critics of ICANN might believe that to be). Since ICANN is funding
the study, it can't be perceived to be without bias, i.e.,
independent. If you want an independent study, I suspect you'll need
to look for funding from someplace other than ICANN.
> i would not be surprised if folks are struggling to separate the more
> politically loaded gTLDexpansion topic from one on which we actually
> have legitimate consensus.
I gather that Ed, presumably backed up by Randy, Jorge, and others,
asserts the consensus on wildcarding in TLDs is for allowing it and
that the recent resolution by ICANN's board is an unacceptable
abridgment of the rights of gTLD administrators. This is what I feel
we'll have to agree to disagree on.
> but as you pointed out, that's not what this
> thread was about, and that conversation really belongs elsewhere (not
> sure where, maybe the list needs a suggestion)
Good question. Perhaps the GA list? (:-)). More seriously, I agree
that this isn't the right place for discussions about ICANN policies
as they affect the technical community. I'm also not sure where the
right place would be. Maybe the right answer is for a technical
constituency to be established within ICANN?
Regards,
-drc
P.S. For those that do not know me and in the interests of full
disclosure, I am ICANN's VP of IT and have been working at ICANN for 3
1/2 years now, however unless otherwise explicitly stated, my comments
here are my own opinions and do not reflect the official positions of
ICANN except by pure coincidence. Apologies for any confusion this
might have caused.
More information about the dns-operations
mailing list