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

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Wed, 2 Nov 2005 22:58:13 -0500

Hi,

Thanks to everyone who commented on this draft.

RFC 2606 documents three things: The rational for reserving certain names at the top and second level. The agreement of IANA to reserve 4 TLDs. And the policy of IANA to reserve the second level label "example" in .com, .net, and .org.

At the time of the issuance of RFC 2606, IANA was under the direction of the IAB and was a part of the IETF and was Jon Postel, who was also RFC editor.

The idea of 2606bis is to update RFC 2606. The policy function of IANA for most of domain name registration and registry selection is now performed by ICANN. So I obtained the closest ICANN policy statement I could to the IANA 2nd level label policy, spliced it in, and produced draft 2606bis. I should probably have included an Informational reference to RFC 2860 (and possibly RFC 2826) in the draft and plan to do so in the next version which I won't be able to post until after the IETF meeting in Vancouver, which I will be attending.

I have read the entire thread so far with this subject line. Hope people don't mind that I'm just replying to the first message. Anyway, there seems to be considerable desire to include something about prohibition of numeric TLDs. At this time, I would think that all the IETF can say is that such TLDs SHOULD be reserved, since it is ICANN's call.

(Also, a quick note on ccTLDs. This draft says nothing about them. It certainly doesn't say that anything is reserved at lower levels in them. Nor does it state that they are not reserved. It does not state that ICANN has the authority to regulate ccTLDs or their contents, nor does it say ICANN does not have that authority. All it says is that, by contract, ICANN imposes restrictions on 'many TLDs' and provides a pointer to a list of TLDs which do not include any ccTLDs. I was really trying to avoid controversy. But I've already gotten troll mail anyway.)

See also below at @@@ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Tveit Alvestrand
Sent: Thursday, October 20, 2005 6:56 AM
To: [email-masked]
Subject: draft-eastlake-2606bis-00.txt: Suggestions for modifications

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

@@@ The old RFC also documents the IANA policy on example.{com|net|org}.

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.

@@@ Well, that's why I say that it is ICANN policy. So I gather you would prefer that the document, perhaps, only document ICANN reservation policy for things reserved for the same reason as the TLD reservations? If so, I would think it should also state that there are other labels, not listed, that ICANN has a policy of reserving in some TLDs. But it doesn't seem that bad to me and of interest to the IETF to know that "ietf", "rfc-editor", etc are being reserved.

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

@@@ But this document isn't, currently, IETF policy. It just motivated and documents IANA/ICANN commitments/policy. 

@@@ Actually, in the past there was a theory that some mechanism might distribute the contents of a zone between servers based on the value of the first label byte. So, though not mentioned in RFC 2606 and possibly not documented anywhere but in moldy old emails, there was an IANA policy not to register single letter 2nd level domain names in .com, .net, or .org. But a few had already been registered by the time this policy was adopted and IANA did not de-register any of those.

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.

This could be added as a subsection of section 2 - since it's a new reason for reserving TLDs.

@@@ Right, but, as I say above, I don't think the IETF can say anything stronger than SHOULD at this point, at least not without explicit agreement of ICANN.

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.

@@@ My source of ICANN policy didn't state motivation but it might be useful to mention the IDN use and clarify this.

I believe there might be an IANA registry of those tags somewhere?
If so, this should be mentioned.

@@@ I'll check on this.

                     Harald

@@@ Anyway, I do plan to do another version improved in various ways as above and with a more clearly stated scope and intent.

@@@ Thanks,
@@@ Donald

--
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: Alex Bligh <[email-masked]>
Date: Thu, 03 Nov 2005 08:46:48 +0000

--On 02 November 2005 22:58 -0500 Eastlake III Donald-LDE008 
<[email-masked]> wrote:

> So I obtained the closest ICANN policy statement I could to the IANA 2nd
> level label policy, spliced it in,

To what extent should we be reproducing ICANN policy in RFCs?

Alex

---

From: Thomas Narten <[email-masked]>
Date: Thu, 03 Nov 2005 11:37:47 -0500

> To what extent should we be reproducing ICANN policy in RFCs?

IMO, we should not at all. At best, include a pointer to ICANN and say
"their turf".

RFCs are around forever. ICANN policy can and will change. Indeed,
ICANN/registry contracts are an area of active evolution at the
moment.

After reading the text, I'd say pretty much all of the new material
that got added to Section 3 should be removed. Specifically:

