Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Oct 2005 21:17:34 +1000

> Hi,
> 
> I couldn't find any discussion of this draft on the mailing list, but the 
> draft says that it should be discussed here, so here it goes... WG chairs, 
> please rule me out of order if it isn't appropriate (and ask the author to 
> update the draft...)
> 
> draft-eastlake-2606bis-00, "Reserved Top Level DNS Names", tries to update 
> the old RFC that reserved ".test", ".example", ".invalid" and ".localhost".
> 
> RFC 2606 is a BCP, so presumably this document aims for the same status.
> 
> Summary: This is definitely not a document that I think the IETF should 
> publish as-is.
> 
> My detailed comments:
> 
> 1) I believe section 3.1  and 3.4 (reservation of "aso", "gnso", "afrinic", 
> "rfc-editor" and so on) is inappropriate for the IETF and should be 
> removed. This is ICANN's business.
> 
> Optionally, I could argue that it should be reduced to "example", so that 
> we could use "example.fr" as well as "example.com" in examples.
> 
> I am less sure about section 3.3 (prohibition of single character and two 
> letter names). There may be technical justification for these (see the RFC 
> describing the "com.com" problem, and how to fix it - the number escapes 
> me) - but I know for a fact that multiple registries do hand out two-letter 
> domain names today, and are likely to continue to do so no matter what the 
> IETF says - so this needs *heavy* justification - my default proposal would 
> be "remove".
> 
> 2) A different conversation led to the (to me) surprising conclusion that 
> there is no IETF document that conclusively states that top level domains 
> shouldn't be all numeric. I think this is an appropriate thing for the IETF 
> to state in a BCP, since 4-component all-numeric domain names are hard to 
> tell from IP addresses - a technical consideration in many protocols.

	RFC 1123 comes close.

           If a dotted-decimal number can be entered without such
           identifying delimiters, then a full syntactic check must be
           made, because a segment of a host domain name is now allowed
           to begin with a digit and could legally be entirely numeric
           (see Section 6.1.2.4).  However, a valid host name can never
           have the dotted-decimal form #.#.#.#, since at least the
           highest-level component label will be alphabetic.
 
> This could be added as a subsection of section 2 - since it's a new reason 
> for reserving TLDs.
> 
> 3) The nature of the reservation of tagged domain names (xn--) in section 
> 3.3 needs to be explained - the sentence is even grammatically incomplete.
> 
> I *think* it's intended to reserve these labels at all levels until a 
> normative interpretation is given in an IETF standard. But the para does 
> not say.
> 
> I believe there might be an IANA registry of those tags somewhere?
> If so, this should be mentioned.
> 
>                      Harald
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 20 Oct 2005 17:14:44 +0200

On Thu, Oct 20, 2005 at 12:55:36PM +0200,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 57 lines which said:

> 1) I believe section 3.1 and 3.4 (reservation of "aso", "gnso",
> "afrinic", "rfc-editor" and so on) is inappropriate for the IETF and
> should be removed. This is ICANN's business.

Correct, it is inappropriate (thanks for finding this word, I was
thinking of something much more violent). But it is not ICANN's
business' either. The rules under ".fr" (or any other ccTLD) are not
to be defined by IETF or ICANN, period (unless of course they are
syntactical ruls or rules *necessary* for good interoperability, but
business rules like those of the draft are a no-no).

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 20 Oct 2005 17:22:50 +0200

> business rules like those of the draft are a no-no).

I happen to agree with you in the case of ccTLDs :-) - but that fight too 
is ICANN's business to fight. We (speaking as an IETF participant) 
shouldn't get involved - either in saying "yes" or in saying "no" to such 
restrictions.

                       Harald

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Oct 2005 16:15:16 +0200

On Thu, Oct 20, 2005 at 12:55:36PM +0200,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 57 lines which said:

> I couldn't find any discussion of this draft on the mailing list,
> but the draft says that it should be discussed here,

Yes, but DNSop would be more adapted, no?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 21 Oct 2005 16:23:15 +0200

On Thu, Oct 20, 2005 at 12:55:36PM +0200,
 Harald Tveit Alvestrand <[email-masked]> wrote 
 a message of 57 lines which said:

> removed. 

3.1 is clearly completely out-of-scope and must be removed. There is
no reason that strings like "iab" or "iana" should be prohibited.

3.4 is a bit different because we no longer talk about "back office"
organisations like IAB or ARIN but about operational uses. "nic" and
"whois" could be seen are reasonable names to reserve to the
infrastructure. I'm more hesitant about "www". While I understand that
http://www.example/ could be seen as a Web site authoritative about
the TLD example, I'm not sure that we should reserve "www" and not
"mail", for instance.

Probably, the logical conclusion will be to drop 3.4 completely,
because I'm not sure we can have a consensus on the list (may be just
on "nic"?)