Re: [DNSOP] draft-liman-tld-names-04

[Doug Barton <[e-mail]>]

On 11/22/2010 06:30, Joe Abley wrote:

> Thanks for your review (Stéphane and Doug), and sorry for not
> replying to your comments earlier, Stéphane.
>
> I also know of no protocol (1034/1035) restriction for labels in the
> root zone. However, as the document describes in citations from 1123
> there is some degree of expectation that top-level domain labels have
> additional technical policy restrictions.

I don't think you can mix those 2 terms in the same sentence. :)  I 
definitely don't think you _should_ mix the 2 concepts in this document.

> I don't know that we have the institutional knowledge to fully
> understand the "alphabetic" reference in 1123,

Arguable, but let's take your premise. Given the world in which we don't 
know exactly what the authors were referring to, in a document that is 
well formatted to clearly delineate the protocol elements from the 
background, IMO what you're attempting to do is ADD a protocol 
restriction where one did not exist previously. That's just plain wrong, 
on several levels.

> and to my knowledge we
> don't have any consolidated, rigourous field experience of what
> software exists that might assume that a label which is not
> "alphabetic" is something other than a component of a domain name.

I'll go you one better. I'm 100% sure that there is deployed software 
that WILL break if you have a TLD label that even starts with a number, 
never mind is all-numeric (I think Andrew did an admirable job of 
explaining this, I won't bother repeating his explanation). But I don't 
care. That isn't a protocol issue, and it's only an operational issue as 
a secondary effect. We already saw this movie in 2001, and we've all 
lived to tell the tale. (I'm assuming that I don't need to remind the 
list of all the excitement created by TLD labels with more than 3 
characters, but I'm happy to if needs be.)

> I'll note (a) that there has never existed a US-ASCII (i.e.
> non-IDNA2008) TLD label that has *not* been "alphabetic", so we have
> no deployed examples in the namespace from which to infer stability,

I'm not sure why you think that distinction (A-label vs. gTLD label) is 
relevant.

> (b) the software we might be concerned about is application-layer
> stuff, really anything that might ever need to process a domain name,
> and hence there's a lot of it and it's hard to catalogue.

Already stipulated, and again, so what? At best this issue warrants a 
paragraph in your draft advising potential new-new-new-TLD applicants 
that this issue exists. I actually considered drafting such a thing (and 
am still willing to do so if there is interest) but I did not because I 
don't think that it belongs in your draft, I think it should be part of 
the policy process.

In fact, if I were to go into full-blown evil genius mode I would say 
that you should _not_ advertise this problem, and fail any applicant for 
a string that contains a digit which does not specifically address the 
issue in their application. But I digress ....

> The conservative path seems to be to assume that there is deployed
> software that relies on the same expectation expressed loosely in
> 1123. In that context, the goal of this document really is to clarify
> the situation and eliminate the ambiguity.

Once again, that's a _policy_ issue, not a technical one. There is no 
_technical_ reason that a TLD label cannot contain, or even begin with a 
digit, and _we_ should not be imposing one. Applicants for new TLDs that 
contain a digit should be informed of the issue, and realize what they 
are getting themselves into.

> I am carefully not expressing a personal opinion about whether the
> technical policy restrictions on TLD labels should change from the
> conservative interpretation of what they are today (per above). No
> doubt a future document, citing a wealth of research and experimental
> data, could successfully update this document and relax the
> restriction.

You have that wrong way around. There is no "technical policy 
restriction" today, you're attempting to assert one, and use the 
"clarification" process to cement your assertion. I object to this in 
the strongest possible terms.

If you/ICANN believes that there _should_ be a technical restriction of 
this nature it's up to you/ICANN to produce a document with a wealth of 
research and experimental data saying so; then let the community decide 
how to proceed. Meanwhile, stop trying to shoehorn policy issues into 
the technical space.

And that's not a snark, I'm quite serious about this. I've sat on both 
sides of the aisle (policy and technical) and just in case there is 
anyone who doesn't already know, in the interests of full disclosure I 
used to be an ICANN staff member. I realize that there are numerous 
"issues" about new TLDs in the ICANN world, and I've been in a position 
similar to the one Joe is in now. It's not fun, I don't envy him, and 
hopefully he realizes that nothing I'm saying is personally directed at 
him. But the advantage of being where I am now is that I get to speak my 
mind, and lob the policy ball back into ICANN's court. I can just 
imagine the ICANN open forum where someone asks, "But WHY can't we have 
TLDs with digits in them?" "Because the IETF says so. Next question?" I 
really do not want to go there.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/