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

From: Marshall Eubanks <[email-masked]>
Date: Fri, 27 Jun 2008 14:43:17 -0400

I have been having a discussion on NANOG about possible problems with  
the
new Top Level Domains coming out of ICANN. It seems like additional  
TLD domains, beyond
just the 4 in RFC 2606, should be either reserved or blocked.  
Suggestions include .local (apparently
used heavily by Microsoft), .internal, as well as maybe translations  
of .test .example .invalid .localhost into
other languages / character sets.

I am curious as to  whether others feel like this is a potential
problem to be addressed (and, not least, whether there is a better  
mail list for this discussion).

Regards
Marshall 
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: David Conrad <[email-masked]>
Date: Fri, 27 Jun 2008 11:51:42 -0700

Hi,

> mail list for this discussion).

I believe an RFC that provides an IETF-defined list of names (beyond  
the 4 in 2606) and/or rules defining names the "Internet technical  
community" feels would be inappropriate as top-level domains would be  
quite helpful.

Regards,
-drc
(speaking personally)

---

From: SM <[email-masked]>
Date: Fri, 27 Jun 2008 12:08:27 -0700

Hi Marshall,
At 11:43 27-06-2008, Marshall Eubanks wrote:
>the new Top Level Domains coming out of ICANN. It seems like additional
>TLD domains, beyond just the 4 in RFC 2606, should be either 
>reserved or blocked.

Frank posted an I-D to update RFC 2606
http://tools.ietf.org/html/draft-ellermann-idnabis-test-tlds-06

>other languages / character sets.

The I-D has an IDN section.  See http://idn.icann.org/ for the 
example.test names.

Regards,
-sm

---

From: SM <[email-masked]>
Date: Fri, 27 Jun 2008 12:21:46 -0700

Hi David,
>community" feels would be inappropriate as top-level domains would be

Do you mean as in RFC 3675?

Regards,
-sm

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 27 Jun 2008 15:43:46 -0400

> Do you mean as in RFC 3675?

Well, I can't speak for David, but that was not really what I was  
thinking of, or what I think the people I was discussing
this were thinking.

I was thinking of things like .local, which could cause problems if  
they were
given out.

Regards
Marshall

---

From: David Conrad <[email-masked]>
Date: Fri, 27 Jun 2008 12:57:40 -0700

Hi,

> Do you mean as in RFC 3675?

No.  I feel an RFC that creates a list (or defines a rule) that  
identifies what names would be inappropriate for top-level domains  
would be quite helpful.  A couple of examples:

- a label consisting of all numbers
- the label "local"

There may be others...

Regards,
-drc

---

From: Joe Abley <[email-masked]>
Date: Fri, 27 Jun 2008 16:31:47 -0400

On 27 Jun 2008, at 15:57, David Conrad wrote:

> would be quite helpful.

Personally, I think that any such list (even one that was not static,  
but existed in the form of an IANA registry) would always be incomplete.

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.

>  A couple of examples:

There will always be others, in my opinion, which is why I think the  
idea of a list of bad ideas is dangerous. Just because things are not  
on the list of bad ideas doesn't mean they are good ideas, but that's  
now how people will interpret it.

Joe

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 27 Jun 2008 13:48:35 -0700

Just register .local and do not assign it in the same way that 10.x.x.x and 192.168.x.x are registered.

________________________________

From: [email-masked] on behalf of Joe Abley
Sent: Fri 6/27/2008 4:31 PM
To: David Conrad
Cc: SM; [email-masked]
Subject: Re: Update of RFC 2606 based on the recent ICANN changes ?

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Jun 2008 09:39:43 +1200

Joe,

On 2008-06-28 08:31, Joe Abley wrote:
> 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.

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.
I see no reason to expect this to be different now they have opened
the floodgates to greed at the TLD level too. So I think that any such
technical review process is doomed. The best we can do is proceed
under the second paragraph of section 4.3 of RFC 2850, i.e. designate
specific TLDs as reserved for technical reasons, and so instruct IANA.
Furthermore, I believe this is not only the *best* we can; it's
essential that we do so, although translating 'example' into every
script and language may be going a bit too far. So I believe that
2606bis is very necessary.

> idea of a list of bad ideas is dangerous. Just because things are not on
> the list of bad ideas doesn't mean they are good ideas, but that's now
> how people will interpret it.

