2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM)
PDP Number: 2008-05 Anycasting Assignments for TLD's and Tier 0/1 ENUM 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" I wouldn't want the ITU to determine who should get address space, and the counterpart for IANA in the ENUM space is RIPE NCC. I see the ITU more in the role ICANN has with regards to TLD's, or perhaps even the US DOC. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/
Antoin and all, Good point. I certainly wouldn't want the ITU doing so either. But you know that there are some that are yet again pushing the ITU as having some sort of authority, however defined, to make such determinations... Antoin Verschuren wrote:
PDP Number: 2008-05 Anycasting Assignments for TLD's and Tier 0/1 ENUM
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"
I wouldn't want the ITU to determine who should get address space, and the counterpart for IANA in the ENUM space is RIPE NCC. I see the ITU more in the role ICANN has with regards to TLD's, or perhaps even the US DOC.
Antoin Verschuren
Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands
T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren@sidn.nl W http://www.sidn.nl/
Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827
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
On Dec 10, 2008, at 11:21, Antoin Verschuren wrote:
I think it should say:
"ENUM tier0/1 operators as defined by RIPE NCC"
I don't think it should say this either Antoin. :-( The NCC does not define the ENUM operators: its role in ENUM is strictly neutral. Strictly speaking, IAB chose the NCC as the ENUM Tier-0 registry and the National Administrations select their corresponding Tier-1 registry. I suggest the following language/definition: Critical Infrastructure Domain: a TLD listed in the IANA database (insert URL here), e164.arpa or any delegation of e164.arpa made according to the arrangements in place between RIPE NCC, IAB and ITU-T (insert url here). Then in the modified 6.9 for RIPE424 say something like The organisation(s) applicable under this policy are operators of Critical Infrastructure Domains. I'm uneasy about explicitly listing e164.arpa since this means the NCC would in principle be able to allocate resources to itself. This might not be wise. Another concern here is ICANN's plans for lots of new TLDs. Though I expect we'll be out of IPv4 space before those TLDs come on-line. And here's a wider question: do these allocations of /24s for infrastructure anycasting go to the registry operator or should they be linked to the domain name? ie If the registry for .nl or 1.3.e163.arpa moves from SIDN, do any anycast allocations for these domains stay with SIDN or would they go back to the NCC or get transferred to the new registry operator?
Jim, On Thu, Dec 11, 2008 at 1:12 PM, Jim Reid <jim@rfc1035.com> wrote:
On Dec 10, 2008, at 11:21, Antoin Verschuren wrote:
I think it should say:
"ENUM tier0/1 operators as defined by RIPE NCC"
I don't think it should say this either Antoin. :-( The NCC does not define the ENUM operators: its role in ENUM is strictly neutral. Strictly speaking, IAB chose the NCC as the ENUM Tier-0 registry and the National Administrations select their corresponding Tier-1 registry.
I suggest the following language/definition:
Critical Infrastructure Domain: a TLD listed in the IANA database (insert URL here), e164.arpa or any delegation of e164.arpa made according to the arrangements in place between RIPE NCC, IAB and ITU-T (insert url here).
When we were ediiting this document we had something very similar to this on the table but it was decided having the explicit url's in the document was a bad thing because if/when they changed it would break the policy. We figured the hostmasters at the NCC would know where to find the relevant definitive list and therefore it didn't need to be explicitly reffered to with a direct url in the document.
Then in the modified 6.9 for RIPE424 say something like
The organisation(s) applicable under this policy are operators of Critical Infrastructure Domains.
I'm uneasy about explicitly listing e164.arpa since this means the NCC would in principle be able to allocate resources to itself. This might not be wise. Another concern here is ICANN's plans for lots of new TLDs. Though I expect we'll be out of IPv4 space before those TLDs come on-line.
Well the intention of the policy is to allow Tier0 and Tier1 ENUM operators to receive the allocations so by definition yes this does mean the NCC can make an allocation to itself, but is this really a bad thing as long as there is a reaonable hard limit (in this case 4 /24's) after all there are other areas where the NCC has allocated address space to itself and I don't believe this has caused a problem.
And here's a wider question: do these allocations of /24s for infrastructure anycasting go to the registry operator or should they be linked to the domain name? ie If the registry for .nl or 1.3.e163.arpa moves from SIDN, do any anycast allocations for these domains stay with SIDN or would they go back to the NCC or get transferred to the new registry operator?
The intention of the policy is that they are allocated to the national operator of ENUM, so for example in the UK, UKEC would be given the allocations for ENUM who would then (hopefully) allow Nominet to use those allocations while they were the registry/dns operator, If/when UKEC decide to move the registry/dns operator to another entity they can then ask Nominet to stop announcing the prefixes so the new registry/dns operator can use them. If this isn't clear in the wording I would welcome an edit. Thanks Brett Carr Nominet
participants (5)
-
Antoin Verschuren -
B C -
Jeffrey A. Williams -
Jim Reid -
Peter Koch