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

[Eastlake III Donald-LDE008 <[e-mail]>]

Hi Thomas,

See below at @@@

-----Original Message-----
From: Thomas Narten [mailto:[e-mail]] 
Sent: Thursday, November 03, 2005 11:38 AM
To: Alex Bligh
Cc: Eastlake III Donald-LDE008; Harald Tveit Alvestrand; [e-mail]
Subject: Re: draft-eastlake-2606bis-00.txt: Suggestions for modifications

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

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

@@@ To some extent this draft was written to get reaction to check that. Things like
http://www.icann.org/tlds/tld-faqs.htm#FAQ36 seem to imply that, at least on some points, ICANN would be happy to follow IETF decisions, even if ICANN is not obliged to do so.

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

@@@ Everything can and will change. I don't see that as a reason not to produce RFCs. In fact, assuming the relevant parts are not changing *too* quickly, one can argue that change makes efforts to update Best Practices more valuable. Also by documenting reasons for some reservations we might increase their stability. 

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

@@@ I don't think stopping there is very good. It was just a policy of IANA but such policies are, as I understand it, now set by ICANN. Since the draft has already made the point of the value of "example" domain names, to merely state a historic fact like this, with no indication of whether it is still true, or what the current source of authority is for it, or whether that authority still supports it, would be a disservice.

>    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 suggests that example.<whatever> are safe to use for testing. Should we suggest that? Do we even need to?

@@@ It tries to accurate state the current status of these names, which are not primarily intended for testing but for documentation example. I do not consider this statement of fact to be suggestive or inappropriate. I do think we should provide this information. I'd be happy to change "many top level domains" to "many but not all top level domains".

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.

@@@ Now you are talking about controversial things. Imposing some such a mandatory requirement on "all TLDs", including ccTLDs, is a political area you don't want to go into. Or did you actually mean all non-cc TLDs or something? I think it is best to avoid saying "all". (But it does seem to me that we should reserve example.arpa.)

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.

@@@ The original impetus for this update draft came from putting out a public service announcement pointing out that TLDs, such as .info and .museum, can be more than three characters. It seemed desirable to use reserved 2nd level domain names for examples in real zones of this type. But I do not see that the update should be limited to that.

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.

@@@ Again, "all TLDs" is dangerous. But, as per the URL above, it may turn out to be relatively easy to get ICANN to agree to reasonable policies recommended by the IETF or have a BCP which, in so far at it specified policies within ICANN purview, takes effect when ratified by ICANN, or the like. Whether such restriction on *all TLDs" are reasonable is another question I don't think we want to go into.

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. 

@@@ But some of these reservations, such as tagged labels and single byte labels, are reserved for prospective IETF protocol reasons. Other are reserved to decrease confusion related to IETF component organizations. In any case, I don't think this policy changes all that often and when it has changed I believe it has mostly been for the addition of more reservations.

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

@@@ I reject your repeated use of the word "need". This document is not intended to be a Needful Current Practice, that is, the equivalent of a MUST standard provision. This is intended to be a Best Current Practice and it is entirely the point of such documents to mention non-essential but good things.

@@@ I agree that the introduction and possibly the title of the draft and some section names should be clearer and more accurate as to their actual scope. But I think it is just obviously the right thing for the IETF to document and support such confusion-avoiding things as the reservation of "ietf", "iab", etc., in many TLDs.

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

@@@ As above, the introduction/title should more clearly and accurately correspond to the actual scope of the document. I don't see any particular reason to have yet another document to put that history in. Notwithstanding its title, the current RFC 2606 talks about "example" as a 2nd level domain name and does so because inclusion of this was suggested by Jon Postel.

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

@@@ I'd agree that this is probably the least important to include, but why not? If there are reasons for listing almost all of ICANN's policy, why bother cutting out a small part of it?

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

@@@ It appears to me that tagged domain names are reserved so that the IETF can define things like Internationalized Domain Names. If there doesn't exist a current IANA registry/policy for classes of tagged domain names and if ICANN would ratify such a policy, then this document seems like a reasonable place for IANA Considerations for the allocation of tagged domain name prefixes, perhaps requiring an IETF Standards Action for their allocation.

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

@@@ Again, need is not the right criterion. It seems to me useful to have some uniform 2nd level domain names for Registry Operators and I don't see any reason not to document and support that 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?

@@@ Well, it is always a judgment call whether it is worth updating something. But it seems useful to add to 2606 information about other label which are or should be reserved under various circumstances including "example" in some TLDs beyond .com, .net, and .org, numeric TLDs, tagged labels, single character 2nd level labels, labels corresponding to IETF organizational components, etc. And it seems useful to state, to the extent practical, the current situation concerning the authority for such policies.

Thomas

@@@ Donald

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