Unfortunately that's true, and that may mean cranking 2606bis repeatedly.
But the alternative (inserting the IETF in a TLD approval process)
is pure lawyer-bait and would no doubt send the IETF's insurer apoplectic.

   Brian

---

From: David Conrad <[email-masked]>
Date: Fri, 27 Jun 2008 16:18:50 -0700

On Jun 27, 2008, at 3:22 PM, SM wrote:
> It would cause problems if .local was given out.  I don't recall  
> seeing any RFC requesting IANA to reserve it.

Right.

> We already have 888.com.  Some users may ask for .888 given its  
> significance in some cultures.

A TLD of all numbers would be a real pain to deal with.  That is, from  
a software parsing perspective, what's the difference between the  
domain name "127.0.0.1" and the IP address "127.0.0.1"?

> I cannot find a technical reason against PAYPAI.c0m.

Right.  There is a policy reason ("confusingly similar"), but that's  
not a technical, e.g., protocol reason.

> If such a technical review process is doomed, then why should the  
> IETF get into defining technical guidelines outside the ".example"  
> examples?

Because, as you've indicated with the .local example above, protocol  
actions can result in technical justification why a particular label  
used as a TLD could be problematic.  An IANA registry defining these  
that ICANN can point to and tell applicants "no, because it is in the  
IETF-defined 'bad' list" would likely be helpful.

Regards,
-drc

---

From: Lawrence Conroy <[email-masked]>
Date: Sat, 28 Jun 2008 01:27:41 +0100

Hi Brian, folks,
  Having just recovered from the heat in Paris...
IIUC, Microsoft would be free to put in an application for .local if  
it is so all-fired important to them.
Also, if I've decoded the slightly delphic comments correctly, the  
bidding war with Apple might be fun.
Finally, the lawyers of Thomson Local Directories in the UK might be  
interested and raise an objection.

I'll believe it has become a problem when the RFP, evaluation and  
objection process have been ->finalised<-, the evaluations have been  
done, and any agreement has been signed. It could take some time...)

all the best,
   Lawrence
(speaking personally)

---

From: "Joe Baptista" <[email-masked]>
Date: Fri, 27 Jun 2008 23:29:43 -0400

> Do you mean as in RFC 3675?
I sometimes wonder how this RFC ever got off the ground.  Its a bit of a
joke.

regards
joe baptista

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 28 Jun 2008 09:15:34 +0200

Marshall Eubanks wrote:

> .internal

What's that supposed to be good for ?  At the moment the
2606bis draft proposes to create a IANA registry of new
reserved TLDs, populated with TLDs surviving IETF review.

> maybe translations of .test

Covered, a copy of the 11 IDN test TLDs created by ICANN
some months ago, complete with A-labels and U-labels, see
http://tools.ietf.org/html/draft-ellermann-idnabis-test-tlds-06#section-4

> .example

Not yet covered, as there's no evidence that ICANN wants
to reserve their initially 11 "example" translations as
TLDs.  With IETF consensus behind it adding them now, or
later in a separate memo, is no issue.

> .invalid .localhost

Bad idea, IMO, these names are not reserved for tests or
examples, but technical reasons, and no subject for I18N.
  
> other languages / character sets.

ITYM languages / scripts, not character sets.  That is a
wide field, as there are dozens of scripts and hundreds
of languages.  If all you want are the *existing* example
translations corresponding to the 11 IDN test TLDs it's
possible.  Otherwise we better wait until the IDN ccTLDs
are on their way in about a year.

>From my POV I'd like to have one I18N example, and don't
care which of the 11 existing strings are reserved, just
take them all is an idea.  But let's not make up things.

> whether there is a better mail list for this discussion

It's as "general" as it can get, and I guess the IDNAbis
folks won't be thrilled if they are hit by side effects
of their effort... ;-)

 Frank

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 29 Jun 2008 10:21:35 +1200

Lawrence,

If the IETF designates .example or .local as reserved for technical
reasons under the clause of the IETF/ICANN MoU that I cited, the
game is over. That's why we included that clause in the first place.

    Brian

On 2008-06-28 12:27, Lawrence Conroy wrote:
> IIUC, Microsoft would be free to put in an application for .local if it
> is so all-fired important to them.

