Subject: [dns-dir] draft-liman-tld-names-00

From: Thomas Narten <[email-masked]>
Date: Tue, 25 Aug 2009 12:01:47 -0400

Hi All.

Tina Dam has asked me to try and move this document along. ICANN
thinks they need it as an RFC before they launch IDNs. It appears to
have been sitting since March...

In reviewing this document, I think it would benefit from some edits
that make it more clear what this document is trying to solve and what
it is not. (Just saying "clears up ambiguities" isn't direct enough,
IMO.)

Even in going back and reviewing the mail thread on dnsop in March,
I'm not entirely clear what this document is trying to fix. Also,
there is much confusion (FUD?) in this space, and I think this
document would be a fine place to do away with some of this.

Some random thoughts (which may not be right).

I think this document cannot say that TLDs MUST be 2 characters
long. What is the technical basis for such a recommendation? My
understanding is that the main motivation for such a rule is to avoid
user confusion and avoid having a single typo change TLD 'a' to some
other TLD and then cause lookup from the wrong site. That is a fine
concern, but we have single letter labels below TLDs, so how big a
problem this is is open for debate. I think it would be fine to state
something like that, but leave it to ICANN to decide. Unless someone
can point me to a real technical argument. Right now, the document
just says it MUST be 2 characters, with no supporting reasoning.

I think this document should go review the history a bit, the various
confusions (DNS vs. host name), note that we don't ever want any DNS
name to be confused with something that inet_pton() would convert,
etc. And so forth.

Thoughts?

Can someone here restate what (if any) issues exist with moving this
document forward? And should it be a WG document rather than an
individual submission?

Thomas

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 25 Aug 2009 23:07:13 -0400

I don't want to speak for Lars Liman, who has done all the work here.
This is just my perspective, from what I remember.

