Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?

From: Tony Finch <[email-masked]>
Date: Tue, 1 Jul 2008 17:40:35 +0100

On Mon, 30 Jun 2008, Stephane Bortzmeyer wrote:
> On Mon, Jun 30, 2008 at 05:49:18AM -0700,
>  David Conrad <[email-masked]> wrote
>  a message of 11 lines which said:
>
> > Speaking technically, how would you distinguish the top-level domain
> > "127.0.0.1" from the IP address 127.0.0.1?
>
> A word while passing here: is there a document (RFC, Posix standard,
> whatever) which says which is the right result in such a case?

RFC 1123 section 2.1, especially the last sentence.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: WEST 4 OR 5, OCCASIONALLY 6 LATER. SLIGHT OR MODERATE BECOMING ROUGH.
THUNDERY SHOWERS. MODERATE OR GOOD.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 01 Jul 2008 09:44:49 -0700

> RFC 1123 section 2.1, especially the last sentence.

Interesting.

I hadn't noticed the implication of that, before, but it seems to be a pretty 
clear technical specification that a top-level domain is not allowed to be a 
decimal number.  Ever.

That's a concrete constraint on what ICANN is permitted to authorize.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 1 Jul 2008 09:58:43 -0700

Another like restriction that might be investigated is whether http://microsoft/ or other similar corporate TLDs would work as intended with deployed legacy browsers.
 
I suspect (but have not tried) that if you simply type 'Microsoft' into the address bar of some browsers you might have the keyword immediately interpreted as a search term, not an address to visit. 

I also suspect that if we actually read the technical specs being proposed we might find that some of these issues have already been anticipated in them and addressed.

________________________________

From: [email-masked] on behalf of Dave Crocker
Sent: Tue 7/1/2008 12:44 PM
To: Tony Finch
Cc: IETF Discussion
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?

Interesting.

d/
--

   Dave Crocker

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 1 Jul 2008 21:44:17 +0200

On Tue, Jul 01, 2008 at 05:40:35PM +0100,
 Tony Finch <[email-masked]> wrote 

> RFC 1123 section 2.1, especially the last sentence.

Well, the last sentence will no longer be true if all-numeric TLDs are
allocated but, before that, one finds:

> The host SHOULD check the string syntactically for a dotted-decimal
> number before looking it up in the Domain Name System.

which seems to reply to David Conrad's question: if all the
implementations are correct, 127.0.0.1 will always be an IP address,
even if the TLD ".1" is allocated.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Thomas Narten <[email-masked]>
Date: Tue, 01 Jul 2008 16:51:19 -0400

Joe Abley <[email-masked]> writes:

> A better approach, I think, would be for proposed TLDs to pass  
> technical review through some suitable body who could consider each  
> case on its merits.

As in https://par.icann.org/files/paris/gTLDUpdateParis-23jun08.pdf,
starting at chart 11? 

Also, for TLDs like .local, one could also to some extent just say
"buyer beware". Anyone wanting a TLD that is known to not be useable
in practice (for some deployed software) would get what they
deserve. :-) The folk wanting TLDs presumably want TLDs that can
actually be used...

That said, I would expect requests for TLDs that would cause real
technical or operational problems to be turned down. There is a step
in the process for input of the form "um, bad idea because..."

Brian E Carpenter <[email-masked]> writes:

> I think all the external evidence is that ICANN is deeply reluctant to
> set up mechanisms that require the application of common sense (a.k.a.
> judgment) as to whether or not a particular domain name may be
> registered.

Perhaps I've had too much of the Kool Aid, but there are steps in
place that are intended to catch potential technical/operational
problems with proposed TLDs. Maintaining DNS stability is a core theme
that appears throughout ICANN.

David Conrad <[email-masked]> writes:

> On Jun 30, 2008, at 5:43 AM, John C Klensin wrote:
> > The other two things that seem to be getting lost in this discussion  
> > is that one can write all of the RFCs one like, but rules like this  
> > are ultimately useless unless ICANN agrees to them

> ICANN has already deferred to the IETF on technical matters (see  
> IDNs).  I'm unclear why ICANN would ignore IETF technical input on  
> this matter.

I'll second that. If the IETF were to say "bad idea" for any
particular TLD (or class of TLDs), I think ICANN would listen.

Thomas

---

From: David Conrad <[email-masked]>
Date: Tue, 1 Jul 2008 13:57:55 -0700

> even if the TLD ".1" is allocated.

Which might tie into the discussion regarding "SHOULD vs. MUST"... :-)

Regards,
-drc

---

From: Philip Guenther <[email-masked]>
Date: Tue, 1 Jul 2008 15:47:06 -0600

On Tue, 1 Jul 2008, Thomas Narten wrote:
...
> deserve. :-) The folk wanting TLDs presumably want TLDs that can

Oh, a TLD of .local has a potential use...of convincing filtering software 
on node A that evil.local is a normal, valid hostname, while node B behind 
it treats evil.local as being in the magic-for-it .local TLD.  Differing 
interpretations result in fragility.

Philip Guenther

---

From: John C Klensin <[email-masked]>
Date: Tue, 01 Jul 2008 17:53:11 -0400

--On Tuesday, 01 July, 2008 16:51 -0400 Thomas Narten
<[email-masked]> wrote:

>...
> Also, for TLDs like .local, one could also to some extent just
> say "buyer beware". Anyone wanting a TLD that is known to not
> be useable in practice (for some deployed software) would get
> what they deserve. :-) The folk wanting TLDs presumably want
> TLDs that can actually be used...
>...

Thomas,

Pretend I'm a fine, upstanding, citizen who is in the domain
names business (I guess that would make me a "domaineer" :-))
and whose business model is based on traffic concentration and
redirection.  

I think I would really like to own "local", although not as much
as I'd like to own "example.com" or any other name to which the
IETF or various protocol designs provide free advertising and
traffic direction.  Every leaked name that might reference a web
page would drive traffic to my site, as well as every action
that led those who didn't know what was going on to open
http://www.local./ to figure out what was going on.

In a more sane world, no one rational would want to build a
business or other activity around a TLD named "local".   But
this is demonstrably not a sane world.

      john

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Jul 2008 15:26:23 -0700

>this is demonstrably not a sane world.

+1. I was approached by one such fine, upstanding citizen who asked 
which names "currently reserved by the IETF" would be most valuable 
for a search page.

This does not mean that ICANN won't listen to the IETF; it means that 
there will be voices more familiar to ICANN saying things different 
than we are.

--Paul Hoffman, Director
--VPN Consortium

---

From: John Levine <[email-masked]>
Date: 1 Jul 2008 22:36:55 -0000

> This does not mean that ICANN won't listen to the IETF; it means
> that there will be voices more familiar to ICANN saying things
> different than we are.

One of the few ICANN committees that actually works is the SSAC, the
Security and Stability Advisory Committee.  It includes a lot of
people we know, starting with Steve Crocker, the chair.  I cannot ever
recall a time when ICANN acted contrary to the advice of the SSAC.

So although I agree that there's a lot not to like about ICANN, the
chances that they will do technically dangerous things are low.

http://www.icann.org/committees/security/

R's,
John

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Jul 2008 10:17:38 -0400

> this is demonstrably not a sane world.

Right. I can see the business case for this. :-(

But at least in the first round, the barrier to entry is so high that
I don't see that sort of thing as being viable. The figure $100K for
a TLD application is what is floating around at the moment, though
that number is not nailed down definitively.

For much of the domain tasting related activities, a fundamental
premise was that the cost of using a name was very low (i.e., zero,
while the AGP was being leveraged).

Thomas

---

From: "James Seng" <[email-masked]>
Date: Wed, 2 Jul 2008 06:41:37 +0800

Which brings up a question can a TLD be used like a domain name?

not just http://microsoft/ but bill.gate@microsoft will likely to fail to.

james

2008/7/2 Hallam-Baker, Phillip <[email-masked]>:
> Another like restriction that might be investigated is whether
> http://microsoft/ or other similar corporate TLDs would work as intended
> with deployed legacy browsers.
>
> I suspect (but have not tried) that if you simply type 'Microsoft' into the
> address bar of some browsers you might have the keyword immediately
> interpreted as a search term, not an address to visit.
>
>
> I also suspect that if we actually read the technical specs being proposed
> we might find that some of these issues have already been anticipated in
> them and addressed.
>
>

---

From: Steve Crocker <[email-masked]>
Date: Tue, 1 Jul 2008 18:38:50 -0400

<blush>

Thanks!

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Jul 2008 09:25:58 -0700

(It's always a bummer when ietf-general turns into ICANN-general, but 
in this case it seems like a useful discussion because the IETF will 
probably be asked policy questions for various proposed TLDs.)

At 10:17 AM -0400 7/2/08, Thomas Narten wrote:
>I don't see that sort of thing as being viable.

Then you're not being creative enough.

>The figure $100K for

...nor justified financially...

>while the AGP was being leveraged).

If that was true, then a domain that was popular but lost its name 
due to negligence in renewal should be able to buy it back from the 
taster for a few hundred bucks. Instead, the price I have heard more 
than once is tens of thousands of dollars.

Without doing a lot of business research and probably some traffic 
capture, you can't estimate the value of .local or a TLD that is a 
typo but not really infringing of a popular search term. We scoff at 
people who say "it would be easy to just add privacy to that 
protocol"; they should scoff at us for making wild guesses about 
values in a huge, unregulated business that is less than ten years 
old.

--Paul Hoffman, Director
--VPN Consortium

---

From: Ole Jacobsen <[email-masked]>
Date: Wed, 2 Jul 2008 09:30:06 -0700 (PDT)

Paul,

But it is still the case that an application for say .local would need 
to go through some review process (regardless of price) which would 
include input from the IETF ICANN rep. I see little reason why or how
a TLD that would be damaging, confusing, or otherwise "bad" for the 
IETF would/could just "slip through" this process.

What am I missing here?

Ole

Ole J. Jacobsen
Editor and Publisher,  The Internet Protocol Journal
Cisco Systems
Tel: +1 408-527-8972   Mobile: +1 415-370-4628
E-mail: [email-masked]  URL: http://www.cisco.com/ipj

---

From: John Levine <[email-masked]>
Date: 2 Jul 2008 16:53:38 -0000

In article <[email-masked]> you write:
>include input from the IETF ICANN rep.

More likely from the SSAC, which would be even better.

In any event, as I said before, although there's a lot not to like
about ICANN, the chances of them doing anything technically
destructive remains low.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Jul 2008 10:45:26 -0700

>IETF would/could just "slip through" this process.

Fully agree.

>What am I missing here?

That there could/would be others arguing that the IETF is 
over-stating the damage from a particular proposal. Anyone who is 
willing to pay the exorbitant^W application fee obviously is willing 
to defend their choice of name. On something like .local (and, I 
predict, ".1"), the counter-argument to anything the IETF says is 
"that's possibly true, but not likely". We can't prove future harm, 
and they can belittle us for being "too cautious". They have money 
behind them, and we have our reputation. ICANN gets to weigh those 
two against each other. This is somewhat parallel to the political 
process in most capitalist democracies.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Jul 2008 18:18:34 -0400

--On Tuesday, 01 July, 2008 09:58 -0700 "Hallam-Baker, Phillip"
<[email-masked]> wrote:

> http://microsoft/ or other similar corporate TLDs would work
> as intended with deployed legacy browsers.  
> I suspect (but have not tried) that if you simply type
> 'Microsoft' into the address bar of some browsers you might
> have the keyword immediately interpreted as a search term, not
> an address to visit.

I suspect that, if Microsoft spent a hundred thousand dollars or
more to secure "microsoft." as a TLD, at least one of those
browsers would be swiftly corrected in a way that they would
find satisfactory.

The issue with billg@microsoft is a little more complex.  After
extended discussions, rfc2821bis still does not permit 
  RCPT TO:<bill@microsoft.>
(note trailing dot) and there are some other issues about trying
to use TLDs as the only label in an email address.

But none of that counts.  There have been more than enough
actors who have wanted TLDs that violate one rule or another,
assuming that applications authors will sort things out as
needed, maybe even with IETF help.  And there have been more
than enough who believe that, if some construction they want
works with the world's most popular browser, then it is
sufficient (non-web protocols be d**ned).

   john

---

From: Lyman Chapin <[email-masked]>
Date: Wed, 2 Jul 2008 11:52:38 -0400

With apologies for coming late to this thread -

Any proposal for a new gTLD must satisfy a number of "string  
criteria" that will be specified explicitly in the RFP, including the  
requirements that the U-label must not:

(a) be identical to an existing TLD;
(b) be identical to a Reserved Name;
(c) consist of a single character;
(d) consist of two characters, unless (a) it consists of a single  
Letter and a single Digit (in either order), or (b) it is an IDN  
string and the two characters are registered as permitted for two- 
character labels in the relevant script/language;
(e) consist entirely of Digits;
(f) be a hexadecimal number consisting of the Digit “0” followed by  
the uppercase or lowercase Letter “x||X” followed by a sequence of  
one or more characters all of which belong to the set of uppercase or  
lowercase Letters “a||A” through “f||F” and the Digits “0” through “9”;
(g) be an octal number consisting of the uppercase or lowercase  
Letter “o||O” followed by a sequence of one or more characters all of  
which belong to the set of Digits “0” through “7”;
(h) contain any Unicode code point that is classified as DISALLOWED  
or UNASSIGNED by RFC nnnn (currently “The Unicode Codepoints and  
IDNA,” draft-faltstrom-idnabis-tables-05.txt);
(i.1) [if IDN Language Reference Tables have been defined] contain  
any Unicode code point that is not present in the IDN Language  
Reference Table to which the Application refers;
(i.2) [if IDN Language Reference Tables have not been defined]  
contain any Unicode code point that is classified as CONTEXTUAL RULE  
REQUIRED by RFC nnnn (currently “The Unicode Codepoints and IDNA,”  
draft-faltstrom-idnabis-tables-05.txt);
(j) begin or end with a Hyphen; or
(k) contain Hyphens in both the third and the fourth position.

In addition, the A-label obtained by applying the IDNA algorithm  
specified in RFC 3492 to the proposed string must:

(l) be identical to the A-label specified in the Application; and
(m) consist of no more than 63 characters.

