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

From: Randy Bush <[email-masked]>
Date: Fri, 27 Aug 1999 09:47:11 -0700 (PDT)

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

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.

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 ]

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

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.

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Aug 1999 21:12:41 -0700 (PDT)

> I thought the entire purpose was to codify guideance to IANA.
                                            ^ technical

randy

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Fri, 27 Aug 1999 22:37:07 -0400

From:  Randy Bush <[email-masked]>
Message-Id:  <[email-masked]>
Date:  Fri, 27 Aug 1999 09:47:11 -0700 (PDT)
To:  namedroppers <[email-masked]>
Sender:  [email-masked]

>would seem to be operational technique, neither ietf standards material nor

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

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

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

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

>purview and icann/iana political policy.  for an rfc, the latter might be

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