> it is not. (Just saying "clears up ambiguities" isn't direct enough,

The goal so far has been, I thought, to do the absolute bare minimum
necessary to change the "alphabetic only" rule, and do nothing more.
Partly, this is a defensive measure against certain parties who warned
they'd kick and scream if anything more than that were done.
 
> I'm not entirely clear what this document is trying to fix.

It was supposed to be an extremely focusssed, narrow fix of exactly
the provision in RFC 1123, §2.1, that says "the highest-level
component label will be alphabetic."  The idea was to get out the door
something that solved exactly the problem standing in the way of
A-labels in the top level, but nothing more.

>  Also,

See the "nothing more", above.  I'm not opposed to tilting at that
particular windmill on principle, but if we're going to do something
for the short term, this isn't the way to do it.
 
> long. What is the technical basis for such a recommendation? 

Well, _at least_ 2 characters long.  The sole justification for this
is that it's ever been thus, and we don't want to change that without
pretty good evidence that it will do no harm.  This is not a "justify
the limitation", it's a "justify the change" space.  At least that's
been the aim

> other TLD and then cause lookup from the wrong site. 

No, the motivation is that there's never been a single-character TLD,
and therefore adding one could break some hard coded assumptions.
Adding >3-character TLDs sure did, and there already _were_ some of
those.

> name to be confused with something that inet_pton() would convert,

I think that would be an excellent project after we got this draft out
the door, because anything that involves (1) the history of the DNS or
(2) anything but the most cosmetic, trivial, or obviously right
alterations to the rules risks going into IETF DoS hell.  To trot out
my favourite personal example, the reverse-mapping-considerations
draft that went to DNSOP WGLC said very little more substantive than,
"Some people like the reverse tree.  You should maintain it for your
site.  Or, not, if you don't want to.  Also, if you use the reverse
tree, don't rely on it too much.  But use it if you want."  Even this
apparently bland claim was unable to make it past the WG, and died.  I
suspect that if a draft came to the DNS community that said, "DNS
exists and (A or not-A)," there would be someone at the mic ready to
complain.  If we want to make progress, let's make it in small
increments.

> document forward? And should it be a WG document rather than an

It should become a WG item, yes.  It seems to be an operational rule
about content of the root zone, so it belongs in DNSOP (but DNSEXT is
willing to take it if the DNSOP Chairs want us to.  Careful what you
wish for: we just sent our AD the request to get our new charter out,
and this sure ain't on it).  I expect that, as with most DNS
documents, the main problem is author's time. 

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 26 Aug 2009 08:28:08 -0400

Hi Andrew.

Thanks for your comments...

> This is just my perspective, from what I remember.

Fair enough!

> necessary to change the "alphabetic only" rule, and do nothing more.

I can understand this, and would also support it. That said, the
document should come out and say that. You have to read between the
lines to understand what the new proposed syntax is actually changing,
and why that needs to be done.

> they'd kick and scream if anything more than that were done.

Right. Can you (or anyone) state what some of these other areas are? I
may well not be inclined to go there either, so we may be in violent
agreement...

> A-labels in the top level, but nothing more.

OK.

> the limitation", it's a "justify the change" space.  At least that's

Then let's document this and move on. I agree it's a possible
concern. But talking with Klensin in particular about the history of
single letter TLDs, my understanding is that the real motivation for
not allowing them is about confusion. Let me dig up a note on this and
forward separately.

> Adding >3-character TLDs sure did, and there already _were_ some of

Right. But then we should document the concern, and not necessarily
say MUST or MUST NOT. At least not a blanket statement without
explaining what must be done first (e.g., first survey deployed
software to find out how significant the concern actually is in
practice, etc.).

> complain.  If we want to make progress, let's make it in small

I don't see the reverse tree analogy the same. But anyway, this
concern would be better discussed in the context of specific proposed
changes/text that would allow us to evaluate specific items on their
merits.

> documents, the main problem is author's time. 

Yeah. It straddles the two WGs. Probably dnsop, as this isn't changing
what the protocol allows, just the operational practices around what
is advisable about TLD labels. Then again, the original DNS specs is
where the current language is...

Thomas

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Aug 2009 09:27:45 -0400

> may well not be inclined to go there either, so we may be in violent

One of them is, in fact, allowing single-letter TLDs.  Another is
allowing TLDs that start with a number.  Really, the feedback I got
(and it was from one of the people who often appears on IETF BINGO
cards, if that helps you narrow it down) was that we should do nothing
more than adjust the rule _exactly_ enough to allow A-labels to be
inserted in the root zone, and no more, or we'd face a nasty slog of a
fight.  The real motivation for that might well be as a proxy for a
policy argument that the individual doesn't want to have, but the
argument presented was on the basis of conservatism with what changes
one would allow in the root zone, because of its sensitivity.

My _personal_ preference is probably more aligned with yours: I think
we should merely require that no TLD be confusable with either an
octet or a numeric address, because otherwise there's no automatic way
to tell whether something is an address or a name; in practice this
means "never starts with a number" and that's probably it.  To me,
anything more is policy.  But we got into this mess because 1123
appears to have conflated policy and protocol (or at least, some have
interpreted it that way), and therefore I can at least follow the
argument that the technically correct thing to do is to leave as much
unchanged as practical.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 28 Aug 2009 21:58:21 +0200

> Hi All.

Hi. I _am_ still alive, despite rumours of the opposite ... I am,
however, beginning to understand how submarine captains relate to the
world ...

> have been sitting since March...

Mea culpa.

> that make it more clear what this document is trying to solve and
> what it is not. (Just saying "clears up ambiguities" isn't direct
> enough, IMO.)

> document would be a fine place to do away with some of this.

My defence for writing the document in the style it has, is that I
wanted to start out with a very strict and limited definition, with
the goal of opening it up just the right amount to satisfy "general
consensus", and any technical specifications that we need to meet. By
being strict, I also _wanted_ to provo^H^H^H^H^H engourage discussion,
so that there would be statements to look at when I/we needed to
decide what the consensus was. If you try to get it right from the
start, fewer people will speak their mind, and there will be less data
(fewer "votes") when the consensus is polled. (Limping English here,
sorry.)

So, you (or anyone else) don't have to be shy to express disagreement -
that's what I wanted to encourage with the -00 version, and that's
what I hoped for.

> just says it MUST be 2 characters, with no supporting reasoning.

Typical provocation on my part. I wanted people to scream exactly
in the way you do, and now I have one more ballot in my consensus
building tool box. Thank you! :-)

My personal take is that an RFC should say precious little about what
names can go in there, as long as they adhere to the technical
specifications for DNS labels.

The only strong feeling I have, is that I would like to keep the rule
that they cannot be digits only. If you allow for digits only, you can
construct domain names that look like 10.2.3.4 (with "4" being the
TLD), and it is obviously impossible for software to know whether that
is a domain name or a literal IPv4 address. By disallowing digits
only, we make sure that that cannot happen. I believe there is a rule
(or folklore) that requires that "not the entire domain name be make
up from digits", but that rule is impossible to enforce (DNS layering
violation! ;-), but by imposing a simpler rule on the root, we can
avoid the problem.