> 3. Reserved Second Level Domain Names
> 
>    At the time of the issuance of [RFC 2606], the Internet Assigned
>    Numbers Authority (IANA, http://www.iana.org) had reserved the
>    following second level domain names reserved which can be used as
>    examples.
> 
>         example.com
>         example.net
>         example.org

OK so far...

> 
>    At this time, similar restrictions are by way of contract between the
>    Internet Corporation for Assigned Names and Numbers (ICANN,
>    http://www.icann.org) and the Registry Operators of many top level
>    domains. See <http://www.icann.org/registries/agreements.htm>.

I don't think the above should be said. It sugggests that
example.<whatever> are safe to use for testing. Should we suggest
that? Do we even need to?

I confess to having  chatted with Don about this document before -00
appeared. At the time, I sort of assumed that "example" might need
reserving in all the TLDs, since new ones had been added. 

But thinking some more about this, I have to actually wonder, what
problem are we trying to fix here? Is there _really_ a need (for,
e.g., documentation) to be able to use example.<whatever>, for any TLD
that exists? The answer is not an obvious yes to me. Just use
example.com. Or example.example, etc.

If we were to conclude that example should be reserved in all TLDs, I
think we'd have to do a careful dance with ICANN before publishing
that in a BCP. I.e., get them to review the proposal, have the board
agree to it, and then somehow both agree this is a recommendation
going forward.

But, I'm not at all convinced this needs doing, as in, this fixes a
known problem.

> 
>    The ICANN "Schedule of Reserved Names" most recent version, as of the
>    date of this document, is at
>    <http://www.icann.org/tlds/agreements/net/net-registry-
>    agreement-01jul05.pdf>.  It reserves the labels listed in the
>    following subsections, except when released by ICANN.

Again, this will change. At most, I'd suggestion text like:

       A number of second-level domains are reserved via ICANN policy, see
       [XXX] for details.

with  [XXX] being a generic reference to policies, not one policy in
particular. 

> 3.1 Labels Reserved at All Levels
> 
>    These are reserved from initial registration, unless ICANN grants an
>    exemption, at the second level and at all deeper levels where the top
>    level registry operator performs registration. If they have been
>    previously registered, they may be renewed and there is no
>    restriction on their existence in delegated zones.
> 
>       ICANN-related names:
>          aso
>          gnso
>          icann
>          internic
>          ccnso
>       IANA-related names:
>          afrinic
>          apnic
>          arin
>          example
>          gtld-servers
>          iab
>          iana
>          iana-servers
>          iesg
>          ietf
>          irtf
>          istf
>          lacnic
>          latnic
>          rfc-editor
>          ripe
>          root-servers

Just remove this entire section. We don't need to document this. It's
not necessary to even know about these from the perspective of
testing/documentation (which is what the introduction talks about).

> 
> 3.2 Additional Second-Level Reservations
> 
>    The follows labels are prohibited as second level domain names:
> 
>       All single character labels.

There is history here, and I think it would be good to document this
somewhere (especially the reasoning behind the prohibition), but I'm
not at all sure that this document is a good place to do it. Again, it
doesn't seem directly relevant to the scope of this draft.

>       All two character labels unless a release is obtained from the
>          government and country-code manager if that two letter
>          combination is an assigned country-code or a release from the
>          ISO 3166 maintenance agency if it has not been so assigned.

Why mention this?

> 
> 3.3 Tagged Domain Names
> 
>    All labels with hyphens in the third and fourth character positions
>    such as "bq--1k2n4h4b" or "xn--ndk061n".

Why does this need to be mentioned?

> 3.4 Second-Level Reservations for Registry Operators
> 
>    The following are reserved for the use of the top level domain
>    Registry Operator and will be transferred whenever the Operator
>    changes:
> 
>          nic
>          whois
>          www
> 
>

Again, ICANN business. No need to say anything here.

Now, having written all the above, I'm back to trying to understand
something very basic: what is the problem with 2606 that needs
fixing/updating? Do we actually need an updated to 2606?

Thomas

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 4 Nov 2005 09:34:54 +0100

On Thu, Nov 03, 2005 at 11:37:47AM -0500,
 Thomas Narten <[email-masked]> wrote 
 a message of 160 lines which said:

> IMO, we should not at all. At best, include a pointer to ICANN and
> say "their turf".

Not even that, IMHO. THere is no reason for the IETF to endorse ICANN
or to imply that it has a role here.
 
> what is the problem with 2606 that needs fixing/updating?

Nobody documentd that.

> Do we actually need an updated to 2606?

No.