---

From: SM <[email-masked]>
Date: Sat, 28 Jun 2008 21:35:36 -0700

>domain name "127.0.0.1" and the IP address "127.0.0.1"?

The domain name may be confused with an IP address.  That can be 
avoided by not allocating numbers from zero to 255 as TLDs.  There 
was a recent thread on the IDNA mailing list about other 
representations of IPv4.

>IETF-defined 'bad' list" would likely be helpful.

The IETF can only publish such a list for protocols within IETF's 
scope, i.e. Internet protocol parameters only as directed by the 
criteria and procedures specified in RFCs, including Proposed, Draft 
and full Internet Standards and Best Current Practice documents, and 
any other RFC that calls for IANA assignment.  That covers 
assignments of domain names for technical uses (such as domain names 
for inverse DNS lookup), (b) assignments of specialised address 
blocks (such as multicast or anycast blocks), and (c) experimental assignments.

That's different from an IETF-based "bad" list.  .local can be 
covered once a RFC meeting the criteria is published.  It doesn't 
fall under RFC 2606.  That RFC lists top level
domain names reserved for use in private testing, as examples in 
documentation, and the like.

Regards,
-sm

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 29 Jun 2008 21:51:17 +0200

On Fri, Jun 27, 2008 at 02:43:17PM -0400,
 Marshall Eubanks <[email-masked]> wrote 
 a message of 20 lines which said:

> It seems like additional TLD domains, beyond just the 4 in RFC 2606,
> should be either reserved or blocked.

I have the feeling that it is a recurring question, although I cannot
find immediately a pointer to the relevant discussions. Anyway, I'm
not sure it is a good idea and, should we publish a RFC, it could
possibly explain why people should not use local TLDs like ".local".

> Suggestions include .local (apparently used heavily by Microsoft),
> .internal

As far as I know (but I cannot find a formal statement from the IAB or
a RFC), "local" TLDs like ".local" are regarded as a bad idea, mostly
because they are a pain to manage, should two organizations
merge. Also, they are vulnerable to leaks (in the Received: headers of
email, for instance). Globally unique domains are therefore better.

At a time (when Network Solutions was taking money from ".com"
registrants and when most ccTLDs were terribly closed), these TLD were
the only reasonable solution for some people.

Now, it is much more realistic to obtain a domain name in the TLD of
your choice for a very small price. Rather than reserving ".local",
shouldn't we advise people to use a regular domain name?

> (and, not least, whether there is a better mail list for this
> discussion).

dnsop ?

---

From: John Levine <[email-masked]>
Date: 29 Jun 2008 20:23:48 -0000

>> should be either reserved or blocked.

In view of Recommendation 4 in ICANN's new GTLD process document, why
do you think this is necessary?

You have read the report, haven't you?

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: Brian E Carpenter <[email-masked]>
Date: Mon, 30 Jun 2008 09:49:34 +1200

On 2008-06-29 16:35, SM wrote:
> The domain name may be confused with an IP address.  That can be avoided
> by not allocating numbers from zero to 255 as TLDs.  There was a recent
> thread on the IDNA mailing list about other representations of IPv4.
> 
> The IETF can only publish such a list for protocols within IETF's scope,

Nonsense. The IETF can reserve any TLDs for technical reasons that
need to be reserved for technical reasons (subject to IETF consensus,
of course).

    Brian

> i.e. Internet protocol parameters only as directed by the criteria and
> procedures specified in RFCs, including Proposed, Draft and full
> Internet Standards and Best Current Practice documents, and any other
> RFC that calls for IANA assignment.  That covers assignments of domain
> names for technical uses (such as domain names for inverse DNS lookup),
> (b) assignments of specialised address blocks (such as multicast or
> anycast blocks), and (c) experimental assignments.
> 
> That's different from an IETF-based "bad" list.  .local can be covered
> once a RFC meeting the criteria is published.  It doesn't fall under RFC
> 2606.  That RFC lists top level

---

From: David Conrad <[email-masked]>
Date: Sun, 29 Jun 2008 17:54:41 -0700

On Jun 28, 2008, at 9:35 PM, SM wrote:
> avoided by not allocating numbers from zero to 255 as TLDs.