I also believe that the general idea of "starting out strict" is the
right way to go. It is always easier to open up more in the future,
then to try to impose stricter limitations at a later stage. However,
the strictness can be applied for different reasons, and by different
bodies. I.e., I can live with a system where this document is fairly
permitting, but where a policy document (by ICANN?) sets a more
limited policy, for reasons that are not necessarily strictly
technical. I can, however, foresee that that might be difficult to
defend to some parts of the "general public". If we can find technical
motivations for keeping things strict, I think that will be easier to
defend, thereby taking some pressure off ICANN and Tina.

> name to be confused with something that inet_pton() would convert,

Where is the history to be found? There is oral folklore out there,
but I would appreciate pointers to more solid documents. I believe one
of the problems, and reasons for writing this document, is that there
are too few solid documents out there.

> document forward? And should it be a WG document rather than an

Some issues were raised at the DNSOP meeting in SFO. I was presenting
at the time, so I hope there are some notes, either in the minutes
from the meeting, and/or in the jabber logs. I would like those issues
to be at least looked at, so that I/we make sure that we don't miss
anything critical.

There are, AFAIK, no formal resons to not forward this document, but
it is too raw as it stands.

(More comments in follow-ups.)

				Cheers,
				  /Liman

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 28 Aug 2009 22:09:14 +0200

> one would allow in the root zone, because of its sensitivity.

Well, I see one of the problems being that it is not quite cast in
stone what the current rules allow for. There are so many stones, and
the runes describe the problem from different angles, so it's not easy
to deduct what the current rules are. That situation is also a reason
to write a document like this one, so that there would be one
document, which (hopefully) unambiguously defines what ther rules
are. No more (RFC 1035 + RFC 1123 - RFC 1597) * 20 years of experience.

> means "never starts with a number" and that's probably it.

Umm, as per my previous message, isn't "not all digits" sufficient to
reach that goal? Is "10.1.2.3com" too risky?

> To me, anything more is policy.

Amen!

> But we got into this mess because 1123 appears to have conflated
> policy and protocol (or at least, some have interpreted it that
> way), and therefore I can at least follow the argument that the
> technically correct thing to do is to leave as much unchanged as
> practical.

You put it so well. Thank you. The problem is just defining what we
don't want to change, i.e., the starting point. ;-)

				Cheers,
				  /Liman

---

From: Lars-Johan Liman <[email-masked]>
Date: Fri, 28 Aug 2009 22:13:51 +0200

[email-masked]:
> All, just catching up on this note. A few comments:

> 1) I agree that we should do this as minimal as possible, and goal is
> to allow A-label TLDs.

At least that is the short term goal.

> 2) on the digit concern, I previously agreed with the authors that
> this did not belong in the RFC but instead should be controlled by
> ICANN. Currently ICANN does not allow leading or trailing digits in
> TLDs. It does not really matter to me where that rule sits, as long as
> it is observed. The reason for the ICANN requirement was not "just"
> the confusability with octets or numeric addresses but also due to the
> results we see with leading trailing digits in a right-to-left
> environment. Because this is a new area it was thought that we better
> be conservative and restrict it completely.

