Dear Pekka,
Yes. Let me clarify my objections: 1) special policy for ccTLDs (if they do not anycast) is not IMHO needed as assignments from (some of the) transits should be enough;
I agree that if a DNS operator is below a certain limit of DNS servers he does not have the need for anycast at all. But once you grow your farm beyond a limit anycast is the current best solution. DENIC for example had 11 different NS before we have started to deploy anycast to further enhance network diversity and capacity and simultaniously introducing AAAA records for our nameservers.
2) special policy for any arbitrary service, if anycast, does not seem justified because it's too open-ended;
In my first presentation I have voted for a more open policy. However I have seen no acceptance to this approach as the process of defining a network critical resource would take too long while I felt consensus that TLD nameservers are critical enough to justify special treatment. So I wrote a policy proposal that is only applicable for TLD nameservers. Why do you think this is open ended?
3) ccTLD combined with requirement to anycast it appears to be suitably well justified operationally and technically.
I have not limited my proposal to ccTLDs but includes any TLD.
In addition, a) we have enough address space that allocating a (v6) /32 is not waste.
If you have seen the updated version of my proposal I hope you will not see any problem iwth a /48 prefix.
b) I'm strongly opposed to creating any special micro-allocation blocks which is just waiting for getting the worms out hence a).
I don't see why you think that it is a bad idea to do the assignments for anycasted nameservers from a bigger block. Can you explain what makes the difference from spreading them all over the address range. Sounds like a security through obscurity approach to me. I haven't made a suggestion on how RIPE should manage their microallocation assignments. From my personal experience I would be an favour of a microallocation block as this bundles the efforts to eliminate routing problems that might exist.
So, I'd say that if the policy proposal is 3) with a (v6) /32, I shouldn't have a problem with it.
As said before, it is a superset of 3. with /48 V6 prefixes. Maybe it's best to take a quick look at the current proposal. Regards Andreas Baess