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/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
