Subject: [dns-dir] draft-liman-tld-names-05, advice sought

From: Joe Abley <[email-masked]>
Date: Mon, 1 Aug 2011 07:12:51 -0700

Colleagues,

I think it's fair to say that the authors of this document feel a little adrift with respect to direction for this work. If the DNS Directorate could give us some advice, that would be appreciated.

The current situation with respect to TLD label syntax is:

1. There is an ambiguous, existing specification in the IETF regarding TLD label syntax, in RFC1123. Even the description of this as a specification is contentious, never mind the interpretation of the text. I believe it is reasonable to say that there is the potential for the text in 1123 to be interpreted as a specification, however, even if we have no clear idea how widespread that interpretation might be. Discussion of the existing "specification" can be found in draft-liman-tld-names.

2. In practice, policy which incorporates syntax restrictions is developed at ICANN and implemented by the IANA. ICANN's policy products are constrained by technical specifications produced by the IETF.

3. The A-Label representation of IDN TLD labels is not consistent with the pre-IDN "specification" pseudo-described in 1123.

Since IDN TLD labels are deployed in the public DNS, (2) and (3) represent a potential conflict between what ICANN has deployed and what the IETF has specified. The ambiguity here has caused some discomfort, and that was one of the motivations for this work.

The document draft-liman-tld-names has not met with any particular enthusiasm in the places it has been circulated. The general consensus seems to be that of apathy. This might be fair enough; if the IETF doesn't want to involve itself in TLD policy, that seems fine, for example. But a clear statement to that effect would be better than the sound of crickets.

I can see a few ways forward. No doubt there are others.

(a) do nothing

Leave the ambiguous specification in 1123, leave the question of whether the IETF has an interest in constraining label syntax for TLDs open, and do nothing.

(b) a label is a label is a label

State clearly that there is no special restriction for TLD labels, distinct from the protocol restrictions for any other label in the DNS tree; in other words, release any interest in TLD label syntax at the IETF, and defer it all to ICANN.

I've heard this approach promoted by people in DNSOP. I expected to hear dissent from the App area people, since the problem remains of how to distinguish between a literal IPv4 address and a domain name in the unlikely event that a TLD exists that is syntactically a legal final component of an IPv4 address. But in Québec those that did express an opinion seemed to say "this is ICANN's business, we don't care". But I'd be hard-pushed to identify consensus in either venue.

(c) koch proposal

Formalise the "alphabetic" constraint for wire-format TLD labels, and extend it specifically to permit "xn--" wire-format labels. This leaves it possible for TLD U-Labels to contain punctuation and digits (i.e. it retains the alphabetic restriction for US-ASCII TLD labels, but does not impose one for IDNs).

(d) draft-liman-tld-names

As discussed (and reviewed exhaustively by Peter, many thanks for that) formalize the "alphabetic" constraint for US-ASCII and for IDNA2008 U-Labels (i.e. keep the restriction consistent for users who may not be aware of whether they are typing, in effect, a U-Label or a US-ASCII label).

(e) something else

. . .

What does the DNS Directorate think about this? Thoughts, opinions?

Joe

---

From: Peter Koch <[email-masked]>
Date: Thu, 4 Aug 2011 17:49:27 +0200

> Formalise the "alphabetic" constraint for wire-format TLD labels, and extend it specifically to permit "xn--" wire-format labels. This leaves it possible for TLD U-Labels to contain punctuation and…

that's not quite what i had in mind, but since i only said what not so far,
let me clarify:  i do not see 'xn--' and the later '-' special in any case.
So, my proposal would be to clarify that the 'will always be alphabetic'
clause is, in hindsight, a wrong prediction and in any case should not be
read in a normative way.  This may or may not change the obligation of or advice
to teh implementor when they exercize the 'dotted quad' confusability checks.
Whether or not we can or should assume 'will never be digit only' instead,
is subject to debate, but history tells us we shouldn't make such broad assumptions.

-Peter

---

From: Joe Abley <[email-masked]>
Date: Thu, 4 Aug 2011 09:03:24 -0700

On 2011-08-04, at 11:49, Peter Koch wrote:

> let me clarify:

OK, then let's re-cast (c) as the pseudo-Koch option; I think your proposal then amounts to option (b).

I believe the situation remains that the consensus-enthusiasm needle for option (d) lies somewhere between "apathy" and "mild dislike", and the opinions of the DNS Directorate would still be beneficial in identifying a path forward.

Joe

> (c) pseudo-koch proposal

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Aug 2011 15:52:55 -0400

> to teh implementor when they exercize the 'dotted quad' confusability checks.

It's not merely "'dotted quad' confusability checks" we have to worry
about.

There are lots of protocol slots that can either take a domain name or
an IP address.  In the happy case of mail, we are relieved of the
burden because you are supposed to use [] around IP addresses.  But
everything else (including URIs, last I checked) can have raw IP
addresses.

Moreover, there is no requirement that the IP address be in a
dotted-anything notation.  Raw apparent integers work in at least some
contexts I have seen.

It is problems like this that set some people on edge.

I think the document should be pursued, and I think it should go on as
it currently does, on the quite correct grounds that whatever happens,
it is always possible to open the door wider later.  (It should
perhaps suggest to IDNA application implementers that they should not
rely on the restrictions to do validity checks, on the grounds that a
wider policy is always possible later.)

To me, this is only an effort to maximise interoperation and minimise
surprise, and therefore to say that the names are required to work
this way on the grounds of minimising such surprise.  Strictly
speaking, there is plenty of room for policy innovation here.  That
doesn't mean there are no potential technical implications.

A

-- 
Andrew Sullivan
[email-masked]