You need a bit more than that.  Under MacOSX (10.5.3, and I suspect  
most BSD derivatives at the very least):

% ping 127.1024
PING 127.1024 (127.0.4.0): 56 data bytes
...
% ping 1.1712312
PING 1.1712312 (1.26.32.184): 56 data bytes
...
% ping 0xdeadbeef
PING 0xdeadbeef (222.173.190.239): 56 data bytes
...
% ping 0xa.0xa
PING 0xa.0xa (10.0.0.10): 56 data bytes
...

Etc.

> That's different from an IETF-based "bad" list.

I'm suggesting it would be helpful if there were an RFC directing IANA  
to establish a registry that contains both labels and rules (e.g, no  
all-numeric strings, no strings that start with 0x and contain  
hexadecimal values, the string 'xn--', the 2606 strings, etc.) that  
specify what cannot be placed into the root zone.  As part of future  
IANA actions, any time a protocol defines a new TLD (e.g., .local) an  
entry should be placed into that registry.

Would there be the downside to this?

Thanks,
-drc

---

From: Bill Manning <[email-masked]>
Date: Sun, 29 Jun 2008 19:46:15 -0700

> Would there be the downside to this?

	several come to mind...

	heres one.  wrt numeric strings, you have examples of the ambiguity
	in implementations on -how- to process non-base 10 numbers.  but
	it is clear that hex encoding is -not- tossed out.  how 'bout octal?
	or base 36?  are numeric string representations now, after 30 years
	going to be outlawed? if so, on what basis?

	creating a useful RFC that creates a registry and maintains it in a timely
	fashion -in this century- seems a bedtime fable.

-- 
--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: "Frank Ellermann" <[email-masked]>
Date: Mon, 30 Jun 2008 05:31:47 +0200

> Would there be the downside to this?

Hi, that's already planned, I'm lazy, here's a copy:

| that will be done in an draft-ietf-idnabis-952bis to nail the
| two RFC 1123 <toplabel> errata, see the "A-label" thread(s)
| on the IDNAbis list: 
|
| <http://thread.gmane.org/gmane.ietf.idnabis/2176/focus=2194>
|
| Executive summary:  Obsoletes RFC 952, updates RFC 1123,
| defines  toplabel = letter 0*61( ldh ) letdig
[...]
| it is not the job of RFC 2606 to obsolete RFC 952 and update
| RFC 1123.  John said it is also not the job of 
| draft-ietf-idnabis-rationale, therefore we settled on "needs
| its own RFC" (John is for BCP).
[...]
| Minus references, legalese, and weasel words it is *one line
| ABNF* (as shown above), but admittedly loaded.

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jun 2008 08:41:27 +0200

On Sun, Jun 29, 2008 at 05:54:41PM -0700,
 David Conrad <[email-masked]> wrote 
 a message of 41 lines which said:

> I'm suggesting it would be helpful if there were an RFC directing
> IANA to establish a registry that contains both labels and rules
> (e.g, no all-numeric strings, no strings that start with 0x and
> contain hexadecimal values, the string 'xn--', the 2606 strings,
> etc.) that specify what cannot be placed into the root zone.
>

There is one (regarding rules, not regarding labels): a TLD is a
domain like any other. It has nothing special, technically
speaking. Since IETF is supposed to work in the field of technology,
not politics, I would object to any registry that lays down special
rules for TLDs, besides the normal RFC 1034/1123/2181 rules (which
apply to every domain).

Reserving TLDs (like ".example") is a different thing: we don't create
new rules, we just use our privilege to get a TLD without paying
100,000 US $ to ICANN. 
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Mon, 30 Jun 2008 08:43:28 -0400

--On Sunday, June 29, 2008 7:46 PM -0700 Bill Manning 
<[email-masked]> wrote:

