Re: draft-ietf-dnsind-iana-dns-00.txt

["Donald E. Eastlake 3rd" <dee3@torque.pothole.com>]

From:  Randy Bush <randy@psg.com>
Message-Id:  <m11KP9j-0008G6C@rip.psg.com>
Date:  Fri, 27 Aug 1999 09:47:11 -0700 (PDT)
To:  namedroppers <namedroppers@internic.net>
Sender:  owner-namedroppers@internic.net

>3.3.1 Becoming Root
>would seem to be operational technique, neither ietf standards material nor
>iana policy

Perhaps this should be moved to an appendix and labeled in some way to
indicate it is commentary. It seemed useful to have some note that it
is easy to be root but the operational consensus is that 99%+ of
everyone wants to use the same root for interoperability (and
interoperability has, I believe, always been a hallmark of the IETF).

>3.3.1 Reserved TLDs in the IN CLASS
>would seem to be new policy.  it might benefit from detailed explanation
>before ietf should assert it.

Didn't think it was new policy.  Certainly RFC 2606 can hardly be new
polciy. Can try to add more explanation.

For comparison, I refer you to draft-bradner-iana-allocation-01.txt
which makes it perfectly clear that there are numerous reserved
address blocks.

>3.3.2 'Country Code' TLDs in the IN CLASS
>would seem to be political policy, and some of it steps quite beyond current
>policy and beyond the ietf's purview, e.g.
>
>   A country code for a territory with a generally recognized acting
>   government should be considered part of the territory of that
>   government.  Decisions by said government as to who should control
>   the DNS for that TLD are final and unappealable.
>
>[ let's restrict namedroppers discussion to the technical issue of ietf's
>  relevance to the item, and take the political part to some icann list ]

I thought there were some TLDs reserved for technical reasons, some
TLDs that belonged to "countries" and the rest was transitioning to
ICANN control.  Seems simple enough.  (Also I notice that the draft
doesn't reference RFC 1591 and it probably should.)

>3.3.3 Other TLDs in the IN CLASS
>seems entirely icann/iana political policy

Well, for technical reasons, the inverse address domains need to work
for inverse addresses.  Agreed, all the rest is rapidly becoming the
ICANN DNSO's problem, which I think this tries to say.

>in general, there seems to be confusion between standards in the ietf
>purview and icann/iana political policy.  for an rfc, the latter might be
>removed.

I thought the entire purpose was to codify guideance to IANA.  IANA
guideance isn't a "standard" or at least it has never gone through the
standards process, as far as I am aware.  My further understand was
that the guidance necessarily reduced IANA's range of policy choices
and that this was thought to be a good and a reduction in the load on
IANA.

We'll see what we can do to clarify things in a revision.

>randy

Thanks,
Donald