No, I don't say that. I'm not happy with these "numerical" requirements. But I'm *more* happy with the SOA count (in our case) then the 512 byte limit.
It is hard to do this kind of policy without numerical requirements. But we need to agree on what will be counted before deciding on the numbers. As you say, it seems bad to count bytes per DNS packet. Counting SOA records seems more reasonable but is still DNS specific and can be spoofed easily. However, counting data centre locations is harder to spoof and is more in line with IP addressing policy. We already allow physical locations as a justification for a subnet. Normally, we also count hosts within the location, but for IPv4 Anycast, multiple hosts hide behind a single IP address so host counting is problematic. Currently, the IPv4 Anycast policy seems to accept 99.6% wasted address space as OK. I am suggesting that the policy should try to reduce that waste, by offering a /24 to organizations which provide Anycast hosting services. Since you can't legitimately offer such a service without having some minimum number of data centre locations, then the policy could specify a minimum number. And if you gain more than 250 or so customers and need another /24 then that should be easy to get. People who want to anycast their DNS, then have the option to set up a generic anycast hosting service, or contract with a service provider who offers such a hosting service. And people who want to anycast something else, like map data or satellite photos, or financial data, can also use IPv4 anycast without chasing the RIR to change policies or pretending to be a DNS hosting service. And people won't complain that RIPE is anti-competitive. Technically, it seems to me that any hosting application which sends out predictable replies to queries from a static database could potentially benefit from anycasting. In any case, RIPE shouldn't tell people what to do, just make it possible for people to do things. --Michael Dillon