That is indeed a valid remark, IMO. This should be documented in the
draft, and that makes the motivation for such a rule even stronger.

> Also, please let me know what I can help with to get this finalized. I
> do believe it is necessary in order for ICANN not to be in violation
> of the RFC when launching IDN TLDs.

I still haven't heard any voices from the DNSOP chairs. I suppose they
are busy building a solid case defending how to make this document
_not_ end up on their table ... (Hi, Peter and Rob! ;-).

				Cheers,
				  /Liman

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 28 Aug 2009 17:50:10 -0400

>_not_ end up on their table ... (Hi, Peter and Rob! ;-).

I will suggest we do not send this to any working group but that
one or more of our AD's sponsor this to be an BCP. Any takers ?

         Olafur

---

From: Tina Dam <[email-masked]>
Date: Thu, 27 Aug 2009 10:08:29 -0700

1) I agree that we should do this as minimal as possible, and goal is to allow A-label TLDs.

2) on the digit concern, I previously agreed with the authors that this did not belong in the RFC but instead should be controlled by ICANN. Currently ICANN does not allow leading or trailing digits in TLDs. It does not really matter to me where that rule sits, as long as it is observed. The reason for the ICANN requirement was not "just" the confusability with octets or numeric addresses but also due to the results we see with leading trailing digits in a right-to-left environment. Because this is a new area it was thought that we better be conservative and restrict it completely.

Also, please let me know what I can help with to get this finalized. I do believe it is necessary in order for ICANN not to be in violation of the RFC when launching IDN TLDs. 

Tina

> -----Original Message-----
> From: Andrew Sullivan [mailto:[email-masked]]
> Sent: Wednesday, August 26, 2009 6:28 AM
> To: Thomas Narten
> Cc: [email-masked]; Tina Dam; dns directorate
> Subject: Re: [dns-dir] draft-liman-tld-names-00
>

---

From: Peter Koch <[email-masked]>
Date: Sun, 30 Aug 2009 21:59:50 +0200

> At least that is the short term goal.

Not sure we should actually be so narrowly focussed since it looks like
"lip service" on a protocol level.  From an IETF point of view I'd say
we somehow found that the phrase "will be alphabetic" appears to be
ambiguous to say the least. It is unclear whetehr it's normative and when
it's normative whether that's a protocol or a policy statement.  For
confusability in the context of that same paragraph, "will not be
digit-only" would be fine (and maintain the ambiguity, but that's a
different issue).  It is this and the extreme positioning of "-" that we
should be concerned about here. ``xn--'' (and inner dashes)  would return
into protocol boundaries as a side effect.

> draft, and that makes the motivation for such a rule even stronger.

IMHO we (==IETF) should constrain ourselves to solve an observed
ambiguity.  ICANN is to set the policy and if there are valid reasons
for restrictions, they don't completely have to originate from IETF
documents.  If there are special conceerns with digits in IDN TLDs,
that's something hopefully covered in operational connsiderations in
IDN documents, at least it is different from the 1123 amendment.

> _not_ end up on their table ... (Hi, Peter and Rob! ;-).

First, given the sensitivity of the topic, I don't think an individual
submission sets the right signal.  I know that some core IETF protocols
have been worked on this way recently, but it's my firm belief this is
a step in the wrong direction.  Open discussion is key here and for
BCP or STD track, there'd be an main IETF list debac^Hte anyway.
I'm happy to have the discussion continue on dnsop.

FWIW, the draft is about to expire in a few days.

Best regards,
   Peter

---

From: Lars-Johan Liman <[email-masked]>
Date: Sun, 30 Aug 2009 22:45:27 +0200

> one or more of our AD's sponsor this to be an BCP. Any takers ?

That was the original plan, IIRC. I'm can go either way, but I think
that if we do need timely results, and we don't want World War III,
that your proposal is probably the better. It _is_ policy stuff,
rather than technical development ... or at least policy is an
important ingredient. ;-)

				Cheers,
				  /Liman