(Note: the capitalized terms will be formally defined in a  
Definitions section of the RFP.)

Having read most, but not all, of the postings to this thread, I  
believe that these rules cover many (but probably not all) of the  
cases that have been discussed. Things will get both simpler and more  
complicated when the IDNAbis WG completes its work, but within ICANN  
there is a clear intention to track that work as closely as possible  
given the timing constraints of the new gTLD program. Many of the  
devils that concern the IETF, of course, are in the details of the  
Reserved Names list. If there are problematic cases other than those  
that would have to involve the Reserved Names list, I would very much  
like to hear about them.

- Lyman

---

From: Steve Crocker <[email-masked]>
Date: Wed, 2 Jul 2008 13:10:18 -0400

While I appreciate the kind words and deference to SSAC, and while we  
would undoubtedly concur with recommendations to reserve names  
like .local, ICANN actually listens to the IETF more directly.   
Moreover, there is a specific slot on the Board of ICANN for a  
Liaison from the IETF.  Thomas Narten does a great job in that role,  
as John Klensin did before him.

Steve

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Jul 2008 18:40:40 -0400

--On Wednesday, 02 July, 2008 10:45 -0700 Paul Hoffman
<[email-masked]> wrote:

>> But it is still the case that an application for say .local
>> would need to go through some review process (regardless of
>> price) which would include input from the IETF ICANN rep. I
>> see little reason why or how a TLD that would be damaging,
>> confusing, or otherwise "bad" for the IETF would/could just
>> "slip through" this process.
> 
> Fully agree.

Ole, even those of us who are most skeptical about relying on
ICANN are not concerned about something "slipping through".  The
concern is about ICANN weighing the issues and deciding that
what someone "wants to do" and on which they are willing to
spend serious money (or, to put that differently, contribute
serious money to ICANN).

> over-stating the damage from a particular proposal. Anyone who
> is willing to pay the exorbitant^W application fee obviously
> is willing to defend their choice of name. On something like
> .local (and, I predict, ".1"), the counter-argument to
> anything the IETF says is "that's possibly true, but not
> likely". We can't prove future harm, and they can belittle us
> for being "too cautious". They have money behind them, and we
> have our reputation. ICANN gets to weigh those two against
> each other. This is somewhat parallel to the political process
> in most capitalist democracies.

Exactly.

