I would suggest a slight re-phrase:
"Operators providing DNS for a zone served by a number of name servers such that the total response size when including the list of nameservers for the zone is close to the UDP packet size limit may be assigned PI network prefixes for the purpose of anycasting name servers, as described on RFC 3258. These shall be: a /24 IPv4 prefix and/or a /32 IPv6 prefix."
Given that the issue is the will to anycast due to the operational impact of adding more servers to the list, not just the size of the NS RRSET itself.
I see your point and it's the same thing I had in mind when I wrote the policy down. I don't think that it makes sense to work to hard on an exact definition when someone classifies for an allocation.
It depends on how tight we want to knit the mesh (and emphasise conservation et.al. :-)
As well it is impractical to say you have to cross the limits first (and prove that your clients are suffering from it) before you can get your allocation.
Agreed.
I thought that those who are attracted by the policy will have no problem justifying it and RIPE would have no problem to ask people returning the networks if they do not use them as stated in the policy. But maybe my thinking is too positive here.
I guess everything which essentially gives you easy access to a PI /24 (/32 for that matter in the long run) is going to attract interest, at least eventually. Thus here are my questions for double-checking my own mental picture and assumptions: - the applicant has to be an established LIR - correct? - as setting up a server and finding slaves, plus anycast in general is not really rocket science: is there any closer definiton of "Operators providing DNS for a zone served by a number of name servers..." - would my own domain (say - netcraft.at) qualify as well? - and trying to reclaim that address space would be pretty cumbersome for both parties, I guess, unless the zone (all zones on those servers?) go(es) away _completely_ ?! Cheers, Wilfried.