>>
>> I'm suggesting it would be helpful if there were an RFC
>> directing IANA   to establish a registry that contains both
>> labels and rules (e.g, no   all-numeric strings, no strings
>> that start with 0x and contain   hexadecimal values, the
>> string 'xn--', the 2606 strings, etc.) that   specify what
>> cannot be placed into the root zone.  As part of future
>> IANA actions, any time a protocol defines a new TLD (e.g.,
>> .local) an   entry should be placed into that registry.
>>
> 	heres one.  wrt numeric strings, you have examples of the
> ambiguity 	in implementations on -how- to process non-base 10
> numbers.  but 	it is clear that hex encoding is -not- tossed
> out.  how 'bout octal? 	or base 36?  are numeric string
> representations now, after 30 years 	going to be outlawed? if
> so, on what basis?
>
> 	creating a useful RFC that creates a registry and maintains
> it in a timely 	fashion -in this century- seems a bedtime
> fable.

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, presumably via the gNSO, one at a time, and via a PDP 
process.  The odds of the very-commercially-oriented gNSO 
agreeing to the IETF's being able to pull a name out of the 
potential namespace by simple IETF consensus (or less) are, IMO, 
around zilch.  Worse, as we move toward IDN TLDs, the odds are 
high that there will be no practical difference between an IDN 
gTLD and an IDN ccTLD other than the ability of the operator to 
shield itself from any potential ICANN enforcement action --even 
of agreements that were signed to get the domain-- by claiming 
national sovereignty and the rule that, in general, private 
bodies can't sue governments without the permission of those 
governments.

The complementary problem is that, in the present DNS 
environment in which typing errors are monetized, an effect of a 
reservation of "example.com" is registration of, e.g., 
"examlpe.com" and "exmaple.com" as placeholders, perhaps in case 
they draw enough traffic that someone would like to buy them 
(the web page for the first of these contains an explicit offer 
to sell it).

To at least some extent, our reserving a name and (if the use in 
plain-text examples, rather than, e.g., MIB examples actually 
drives non-trivial traffic toward those names) publicizing it 
makes spelling variations of that name more valuable.  I don't 
know if the gNSO would like that or not, but it seems to argue 
that we should be conservation about what names we reserve and 
thereby promote.

That has an interesting corollary: to the extent to which 
domains, especially web sites, consider unexpected access to be 
a potential profit source, rather than an annoyance, using 
someone else's domain name in an example may be "welcome free 
advertising", rather than a "rude intrusion".  One can argue 
against use of those names on either basis, but let's stop 
pretending that we have complete knowledge of what is going on 
here and of the consequences of our actions.

Perhaps we should ask ICANN to reserve all single-letter TLDs 
(in any script) for IETF use.  That would make the examples very 
clear, would avoid driving traffic to alternate sites (since we 
would "own" all of them) and would constitue a relatively closed 
list :-)

    john

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Jun 2008 05:49:18 -0700

Stephane,

On Jun 29, 2008, at 11:41 PM, Stephane Bortzmeyer wrote:
> a TLD is a domain like any other.

In theory, yes.  In reality, no.  Speaking technically, how would you  
distinguish the top-level domain "127.0.0.1" from the IP address  
127.0.0.1?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Jun 2008 06:41:08 -0700

> are numeric string representations now, after 30 years

> 	going to be outlawed? if so, on what basis?

?

I'm suggesting that there are technical reasons why strings comprised  
of all numbers and those that start with 0x and contain hex digits  
should not be TLD labels.

In theory, the limitation against all-numeric/hex TLD labels should  
not need to be made.  However, in theory, a label can support any  
octet value between 0 and 255 yet the IETF has gone to great lengths  
to greatly limit the values within "hostname" labels...

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Jun 2008 06:43:39 -0700

> | defines  toplabel = letter 0*61( ldh ) letdig