And, in that regard, I draw no comfort from Thomas's comment
about a likely $100K application fee.  Assume we have
organizations who are willing to put that sort of money into an
application for a TLD they think would be profitable or
beneficial to themselves... and probably to spend that much
again on lawyers, consultants, etc., to prepare an application
that will get through the system.  If they see IETF-imposed
restrictions as being in their way, they are likely to be
willing to put significant energy and resources into sweeping
those restrictions out of the way, using precisely the sort of
"those guys are too conservative" argument Paul posits (or its
relatives "those guys are trying to make policy and disguise it
as an inevitable technical choice" or "the risks are low and
here is our large chunk of money to prove that we think there
are overriding commercial considerations").

Now, for example, I happen to believe that "one-off typing error
is guaranteed to yield a false positive", is a more than
sufficient _technical_ basis to ban single-alphabetic-letter
domains at either the top or second levels and to advise
lower-level domains against their use.  Those are technical
grounds based on human interface design and information
retrieval principles, not "the network will break if that is
done".  But few of the recommendations or reservations we might
make fall into that network-breaking latter category.  Even some
of those that fall closest to the line involve cases that we
could "fix" by modifying our applications protocols to lexically
distinguish between domain names and address literals
(http://[10.0.0.6]/ anyone?).

It is, of course, possible to argue the case for and against
single-letter domains in other ways and reach the conclusion
that the advantages of permitting one-character alphabetic TLDs
far outweigh the possible risks, especially since the end users
who can get hurt by this stuff don't have much practical voice
in ICANN.  To someone worried about ICANN's budget, or trying to
make the staff-empire even larger, $2,600,000 or $3,600,000 (26
letters, or 26 letters plus ten digits, times $100K) might
themselves be a powerful argument.

But, should those of us who believe that single-letter domains
are bad news refrain from advocating for that rule because those
who oppose it could use it to discredit other IETF
recommendations that might be more important?    I don't know
the answer to that question, but I do know that the IETF has a
lot of trouble making clear decisions when those sorts of
politics start to intrude.

--On Tuesday, 01 July, 2008 09:44 -0700 Dave Crocker
<[email-masked]> wrote:

> I hadn't noticed the implication of that, before, but it seems
> to be a pretty clear technical specification that a top-level
> domain is not allowed to be a decimal number.  Ever.
> 

The rather odd phrasing there has been the source of a lot of
discussion in the past in both selected IETF and ICANN circles.
Some of us read it as "TLDs will be alphabetic only -- no
digits", not just "cannot be all digits".  The former was
certainly the IANA intent when we were discussing RFC 1591.
But does it apply today?  Can ICANN override it?  I can assure
you that there are groups within ICANN who believe that they can.

--On Monday, 30 June, 2008 12:29 -0700 David Conrad
<[email-masked]> wrote:

>...
> Sort of like the concerns about unexpected behavior that
> resulted in rejecting UTF-8 labels and coming up with punycode.
>...

But the behavior that would occur if that were done wasn't
unexpected or unpredictable at all.    We have a good number of
popular applications protocols, starting with SMTP, that insist
that domain names contain labels all of which are in "hostname"
(LDH) form.  Anything else is a syntax error, and lots of
implementations support that and check for the error case.  We
know that a number of implementations of applications got into
trouble when ICANN allocated TLDs of more than four characters
(without consulting the IETF, by the way).   It is really hard
to predict what would happen in some of  these other cases,
other than "inconsistent behavior" (resulting from different
implementations interpreting the rules differently).

    john

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jul 2008 15:47:48 -0700

> > Another like restriction that might be investigated is whether> > http://microsoft/ or other similar corporate TLDs would work> > as intended with deployed legacy browsers. 
 
I think there are two orthogonal issues which are being conflated here. 
One issue is the ability of existing implementations to support services 
hosted within a TLD (e.g. http://com/).  A separate issue relates to 
the creation of new TLDs.  Creating new TLDs does not necessarily
imply hosting of services within a TLD, although this could be an
(unintended) consequence. 
> > I suspect (but have not tried) that if you simply type> > 'Microsoft' into the address bar of some browsers you might> > have the keyword immediately interpreted as a search term, not> > an address to visit.
 
While I can't speak for the behavior of any browser, no application 
relying on the Windows resolver will behave in this way,
including IE or Mozilla. 
> I suspect that, if Microsoft spent a hundred thousand dollars or> more to secure "microsoft." as a TLD, at least one of those> browsers would be swiftly corrected in a way that they would> find satisfactory.
 
Again, several issues are being conflated here.  
http://foo.com/, http://foo.ietf/, http://foo.microsoft/, etc. 
will resolve correctly on all versions of Windows, with no changes
needed.   
 > But none of that counts. There have been more than enough> actors who have wanted TLDs that violate one rule or another,> assuming that applications authors will sort things out as> needed, maybe even with IETF help. And there have been more> than enough who believe that, if some construction they want> works with the world's most popular browser, then it is> sufficient (non-web protocols be d**ned).
As noted above, the issue is not just the interaction of new TLDs
with one or more implementations.  There is also the issue of
the usage of the new TLDs, specifically the hosting of services
within them.

---

From: John C Klensin <[email-masked]>
Date: Wed, 02 Jul 2008 19:01:41 -0400

--On Wednesday, 02 July, 2008 11:52 -0400 Lyman Chapin
<[email-masked]> wrote:

> criteria" that will be specified explicitly in the RFP,
> including the requirements that the U-label must not:
> 

Is "сом" identical to "com"? (the first of these is U+0441
U+043E U+043C)

> (c) consist of a single character;

I've heard it argued repeatedly that this is an unreasonable
rule for ideographic characters.   I don't have an opinion, but
hope that ICANN has considered that case in full details.

> (d) consist of two characters, unless (a) it consists of a
> single Letter and a single Digit (in either order), or (b) it
> is an IDN string and the two characters are registered as
> permitted for two-character labels in the relevant
> script/language;

This rule would permit such TLDs as "1F" or "0F", which I'm not
persuaded are good ideas given what some operating systems (as
discussed on this list) think might be "digits".

I also trust that ICANN has obtained an agreement from ISO,
signed in some appropriate medium like blood, that the ISO
3166-1 alpha-2 code list will not be expanded to include
letter-digit combinations when the 50-year rule (new with ISO
3166-1:2007) causes them to run short of codes.

> (f) be a hexadecimal number consisting of the Digit "0"
> followed by the uppercase or lowercase Letter "x||X"
> followed by a sequence of one or more characters all of which
> belong to the set of uppercase or lowercase Letters "a||A"
> through "f||F" and the Digits "0" through "9";

This is, IMO, much too subtle and admits of cases that will
confuse some applications.   It is not an accident that the
statement in 1123 can (and, if my recollection of 1591 is
correct, should) be interpreted as prohibiting TLDs that are
non-alphabetic.   That rule obviously needs to be modified for
IDN A-labels, but should still be treated with care, IMO.

> (g) be an octal number consisting of the uppercase or
> lowercase Letter "o||O" followed by a sequence of one or
> more characters all of which belong to the set of Digits
> "0" through "7";

See above.

> (h) contain any Unicode code point that is classified as
> DISALLOWED or UNASSIGNED by RFC nnnn (currently "The Unicode
> Codepoints and IDNA," draft-faltstrom-idnabis-tables-05.txt);
> (i.1) [if IDN Language Reference Tables have been defined]
> contain any Unicode code point that is not present in the IDN
> Language Reference Table to which the Application refers;
> contain any Unicode code point that is classified as
> CONTEXTUAL RULE REQUIRED by RFC nnnn (currently "The Unicode
> Codepoints and IDNA," draft-faltstrom-idnabis-tables-05.txt);
> In addition, the A-label obtained by applying the IDNA
> algorithm specified in RFC 3492 to the proposed string must:
> 
> Having read most, but not all, of the postings to this thread,
> I believe that these rules cover many (but probably not all)
> of the cases that have been discussed. Things will get both
> simpler and more complicated when the IDNAbis WG completes its
> work, but within ICANN there is a clear intention to track
> that work as closely as possible given the timing constraints
> of the new gTLD program. Many of the devils that concern the
> IETF, of course, are in the details of the Reserved Names
> list. If there are problematic cases other than those that
> would have to involve the Reserved Names list, I would very
> much like to hear about them.

As a rhetorical question relating to several of the other
comments in this thread, has the IETF been formally asked to
review and sign off on these rules?

    john

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Jul 2008 09:23:58 +1000

> not just http://microsoft/ but bill.gate@microsoft will likely to fail to.
	The Internet went to multi-label hostnames ~20 years ago.
	We added ".ARPA" to all the single label hostnames as part
	of that process.  The only hold over is "localhost" and
	that is implemeted locally, not in the global DNS.

	No sane TLD operator can expect "http://tld" or "user@tld"
	to work reliably.  I suspect there are still mail configuations
	around that will re-write "user@tld" to "[email-masked]".

	Should we be writting a RFC which states that MX and address
	records SHOULD NOT be added to the apex of a TLD zone?

	Should we be writting a RFC which states that single label
	hostnames/mail domains SHOULD NOT be looked up "as is" in
	the DNS?

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jul 2008 17:07:44 -0700

Mark Andrews said:
 
"The Internet went to multi-label hostnames ~20 years ago.We added ".ARPA" to all the single label hostnames as partof that process. The only hold over is "localhost" andthat is implemeted locally, not in the global DNS. No sane TLD operator can expect "http://tld" or "user@tld"to work reliably. I suspect there are still mail configuationsaround that will re-write "user@tld" to [email-masked] we be writting a RFC which states that MX and addressrecords SHOULD NOT be added to the apex of a TLD zone?
 
Should we be writting a RFC which states that single labelhostnames/mail domains SHOULD NOT be looked up "as is" inthe DNS?"
 
Both sound like good ideas to me.

---

From: SM <[email-masked]>
Date: Wed, 02 Jul 2008 17:21:56 -0700

>done".  But few of the recommendations or reservations we might

Some people may question a technical recommendation that is not based 
on "the network will break".

>(http://[10.0.0.6]/ anyone?).

Or wait for http://[2001:1890:1112:1::20]/ to catch up.

>recommendations that might be more important?    I don't know

That's a question to consider before getting into any rule-making.

>you that there are groups within ICANN who believe that they can.

RFC 1591 has been swept away by the changes that have taken placed 
since then.  By making a few changes to RFC 5241, we could have a 
document relevant to this topic. :-)

>         around that will re-write "user@tld" to "[email-masked]".

http://museum/

>         records SHOULD NOT be added to the apex of a TLD zone?

The above TLD has an address record.

>         hostnames/mail domains SHOULD NOT be looked up "as is" in

There was a ccTLD operator who expressed the wish for such mail domains.

Regards,
-sm

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Jul 2008 14:48:25 +1000

> >         around that will re-write "user@tld" to "[email-masked]".

	The key word word is "reliably".  http://museum/ can never
	be guarenteed to work.

	I can have museum.example.net with a search list containing
	example.net.  Which one would you expect to match?  Note
	changing the search order to try single labels "as is" first
	is not safe from a security perpective (see RFC 1535 for why
	not) as the introduction of a new TLD will break things.  

	Getting rid of search lists is also a show stopper.
 
> The above TLD has an address record.

	It still does not make it a good thing.
 	
> There was a ccTLD operator who expressed the wish for such mail domains.

	And I can wish for a million dollars to be added to my
	savings account.  It doesn't mean I'll get it or that the
	ccTLD operator should get it.

	Mark

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 05:22:32 +0200

> The Internet went to multi-label hostnames ~20 years ago.

As noted in RFC 2821 as "one dot required" syntax, also
mentioned in RFC 3696.  Recently *overruled* by 2821bis.

> to work reliably.  

Certainly not expect, but some gave it nevertheless a try.
My bastard browser from hell let's me say <http://museum./> 
(note trailing dot).

> I suspect there are still mail configuations around that 
> will re-write "user@tld" to "[email-masked]".

They didn't note that RFC 2821 upgraded the 821 examples,
sh*t happens... <eg>

> Should we be writting a RFC which states that MX and 
> address records SHOULD NOT be added to the apex of a
> TLD zone?

No, there are enough TLDs disagreeing with this idea...

> Should we be writting a RFC which states that single
> label hostnames/mail domains SHOULD NOT be looked up
> "as is" in the DNS?

...the 2821bis Last Call ended months ago, and "one dot
required" was discussed long enough.  Change this again,
and I'll scream.

 Frank
-- 
Repost, apparently my first attempt didn't make it.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 08:09:48 +0200

John C Klensin wrote:

> http://[10.0.0.6]/ anyone?

My bastard browser from hell eats http://[208.77.188.166]/

It's certainly no STD 66 URL.  But it won't surprise me if
the URL-bis, charset-bis, net_2.0-bis, MIME-bis, XHTML-bis,
(etc. ad nauseam) effort styling itself as "HTML5" decrees
that this is as it should be based on current practice in
the browser industry.

That would be also the moment where I'd welcome a new TLD 
"6]" just to prove a "subtle" technical point.

> the IETF has a lot of trouble making clear decisions when
> those sorts of politics start to intrude.

So far nobody disagreed with RFC 1123 erratum 1335.  FWIW
that also eliminates "6]" from the list of potential TLDs.

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 3 Jul 2008 10:06:40 +0200

On Thu, Jul 03, 2008 at 09:23:58AM +1000,
 Mark Andrews <[email-masked]> wrote 

> 	No sane TLD operator can expect "http://tld" or "user@tld"

[Mark, you used non-RFC2606 names, the IESG will put a DISCUSS against
you.]

I agree but it is not the point: an email adress like
[email-masked] is legal and works but not reliably (there are
many stupid broken Web forms which refuse it and tell me it's not
valid).

http://example is legal and should work. If it does not, it may
indicate a broken implementation.

>       I suspect there are still mail configuations

There are many broken mail configurations.

> 	records SHOULD NOT be added to the apex of a TLD zone?

No. A TLD is a domain like any other and we should not write special
rules for them.

> 	hostnames/mail domains SHOULD NOT be looked up "as is" in

I hate special cases.

---

From: SM <[email-masked]>
Date: Thu, 03 Jul 2008 02:16:31 -0700

Hi Mark,
>         The key word word is "reliably".  http://museum/ can never

I saw the key word and I agree with you.  Someone out there thought 
that it was a good idea or else we wouldn't be discussing about 
this.  Your technical arguments are sound but they are unfortunately 
being overridden by other considerations.

There are currently 22 TLDs with MX records, 16 TLDs with address 
records and 11 TLDs with wildcards.

   "The notion that different domains would be run in different ways --albeit
    within the broad contexts of "public service on behalf of the
    Internet community" and "trustee... for the global Internet
    community"-- was considered a design feature and a safeguard against
    a variety of potential abuses.  Obviously the world has changed in
    many ways" (since then) ...

Regards,
-sm

---

From: Mark Andrews <[email-masked]>
Date: Thu, 03 Jul 2008 21:21:52 +1000

> indicate a broken implementation.

	But where should it resolve to?  "example.example.net."
	or  "example."?  Under what circumstances?

> No. A TLD is a domain like any other and we should not write special

	Names with and without dots already have different semantics.
	
> > 	hostnames/mail domains SHOULD NOT be looked up "as is" in

	TLDs are already a special cases in so many ways.

	Mark

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 01:21:31 +0200

Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 01:59:14 +0200

Frank

---

From: "James Seng" <[email-masked]>
Date: Thu, 3 Jul 2008 08:29:40 +0800

> Is "сом" identical to "com"? (the first of these is U+0441

The current principle is that it should be be a "confusing string",
which is vague enough to cover the case above (but perhaps not able to
cover .co)

> hope that ICANN has considered that case in full details.

This is where we dive into a discussion what is a "character". In
ideographic based language, there isnt a concept of a "word".

For example, Chinese, Japanese and Korean are actually "phonetics
language", and that ideograph characters are used to express the
phonetics. A "word" or more accurately "morphemes" can be express in a
single or more ideographs. A single latin character is unlikely to be
useful by itself (except of a and i) but thats not the case in CJK.

If the condition is that "no single ASCII character", I may be neutral
about it (since a single ideograph would never translate to a single
ASCII character in the zonefile, due to the xn-- prefix) but if the
"character" is defined more broadly to cover "U-label" character, then
I would have strong objections.

Incidentally, I remember it is a standing "tradition" that labels may
not be a single ascii character. But is there any technical reason we
should forbid it? (e.g. 6.cn have not kill any kittens yet)

-James Seng

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jul 2008 03:00:18 +0200

James Seng wrote:

> if the "character" is defined more broadly to cover "U-label"
> character, then I would have strong objections.

+1  And fortunately it's not our job to figure out what a term
like "IDN ccTLD" actually means, where that might be important.

> I remember it is a standing "tradition" that labels may not 
> be a single ascii character.

IIRC "SC SLDs" were recently permitted.  In this acronym soup
that's "single character second-level domains" affecting TLDs
with a contract not permitting such beasts.  ASCII characters,
[0-9A-Za-z].

No TLD is forced to adopt this idea, and many TLDs have their
own rules.

> But is there any technical reason we should forbid it? (e.g.
> 6.cn have not kill any kittens yet)

It is certainly an obstacle for *simple* definitions of what
constitutes "confusingly similar" or "typo resistent".  But I
guess there is no *simple* definition also covering typos in
IDN A-labels, so maybe that point is moot.

Unrelated:  The "2606" thread on the general list so far was
about many interesting topics, notably about <toplabel>s, but
not about the 2606bis draft.  

For the 3920bis-06 draft I sent this comment to the author:

> You claim to import <idnlabel> from RFC 3490, but there is
> no <idnlabel> in RFC 3490.  Besides you don't want only
> "xn--" labels, you want <ldh-label> not limited to "xn--".
 
> How about this, based on latest RFC 1123 toplabel erratum:
 
> | domain   = fqdn / address-literal
> | fqdn     = *(ldhlabel ".") toplabel
> | ldhlabel = letdig [*61(ldh) letdig]
> | toplabel = ALPHA   *61(ldh) letdig
> | letdig   = ALPHA / DIGIT
> | ldh      = ALPHA / DIGIT / "-"

 Frank

---

From: "James Seng" <[email-masked]>
Date: Fri, 4 Jul 2008 06:14:41 +0800

> At the moment, the condition is "no single Unicode code point." To
> the extent that a single CJK ideograph can be expressed using a
> single Unicode code point, this would represent the situation to
> which you say you would object. I will dig through my notes to find
> out why the "single character" condition was adopted -

Would you be able to explain why the condition is "no single Unicode
code point"? Whats the technical basis for that?

-James Seng

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 3 Jul 2008 15:26:45 -0700

Lyman said: 
 
> I'm familiar with <draft-klensin-rfc2821bis-10.txt> and understand > the importance of using only FQDNs in SMTP exchanges given that "[i]n > the case of a top-level domain used by itself in an email address, a > single string is used without any dots." What I'm interested in is > any reason to proscribe the use of a TLD as a single label hostname > (particularly for email addresses) other than the fact that there is > software out there that will interpret it incorrectly -
Potential problems with global use of single-label names go beyond SMTP.  
For example,  RFC 4282, which defines the Network Access Identifier 
(NAI), does not permit the use of single-label names. From Section 2.1: 
 
   realm       =  1*( label "." ) label
 
As a result, someone purchasing the "example" TLD and using the NAI
bob@example in order to obtain access to the network, might well 
discover that this would not work.

---

From: "James Seng" <[email-masked]>
Date: Fri, 4 Jul 2008 06:31:08 +0800

RFC 4282 defined

   label       =  let-dig *(ldh-str)

which means a single-label Unicode string would be absolutely fine
since it translate to xn--gibberish. A shorter gibberish of cos, but
still longer than a single character.

-James Seng

---

From: "James Seng" <[email-masked]>
Date: Fri, 4 Jul 2008 06:32:11 +0800

Oops, ignore my email :P My reading comprehension is bad in the morning.

-James Seng

---

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Jul 2008 09:14:34 +1000

> mentioned in RFC 3696.  Recently *overruled* by 2821bis.

	There is a difference between allowing protocol to be used
	in a "local" only mode (single label) and a "global" mode
	(multi-label) and saying you must support single label in
	a global context.

	Single label names are local in scope.  Attempting to use
	them in a global context does not work.  As the names in
	"." get more interesting the probability of collisions with
	existing names goes up.  Not many people choose two letter
	labels for the least significant parts of their host names
	unless they are choosing their initials.

	Museum on the other hand is a real English word.  I'm sure
	you will find lots other uses of "museum" in the DNS.  The
	same thing will happen with other TLD's as the rules are
	relaxed.

	Single label hostnames are not globally unique.  They SHOULD
	NOT be used in a context where globally unique names are
	required.

	Mark

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jul 2008 12:51:44 -0400

> 	NOT be used in a context where globally unique names are

Mark,

With the understanding that I agree with everything you say
above, there are some interesting problems with SMTP (and maybe
some other protocols) as well as with how ICANN is proceeding.
In no particular order...

(1) ICANN is well aware of the problem you mention with "museum"
and presumably with "coop", "jobs", "name", and maybe some
others I've forgotten at the moment.  As I understand it, they
have explicitly decided to ignore that problem except for names
of countries.  The problem also gets orders of magnitude worse
as we move to IDNs, especially it we also consider
transliterations of non-ASCII strings into scripts other than
the those to which the relevant word is native (whatever that
means -- the concept is extremely dubious for some languages).   

Whether the decision to enable the searching risks associated
with the use of names, rather than short mnemonics of
pre-specified length, is the result of realizing that the
problem is hopelessly intractable (it is) or the result of
rampant commercialism is probably in the eye of the beholder.

(2) Regardless of what some of us may think about the
desirability (or not) of associating services with TLD names, as
soon as we accept the idea that top-level domain names have
semantic content and are associated with fields of endeavor,
types of organizations or enterprises, etc., the desire to
associate, e.g., directory services or "help" functions with the
TLD follows almost naturally.   For years, we managed to dodge
that problem with conventional subdomains (e.g., nic.example.),
but we have not, to my knowledge, ever promoted those uses via,
e.g., a BCP that strongly recommends them (unlike the email
case, where RFC2142 does just that).

In the absence of reserved-name recommendations strong enough to
substitute for services associated with TLDs (and the horse has
probably let the barn on doing that), I think it is inevitable
that we will see more and more demand for the functionality
implied by

   some-protocol://TLD-name./

(with or without that trailing dot).   Some sort of directory
service for the domain is the obvious case, but there are
others.  I can think of only three ways to get that
functionality:

	(i) Associate services with the TLD in the DNS.
	
	(ii) Install a TLD wildcard that points to the relevant
	services (and pray that it doesn't point to anything
	else)
	
	(iii) Reserve conventional subdomain names so that an
	application can turn "some-protocol://TLD-name/" into,
	e.g., 
	  some-protocol://some-protocol.TLD-name/

But, as discussed above, I believe we have waited much too long
to do anything effective about the third possibility.  And
simply saying "this is a bad way to use the DNS" is clearly not
going to get us anywhere in the current environment, even if it
were true.

(3)  SMTP does not permit an explicit trailing period in
addresses on the wire, so 
    RCPT TO:<somemailbox@example.>
is a syntax error.   RFC 2821 permitted it (as Frank points
out), unlike RFC 821 (which, I think, predated the discovery
that being able to explicitly specify the root was sometimes
important).  Discussion about 2821bis concluded that permitting
the trailing period caused more problems than it solved, so we
are back to not permitting it.   What 2821bis says in essence is
that it is the responsibility of the sending application to
figure out whether, if a user presents "somemailbox@example",
that implies the "example" TLD or an invitation to start
searching.  The application is expected to provide local syntax
when necessary to assist in making that distinction.

So, much as I'd like it if we could say "Single label names are
local in scope...does not work", I fear that it is unrealistic
in practice unless we can somehow turn the clock back 15 years
or so.  If one even wanted to try to do that, the first step
would be to write that BCP that recommended a set of
role-specific second-level names.   Changes to the 2606 list are
irrelevant to that goal.

    john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Jul 2008 10:19:45 -0700

> 	(multi-label) and saying you must support single label in

If a protocol is used in a global mode, the problem with trying to use it in a 
tailored, local mode is that the various defaults of the local context are not 
carried with the data that escapes into the global context.

There must be perfect gatewaying between the two contexts and this almost never 
achieved.

d/

-- 

   Dave Crocker

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jul 2008 10:49:50 -0700

> above, there are some interesting problems....

Referring to the point Mark is making as a "problem" is a bit like
saying that someone attempting to sell the Brooklyn Bridge has
a "problem".  While the potential bridge purchaser may in fact very
much desire to own the bridge, the "problem" is that the seller may
not in fact have the right to sell it. 

That's really at the core of what Mark is arguing -- that various
RFCs allocate single-label names for local use, and therefore that
ICANN may not possess the right to sell that property
to another party. 

> (1) ICANN is well aware of the problem you mention....
> As I understand it, they have explicitly decided to ignore that problem...

Someone attempting to sell the Brooklyn Bridge can also explicitly
decide to ignore the "problem" of whether they in fact own it. 
That won't make the "problem" go away. 

In this particular case, we are talking about RFCs that are included
as requirements for purchase worth billions of dollars annually, as
well as local names currently in local use by hundreds of millions of
people. So we're not talking about selling a single Brooklyn Bridge
here, but many. 
 
> desirability (or not) of associating services with TLD names

The issue is not "desirability".  Someone might very much "desire"
to purchase the Brooklyn Bridge.  It has many excellent qualities -- it is
used by many people over the course of a day, it is a registered historical
site making it of great interest to tourists, etc.   The "problem" is whether the
seller can establish title. 
  
> local in scope...does not work"

Mark's point is that several RFCs already say this.  So what we have
here isn't really an technical argument or one about "desirability" -- it's
a property rights argument. 
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jul 2008 13:50:01 -0400

Vint,

In the ASCII space, there have been three explanations offered
historically for the one-character prohibition on top and
second-level domains.   I've written variations on this note
several times, so will just try to summarize here.  Of the
three, the first of these is at best of only historical interest
and may be apocryphal and the second is almost certainly no
longer relevant.  The third remains significant.

(1) Jon has been quoted as suggesting that we could have
eliminated many of the problems we now face with TLDs and
simultaneously made the "no real semantics in TLD names" rule
much more clear had we initially allocated "b".."y" as TLDs.
Then, when someone asked for an assignment, it would have been
allocated at random to one of those domains.  While this has a
certain amount of appeal, at least in retrospect, there is
probably no way to get from where we are today to that model...
unless actions taken in the near future so ruin the current DNS
tree as a locus for stable and predictable references that we
need to start over with a new tree.  I don't think that a "have
to start over" scenario is at all likely, but I no long believe
it to be impossible.

(2) There was an idea floating around for a while that, if some
of the popular TLDs "filled up", one could create single-letter
subdomains and push subsequent registrations down the tree a
bit.  For example, if .COM were declared "full", then "a.com",
"b.com", etc., would be allocated and additional reservations
pushed into subdomains of those intermediate domains rather than
being registered at the second level.  Until and unless the
conventional wisdom that adding more names to .COM merely
requires more hardware  and/or bandwidth, that won't be a
"filled up" point at which this sort of strategy could be
triggered.  Worse, trying to use single-letter subdomains as an
expansion mechanism would raise political issues about putting
latecomers at an advantage that would be, IMO, sufficient to
completely kill the idea.  In the current climate, I think the
community would decide that it preferred a disfunctional DNS if
that were ever the choice (see the "start over" remark above).

(3) At least in the discussions that led up to RFC 1591, and
probably much earlier, there were concerns about reducing the
likelihood of false hits if the end user made single-character
typing errors.  With only 26 (or maybe 36) possible characters,
it could just about be guaranteed that all of them would be
registered and that _any_ typing error would yield a false
match.  That, in itself, has been considered sufficient to
prohibit single-letter labels and, by extension, to be fairly
careful about two-letter ones.   There have been arguments on
and off over the years as to whether this is a "technical"
reason or an attempt to set policy.  Even though the mismatches
would obviously not cause the network to explode or IP to stop
working, at least some of us consider the informational
retrieval and information theoretic reasons to insist on more
information in domain name labels in order to lower the risk of
false positive matches to be fully as "technical" as something
that would have obvious lower-level network consequences.
Others --frankly especially those who see commercial advantage
in getting single-letter names-- have argued that this position
is just a policy decision in disguise.

Note that, with slight modifications, the second and third
arguments apply equally well to TLD allocations and to SLD
allocations, especially in popular domains.  

The reasoning associated with the third case also applies to any
other script that contains a fairly small number of characters.
One could manage a long philosophical discussion as to whether
there are sufficient characters in the fully-decorated
Latin-derived collection to eliminate the problem, but an
analysis of keyboard and typing techniques/ input methods for
that range of characters would, IMO, yield the same answer --
single-letter domains are just not a good idea and two-letter
ones near the top of the tree should be used only with great
caution.   

On the other hand, the same reasoning would break down when
confronted with a script that contains thousands of characters,
such as the "ideographic" ones.  There are enough characters
available in those scripts that one can presumably not worry
about single-character typing errors (and one can perhaps worry
even less if the usual input methods involve typing
phonetically, using a different script, and then selecting the
relevant characters from a menu -- in those cases, the phonetic
representations are typically more than a character or two long
and the menu selection provides an extra check about false
matches).

     john

--On Thursday, 03 July, 2008 19:04 -0400 Vint Cerf
<[email-masked]> wrote:

> seems odd to me too, James.
> 
> vint
> 
> 
> On Jul 3, 2008, at 6:14 PM, James Seng wrote:
> 
>>> At the moment, the condition is "no single Unicode code
>>> point." To the extent that a single CJK ideograph can be
>>> expressed using a single Unicode code point, this would
>>> represent the situation to which you say you would object. I
>>> will dig through my notes to find out why the "single
>>> character" condition was adopted -
>> 
>> Would you be able to explain why the condition is "no single
>> Unicode code point"? Whats the technical basis for that?

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jul 2008 14:35:41 -0400

--On Friday, 04 July, 2008 10:49 -0700 Bernard Aboba
<[email-masked]> wrote:

> Referring to the point Mark is making as a "problem" is a bit
> like saying that someone attempting to sell the Brooklyn
> Bridge has a "problem".  While the potential bridge purchaser
> may in fact very much desire to own the bridge, the "problem"
> is that the seller may not in fact have the right to sell it. 
> 
> That's really at the core of what Mark is arguing -- that
> various RFCs allocate single-label names for local use, and
> therefore that ICANN may not possess the right to sell that
> property to another party. 
> 
> Someone attempting to sell the Brooklyn Bridge can also
> explicitly decide to ignore the "problem" of whether they in
> fact own it.  That won't make the "problem" go away. 
> 
> In this particular case, we are talking about RFCs that are
> included as requirements for purchase worth billions of
> dollars annually, as well as local names currently in local
> use by hundreds of millions of people. So we're not talking
> about selling a single Brooklyn Bridge here, but many. 
>  
> The issue is not "desirability".  Someone might very much
> "desire" to purchase the Brooklyn Bridge.  It has many
> excellent qualities -- it is used by many people over the
> course of a day, it is a registered historical site making it
> of great interest to tourists, etc.   The "problem" is whether
> the seller can establish title. 
>   
>> So, much as I'd like it if we could say "Single label names
>> are local in scope...does not work"
> 
> Mark's point is that several RFCs already say this.  So what
> we have here isn't really an technical argument or one about
> "desirability" -- it's a property rights argument. 

Not really.  ICANN isn't "selling" single-label domains.  They
are selling (and I believe "selling" is probably now the correct
term) plain, ordinary, TLD delegations.  If I get one of those
and populate the TLD zone only with delegation records, there
are no problems with what ICANN has done at all, whether you
describe it a property rights or in some other way.  On the
other hand, if they delegate one and the enterprise that buys it
chooses to populate the zone with service records, then ICANN's
position will certainly be that any inability to use those
service records isn't ICANN's problem -- any more than
difficulties using .museum or .aero were ICANN's problem when
those to whom those domains were delegated discovered that a lot
of applications software thought that the one TLD label of more
than three characters was "ARPA".

So the "problem" isn't whether some string not listed in 2606
can be allocated, it is how it is used after it is allocated.
And _that_ situation has a lot more to do about "buyer beware"
and understanding of conflicting expectations about use than it
does about ownership. 

    john

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 4 Jul 2008 13:52:09 -0700

> describe it as a property right or in some other way.  

Agreed. 

> On the other hand, if they delegate one and the enterprise that buys it

Is generic "buyer beware" disclaimer really sufficient here? 
The problem isn't just "inability to use" -- it's that other parties exist 
who may claim the usage right, and provide citations to RFCs to back up their claim.

For example, typing http://brooklynbridgepark/ into a browser utilizing
a resolver compliant with RFC 1536 will bring you to the web site of 
Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist.

If ICANN sells the brooklynbridgepark TLD delegation to another party who populates
the zone with service records,  should that party expect that http://brooklynbridgepark/  
will now resolve to their site?  RFC 1536 says "no".  

Similar problems will occur when the party purchasing the brooklynbridgepark TLD 
attempts to use the single-label name "brooklynbridgepark" for other uses, such as
network access. 

> and understanding of conflicting expectations about use than it

Today there is a distinction between types of property rights - surface, subsurface,
or rights to the air above a property.  As noted at http://geology.com/articles/mineral-rights.shtml 
this was not always the case: 

      If we go back in time to the days before drilling and  mining, real estate transactions 
      were fee simple transfers.  However, 
once  subsurface mineral production became 
      possible, the ways in which people own property became much more complex.

If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then
we could be talking about a "fee simple" transfer in a situation where sub-rights may 
be claimed to belong to someone else.

---

From: John Levine <[email-masked]>
Date: 4 Jul 2008 21:13:51 -0000

>Is generic "buyer beware" disclaimer really sufficient here? 

The cost to get a domain from ICANN under the new rules is estimated
to be about $100,000.  Don't you think we can assume that people who
are laying out that kind of money are big boys and girls who will do
adequate due diligence?

>The problem isn't just "inability to use" -- it's that other parties
>exist who may claim the usage right, and provide citations to RFCs to
>back up their claim.

There are several ICANN documents describing the new process that
include a set of recommendations to guide the process.  You must have
read them, since you are concerned about this proposal.  Do you think
that recommendations 3, 4, and 20 are adequate to address this
problem?  If not, why not?

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Fri, 04 Jul 2008 14:52:24 -0700

> problem?  If not, why not?

John, et al,

While I think it entirely appropriate to check whether any of us has a clue 
about what ICANN is actually doing, I do suggest that reference to a document 
warrants providing a specific citation, particularly when there are so many 
possible choices at the ICANN cite.

I'm guessing you mean:

<http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm#_Toc43798015>

and specifically the Recommendations table.

If so...

No. 3 is about legal infringement.  That seems wholly irrelevant to the scope of 
IETF work, although I agree that the ietf list thread has started using language 
that sounds related.

No. 4 says "Strings must not cause any technical instability." which sounds 
exactly within IETF scope covers the gist of the technical aspects of the ietf 
list discussion.

No. 20 seems to have to do with failing a popularity contest.  Probably a good 
escape clause to include, but not all that relevant to our I discussion... I hope.

Let me stress that I do think language like "claim the usage right" makes No. 3 
sound appropriate, but that the scope of IETF RFCs is technical specifications, 
rather than "rights".  While yes, one can say that reserving a name or 
proscribing against the use of a name -- such as a single, top-level label as a 
standalone name -- can be interpreting as declaring a "right", I suggest that an 
IETF discussion will fare much better by focusing on the technical issues that 
lead to the constraints, rather than attempting a quasi-pseudo-meta-legal 
discussion.

Simply put:  If an IETF specification has gone through the IETF consensus 
process and been approved, the requirements and constraints imposed are almost 
by definition technical requirements.

Violating one of them invites instability, if only because it invites variable 
implementations.  At the least, treating such constraints as subject to creative 
interpretation by another body renders all output of the IETF fluid.

And just to press this to a logical conclusion, albeit not one that seems to be 
at issue... yet:  If ICANN believes that the IETF has issued a problematic 
specification, then ICANN needs to ask the IETF to fix it, rather than to have 
ICANN, or anyone else, issue a modification/clarification.

d/

-- 

   Dave Crocker

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Jul 2008 08:34:53 +1000

> and understanding of conflicting expectations about use than it

	I really wish it was *just* "buyer beware".  If http://museum/
	only works for some clients and not other then there really
	isn't a problem.  By "works" here I mean connects to
	83.145.59.103 or nowhere.

	The problem is that it isn't just "buyer beware".  If the
	buyer adds any records are looked up by search mechanisms
	as a part on normal application activity, A, AAAA and MX
	are simple examples, then *ALL* the users of the Internet
	need to be aware that they are there.

	This is a security problem, not a buyer beware problem.

	This is a namespace clash and namespace clashes are bad for
	many reasons.

	Now as far as I can see there are two solutions which attack
	the problem from different ends.

	1. ban the adding of any records which meet the above criteria.
	2. rewrite resolvers to not lookup single labels against the
	   root.

	Note banning would have to be described is a manner that
	didn't preclude the negative advertisement of a service.
	It would also have to be writen to exclude records that a
	looked up with a prefix added.

	Also what is the penalty for adding banned records?

	Mark

; <<>> DiG 9.3.4-P1 <<>> museum
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61108
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0

;; QUESTION SECTION:
;museum.				IN	A

;; ANSWER SECTION:
museum.			86034	IN	A	83.145.59.103

;; AUTHORITY SECTION:
museum.			22099	IN	NS	ns-ext.vix.com.
museum.			22099	IN	NS	ns1.getty.edu.
museum.			22099	IN	NS	nic.icom.org.
museum.			22099	IN	NS	ns.icann.org.
museum.			22099	IN	NS	nic.museum.

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul  5 08:22:30 2008
;; MSG SIZE  rcvd: 162

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Jul 2008 08:42:37 +1000

> exactly within IETF scope covers the gist of the technical aspects of the iet

	We need "cannot be used in a manner that causes technical
	instablitity.  Known causes include, but are not limited
	to, adding A, AAAA and MX records at the zone apex."

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Jul 2008 19:49:32 -0400

Bernard,

I'm going to try to respond to both your note and Mark's, using
yours as a base because it better reflects my perspective.

Before I go on, I think the three of us are in agreement about
the situation.  The question is what can (or should) be done
about it.

--On Friday, 04 July, 2008 13:52 -0700 Bernard Aboba
<[email-masked]> wrote:

>> are selling (and I believe "selling" is probably now the
>> correct term) plain, ordinary, TLD delegations.  If I get one
>> of those and populate the TLD zone only with delegation
>> records, there are no problems with what ICANN has done at
>> all, whether you describe it as a property right or in some
>> other way.  
> 
> Agreed. 
> 
>> On the other hand, if they delegate one and the enterprise
>> that buys it chooses to populate the zone with service
>> records, then ICANN's position will certainly be that any
>> inability to use those service records isn't ICANN's problem
>> -- any more than difficulties using .museum or .aero were
>> ICANN's problem when those to whom those domains were
>> delegated discovered that a lot of applications software
>> thought that the one TLD label of more than three characters
>> was "ARPA".
> 
> The problem isn't just "inability to use" -- it's that other
> parties exist  who may claim the usage right, and provide
> citations to RFCs to back up their claim.
> 
> For example, typing http://brooklynbridgepark/ into a browser
> utilizing a resolver compliant with RFC 1536 will bring you to
> the web site of  Brooklyn Bridge Park Conservancy, assuming
> that .org is in your searchlist.

We agree so far, but let me note that 1536 is an informational
document.  We generally don't claim that systems are expected to
be compliant with those.
 
> If ICANN sells the brooklynbridgepark TLD delegation to
> another party who populates the zone with service records,
> should that party expect that http://brooklynbridgepark/  
> Similar problems will occur when the party purchasing the
> brooklynbridgepark TLD  attempts to use the single-label name
> "brooklynbridgepark" for other uses, such as network access.

Yes.  And what I fear is that some applications and
implementations will support services on "brooklynbridgepark" as
a TLD and others will start searching.   Yes, that goes well
beyond "buyer beware".

>> and understanding of conflicting expectations about use than
>> it does about ownership. 
> 
> Today there is a distinction between types of property rights
> - surface, subsurface, or rights to the air above a property.
> As noted at http://geology.com/articles/mineral-rights.shtml 
>       If we go back in time to the days before drilling and
> mining, real estate transactions were fee simple
> transfers.  However, once  subsurface mineral production
became 
> possible, the ways in which people own property became

Sure.  But I know who to call --title insurance companies,
lawyers, judges, etc.-- when your mineral rights intrude on my
surface building rights or vice versa.

> If the analogy holds (and I'm not a lawyer, so I have no idea
> if it does), then we could be talking about a "fee simple"
> transfer in a situation where sub-rights may  be claimed to
> belong to someone else.  

But this gets back exactly to both the rude comments I've been
making about ICANN and the example I tried to construct (not
carefully enough) about a Microsoft TLD.

Let's take the second one first.  Suppose that Microsoft, at a
high corporate level, decided that they wanted to have a TLD
called "microsoft" and that they wanted to attach services to
it.  You would advise against that.  I would advise against
that.  So would others.  We would cite 1535, a number of other
RFCs, and general bad taste.  My assumption is that Microsoft
would give it up -- even if they wanted the domain, they
wouldn't expect to locate services at the top level.  But
suppose some marketing force took over and overwhelmed those
arguments.  The thing that makes Microsoft relevant to this
example is that the company distributes a very popular browser
and a couple of very popular email clients.  Were a corporate
decision to be made to support services on a TLD, at least
services on that one special-case TLD, than that decision could
extend to modifications to those application programs that would
permit access to those services.  

Again, I don't expect that to happen, but it carries over
directly into the main point I'm trying to make, which is that
"property rights" are a relevant metaphor for this situation
only if there is some basis or authority for enforcing those
rights.  As I've pointed out in other contexts recently, the
last few times I've tried to call the Protocol Police, they
didn't answer.

Ultimately, I'm concerned about what the IETF can usefully do
about this situation.   I'm fairly depressed about that because
there is little evidence that ICANN is seeking out in-depth
technical advice and acting on it.  Certainly this set of issues
are not reflected in the list Lyman circulated (and which John
Leslie recently cited in a different form).   If I were actively
involved with the Brooklyn Bridge Park Conservancy and I noticed
that ICANN was considering allocating "brooklynbridgepark" as a
TLD, I would protest and offer to sue ICANN on the grounds that
attempts to use that domain would interfere with the quiet
enjoyment of brooklynbridgepark.org by my members and visitors,
but I don't think we can depend on that in the general case.

I think we could do the following, but given the track ICANN
seems to be on and the rate at which they seem to be trying to
speed down that track, we had better do them soon:

(1)  Get RFC 1536, probably RFC 1535, any pieces of 1591 we
still care about, and perhaps some other documents promoted from
Informational to BCP (or generate revisions/ updates to them and
publish those at BCP).

(2) Generate a good "use of these sorts of names would really be
a bad idea" document and move it into BCP.  Note that this
document is very different from reserving more names for IETF,
documentation, or similar uses in some form of 2606bis (see the
postscript below).

(3) Review BCP17/RFC2219, be sure that we still believe it (I
see several names that are not on the list in Section 3 of that
document that probably should be), update it as needed, and then
call ICANN's attention to that list and suggest that its entries
be added to their prohibited lists for TLDs.

(4) Tell ICANN that a condition of safe allocation of a large
collection of new TLDs is that they require, as a contractual
matter, that the holders of any new delegations explicitly agree
to not install anything but delegation and glue records in their
TLD zones and to caution people against trying to use glue
records to support services (or whatever rule is actually
correct -- I'm not sure that is it).   Whether they would do
that or not might be an interesting test of how much they are
really concerned about the continued usability and
predictability of the DNS.

regards,
     john

p.s. I started on a "bad idea to use these names, or use them in
these ways" document fairly early in these discussions, before
they went off in directions I could not have predicted.  I have
neither the time nor the resources to finish it and especially
not to try to steer it through dnsops and the Applications Area.
But, if anyone else is contemplating doing such a document and
would like a partially-completed version with the needed
references, etc., filled in as a starting point, I'd be happy to
send what I have along.

---

From: JFC Morfin <[email-masked]>
Date: Sat, 05 Jul 2008 02:44:34 +0200

I feel that Edmon's report of the ICANN/GNSO point of view and the 
positions of James Seng are shared by most of the groups we relate 
with (Internet @large, open roots, ISO lobbies, Multilinc, MINC, 
Eurolinc, ISOC France, ccTLDs, etc.). If this WG does not think they 
are technically adequate there would certainly be a real urgency to 
document why, to have it confirmed by the IAB, and disseminated. This 
is due to the constraints a change would introduce outside of the 
Internet community and the général awareness of this debate after the 
Paris meeting. This WG needs to speak up now, or status quo will be 
considered as definitly settled.

I expect one single sign (logo) gcTLDs [geocultural] to be documented 
this year for multilingual information machines (airports, 
transports, health, kids, disabled). BTW this is also why I would 
recommend to refer to the semiotic rather than to the semantic aspects.
jfc

At 01:33 05/07/2008, Edmon Chung wrote:
>Regarding single Unicode code-point labels at the TLD level, there was quite
>some discussion on this topic at the GNSO Reserved Names working group and
>then at the new gTLD discussion.  The final recommendation from the GNSO
>was:
>
>"Single and two-character U-labels on the top level and second level of a
>domain name should not be restricted in general. At the top level, requested
>strings should be analyzed on a case-by-case basis in the new gTLD process
>depending on the script and language used in order to determine whether the
>string should be granted for allocation in the DNS. Single and two character
>labels at the second level and the third level if applicable should be
>available for registration, provided they are consistent with the IDN
>Guidelines."
>
>As for ASCII, the recommendation was:
>"We recommend reservation of single letters at the top level based on
>technical questions raised. If sufficient research at a later date
>demonstrates that the technical issues and concerns are addressed, the topic
>of releasing reservation status can be reconsidered."
>
>Edmon

---

From: Karl Auerbach <[email-masked]>
Date: Fri, 04 Jul 2008 19:10:04 -0700

> yours as a base because it better reflects my perspective.

I sense that many of your concerns are well grounded.  And I find it 
interesting that the concerns come not so much from DNS as a system and 
protocol in and of itself but rather from the practices that have 
developed in the ways that DNS is used.

I see that you consider this situation urgent.

But I think that even your sense of urgency may underestimate the 
exigency of the need to coming up with an answer that can be labeled as 
a standard or BCP.

It is my feeling that pretty much every company in the Fortune 1,000,000 
is going to want to go for their name as a TLD.  And the marketing 
people at those companies will exert strong internal pressures to have 
every service - from web to email to SIP to whatever - using only the 
single TLD/company name.

As for contracts - ICANN should, if it is not doing so aready, clearly 
articulate a requirement that TLD operators clearly agree to follow 
written and broadly practiced internet technical standards that pertain 
to DNS.  (I've gone further and suggest that this ought to be ICANN's 
sole criterion for accepting [which does not mean granting] an 
application for a new TLD, but that's another discussion for another day.)

But contracts only go so far.  First of all there is the issue of the 
ccTLDs - they tend to operate outside of the ICANN contractual hierarchy.

Then there is the issue of enforceability of contract provisions.  ICANN 
seems to have an institutional fear of something called "third party 
beneficiary" status.  This is a thing that a contract can grant to 
certain non-parties so that those parties can step in and demand that 
certain contract terms be enforced against one or both of the parties 
even if the parties themselves are not holding one another to account.

In other words, unless the contracts give these rights, the IETF and 
others might have to stand on the sidelines and able to do no more than 
gnash their teeth in frustration.

ICANN has not demonstrated that it is quick to take up its sword to 
enforce its contractual rights when users are being harmed - For 
instance it kinda took dynamite to get ICANN to notice, much less to 
react to the developing RegistryFly mess.

Also you mentioned that the Brooklyn Bridge park folks might want to sue 
ICANN rather than the people who register "brooklynbridgepark" as a TLD. 
  My sense is that this might be a poor strategy because ICANN might be 
able to excuse itself as merely acting as a bookeeper and recommending 
that you sue the people who registered the TLD once they show, through 
actual use, that you have suffered some concrete harm.  Also, ICANN 
operates with a somewhat uncertain shield that exists because ICANN is 
able to operate in that vague middle ground between being a private 
entity and an arm of the US government.  (It is this same uncertainty 
that may explain why ICANN has so far avoided squarely facing the 
restraint of trade question in the US or elsewhere.)

Also, you use the word "property".  That's a word so full of different 
meanings to different people in different places that it tends to cause 
more trouble than it is worth.  I might suggest that we look at this 
situation as one in which the various actors have various explicit 
rights (contractual or otherwise) and duties towards certain domain 
names.  That way we can deal with these things with clarity rather than 
getting buried under the emotional baggage that comes from the word 
"property".

With regard to that final point about requiring only delegation and glue 
records - what about things like LOC and some of the TXT and other 
records for things like DKIM, SPF, SIP, etc?  My point here is that this 
might not be as simple to define as we might initially think.

But the boiler in ICANN's locomotive is coming up to pressure and we can 
expect ICANN's new TLD train to start chugging fairly soon - so answers 
may be needed more at IETF 1988 speed rather than IETF 2008 speed.

		--karl--

---

From: John Levine <[email-masked]>
Date: Fri, 4 Jul 2008 22:43:49 -0400 (EDT)

>> No. 4 says "Strings must not cause any technical instability." which 
>> sounds exactly within IETF scope covers the gist of the technical 
>> aspects of the ietf list discussion.

> 	to, adding A, AAAA and MX records at the zone apex."

As someone else pointed out, there are currently about two dozen TLDs with 
A or MX records at the apex.  Some of them have been like that for many 
years, and as best I can tell, the Internet has not thereby collapsed.

I think we all understand that the use of addresses like http://tld/ and 
foo@tld may be flaky due to bugs in client software, but if someone wants 
to spend $100 grand on a TLD and install a flaky A or MX, why is that an 
urgent problem the IETF needs to solve rather than a private issue between 
the TLD and its registrants?

Also keep in mind that most of those apex records are in ccTLDs over which 
ICANN and the IETF have no authority, so no matter what the we were to 
say, they're not going away.

Regards,

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Jul 2008 05:28:21 +0200

John Levine wrote:
 
> The cost to get a domain from ICANN under the new rules is 
> estimated to be about $100,000.  Don't you think we can assume
> that people who are laying out that kind of money are big boys
> and girls who will do adequate due diligence?

How could their money help them to find a case like "demon" ? 
<http://article.gmane.org/gmane.ietf.usenet.format/30504/match=demon>

 Frank

---

From: Mark Andrews <[email-masked]>
Date: Sat, 05 Jul 2008 15:00:13 +1000

> years, and as best I can tell, the Internet has not thereby collapsed.

	How many label our hosts with two letter domain names?

	Do you have any evidence that they have not caused problems?
	I suspect that other sites that used the names just put up
	with the pain of renamimg hosts along with the resultant
	risk of email being misdirected.

> the TLD and its registrants?

	This sentence indicates that you fail to understand all of the
	issues involved.

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 5 Jul 2008 10:01:43 +0200

John C Klensin wrote:

> For years, we managed to dodge that problem with conventional
> subdomains (e.g., nic.example.), but we have not, to my knowledge,
> ever promoted those uses via, e.g., a BCP that strongly recommends
> them (unlike the email case, where RFC2142 does just that).

I'd be happy if we can salvage abuse@ from the remains of RFC 2142,
anything else is IMO hopeless:  The netnews folks flat out refused
to get as much as an informative reference to RFC 2142 for the old
news@ / usenet@ / netnews@ mess.  

Compare <http://rfc-editor.org/errata_search.php?rfc=2142> (Caveat:
errata links on the IETF Tools server are unreliable at the moment,
reported bug)

IOW we can say that spam killed RFC 2142, and maybe indirectly an
IETF WG.  RFC 2142 was published before RFC 2277, today its lack of
I18N considerations is rather peculiar.  I don't see what RFC 2142
has to do with reserved TLDs for technical reasons.
 
> is a syntax error.   RFC 2821 permitted it

Nope, RFC 2821 *required* more than one label, but it didn't allow
a trailing dot.  2821bis stripped the requirement.  In other words
somemailbox@example *is* an RFC 2821 syntax error until the second
when 2821bis is approved, after that it's only a bad idea.  

"One dot required" (but no trailing dot) also made it in RFC 4871,
among others, so far for TLDs trying to use DKIM directly at their
root.  SPF cannot talk about TLDs, but TLDs can have SPF records.
TLDs starting a news server will coordinate their activities with
the UUCP world map project (this involves time travel).

> or so.

[...seven hours later you wrote...]

> let me note that 1536 is an informational document.  We generally
> don't claim that systems are expected to be compliant with those.

[ITYM s/1536/1535/g for those search lists (?)]
The complete concept of IDN TLDs including the running experiment
with the eleven IDN test TLDs, builds on an informational RFC 3696,
or on RFC 1123 errata, in a certain sense; often the status of an
RFC is unrelated to its importance.  

> Review BCP17/RFC2219, be sure that we still believe it

Not sure, it talks about WKS, it is apparently older than SRV, it
has no proper IANA registry; "archie", "finger", "gopher", "ph",
"rwhois", and "wais" are dead (but you can't say that in an RFC,
because some folks including me would whine wrt "gopher")

Apart from being odd names, what is wrong with a TLD ".abuse" or
a TLD ".archie" ?  TLD ".finger" could be funny for some Finnish-
German organization.  

 Frank

---

From: John Levine <[email-masked]>
Date: Sat, 5 Jul 2008 09:00:36 -0400 (EDT)

> 	How many label our hosts with two letter domain names?

Beats me, but since there are several hundred TLDs, it seems to me that 
the chances are pretty low that everyone in the world has managed to avoid 
using them as host names.

> 	Do you have any evidence that they have not caused problems?

Hey, you're the one claiming that there's a global disaster in progress of 
which nobody seems to be aware.  If there's evidence, tell us about it.

>        risk of email being misdirected.

Perhaps you could start by asking people at ai.mit.edu how long their mail 
has been unusable.

Look, we all know there's an unlimited number of ways one can screw up 
mail and web configuration.  If you put an underscore in the name of a web 
server, as often as not it sort of works even though it's flatly forbidden 
by RFCs.  Or if you put an @ or % character in the local part of your 
e-mail address, it'll fail all over the place even though the RFCs say 
that's fine.

Why is this particular configuration issue so uniquely awful that the IETF 
and ICANN need to tie themselves up in knots about it?  ICANN has plenty 
of real problems on its plate, like registrars who steal people's names 
and won't give them back.  This isn't one of them.

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Jul 2008 09:34:34 +1200

On 2008-07-06 01:00, John Levine wrote:
...

> the chances are pretty low that everyone in the world has managed to
> avoid using them as host names.

Back in the early days, when Czechoslovakia existed, and cs. was
active, I recall cs.ucl.ac.uk causing great difficulty. Of course, the
difficulty was due to email systems doing pragmatic things about
JANET formats, before MX records were in use. We also had great
difficulty, I remember, with uk.oracle.com.

...
> mail and web configuration.  

Right, so let's make that even *more* likely...

   Brian

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Jul 2008 19:38:24 -0400

Historical note...

--On Sunday, 06 July, 2008 09:34 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> Beats me, but since there are several hundred TLDs, it seems
>> to me that the chances are pretty low that everyone in the
>> world has managed to avoid using them as host names.
> 
> Back in the early days, when Czechoslovakia existed, and cs.
> was active, I recall cs.ucl.ac.uk causing great difficulty. Of
> course, the difficulty was due to email systems doing
> pragmatic things about JANET formats, before MX records were
> in use. We also had great difficulty, I remember, with
> uk.oracle.com.

Part of the problem in that case was that, because JANET used
little-endian names internally, the big-endian foo.ucl.ac.uk (in
DNS order) had to be be mapped into uk.ac.uck.foo (in JANET
order) and vice versa.  That mapping was trivial as long as one
could run a simplistic "whichever end the TLD was on had to be
the big side" test.  When "CS" was introduced, blew up that
simple test.  In the JANET case, it failed since there were
strings that could be TLDs at both ends of the string, i.e., in
principle, cs.ucl.ac.uk could have been a string that was
already in JANET order and that would appear in the DNS order as
uk.ac.ucl.cs.  While other heuristics could disambiguate that
one (as long as the Czech TLD didn't do deliberately
pathological things), uk.oracle.com illustrates a case in which
none of the heuristics worked -- the string was simply ambiguous
and one had to know, via out-of-band info, whether it was a
JANET or DNS name.

The introduction of "cs" caused more general problems, unrelated
to name ordering, because there were systems all over the
network in computer science departments with FQDNs like
host.cs.someuniversity.edu.  It was common in many of those
institutions to set up university-wide search rules so that a
reference to host.cs would do the right thing, just like
host.physics, host.philosophy, and so on.  When "CS" was
introduced as a TLD, "host.cs" suddenly became ambiguous (or at
least dependent on exactly how the search rules were set up) as
to whether it represented "host.cs." or
"host.cs.someuniversity.edu.".

And, that, if my memory is correct, was the beginning of our
understanding that search rules needed to be used with great
care, if at all, and that incomplete domain names should not be
sent on the wire as part of protocols.

Note that MX had little or nothing to do with any of this unless
MX records were probed as part of trying to disambiguate the
names.

As an aside, we are at some risk of reinventing the "can't quite
figure out which order the label of this domain name are in" as
we introduce IDNs that contain labels in right to left scripts.
Those who are interested in that issue should pay very careful
attention to the IRI spec and to draft-ietf-idnabis-bidi.

     john

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2008 10:30:18 +1000

> Perhaps you could start by asking people at ai.mit.edu how long their mail 

	The problem is that user@ai is not globally unique. 

	MIT users will have problems talk to user@ai when "ai" means
	Anguilla.  The is a current security issue.

	If / when MIT stop using ai.mit.edu, "user@ai" will not longer
	mean [email-masked].  This will mean that any configuration file
	that has "user@ai" will now, suddenly, get a different meaning.
	This is a latent security issue.

> e-mail address, it'll fail all over the place even though the RFCs say 

	I don't condone those actions.

	If I see someone using underscore in a hostname I tell them
	that they have made a error.

	As for the % hack.  That should only be processed by the
	machines handling the domain to the right of the @ sign.
	If I saw a machine mishandling it I would complain to the
	owner of the broken machine.

	Similarly if "foo@bar"@domain failed I'd complain to owner
	of the machine that is broken.
 
> and won't give them back.  This isn't one of them.

	This is worse.

	The owner of a domain name that has been stolen can go to
	the courts to get it back.  The have a remedy path outside
	of ICANN.

	This is a fundemental attack on the communication infrastruction
	of the Internet which is predicated on there being globally
	unique names.  It needs to be nipped in the bud before it
	gets too bad.

	Mark

---

From: John Levine <[email-masked]>
Date: Sun, 6 Jul 2008 22:12:53 -0400 (EDT)

> 	This is a latent security issue.

If by "latent" you mean "so obscure that in the ten years that there's 
been A and MX records at TLDs nobody's been affected" I guess I agree.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2008 12:25:50 +1000

> been A and MX records at TLDs nobody's been affected" I guess I agree.

	Again you are asserting that no one has ever been effected.

	By latent, I mean it will cause problems in the future when the
	conditions described are met.

	Not every action has a immediate consequence.  Some consequences
	can happen years after the initial action was taken.

	The consequences here are foreseeable but not necessarially
	obvious to everyone affected.

	Mark

---

From: John Levine <[email-masked]>
Date: Sun, 6 Jul 2008 23:21:27 -0400 (EDT)

> 	Again you are asserting that no one has ever been effected.

No, I'm saying that you can only cry wolf so many times.

The disaster you are predicting has in fact been in progress for over
a decade, and the mountains of casualties are nowhere to be found.

>        risk of email being misdirected.

There's at least one well known mail host whose name has matched a TLD 
with an MX for ten years now.  Did they rename?  Are they losing floods of 
mail to the Caribbean?  Uh, well, if they are, they're not telling anyone. 
How do we explain this conspiracy of silence?

Finally, as I presume you're aware, some browsers including Firefox retry 
with an appended .com if the address you type doesn't resolve, so if you 
type something like www.pets into your browser, it will find www.pets.com. 
This means that if ICANN creates new TLDs that match any of the 70 million 
existing .com domains, users of popular current software will suddenly 
find that they're not seeing the sites they used to see.  (We're not 
talking about records at the apex of a TLD here, it's www.blah.com vs. 
www.blah.)  Should all of the existing .com domain names be reserved as 
TLDs?  If not, why not?  It's the same problem, only it affects a lot more 
people.

R's,
John

PS to everyone else: I'll stop beating this dead horse now.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Jul 2008 14:37:27 +1000

> a decade, and the mountains of casualties are nowhere to be found.
 
	Just because there are no newspaper articles being published
	doesn't mean that there are not problems.  There will have
	been lots of little incidents over the years.  Each one
	will have been cleaned up quietly.

	e.g.
	    A .forward pointing to "user@host" where host has gone
	away but it also matches a tld with a A record.  In most
	cases the administator will just remove the .forward and
	not bother complaining that the mail was being mis-directed
	for a while.

> How do we explain this conspiracy of silence?

	Well if they wanted to email user@ai then yes.  It's a case
	of something has got to give.
 
> TLDs?  If not, why not?  It's the same problem, only it affects a lot more 

	Firefox's defaults are just plain wrong.  This has been
	pointed out multiple times by multiple people.  It's also
	easily addressable by the end user.

	Set browser.fixup.alternate.enabled to false in about:config.

	Two wrongs don't make a right.  They just make two things
	that need to be fixed.

	Mark

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 07 Jul 2008 15:03:06 +0200

Historical note...
    
To confirm this:

Being at one of the major connections to JANET (mcvax was connected to
Canterbury, which was the first gateway trying compensate for the JANET
order (uk.ac.foo) I vividly remember the day that loads of traffic was
forwarded to cs.vu.nl .

Since that day I stopped using a search path for dns I could avoid it.

	jaap

---

From: Lyman Chapin <[email-masked]>
Date: Thu, 3 Jul 2008 16:05:14 -0400

> which is vague enough to cover the case above (but perhaps not able to

"Similarity" can be defined and tested, by setting thresholds and the  
like, but "confusing" refers to a state of mind - something is  
"confusing" if the people who are likely to encounter it consider it  
to be confusing. There's no way to objectively define or test for  
"confusing" similarity without reference to how actual people respond  
to a particular string. That means either mining data collected from  
circumstances in which people have mistaken one string for another  
(perhaps a history of Google searches), or consulting a panel of real  
people whenever it is necessary to decide whether or not two strings  
are "confusingly" similar.

- Lyman

---

From: Lyman Chapin <[email-masked]>
Date: Thu, 3 Jul 2008 16:59:50 -0400

I understand the objection to MX records in TLDs based on the past  
history of how single label hostnames were (and, as Mark points out,  
undoubtedly still are) handled. If it were possible to put that  
aside, would you have any other objection to single label hostnames?  
I know that at least some of the interest in new gTLDs has been  
expressed by companies that like the idea of using a globally- 
recognized trademark as a TLD - for example,  
"customerservice@ibm" (not to imply that IBM is one of the companies  
that has expressed this sort of interest).

I'm familiar with <draft-klensin-rfc2821bis-10.txt> and understand  
the importance of using only FQDNs in SMTP exchanges given that "[i]n  
the case of a top-level domain used by itself in an email address, a  
single string is used without any dots." What I'm interested in is  
any reason to proscribe the use of a TLD as a single label hostname  
(particularly for email addresses) other than the fact that there is  
software out there that will interpret it incorrectly -

- Lyman

On Jul 2, 2008, at 8:07 PM, Bernard Aboba wrote:
>
> Mark Andrews said:
>
> "The Internet went to multi-label hostnames ~20 years ago.We added  
> ".ARPA" to all the single label hostnames as partof that process.  
> The only hold over is "localhost" andthat is implemeted locally,  
> not in the global DNS. No sane TLD operator can expect "http://tld"  
> or "user@tld"to work reliably. I suspect there are still mail  
> configuationsaround that will re-write "user@tld" to  
> [email-masked] we be writting a RFC which states that MX and  
> addressrecords SHOULD NOT be added to the apex of a TLD zone?
>
> Should we be writting a RFC which states that single labelhostnames/ 
> mail domains SHOULD NOT be looked up "as is" inthe DNS?"
>

---

From: Vint Cerf <[email-masked]>
Date: Thu, 3 Jul 2008 19:04:44 -0400

vint

On Jul 3, 2008, at 6:14 PM, James Seng wrote:

> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update

---

From: "William Tan" <[email-masked]>
Date: Fri, 4 Jul 2008 15:01:29 -0400

John,

To add to your point, one should also consider the question of
embedded semantics in a single-character label.

Alphabetic scripts such as Latin mostly represent sounds used to make
up words. While one can certainly find some legitimate
single-character words (such as the article "a" or the personal
pronoun "i") and dream up others, it would not be very convincing in
the face of your explanation #3.

On the other hand, characters in ideographic scripts such as Han are
not mere sounds or glyphs; they represent one or more concepts.
Therefore, a single-ideographic-character TLD label is certainly more
justifiable. I would even go as far as to suggest that it is essential
in many cases. For example, "猫" (U+ 732B) in both Simplified Chinese
and Japanese means "cat" as in English, not the abbreviation for
Catalan nor the UNIX command. The reverse translation of "cat" yields
the exact character in Simplified Chinese, though in Japanese
sometimes the Hiragana sequence "ねこ" is also used. One would be
hard-pressed to come up with a different character to represent the
same concept in Han, aside from the traditional Chinese counterpart
"貓" (U+8C93).

I don't know what the present thinking is on the idea of non-semantic
TLDs, but IMHO the social expectations of DNS usage is cast in stone.
Jon's idea would simply shift the semantics to the second level,
thereby creating 24 roots instead of a single "."

=wil

-- 
http://xri.net/=wil

---

From: Vint Cerf <[email-masked]>
Date: Fri, 4 Jul 2008 15:33:18 -0400

john,

my reaction was specific to IDN single character TLDs. In some  
languages these are complete words.

vint

---

From: "Edmon Chung" <[email-masked]>
Date: Sat, 5 Jul 2008 07:33:03 +0800

Edmon

> -----Original Message-----
> From: [email-masked] [mailto:idna-update-
> [email-masked]] On Behalf Of Vint Cerf
> Sent: Saturday, July 05, 2008 3:33 AM
> To: John C Klensin
> Cc: James Seng; [email-masked]; [email-masked]; Lyman Chapin
> Subject: Re: Single-letter names (was: Re: Update of RFC 2606 based on the
> recent ICANN changes?)
> 
> john,
>

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jul 2008 09:24:39 -0700

Lyman Chapin wrote:
>    If it were possible to put that aside, 
> would you have any other objection to single label hostnames? I know 
> that at least some of the interest in new gTLDs has been expressed by 
> companies that like the idea of using a globally-recognized trademark as 
> a TLD - for example, "customerservice@ibm" (not to imply that IBM is one 
> of the companies that has expressed this sort of interest).

What will be the impact of having, perhaps,

   1)  millions of entries in the root servers, and

   2)  constant traffic banging on those servers?

Historically, the view has been that bloating the root servers in that way would 
be very dangerous.

Counter-claims observe that .com seems to have survived with a similar storage 
and traffic pattern, so why should there be a problem moving the pattern up one 
level?

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 12:25:09 -0400

--On Monday, 07 July, 2008 10:30 +1000 Mark Andrews
<[email-masked]> wrote:

> 	mean [email-masked].  This will mean that any configuration
> file 	that has "user@ai" will now, suddenly, get a different
> meaning. 	This is a latent security issue.

Mark,

While I'm basically sympathetic to the position you are taking
on this, we have recommended for years and years (since the CS.
incident, if not earlier), that things like configuration files
use FQDNs and only FQDNs.  SMTP imposes the same requirement on
addresses in MAIL and RCPT commands.  

If user@ai is in a config file with the intent of identifying
[email-masked] then the config file is broken.    Conversely,
if the config file format is intended to permit references to
TLDs, I would hope that it would be possible to write "ai." if
the TLD were intended.

Personally, I'm very concerned about what users type and what
happens after that.  For configuration files and the like, I
believe that we have a case of bad design if the interpretation
of the configuration is dependent on things outside the scope of
that file and, in particular, if there is a dependency on DNS
search procedures rather than one explicit FQDNs.

Quoting from your comment about Firefox, "Two wrongs don't make
a right.  They just make two things that need to be fixed."

    john

---

From: <[email-masked]>
Date: Mon, 7 Jul 2008 17:25:28 +0100

> Alphabetic scripts such as Latin mostly represent sounds used 
> to make up words. While one can certainly find some 
> legitimate single-character words (such as the article "a" or 
> the personal pronoun "i") 

And lest someone might think that this curiosity of single
character words only applies to vowel sounds, in Russian,
the Cyrillic letter equivalents of v, k and s, are also
single letter words. 

> On the other hand, characters in ideographic scripts such as 
> Han are not mere sounds or glyphs; they represent one or more 
> concepts.

Some people might dispute that and say that they represent
syllables. Since the various Chinese dialects tend to have
monosyllabic words, almost all possible syllables also represent
a word or concept. However, many concepts in modern Chinese
dialects require multiple syllables to express them and
therefore multiple characters to write them. So there isn't
really a one to one mapping of word, syllable, concept as
many people suppose.

It would be more defensible to disallow single codepoint labels
where the code point represents a single consonant sound or a single
vowel sound. That still leaves a grey area of syllabic symbol systems
such as Hiragana, Inuit syllabics, etc. However, the number of people
affected by a rule on syllabics is small enough that one could
reasonably
poll representatives of these language communities to see if a rule
prohibiting single-syllable TLDs would cause hardship.

Note that the current system allows both single syllable TLDs such
as .to and single ideograph TLDs such as .sing when ASCII characters
are used. Or if you want to include tones, then .sing4 would be a single
ideographic codepoint. I think that it would be a good thing to update 
RFC 2606 to collect the various arguments and reasoning so that the
ICANN 
experts have some guidance to work from. If we can't deal with all the 
corner cases in an updated RFC, then at least ICANN experts have a point

of reference from which to depart, or not.

--Michael Dillon

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Jul 2008 12:59:42 -0400

> Historically, the view has been that bloating the root servers in that 
> way would be very dangerous.
> 
> Counter-claims observe that .com seems to have survived with a similar 
> storage and traffic pattern, so why should there be a problem moving the 
> pattern up one level?

because it makes the root more expensive to run, and thereby makes the 
root more vulnerable to capture by people bent on making money or 
wielding power (and all that that entails) rather than running it as a 
reliable service for the benefit of the entire network.

indeed, the history of .com provides many instructive examples of why 
the root should NOT be run the same way.

Keith

---

From: John Levine <[email-masked]>
Date: 7 Jul 2008 17:19:26 -0000

>   1)  millions of entries in the root servers, and

Let's start by considering thousands of entries, since I see little
reason to expect even that many from ICANN's current plans.

>   2)  constant traffic banging on those servers?

The latest CAIDA study says:

* The overall query traffic experienced by the roots continues to
  grow. The observed 2007 query rate and client rate was 1.5-3X above
  their observed values in 2006

* The proportion of invalid traffic, i.e., DNS pollution, hitting the
  roots is still high, over 99% of the queries should not even be sent
  to the root servers. We found an extremely strong correlation both
  years: the higher the query rate of a client, the lower the fraction
  of valid queries.

That suggests that if the legit traffic increased by an order of
magnitude, it would still be down in the noise compared to the junk.
Conversely, if root server traffic is an issue, getting networks to
clean up their DNS traffic would be much more effective than limiting
the number of TLDs.

http://www.caida.org/research/dns/roottraffic/comparison06_07.xml

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Mon, 07 Jul 2008 13:25:22 -0400

> clean up their DNS traffic would be much more effective than limiting

sounds good.  and why wouldn't "cleaning up DNS traffic" include 
refusing to refer any single-label query (for any record type other than 
NS, say) to an upstream server?

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 13:49:30 -0400

--On Monday, 07 July, 2008 17:19 +0000 John Levine
<[email-masked]> wrote:

>...
> * The proportion of invalid traffic, i.e., DNS pollution,
> hitting the   roots is still high, over 99% of the queries
> should not even be sent   to the root servers. We found an
> extremely strong correlation both   years: the higher the
> query rate of a client, the lower the fraction   of valid
> queries.
> 
> That suggests that if the legit traffic increased by an order
> of magnitude, it would still be down in the noise compared to
> the junk. Conversely, if root server traffic is an issue,
> getting networks to clean up their DNS traffic would be much
> more effective than limiting the number of TLDs.
> 

John,

While I find this interesting, I don't see much logical or
statistical justification for the belief that, if one increased
(by a lot) the number of TLDs, the amount of "invalid" traffic
would remain roughly constant, rather than increasing the
multiplier.  

And, of course, two of the ways of having "networks [to] clean
up their DNS traffic" depend on local caching of the root zone
(see previous note) and filtering out root queries for
implausible domains.  Both of those are facilitated by smaller
root zones and impeded by very large ones.

    john

---

From: John Levine <[email-masked]>
Date: Mon, 7 Jul 2008 13:54:05 -0400 (EDT)

> While I find this interesting, I don't see much logical or statistical 
> justification for the belief that, if one increased (by a lot) the 
> number of TLDs, the amount of "invalid" traffic would remain roughly 
> constant, rather than increasing the multiplier.

As I recall from prior surveys, the invalid traffic is largely independent 
of valid domains, e.g., queries from RFC1918 space (4% of all traffic at 
one server), repeated queries for the same nonexistent name, dynamic rDNS 
updates from misconfigured Windows boxes, stuff like that.

> root zones and impeded by very large ones.

Oh, I agree.  But I really don't think there's much point in worrying 
about root zones with millions of domains.  Nothing ICANN is likely to do 
would raise it above thousands, and a zone with a few thousand entries 
should be well within the capacity of any DNS server.

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jul 2008 11:06:07 -0700

> reason to expect even that many from ICANN's current plans.

When making a paradigm change to a core, infrastructure mechanism, it is best to 
assume the worst-case conditions, rather than best.

For example, I can assure you from first-hand knowledge that US$ 100K cost for a 
domain name a company deems desirable is not all that rare.  I would certainly 
not assume the global limit to be a few thousand.

More generally, the difference between allowing unbounded TLDs, versus limiting 
them by a price, involves very different strategic decision-making.  The former 
is massive and fundamental.  The latter is rather minor and likely to be viewed 
as tweaking.

So any analysis had better be made on the assumption that limits are from more 
natural and persistent characteristics, rather than from a current charging or 
operations constraints decision.

>   to the root servers. 
...
> magnitude, it would still be down in the noise compared to the junk.

Not if, for example, the 99% also grew with the added legitimate traffice.

Again, the operations rule I've been taught is to base analyses based on the 
limit of worst-case scenarios that one can tolerate, not to make assumptions 
about reasonableness (other than there won't be any.)

d/

ps. I assume (and hope) that the real DNS root experts will weigh in on this, 
here, soon...

-- 

   Dave Crocker

---

From: Bill Manning <[email-masked]>
Date: Mon, 7 Jul 2008 12:08:31 -0700

> a right.  They just make two things that need to be fixed."

	John, do you beleive that DNS host semantics/encoding that form the bulk
	of the IDN work (stringprep, puny-code, et.al.) are applicable -only- in
	the context of zone file generation or are they also applicable in 
	configuration and acess control for DNS?

	path/alias expansion/evaluation will be interesting if "." is not what
	7bit ASCII thinks of as "."

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: John Levine <[email-masked]>
Date: Mon, 7 Jul 2008 15:44:27 -0400 (EDT)

> NS, say) to an upstream server?

I have to congratulate you on one of the most subtle proposals to destroy 
the Internet that I have seen in a long time.  More on that in a moment.

As I recall from prior root server surveys, the invalid traffic is 
unambiguously bogus, e.g., queries from RFC1918 space (4% of all traffic 
at one server), repeated queries for the same nonexistent name, dynamic 
rDNS updates from misconfigured Windows boxes, stuff like that where thre 
is no question it's wrong.

But, wow, what a can of worms would be opened by making a subtle semantic 
change to root DNS resolution.  As I presume everyone knows, the DNS is 
managed via a Mexican standoff among the root server operators, ICANN, and 
national governments.  The root servers don't have to do what ICANN says, 
so ICANN has (to date at least) been very careful never to ask them to do 
anything they might not want to do.  Governments assert control over their 
ccTLDs, so ICANN has carefully run IANA as a purely clerical operation, 
with policy decisions limited to verifying that updates are indeed from 
the relevant governments, and the root operators have always accepted the 
ccTLD delegations forwarded by IANA.  Nobody knows exactly what authority 
various governments have over various root servers, which are located in 
many countries all over the world.

So now ICANN and/or the root servers say, we changed our mind, we're not 
going to resolve names without dots.  So who's going to explain to the 
Vatican that, sorry, pope@va doesn't work any more?  Or will the US take 
issue when addresses @as, which is part of the US, don't work?  Or France 
about @gp and @mq, which are as much part of France as Hawaii is part of 
the US?

What will Hong Kong or China do when the F and I roots in Hong Kong no 
longer resolve http://hk/?  The Philipines when the I root in Manila 
doesn't resolve http://ph/?

I'm impressed, it never occurred to me that one could cause this much 
damage with such an arcane change to name resolution.  That was really 
diabolical.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 17:12:56 -0400

--On Monday, 07 July, 2008 09:24 -0700 Dave Crocker
<[email-masked]> wrote:

>> would you have any other objection to single label hostnames?
>> I know  that at least some of the interest in new gTLDs has
>> been expressed by  companies that like the idea of using a
>> globally-recognized trademark as  a TLD - for example,
>> "customerservice@ibm" (not to imply that IBM is one  of the
>> companies that has expressed this sort of interest).
> 
> Historically, the view has been that bloating the root servers
> in that way would be very dangerous.
> 
> Counter-claims observe that .com seems to have survived with a
> similar storage and traffic pattern, so why should there be a
> problem moving the pattern up one level?

To answer your question with a question...

At least one rather popular DNS server implementation on a
popular platform now comes with initial configuration files that
strongly suggest local caching of the entire root zone file.
Although it may not be a universally good recommendation (and
the config file is careful to note that), it is entirely
reasonable and practical for many or most situations.  What do
you think would happen to that recommendation, and the benefits
it affords, if the size of the root zone increased by an order
of magnitude or so?  Think ICANN (or anyone else) has done
traffic projections on what would happen if the root zone were
cached at many locations on the network but had, not only the
same size but roughly the same volatility (e.g., updates due to
changes in servers or services) as COM does today and, if so,
what those analyses suggest?

    john

---

From: Karl Auerbach <[email-masked]>
Date: Mon, 07 Jul 2008 15:03:12 -0700

I guess you've heard the old joke which asks "How could God create the 
world in only seven days? - Because He had no installed base."

If we move this thread up one level of abstraction much of the 
conversation is asking the question of how strongly we respect the 
installed base of software out there on the net.

Do we have any principles we can use to guide our choice of where we put 
the needle along the continuum from "no change, no way" to "any and 
every change is allowed"?

  		--karl--

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 18:37:22 -0400

--On Monday, 07 July, 2008 15:03 -0700 Karl Auerbach
<[email-masked]> wrote:

> 
> I guess you've heard the old joke which asks "How could God
> create the world in only seven days? - Because He had no
> installed base."

yes.  But six.  He could then rest, rather than dealing with
irate users.

> conversation is asking the question of how strongly we respect
> the installed base of software out there on the net.
> 
> Do we have any principles we can use to guide our choice of
> where we put the needle along the continuum from "no change,
> no way" to "any and every change is allowed"?

Apropos to your opening comment, it is probably ultimately a
matter of religion.   And mine, FWIW, it that, in cases where it
is hard or impossible to prove that their will be no ill-effects
on that portion of the installed base that conforms to existing
standards, I'm inclined to argue for a very high level of
demonstration that there are no ways to do whatever is wanted
within the existing models.   Such demonstrations may be
persuasive that problems that may be lying in wait for us are
worth the risks.   In their absence, it is hard for me
--religiously or pragmatically-- to accept the view that
possibly-significant risks are worth it.

I note that, because of the caching issue as well as several
others, I have never found the position that "we know that COM
could be expanded well beyond original design expectations,
therefore the root can be" particularly persuasive.

Of course, if one is unpersuaded by the potential for risks to
the installed base, then one would position oneself to try to
get those who are concerned about those risks to prove that they
exist.

    john

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2008 09:58:55 +1000

> that has expressed this sort of interest).

	You still have the issue that "telnet host" will suddenly
	become "telnet tld" when "host" is not longer in the search
	list because it has been deprecated.   This then lets "tld"
	harvest username / password pairs etc.

	Every protocol has its own set of gotchas.  Email was just
	a example everyone should be able to recognise.
 
	Note:  "tld" does not meet the requirements of a Hierarchical
	Names as specified in RFC 921.  Hierarchical Names are what
	we now call globally unique names.

	Trying to treat "tld" as a heirachical name does not work.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jul 2008 18:14:48 -0700

John C Klensin wrote:
>      What do
> of magnitude or so?  

2 orders?  20K?

No, sorry.  Think 3-4 orders of magnitude.

Really.

Let me explain: I'm not against more TLDs.  Quite the opposite.  (I appointed by 
Postel to participate in the pre-ICANN committee tasked with increasing the number.)

But there is a paradigmatic difference between a TLD defined and operated to 
mediate on behalf of a general and diverse population, versus one constrained to 
a narrow and controlled constituency, such as a single company.

The number of the latter is quite large.  And by that I mean *really* large.

And all of the questions I asked 10 years ago said that TLDs on that latter 
scale would be problematic to the root.

d/
-- 

   Dave Crocker

---

From: "James Seng" <[email-masked]>
Date: Tue, 8 Jul 2008 09:36:57 +0800

> scale would be problematic to the root.

Was that pre-Anycast or post-Anycast?

-James Seng

---

From: Dave Crocker <[email-masked]>
Date: Mon, 07 Jul 2008 18:46:08 -0700

> Was that pre-Anycast or post-Anycast?

pre-

(And, by the way, an interesting question.  It's probably why it would be good 
for someone to formulate a consensus opinion about current size and traffic 
limits on the current root...)

d/

-- 

   Dave Crocker

---

From: Joe Abley <[email-masked]>
Date: Mon, 7 Jul 2008 22:55:01 -0400

> Was that pre-Anycast or post-Anycast?

There are plenty of examples of people hosting large, infrastructure- 
type zones using servers and software that are conventional, commodity  
choices. NSD and BIND9 are both quite capable of hosting zones with  
single-digit millions of delegations without needing special care and  
feeding, for example.

Whether the DNS service for a zone is anycast or not has some, but  
really not that much relevance when you're considering the risk of an  
engorged root zone. I don't read anything in the layer-9 musings I've  
seen so far to suggest that the bar to entry for new TLDs will be so  
low that we'll see widespread TLD tasting and churn, for example,  
sufficient to make far-flung anycast instances struggle to keep up.

I'm not suggesting that growth should be allowed to happen without  
considering the technical consequences. However, I believe in practice  
with the headroom in systems and network that root server operators  
generally install anyway, there's considerable room for growth and the  
general argument that growth in the root zone will undermine stability  
sounds more like hysteria than science.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Jul 2008 15:48:55 +1200

Joe,

On 2008-07-08 14:55, Joe Abley wrote:
...
> generally install anyway, there's considerable room for growth 

'Considerable' isn't science. How many orders of magnitude do we
have good reason to believe is OK?

> and the

No, it sounds like an absence of science. All we know is that
we are somewhere between 'considerable room for growth' and
'undermining stability.'

Frankly I don't think we have any more idea of the answer to that
than we did on 23 Feb 1998 when the IAB wrote to Ira Magaziner
(http://www.ietf.org/mail-archive/web/ietf/current/msg04154.html):

> On the other hand, a very large increase in the total number of gTLDs
> (say to thousands) would lead us into technically unknown territory.

I suggest that there is some urgency in conducting a data-based
study of where the limit to stability lies.

    Brian

---

From: Douglas Otis <[email-masked]>
Date: Mon, 7 Jul 2008 21:18:18 -0700

On Jul 7, 2008, at 10:49 AM, John C Klensin wrote:
> statistical justification for the belief that, if one increased (by  
> a lot) the number of TLDs, the amount of "invalid" traffic would  
> remain roughly constant, rather than increasing the multiplier.
>
> And, of course, two of the ways of having "networks [to] clean up  
> their DNS traffic" depend on local caching of the root zone (see  
> previous note) and filtering out root queries for implausible  
> domains.  Both of those are facilitated by smaller root zones and  
> impeded by very large ones.

Agreed.  This is happening while some email providers suggest  
widespread adoption of MX resource records targeting roots to signify  
opting-out.  Not only does this form of email opt-out unfairly burden  
the victim, this scheme also victimizes roots.  Are roots really  
inexhaustible and capable of sustaining high levels of horizontal  
growth, and ever greater levels of DNS misuse while adopting an  
additional security layer?  How will roots be able to block abuse once  
it proves destructive?

 From the human aspect, the list of common file extensions is mind- 
numbingly long.  With a changing TLD landscape, one will no longer be  
sure whether a reference is to a file or to an Internet host.  This  
becomes critical since automation is often used to fully construct  
links.  Will obvious names be precluded such as .C0M, or those less  
obvious having international domain names?  While this might help  
ICANN raise money, their profit seems destine to come at the expense  
of those currently supporting existing infrastructure.  If domain  
tasting is an example of governance, then how can ICANN be trusted to  
operate in the greater interest of the Internet?  It seems more  
reasonable to extend ccTLDs into a comparative list of international  
domain names where desired, and then wait a decade to measure its  
impact and to allow wider deployment of DNSsec.

Smaller steps rather faith in ever greater capacity seems more  
appropriate.  If DNS were to approach the ability of roots to respond,  
then DDoS attacks take on truly global proportions.

-Doug

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jul 2008 01:49:24 -0400

--On Monday, 07 July, 2008 12:08 -0700 Bill Manning
<[email-masked]> wrote:

> 	John, do you beleive that DNS host semantics/encoding that
> form the bulk 	of the IDN work (stringprep, puny-code, et.al.)
> are applicable -only- in 	the context of zone file generation
> or are they also applicable in  	configuration and acess
> control for DNS?

I think I don't understand the question.   RFC 3490 tries to
make a distinction between IDNA-aware and IDNA-unaware
applications and domain name "slots".  The intent is, more or
less, to permit a punycode-encoded string with the prefix (which
the IDNA2008 drafts call an "A-label") to appear nearly anywhere
in the DNS but to expect conversion to and/or from native
characters only in contexts where IDNA is explicitly applied.
Even in zone files, IDNA is generally applicable only to labels
and not to data fields.

> 	path/alias expansion/evaluation will be interesting if "." is
> not what 	7bit ASCII thinks of as "."

RFC 3490 lists a series of other characters that are to be
treated as label-separating dots if encountered in an IDNA
context.  That model causes a number of interesting problems in
contexts where one has to recognize a string as a domain name,
and possibly process it, without knowing anything about IDNA.
The problems show up in situations as simple as conversions
between label-dot-label-dot-label format and length-label list
format, making it very important whether one identifies an FQDN
as containing IDNA labels or converts it to length-label form
first.  IDNA2008 (see the IDNABIS WG and its documents and
mailing list) does away with all of this as part of a general
plan to do a lot less mapping of characters into other
characters.  So, for the proposed newer version the only
label-separating dot permitted in the protocol is the character
you know as 7bit ASCII "." (U+002E in Unicode-speak).

Does that answer whatever the question was intended to be?

   john

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jul 2008 05:14:22 -0400

--On Monday, 07 July, 2008 18:14 -0700 Dave Crocker
<[email-masked]> wrote:

> 
> 
> John C Klensin wrote:
>>      What do
>> you think would happen to that recommendation, and the
>> benefits it affords, if the size of the root zone increased
>> by an order of magnitude or so?  
> 
> 
> 2 orders?  20K?
> 

Yes.  I choose the smaller number because various folks around
ICANN seem to be expecting a thousand applications or so.
Unless the application fee turns into much more of a deterrent
than I expect, I agree that this is likely to open the
floodgates and that your estimate is more likely.  While INAL
and this is certainly not my area of expertise, a possible issue
in the requirement to defend trademarks might act as a strong
accelerator once one starts seeing individual enterprise TLDs
(or even the suspicion of applications for them).

> Let me explain: I'm not against more TLDs.  Quite the
> opposite.  (I appointed by Postel to participate in the
> pre-ICANN committee tasked with increasing the number.)
> 
> But there is a paradigmatic difference between a TLD defined
> and operated to mediate on behalf of a general and diverse
> population, versus one constrained to a narrow and controlled
> constituency, such as a single company.

Indeed, although ICANN has already opened that door by
allocating "sponsored" gTLDs to a few entities which have
restricted membership that is smaller than the interest group
associated with some larger companies.

> And all of the questions I asked 10 years ago said that TLDs
> on that latter scale would be problematic to the root.

Yes.  And, for large scale, our more complicated root
environment (e.g., Anycast* and more local caching of root
copies in the presence of a root that might, worst case, end up
on the same order of magnitude in size, and with similar
volatility, to .COM) may actually make that situation worse than
it would have been in estimates of a decade ago.

     john

* I am assuming that, while Anycast reduces the load on
individual servers by making more of them, it does not reduce
the total query load on the network and increases the amount of
bandwidth used in distributing updates.  The latter is
presumably trivial as long as the refresh time for the root zone
is fairly long and updates are infrequent (or incremental "push"
update is used), but could get interesting if magnitudes evolved
toward the current .COM situation.  But that is clearly not an
analysis based on actual data.

---

From: Bill Manning <[email-masked]>
Date: Tue, 8 Jul 2008 04:28:39 -0700

> Does that answer whatever the question was intended to be?

perhaps - let me try again w/ example.

in my resolv.conf file, I have the following three lines:

search . karoshi.com. ip4.int. ep.net.
nameserver 198.32.2.10
nameserver 2001:478:6:0:230:48ff:fe22:6a29

the line of interest is the first line, starting w/ search.
the expectation is that the items on this list are domain names.
in my case, they are all "fully qualified".   since this is a 
configuration file - not a zone file, is IDNA2008 expected to 
apply?  this data is not, per se, in the DNS.

-- 
--bill

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 8 Jul 2008 09:13:36 -0400

On Jul 7, 2008, at 10:55 PM, Joe Abley wrote:

> type zones using servers and software that are conventional,  
> commodity choices. NSD and BIND9 are both quite capable of hosting  
> zones with single-digit millions of delegations without needing  
> special care and feeding, for example.
>
> really not that much relevance when you're considering the risk of  
> an engorged root zone. I don't read anything in the layer-9 musings  
> I've seen so far to suggest that the bar to entry for new TLDs will  
> be so low that we'll see widespread TLD tasting and churn, for  
> example, sufficient to make far-flung anycast instances struggle to  
> keep up.

It seems to me that it might be better to turn that around :

The new TLD system should not allow for widespread TLD tasting and  
churn.

I worry about depending on artificial limits imposed by fees. ICANN  
will certainly be lobbied to lower their
fees; what if the fee in 2012 is $ 100 not $ 100,000 ?

Regards
Marshall

> considering the technical consequences. However, I believe in  
> practice with the headroom in systems and network that root server  
> operators generally install anyway, there's considerable room for  
> growth and the general argument that growth in the root zone will  
> undermine stability sounds more like hysteria than science.
>
>
> Joe

---

From: John C Klensin <[email-masked]>
Date: Tue, 08 Jul 2008 09:30:18 -0400

--On Tuesday, 08 July, 2008 04:28 -0700 Bill Manning
<[email-masked]> wrote:

>> > form the bulk 	of the IDN work (stringprep, puny-code,
>> > et.al.) are applicable -only- in 	the context of zone file
>> > generation or are they also applicable in  	configuration
>> > and acess control for DNS?
>> 
>> less, to permit a punycode-encoded string with the prefix
>> (which the IDNA2008 drafts call an "A-label") to appear
>> nearly anywhere in the DNS but to expect conversion to and/or
>> from native characters only in contexts where IDNA is
>> explicitly applied. Even in zone files, IDNA is generally
>> applicable only to labels and not to data fields.
>> 
>> > 	path/alias expansion/evaluation will be interesting if "."
>> > 	is not what 	7bit ASCII thinks of as "."
>> 
>> context.  That model causes a number of interesting problems
>> in contexts where one has to recognize a string as a domain
>> name, and possibly process it, without knowing anything about
>> IDNA. The problems show up in situations as simple as
>> conversions between label-dot-label-dot-label format and
>> length-label list format, making it very important whether
>> one identifies an FQDN as containing IDNA labels or converts
>> it to length-label form first.  IDNA2008 (see the IDNABIS WG
>> and its documents and mailing list) does away with all of
>> this as part of a general plan to do a lot less mapping of
>> characters into other characters.  So, for the proposed newer
>> version the only label-separating dot permitted in the
>> protocol is the character you know as 7bit ASCII "." (U+002E
>> in Unicode-speak).
>> 
> the expectation is that the items on this list are domain
> names. in my case, they are all "fully qualified".   since
> this is a  configuration file - not a zone file, is IDNA2008
> expected to  apply?  this data is not, per se, in the DNS.

Nothing in IDNA2008 makes it apply.  Nothing in IDNA2008 even
makes it apply to zone files (!).   My personal view --others in
the WG might have other opinions-- is that one would be better
off using A-labels (the punycode-encoded forms) in this sort of
context.

The reasoning involves two points:

	* While I don't imagine you would put domain names in
	your search rules that you couldn't render (or easily
	type) on your machine, I believe that will happen with
	some servers who are supporting multilingual
	communities.  The A-labels can be typed and rendered
	accurately on any system that can handle construction of
	the config file (with its ASCII keywords) itself.  The
	U-labels put you at some risk of seeing little boxes or
	question marks (or, in some cases, worse) as well as
	potentially being hard to type.
	
	* An explicit design goal for IDNA (both versions) is to
	avoid changing the DNS or low-level DNS implementations.
	The search rule interpreter in your resolver is going to
	have to substitute names in that can be used in the DNS
	and those are the A-labels.  Putting U-labels in the
	config file would requires that the resolver be
	IDNA-aware, understand those labels, and map them to the
	A-label form before doing lookups.  It would also
	presumably require doing that every time the config file
	is read, a small decrement in efficiency.

Now, to give you a slightly different answer, I sort of expect
that communities who use IDNs a lot, especially those for whom
typing ASCII is uncomfortable, will find that IDNs drive them
toward "compilers" or special user interfaces to aid them in
producing all sorts of config files.  I'd expect them to develop
tools to permit constructing zone file and resolver config file
templates with IDN U-labels in them and then translating them
into DNS-internal forms (i.e., with the A-labels).  I'd even
expect such tools to provide screen interfaces that permit
working with the keywords of the config files without having to
type them out (a process that gets error-prone if words like
"search" or "nameserver" or "$ORIGIN" are not familiar and/or
the keys to enter them aren't on the keyboard).

But those are local tools, not part of anyone's protocol or
global facilities.

Again, just IMO.

   john

---

From: "Cellario Luca" <[email-masked]>
Date: Tue, 8 Jul 2008 15:39:28 +0200

UNSUBSCRIBE

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John C Klensin
> Sent: Tuesday 8 July 2008 15:30
> To: Bill Manning
> Cc: Mark Andrews; [email-masked]
> Subject: Re: Services and top-level DNS names (was: Re: Update of RFC
> 2606
>
>
>

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to <mailto:[email-masked]>[email-masked]. Thank you<http://www.loquendo.com>www.loquendo.com
================================================
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf