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

[Thomas Narten <[e-mail]>]

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

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

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