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

Editorial -

B C wrote:

> On Fri, Apr 17, 2009 at 2:34 PM, Jim Reid <jim at rfc1035.com> wrote:
> 
>>Apologies for providing a meaningful Subject: header. :-)

Could we please keep the policy proposal ID in the Subject?

Thanks,
Wilfried.

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