2008-05 New Draft Documents Published (Anycasting Assignments for TLDs and Tier 0/1 ENUM)
PDP Number: 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM Dear Colleagues The text of the policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM" has been revised. We have published the new version (version 3.0) today. The draft documents for the proposal have also been published, as well as the impact analysis that was conducted for this proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-05.html and the draft documents at: http://www.ripe.net/ripe/draft-documents/ripe-449-draft2008-05.html http://www.ripe.net/ripe/draft-documents/ripe-450-draft2008-05.html We encourage you to read the draft documents and send any comments to address-policy-wg@ripe.net before 23 April 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC
All, Filiz Yilmaz wrote:
PDP Number: 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM
This policy proposal makes sense to me. -- Shane
On Thu, Mar 26, 2009 at 02:05:19PM +0100, Filiz Yilmaz wrote:
Anycasting Assignments for TLDs and Tier 0/1 ENUM
{Full disclosure: DENIC would benefit from the implementation of this proposal.} I support the proposal, but I'm still unhappy with parts of the wording: {only looking at the v4 text, comments apply to the v6 version accordingly}
6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers
Critical DNS infrastructure is defined as infrastructure providing Authoritative TLD or ENUM Tier 0/1 DNS lookup services.
The term "Critical DNS infrastructure" is defined here just to be referred to in one single place three paragraphs down. I'd prefer if the term would be avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be inserted at the appropriate place.
The organisations applicable under this policy are TLD operators as defined by IANA and ENUM operators as defined by the ITU. The organisation may receive up to four /24 prefixes per TLD/ENUM. These prefixes must be used for the sole
"TLD operators as defined by IANA" may be a well intended phrase, but many affected registries would reject being "defined" by IANA. 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. "TLD manager/administrator as described in RFC 1591" might be more acceptable. Similar considerations apply to "ENUM operators as defined by the ITU". As a side note, ENUM Tier 0 assignments would probably have interactions with the policy proposal on "Assignments to the NCC".
purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in RFC 3258.
This is a verbatim quote from the current policy documents, but a reference to BCP126/RFC4786 might be more appropriate these days.
Assignments for Critical DNS infrastructure are subject to the policies described in the RIPE document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for Critical DNS infrastructure any longer.
OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose justifying the assignment/. -Peter
"TLD operators as defined by IANA" may be a well intended phrase, but many affected registries would reject being "defined" by IANA.
running a number of cctlds which have not signed silly papers with iana, i have no problem with the phrase. though i think it could probably be improved, e.g. servers in the root zone is what i suspect is intended. this comment should not be taken to imply i support this policy proposal. randy
Peter, thanks for the input much appreciated. On Wed, Apr 15, 2009 at 2:43 PM, Peter Koch <pk@denic.de> wrote:
On Thu, Mar 26, 2009 at 02:05:19PM +0100, Filiz Yilmaz wrote:
Anycasting Assignments for TLDs and Tier 0/1 ENUM
{Full disclosure: DENIC would benefit from the implementation of this proposal.}
I support the proposal, but I'm still unhappy with parts of the wording: {only looking at the v4 text, comments apply to the v6 version accordingly}
6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers
Critical DNS infrastructure is defined as infrastructure providing Authoritative TLD or ENUM Tier 0/1 DNS lookup services.
The term "Critical DNS infrastructure" is defined here just to be referred to in one single place three paragraphs down. I'd prefer if the term would be avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be inserted at the appropriate place.
I'm happy to change this if the working group feels it's needed.
The organisations applicable under this policy are TLD operators as defined by IANA and ENUM operators as defined by the ITU. The organisation may receive up to four /24 prefixes per TLD/ENUM. These prefixes must be used for the sole
"TLD operators as defined by IANA" may be a well intended phrase, but many affected registries would reject being "defined" by IANA. 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. "TLD manager/administrator as described in RFC 1591" might be more acceptable.
Well the input from the working group I had received earlier was that the allocation should not necessarily go to either the registry or the DNS operator but to the organisation who has been delegated authority over the namespace from either IANA or ITU, In most cases this is the same organisation but it could be that the IANA/ITU gives responsibility for a Tier1 ENUM to an organisation[1] and they subcontract the registry to one company[2] and public facing DNS to another [3], in this situation my intention was for the allocation to go to [1] I believe the wording as is reflects this, I'm happy to update it but would prefer the allocation still goes to [1] How about "The organisations applicable under this policy are TLD operators as recorded in the IANA's Root Zone Database and ENUM operators as approved and recorded by the ITU".
Similar considerations apply to "ENUM operators as defined by the ITU". As a side note, ENUM Tier 0 assignments would probably have interactions with the policy proposal on "Assignments to the NCC".
purpose of anycasting authoritative DNS servers for the stated TLD/ENUM, as described in RFC 3258.
This is a verbatim quote from the current policy documents, but a reference to BCP126/RFC4786 might be more appropriate these days.
This sounds sensible
Assignments for Critical DNS infrastructure are subject to the policies described in the RIPE document entitled "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region".
Anycasting assignments are registered with a status of 'ASSIGNED ANYCAST' in the RIPE Database and must be returned to the RIPE NCC if not in use for Critical DNS infrastructure any longer.
OK, 2nd occurence, but s/Critical DNS infrastructure/the purpose justifying the assignment/.
Thanks for the comments, Some credit should also go to Leo Vegoda for some input, thanks Leo. Brett
The term "Critical DNS infrastructure" is defined here just to be referred to in one single place three paragraphs down. I'd prefer if the term would be avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be inserted at the appropriate place. I'm happy to change this if the working group feels it's needed.
<opinion of just another bozo on this bus> i like "critical infrastructre." this is because, while i understand that the roots need golden space, and i can almost see that anycasted services need micro-allocations, i do not feel that tlds per se are critical in the sense that they need golden space. there is a reason the dns maps from names to addresses. use it. randy
On Thu, Apr 16, 2009 at 09:00:36PM +0900, Randy Bush wrote:
i like "critical infrastructre." this is because, while i understand that the roots need golden space, and i can almost see that anycasted services need micro-allocations, i do not feel that tlds per se are critical in the sense that they need golden space.
that would suggest an external reference to the term and other evaluation criteria than those proposed. Also, could you elaborate on the difference between "micro-allocations" and "golden space"?
there is a reason the dns maps from names to addresses. use it.
Sure, we use anycast to support performant and resilient mapping. -Peter
Hi all, 1) I fully support this policy to move forward. As a matter of fact, AFNIC is preparing an in-house Anycast solution, to be deployed soon for a first group of nodes. Later, we intend to deploy other groups and we will then need to rely on this policy to ask for extra Prefixes. Btw, for our two other running Anycast groups, our choice is a priori to let the Anycast operator ask for address resources they need (a way to mutualize those resources among their customers, thus less address consumption globally). 2) I don't have a strong opinion on using or not "Critical infrastructure expression. Nonetheless, I would prefer we rather avoid that expression in this kind of document (I know it's too late for DNS Root Servers). This might be interpreted by some publicauthorities as an elevation of the TLDs DNS service to a rank of other well-known "Critical infrastructures" like Water or Electricity. I'm not sure we have reached that level of criticity equivalence today, nor am I sure that TLD operators want to spread this perception nowadays. Instead, maybe something less "loaded/exposing" such as "Key/Essential service/infrastructure" (choose a combination as you like) would be more appropriate for this document. Cheers, Mohsen. On 16 Apr, Peter Koch wrote: | On Thu, Apr 16, 2009 at 09:00:36PM +0900, Randy Bush wrote: | | > i like "critical infrastructre." this is because, while i understand | > that the roots need golden space, and i can almost see that anycasted | > services need micro-allocations, i do not feel that tlds per se are | > critical in the sense that they need golden space. | | that would suggest an external reference to the term and other evaluation | criteria than those proposed. Also, could you elaborate on the difference | between "micro-allocations" and "golden space"? | | > there is a reason the dns maps from names to addresses. use it. | | Sure, we use anycast to support performant and resilient mapping. | | -Peter -- -- //===================================================================\\ | Mohsen Souissi | | AFNIC - Responsable R&D | | Mohsen.Souissi@nic.fr | Tél./Fax : 01 39 30 83 40 / 01 39 30 83 01 | \\===================================================================//
i like "critical infrastructre." this is because, while i understand that the roots need golden space, and i can almost see that anycasted services need micro-allocations, i do not feel that tlds per se are critical in the sense that they need golden space. that would suggest an external reference to the term and other evaluation criteria than those proposed.
Also, could you elaborate on the difference between "micro-allocations" and "golden space"?
the use case for micro-allocation that ws used in arin, until cathy started screaming at me, was cnn.
there is a reason the dns maps from names to addresses. use it. Sure, we use anycast to support performant and resilient mapping.
i have sympathy for the anycast need. i do not have sympathy for non-anycast tds, and i run a number of them. randy
Peter, On Wed, Apr 15, 2009 at 3:43 PM, Peter Koch <pk@denic.de> wrote:
6.9 Anycasting TLD and Tier 0/1 ENUM Nameservers
Critical DNS infrastructure is defined as infrastructure providing Authoritative TLD or ENUM Tier 0/1 DNS lookup services.
The term "Critical DNS infrastructure" is defined here just to be referred to in one single place three paragraphs down. I'd prefer if the term would be avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be inserted at the appropriate place.
We could probably change this, but I think that the reasoning behind this definition was not only to use it as reference, but also to say that these DNS servers are different - all other domain names depend on them.
The organisations applicable under this policy are TLD operators as defined by IANA and ENUM operators as defined by the ITU. The organisation may receive up to four /24 prefixes per TLD/ENUM. These prefixes must be used for the sole
"TLD operators as defined by IANA" may be a well intended phrase, but many affected registries would reject being "defined" by IANA. 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. "TLD manager/administrator as described in RFC 1591" might be more acceptable.
I did some reading on IANA website and maybe the problem is that each of us imagine different thing under "defined by IANA" since I didn't find anything like this on IANA website. Since RFC 1591 and ICP-1 uses term 'designated manager' and other IANA documents speaks about "(re)delegation" would: "designated manager for TLD as delegated by IANA" be OK
Similar considerations apply to "ENUM operators as defined by the ITU". As a side note, ENUM Tier 0 assignments would probably have interactions with the policy proposal on "Assignments to the NCC".
ITU documents use these terms: 3.2.1 administrator: The organization entrusted with the administration of a resource derived from an international numbering plan. 3.2.2 assignee: The applicant to whom E-series international numbering resources have been assigned. 3.2.3 assignment: The process for providing an international numbering resource to an eligible applicant. 3.2.4 country: A specific country, a group of countries in an integrated numbering plan or a specific geographical area. so is "ENUM administrator as assigned by the ITU" more appropriate? Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ sip:ondrej.sury@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 -----------------------------------------
We could probably change this, but I think that the reasoning behind this definition was not only to use it as reference, but also to say that these DNS servers are different - all other domain names depend on them.
ahh, you meant the root servers. indeed, as one can not look them up using a resilient dymanic protocol, they ar eunique. the rest, try using the dns. randy
Thanks for the commets all, Ondrej and myself are in the process of tweaking the proposal to take these into consideration. We hope to publish a new version when the current review period ends and in advance of RIPE 58. Brett Carr Nominet.
Ondrej, Brett, thanks for your considerate responses. On Thu, Apr 16, 2009 at 05:21:15PM +0200, Ond??ej Surý wrote:
in one single place three paragraphs down. I'd prefer if the term would be avoided and "Authoritative TLD or ENUM Tier 0/1 DNS lookup services" be inserted at the appropriate place.
We could probably change this, but I think that the reasoning behind this definition was not only to use it as reference, but also to say that these DNS servers are different - all other domain names depend on them.
I respectfully suggest we don't even try to go down this path and for the reasoning I'd like to refer to Mohsen's message. He hit the nail on the head.
matter). The former makes more sense to me. "TLD manager/administrator as described in RFC 1591" might be more acceptable.
I did some reading on IANA website and maybe the problem is that each of us imagine different thing under "defined by IANA" since I didn't find anything like this on IANA website.
If you mean that some IANA document(?) ``defines'' the term, then that'd not be a problem. The way it is written looks like IANA would define _who_ the operator is. I assume we agree that's not the case, so
"designated manager for TLD as delegated by IANA" be OK
is better, but "recorded" would even better reflect the point that this is only to make sure there's a single database that is to be consulted -- and not how entries got in there.
As a side note, ENUM Tier 0 assignments would probably have interactions with the policy proposal on "Assignments to the NCC".
Not to forget this ...
ITU documents use these terms:
[...]
"ENUM administrator as assigned by the ITU"
I doubt that since ITU may have defined the term (then quote that reference) but does not assign the administrator rights. Similar to the TLDs, it's probably more important to give guidance where the list of operators is available. I'd assume that the ENUM Tier0 operator has such a list (and would have it independent of the fact that this is again the NCC with a different role). Regards, Peter
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.
Jim, Jim Reid wrote:
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.
I agree that the assignment should go to the registry. -- Shane
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
Editorial - B C wrote:
On Fri, Apr 17, 2009 at 2:34 PM, Jim Reid <jim@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
* Filiz Yilmaz:
The text of the policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM" has been revised. We have published the new version (version 3.0) today. The draft documents for the proposal have also been published, as well as the impact analysis that was conducted for this proposal.
This proposal does not allow for a local/global node split. Is this a problem? Section 6.9 make it clear whether the prefix is per service or per organization (that is, if an organization which runs multiple TLDs and ENUM receives one, two, or many prefixes). Should critical DNS infrastructure include DLV zones for public use? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Wed, Apr 22, 2009 at 09:27:45AM +0200, Florian Weimer wrote:
* Filiz Yilmaz:
The text of the policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM" has been revised. We have published the new version (version 3.0) today. The draft documents for the proposal have also been published, as well as the impact analysis that was conducted for this proposal.
This proposal does not allow for a local/global node split. Is this a problem?
Section 6.9 make it clear whether the prefix is per service or per organization (that is, if an organization which runs multiple TLDs and ENUM receives one, two, or many prefixes).
Should critical DNS infrastructure include DLV zones for public use?
$diety NO. --bill
-- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra_e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Should critical DNS infrastructure include DLV zones for public use?
$diety NO.
Why not? How it is different from ENUM? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Wed, Apr 22, 2009 at 10:27:01AM +0200, Florian Weimer wrote:
Should critical DNS infrastructure include DLV zones for public use?
$diety NO.
Why not? How it is different from ENUM?
-- Florian Weimer <fweimer@bfk.de>
DLV - as practiced by many - is a specific service offering by one vendor. ENUM on the other hand is a broadly defined/used service by many parties. I refer to Jim Reids posting for more reasons why DLV-specific policies by an RIR are short-sighted at best. --bill
On 22 Apr 2009, at 08:27, Florian Weimer wrote:
Should critical DNS infrastructure include DLV zones for public use?
No. Absolutely not. DLV is not critical to the operation of the Internet. [IMO it's a short-term hack that will go away once the root and/or major TLDs get signed.] The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM delegations are critical. If they went away, everyone would immediately notice that. If a DLV zone's DNS servers fail, an insignificant number of people would notice. DLV users are a fraction of the tiny number of people using DNSSEC today. Another point: anyone can set themselves up a DLV provider. So if arbitrary DLV operators were able to get anycast allocations, this would be a good way of depleting the remaining IPv4 space. At least there's a finite number of TLD and Tier-1 ENUM delegations which are underpinned by "official" registries and procedures for obtaining/ managing them. This is not the case for DLV providers (if I can use that vague term). Oh and what happens when the next flavour-of-the-month DNSSEC validation hack comes along? Should the policy be modified to accommodate that too?? BTW I am also uncomfortable with attempts to shore up DLV or to make it more permanent. That takes resources away from getting DNSSEC properly deployed by having the root and TLDs signed.
* Jim Reid:
On 22 Apr 2009, at 08:27, Florian Weimer wrote:
Should critical DNS infrastructure include DLV zones for public use?
No. Absolutely not. DLV is not critical to the operation of the Internet.
And ENUM is? Which part of the Internet depends on it?
The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM delegations are critical. If they went away, everyone would immediately notice that.
Could you name a ENUM delegation which is critical in this sense? (This is exclusively about e164.arpa and its children, right?)
Another point: anyone can set themselves up a DLV provider. So if arbitrary DLV operators were able to get anycast allocations, this would be a good way of depleting the remaining IPv4 space. At least there's a finite number of TLD and Tier-1 ENUM delegations which are underpinned by "official" registries and procedures for obtaining/ managing them. This is not the case for DLV providers (if I can use that vague term).
This is certainly the best argument, although it's rather discriminating. (Although the situation with TLDs will likely evolve into more general availability.)
Oh and what happens when the next flavour-of-the-month DNSSEC validation hack comes along? Should the policy be modified to accommodate that too??
Oh, come on, DLV is less of a hack than ENUM. At least it uses DNS for storing DNS-related data, and it's a rather good match conceptually (incremental dialing anyone?).
BTW I am also uncomfortable with attempts to shore up DLV or to make it more permanent.
I can understand that, but isn't this something beyond addressing policy? It's a bit like denying .BY an anycast prefix because you don't like the political situation over there. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 22 Apr 2009, at 12:05, Florian Weimer wrote:
* Jim Reid:
On 22 Apr 2009, at 08:27, Florian Weimer wrote:
Should critical DNS infrastructure include DLV zones for public use?
No. Absolutely not. DLV is not critical to the operation of the Internet.
And ENUM is?
Well it definitely has more people/applications depending on it than DLV. And unlike DLV, ENUM has paying customers and businesses which depend on it. Even in the public e164.arpa tree.
Which part of the Internet depends on it?
See above. Pretty much anything doing lookups in e164.arpa: Asterisk servers, various other SIP services, VoIP providers, smartphones, etc. ENUM may have a low usage. But unlike DLV, ENUM is not just for consenting adults: everything and anything can do an ENUM lookup straight out of the box. This is not the case for DLV because DNSSEC- aware validators -- a miniscule percentage of the world's resolving servers -- have to be specially configured, DLV policies need to be defined, key mangament issues have to be worked out, etc, etc.
The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM delegations are critical. If they went away, everyone would immediately notice that.
Could you name a ENUM delegation which is critical in this sense?
Well I know there are paying customers and commercial services dependent on ENUM in Austria, Romania and the UK. I expect this is also true other countries: I can't be bothered to look. FYI the Austrian regulator has set aside a block of their number space for ENUM-only telephony.
Oh, come on, DLV is less of a hack than ENUM. At least it uses DNS for storing DNS-related data, and it's a rather good match conceptually (incremental dialing anyone?).
This is not the forum to debate whether ENUM or DLV is a better use of the DNS. Please take this argument somewhere else.
BTW I am also uncomfortable with attempts to shore up DLV or to make it more permanent.
I can understand that, but isn't this something beyond addressing policy? It's a bit like denying .BY an anycast prefix because you don't like the political situation over there.
It's not like that at all. The policy can be summarised as "important DNS infrastructure can get an anycast allocation from the NCC". No more, no less. You're quibbling about what the definition of important is. So far the view on this list is that DLV zones do not deserve to be called important. IMO valid reasons have been presented to explain why DLV doesn't deserve one of these anycast allocations. You may well disgaree with that view. But you've yet to present any justification why DLV zones should be treated in the same way as a TLD or ENUM Tier-1 delegation. Saying "I think ENUM sucks" does not make that case. If you think DLV deserves these anycast allocations, present the justifcation and convince this list.
What Jim said. In addition, the way I see it is that DLV is a temporary measure until the root gets signed and all the world is happily using DNSsec. As this is only a very temporary situation, why make this part of permanent policy? If DLV needs anycast, file a proposal. Better yet - the RIRs in my experience have no problems doing temporary resource allocations for experiments, given a justification. Why not try that? Or will DLV be another artefact that will be around forever? Best, Remco On 22-04-09 13:42, "Jim Reid" <jim@rfc1035.com> wrote:
On 22 Apr 2009, at 12:05, Florian Weimer wrote:
* Jim Reid:
On 22 Apr 2009, at 08:27, Florian Weimer wrote:
Should critical DNS infrastructure include DLV zones for public use?
No. Absolutely not. DLV is not critical to the operation of the Internet.
And ENUM is?
Well it definitely has more people/applications depending on it than DLV. And unlike DLV, ENUM has paying customers and businesses which depend on it. Even in the public e164.arpa tree.
Which part of the Internet depends on it?
See above. Pretty much anything doing lookups in e164.arpa: Asterisk servers, various other SIP services, VoIP providers, smartphones, etc. ENUM may have a low usage. But unlike DLV, ENUM is not just for consenting adults: everything and anything can do an ENUM lookup straight out of the box. This is not the case for DLV because DNSSEC- aware validators -- a miniscule percentage of the world's resolving servers -- have to be specially configured, DLV policies need to be defined, key mangament issues have to be worked out, etc, etc.
The DNS servers for TLDs, and to a lesser extent, the Tier-1 ENUM delegations are critical. If they went away, everyone would immediately notice that.
Could you name a ENUM delegation which is critical in this sense?
Well I know there are paying customers and commercial services dependent on ENUM in Austria, Romania and the UK. I expect this is also true other countries: I can't be bothered to look. FYI the Austrian regulator has set aside a block of their number space for ENUM-only telephony.
Oh, come on, DLV is less of a hack than ENUM. At least it uses DNS for storing DNS-related data, and it's a rather good match conceptually (incremental dialing anyone?).
This is not the forum to debate whether ENUM or DLV is a better use of the DNS. Please take this argument somewhere else.
BTW I am also uncomfortable with attempts to shore up DLV or to make it more permanent.
I can understand that, but isn't this something beyond addressing policy? It's a bit like denying .BY an anycast prefix because you don't like the political situation over there.
It's not like that at all. The policy can be summarised as "important DNS infrastructure can get an anycast allocation from the NCC". No more, no less. You're quibbling about what the definition of important is. So far the view on this list is that DLV zones do not deserve to be called important. IMO valid reasons have been presented to explain why DLV doesn't deserve one of these anycast allocations. You may well disgaree with that view. But you've yet to present any justification why DLV zones should be treated in the same way as a TLD or ENUM Tier-1 delegation. Saying "I think ENUM sucks" does not make that case.
If you think DLV deserves these anycast allocations, present the justifcation and convince this list.
This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.
* Jim Reid:
Which part of the Internet depends on it?
See above. Pretty much anything doing lookups in e164.arpa: Asterisk servers, various other SIP services, VoIP providers, smartphones, etc. ENUM may have a low usage. But unlike DLV, ENUM is not just for consenting adults: everything and anything can do an ENUM lookup straight out of the box.
I don't think this is how things work. For sure, ENUM isn't enabled by default on many devices. Otherwise, a sizeable fraction of all calls to +1 numbers leaked to the e164.arpa server operators. This doesn't seem to be the case. Unfortunately, RIPE doesn't publish absolute query numbers, so it's impossible to even approximate how much ENUM usage there is out there. (Note that due to the way DNS works, the e164.arpa server operators see full phone numbers for non-delegated subtrees, and resolvers can't learn that a whole subtree does not exist, so negative caching only helps if the same phone number is called twice within the negative caching interval.)
This is not the case for DLV because DNSSEC- aware validators -- a miniscule percentage of the world's resolving servers -- have to be specially configured, DLV policies need to be defined, key mangament issues have to be worked out, etc, etc.
ENUM has to be specifically enabled by the end user, too. I would go as far to say that a German operator which ships a smartphone which performs ENUM lookups (perhaps indirectly) via e164.arpa has a very, very hard time fulfilling its obligations under §88, 109 TKG.
Well I know there are paying customers and commercial services dependent on ENUM in Austria, Romania and the UK. I expect this is also true other countries: I can't be bothered to look. FYI the Austrian regulator has set aside a block of their number space for ENUM-only telephony.
On the other hand, DENIC has been reporting for several years that demand for ENUM is below expectations, despite continuous marketing efforts. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 22 Jun 2009, at 09:27, Florian Weimer wrote:
Which part of the Internet depends on it?
See above. Pretty much anything doing lookups in e164.arpa: Asterisk servers, various other SIP services, VoIP providers, smartphones, etc. ENUM may have a low usage. But unlike DLV, ENUM is not just for consenting adults: everything and anything can do an ENUM lookup straight out of the box.
I don't think this is how things work.
It is. Compare and contrast the effort needed to setup DLV (and make it work) on a DNS server with that needed for an ENUM lookup. Now do the same thing for on-going maintenance and administration of both technologies. Why this discussion has popped up in address-policy-wg and not dns-wg is "interesting".... Anyway, I fail to see what point you're making or what relevance it has. Please don't bother to do that now: I'm long past caring. FWIW any clarifications you provide probably shouldn't go to this list. Discussions about ENUM query rates are best taken to the ENUM WG or maybe the DNS WG. There's a consensus here to have anycast allocations for Tier-1 ENUM delegations. It's not clear whether you agree or disagree with that. You've never said either way: at least not that I remember. Instead, you've tried to open up a rat-hole about making DLV a special case. When you suggested DLV zones deserved anycast allocations, nobody on this list appears to have been in favour of that. IIRC few people explained why DLV zones did not merit these allocations. At least not at present. That looks to be the consensus position, not that I speak for this list/WG of course. I also note that although you seem keen to open up and explore rat- holes, you're not coming forward with anything constructive: eg amended text for a policy proposal or even new drafts in support of your point of view. This is not productive. I strongly suggest you end this discussion -- what have DNS query rates under e164.arpa got to do with address allocation? -- or take it somewhere else. It's no longer relevant or appropriate for address-policy-wg@ripe.net. To summarise, the recent updates to the NCC's address policy allow for anycast allocations to be made for "important" DNS zones: TLDs and Tier-1 ENUM delegations. These are considered to be critical infrastructure (for some definition of that term), not just by the technical community but by governments and regulators. It is therefore responsible and prudent for the NCC to have an addressing policy that facilitates a technology (anycasting) which can improve the robustness and stability of those important DNS zones. DLV is not considered as important by these communities. At least not yet. If and when DLV gets that recognition, or appears to be getting it, that will be the time for amending the address policy to accommodate anycast for DLV. This of course does not stop someone like ISC using a chunk of their existing address space to provide anycast service for dlv.isc.org (or whatever). IMO, it's up to the DLV cheerleaders to make the case that their zones are "important" enough to deserve special anycast allocations. That case has still to be made.
* Jim Reid:
It is. Compare and contrast the effort needed to setup DLV (and make it work) on a DNS server with that needed for an ENUM lookup. Now do the same thing for on-going maintenance and administration of both technologies. Why this discussion has popped up in address-policy-wg and not dns-wg is "interesting"....
You claimed that ENUM is a critical service and therefore deserves special treatment as far as addressing policy is concerned. I think this is just wishful thinking. ENUM (in the public e164.arpa tree) hasn't got a significant user base. Certainly, it's not critical Internet infrastructure, and so it doesn't need special treatment for address allocation. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian Weimer wrote:
I think this is just wishful thinking. ENUM (in the public e164.arpa tree) hasn't got a significant user base.
FYI, ENUM concept to let callee side, who won't pay calling fee, determine the internet-PSTN gateway is broken from the beginning. Telcos managing telephone numbers of callees will, as a default gateways of callees, choose the most profitable (which is likely to be unnecessarily expensive to callers) gateway for the telcos and callees will be uninterested in the choice. ENUM could be fixed, if access telcos only are allowed to be delegated ENUM records and the telcos are forced to have gateways from which all subscribers of the telco can be reached at least expensive rate. Still, ENUM is not a very interesting concept.
Certainly, it's not critical Internet infrastructure, and so it doesn't need special treatment for address allocation.
True. Just as PSTN does not need public IP addresses, the Internet does not need E.164 addresses. Masataka Ohta
This of course does not stop someone like ISC using a chunk of their existing address space to provide anycast service for dlv.isc.org (or whatever). IMO, it's up to the DLV cheerleaders to make the case that their zones are "important" enough to deserve special anycast allocations.
Your example is essentially saying there is no barrier for a holder of an anycast address block, to offer more than one anycast service from that block. I think that address policy should be addressing that general case of an anycast network services provider rather than dealing with various special cases of applications that require anycast network services. --Michael Dillon
On 22 Jun 2009, at 12:20, <michael.dillon@bt.com> wrote:
Your example is essentially saying there is no barrier for a holder of an anycast address block, to offer more than one anycast service from that block.
Hmm. What you really seem to be saying here is there is no barrier for a holder of an address block to offer more than one service from that block. That principle should not come as a surprise. :-) To get back to the anycast allocation provisions, the new policy says these allocations are for DNS service for TLDs and ENUM Tier-1 delegations. So if the holders of these blocks used them for other things, they'd presumably be in violation of that policy.
I think that address policy should be addressing that general case of an anycast network services provider rather than dealing with various special cases of applications that require anycast network services.
I tend to sympathise with that view. However the current policy only concerns itself with anycast allocations for "important" DNS zones. Let's see how that works out in practice before considering how or if the policy should be extended. [My guess is the IPv4 shelves will be bare before we reach that point.] I'm also a bit concerned that a more liberal approach to anycasting allocations would be easy to game once the land-grab for the last chunks of IPv4 space kicks in.
Jim Reid wrote:
To get back to the anycast allocation provisions, the new policy says these allocations are for DNS service for TLDs and ENUM Tier-1 delegations. So if the holders of these blocks used them for other things, they'd presumably be in violation of that policy.
For essential services, it's fine to allocate an entire /24 or /16 for an anycast address that there is no point to have address blocks for multiple anycast addresses. Masataka Ohta
On Wed, Apr 22, 2009 at 8:27 AM, Florian Weimer <fweimer@bfk.de> wrote:
* Filiz Yilmaz:
The text of the policy proposal 2008-05, "Anycasting Assignments for TLDs and Tier 0/1 ENUM" has been revised. We have published the new version (version 3.0) today. The draft documents for the proposal have also been published, as well as the impact analysis that was conducted for this proposal.
This proposal does not allow for a local/global node split. Is this a problem?
I don't think it is a problem I don't believe the policy should refer to any type/implementation of Anycast.
Section 6.9 make it clear whether the prefix is per service or per organization (that is, if an organization which runs multiple TLDs and ENUM receives one, two, or many prefixes).
I had already decided that this needed clarification and it has been done int he new version.
Should critical DNS infrastructure include DLV zones for public use?
Definitley not DLV although it can be useful is a short term hack that hopefully will go away when the root (and some significant TLD's) is signed. Brett Carr
* B. C.:
This proposal does not allow for a local/global node split. Is this a problem?
I don't think it is a problem I don't believe the policy should refer to any type/implementation of Anycast.
If you assign a /24 instead of a /23, you rule out certain implementations. You can't reliably run cross-AS local nodes with a single /24 because a preferred, non-exported prefix typically suppresses announcements of the prefix---even if a non-preferred prefix exists which could be announced. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Florian, On Wed, Apr 22, 2009 at 10:38 AM, Florian Weimer <fweimer@bfk.de> wrote:
* B. C.:
This proposal does not allow for a local/global node split. Is this a problem?
I don't think it is a problem I don't believe the policy should refer to any type/implementation of Anycast.
If you assign a /24 instead of a /23, you rule out certain implementations. You can't reliably run cross-AS local nodes with a single /24 because a preferred, non-exported prefix typically suppresses announcements of the prefix---even if a non-preferred prefix exists which could be announced.
The purpose of the proposed policy amendment is two fold. 1. To expand the policy to cover enum aswell as TLD's. 2. To expand the usage from one nameserver to up to four nameservers. I think you raise a valid point above and this may be something that the working group needs to discuss further (maybe with input from the routing-wg) however I believe this is out of scope of the current proposal and if you feel this is important it could/should be submitted as a seperate proposal. Brett.
participants (14)
-
B C -
bmanning＠vacation.karoshi.com -
Filiz Yilmaz -
Florian Weimer -
Jim Reid -
Masataka Ohta -
michael.dillon＠bt.com -
Mohsen Souissi -
Ondřej Surý -
Peter Koch -
Randy Bush -
Remco van Mook -
Shane Kerr -
Wilfried Woeber, UniVie/ACOnet