[address-policy-wg] Anycast assignments for ENUM/TLD registries

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.

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.

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.

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