[dns-operations] When TLDs have apex A records

bmanning at vacation.karoshi.com bmanning at vacation.karoshi.com
Mon Jul 6 22:22:38 UTC 2009


On Mon, Jul 06, 2009 at 02:49:41PM -0700, David Conrad wrote:
> 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. 

	you ought to read the GAC meeting minutes or review
	the RSST transcripts.  many GAC and GNSO folks are 
	laboring under that particular belief.

	"We were promised unlimited TLDS three years ago. Its
	 kind of late to do this study."  -  French GAC rep.

> 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.

	to be sure.  for many the question is not when but how many how
	soon.

> >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.

	the current study is conducted under standard ICANN NDA.

> 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.

	thats true enough.

> 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.

	perhaps - just maybe - the concern is that administratively
	constraining something allowed by protocol -unilaterally- is 
	a poor choice.  I asked, apparently too late, to have the text
	mitigated to allow for a wildcard if backed by acceptable justification.

	the problem is, wildcards in and of themselves are not inherently evil,
	bad or misbegotten.  in fact a few TLDs use them today.  the trick here
	is -what- folks do w/ that entry in the zone...

> 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.

	nice hat.

> 
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations



More information about the dns-operations mailing list