On Wed, Dec 10, 2008 at 12:21:40PM +0100, Antoin Verschuren wrote:
PDP Number: 2008-05 Anycasting Assignments for TLD's and Tier 0/1 ENUM
I'm a little less happy than Leo to see the external reference vanish, but I'm happy to no longer see it being extended to ENUM, because it wouldn't have been applicable there. Not only are ENUM Tier1 delegations not subject to IANA's tests, also the 512 octet boundary doesn't make much sense in the ENUM context. That said, it is an honest appreciation of operational practice to see the 512 boundary disappear, since it is no longer the only reason to deploy DNS anycast. Therefore, the pro argument # If deployment of anycast is increased it could keep (or decrease) the number # of NS records per TLD/ENUM, in turn this would enable operators to keep DNS # reply size low even with DNSSEC. appears a bit misleading to me. It could go without harm. # Critical DNS infrastructure is defined as infrastructure providing # Authoritative TLD or ENUM Tier 0/1 DNS lookup services. Critical [DNS] infrastructure is a loaded term, and I don't see the necessity to make that definition here, given that it's used only twice in the following text. However, we can take the terminology debate to the DNS (and ENUM) WGs.
While I strongly support the proposal for more than 1 anycast assignment per TLD/ENUM tier1 operator, I do have some problems with the definition of the ENUM tier1 operators.
Where it says:
"ENUM operators as defined by the ITU"
I think it should say:
"ENUM tier0/1 operators as defined by RIPE NCC"
# "The organisation(s) applicable under this policy are TLDs operators as defined # by IANA and ENUM operators as defined by the ITU." I don't think it should say "defined" here at all, neither ITU nor the NCC nor IANA (in the case of TLDs). The point is to assign in accordance with the records kept by IANA and the Tier0 registry, respectively. Speaking of definition, though, any reference for the terms "Tier0" and "Tier1" in this context anyone? When the policy refers to operators, I'm sure that aims at the registry in charge, not the actual DNS operators, in cases where these entities differ. # "These prefixes must be used for the sole purpose of anycasting authoratitve # DNS servers for the stated TLD/ENUM, as described in RFC 3258." Understood this is mostly original text, I'd like to suggest the reference be adjusted to cover RFC 4786/BCP 126. Also, while DNS is and should remain the driving factor, "the sole purpose" is a bit restrictive, since one might want to co-locate other services, e.g. DCHK/IRIS, with the name service, which would not be allowed under the current text. -Peter