On Fri, Apr 17, 2009 at 2:34 PM, Jim Reid <jim@rfc1035.com> wrote:
Apologies for providing a meaningful Subject: header. :-)
On Apr 15, 2009, at 14:43, Peter Koch wrote:
"TLD operators as defined by IANA" may be a well intended phrase, but many affected registries would reject being "defined" by IANA.
Peter, I feel you're being overly picky here. If an organisation doesn't like the wording of some policy then they are of course free to choose not to enjoy the benefits of that policy. Better still, they could suggest text that makes them feel more comfortable. :-) I think the wording Ondrej has proposed should provide that level of comfort.
This wording will be in the new version.
I'm ultimately guilty of the insertion of "as defined by IANA". The intent here was to come up with a policy that would allow anycast assignments to real TLD registries (ie those in the IANA database) rather than for whatever gunk lies in so-called alternate roots and so forth. The same goes for the ENUM Tier-1 registries, though in this case it's ITU and not IANA that has the definitive database for that. Again, the intent here was to have policy wording that would prevent charlatans setting up bogus-e164.com (or whatever) and then come to NCC claiming an entitlement of 200 or so Tier-1 "country code" anycast assignments: ie essentially having alternate roots in a slightly different guise.
In an earlier discussion about this draft I contributed text containing the URLs for the IANA and ITU databases. This was considered a Bad Idea because these links could change. So that's what provoked the "as defined by" revision in the next iteration of the document.
This layer 9 stuff aside, I'm still uncertain whether the assignment goes to the registry itself or to some operator who provides name service for TLDs (or ENUM, for that matter). The former makes more sense to me.
I am still not certain the latest draft resolves this confusion either.
This has also been addressed in the newest version.
I strongly believe that the assignment should go to the registry and not the provider of registry or DNS services for that registry. Even if these are the same entity, their roles and their responsibilities are different. On a practical level, the TLD or Tier-1 administrator might want to split their anycast assignment between DNS providers: say discrete /24s to each of them. This wouldn't be easy to do (or change) if that anycast assignment was held by their registry operator. And suppose the registry has a serious disagreement its registry operator or the back-end provider changes when the contract goes out to tender.
"TLD manager/administrator as described in RFC 1591" might be more acceptable.
IMO the language that needs to be use here has somehow to be linked to the TLD managers that are known to the IANA database. RFC 1591 seems too fuzzy and very out of date. The excellent text Ondrej suggested -- "designated manager for TLD as delegated by IANA" -- works for me. I hope it will for everyone else.
This has also been added to the new version.
Similar considerations apply to "ENUM operators as defined by the ITU".
I don't think so. ITU implicitly define this as they have effective administrative control for the delegations under e164.arpa. Ondrej's come up with better text for that too: "ENUM administrator as assigned by the ITU". Can we agree to use that?
OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose justifying the assignment/.
Again, I think you're being unduly picky Peter. IIRC there was a rough consensus on the policy draft using "Critical DNS Infrastructure" as a definition of the DNS servers needed for the TLDs in the IANA database and the Tier-0/1 ENUM domains in the ITU database. If you don't like the word "Critical" here, let's choose something else like "Qualifying" or "Eligible". OTOH, this is for critical DNS infrastructure so there's no reason IMO for not making that explicit.
I have removed the "critical dns infrastructure wording" from the document and replaced it with something a little less controversial but meaningful. I think/hope that the new draft Ondrej and I submitted today should address everything below and satisfy points made here by everybody (It's Friday and hence I'm feeling positive) it will be made available shortly after the review period ends for current version (23/04) Brett