So, TLDs starting with a number but containing non-numerics would be  
disallowed (I'm reminded of the fun long ago with 3com.com)?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Jun 2008 06:49:54 -0700

John,

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 don't know if the gNSO would like that or not, but it seems to  
> argue that we should be conservation about what names we reserve and  
> thereby promote.

Yep.  The only additional label (to those in 2606) that seems to have  
a technical justification for being disallowed would appear to be  
".local" due to the zeroconf(-like) mechanisms that use it.

> Perhaps we should ask ICANN to reserve all single-letter TLDs (in  
> any script) for IETF use.

I don't necessarily agree or disagree, but what would be the technical  
justification?

Regards,
-drc

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 30 Jun 2008 16:17:33 +0200

David Conrad wrote:

> TLDs starting with a number but containing non-numerics would be  

Yes, killing the  "0x" 1*HEXDIG  oddity.  I wasn't thrilled when
my browser supported the <http://0xd0.0x4d.0xbc.0xa6/> "feature".

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 30 Jun 2008 15:37:06 +0200

John C Klensin wrote:

> process.

As long as PDP translates into "individual Last Call comments"
for a future draft-ietf-idnabis-952bis that's fine.  

Nothing rush like <http://idn.icann.org/Special:Recentchanges>

> it seems to argue that we should be conservation about what
> names we reserve and thereby promote.

Sure, there also rules about not creating confusingly similar
TLDs, proposed TLDs exmaple or examlpe won't pass that check.

> (in any script) for IETF use.

s/ICANN/IANA/, and that is an odd idea.  We don't need 2**20
example TLDs.  But a few would be nice, for examples in EAI
and IDNAbis drafts, or similar.

 Frank

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jun 2008 19:16:07 +0200

On Mon, Jun 30, 2008 at 08:43:28AM -0400,
 John C Klensin <[email-masked]> wrote 
 a message of 83 lines which said:

> there will be no practical difference between an IDN gTLD and an IDN
> ccTLD other than the ability of the operator to shield itself from
> any potential ICANN enforcement action --even of agreements that
> were signed to get the domain--

Before bashing the ccTLD, wait the final text of the "IDN fast track"
process document. In its current version
<http://ccnso.icann.org/workinggroups/idnc-wg-board-proposal-25jun08.pdf>,
it does not mandate agreements between ICANN and the ccTLD, far from
it.

"The GAC also feels that it would be inappropriate for new IDN ccTLDs
to be obliged to enter into contractual agreements with ICANN,"

That's just GAC's opinion but it is apparently the only place where
these agreements are mentioned.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 30 Jun 2008 21:01:53 +0200

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?

There are protocol-specific rules. RFC 3986, section 3.2.2, clearly
says that the IP address wins and so your example would be regarded
as the localhost IP address, wether the TLD ".1" is delegated or no.

But I do not find generic rules.

RFC 3493 which specifies getaddrinfo is not very clear. Section 6.1
apparently does not address your issue.

So, I would say there is a normalization failure here: since 127.0.0.1
can be a domain name and an IP address, we really should have
precedence rules for such case (instead of asking ICANN to solve them
by forbidding all-numeric TLD).

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Jun 2008 12:29:38 -0700

> whatever) which says which is the right result in such a case?

Not that I'm aware of (and that's sort of the point), however there is  
a lot of code out there that are variations on checking to see if a  
string is comprised of all digits and '.' and if so, declares the  
string to be an IP address.  If an all-numeric TLD were to be created,  
I would expect lots of unexpected behavior.

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

> by forbidding all-numeric TLD).

I'm not asking that ICANN solve this problem, rather that the IETF  
solve it so that ICANN can point to the IETF solution.  Having been in  
some of the discussion internally within ICANN on this topic, I figure  
something like this would be really nice...

Regards,
-drc

---

From: Philip Guenther <[email-masked]>
Date: Mon, 30 Jun 2008 13:54:20 -0600

> whatever) which says which is the right result in such a case?

POSIX (IEEE Std 1003.1, 2004 Edition, aka the Single UNIX Specification, 
Version 3) specifies both inet_pton() and inet_addr().  The latter is 
required to accept the 'traditional' forms for IPv4 addresses with fewer 
than four components or using hex or octal numbers.  Contrawise, the 
former is forbidden from accepting such forms.

So the answer from that direction is "it depends".

Philip Guenther

---

From: Mark Andrews <[email-masked]>
Date: Tue, 01 Jul 2008 10:14:02 +1000

> by forbidding all-numeric TLD).

	I think you will find that getaddrinfo() implementations
	catch IP address rather than look them up.  The question is
	more what they catch rather than when they catch.

	For IPv6 it is pretty straight forward.  There is a recommend
	a followed syntax.

	IPv4 on the other hand has lots of history involved.  OS's
	with lots of history tend to support very liberal syntaxes.
	OS's with not so much history tend to be limited to dotted
	decimal quad.

	ICANN is in a position to look at what the various OS's
	accept and rejects TLD's application that will potentially
	conflict with the existing practice of any current OS.  This
	will prevent users that switch OS's and use something other
	than dotted decimal quad getting a match in the DNS when
	the new OS is not as permissive as the old OS.

-- 
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