Hi, Gert Doering wrote:
Hi, [...] So there's actually just two thing that we want to decide *now*:
- do we want to change the rules for this specific policy to apply to other entities as well?
basically, yes. Anycast is a nice technology, works great for DNS and i don't like being hindered to deploy new technologies by outdated policies that much in general (even that i don't have any personal interest in DNS Anycast on the public internet atm.) What i'm not sure about is other-than-DNS Anycast usage. If anyone can come up with nice examples.... fine. Otherwise i would - for now - only deal with DNS-Anycast in any new/changed policy, and probably look into that issue again if there are clear ideas for other Anycast setups (on the public Internet). (That one is aimed towards those who would like to expand the policy change to anything beyond DNS...)
- if yes, what shall the new rules be?
Always a good qustion - which i don't have much clue about since i never felt the need for DNS anycast (yet). As an outsider here, i'd rather like to have a not-so-strict policy/rules about that on a first glance. I probably want to be able to anycast my own small nameservers just for the fun of it sometimes - "i don't get Anycast Addresses due to anycast policy issues? Ok then i will just use some PI/Unspecific for that" ... (i guess you all get the idea of what i want to point out with that fictional statement). But i'm not familiar with DNS Setups which would require/benefit from anycast, so i'm really out of ideas about possible boundaries for a yes or no.
The rules should always aim to
- solve the problem (so it would be helpful if organizations that are *not* a TLD operator but would want to do an externally-visible anycast setup to speak up, say what they are doing, and why it can't be done using the standard way to build nameserver redundancy "just put up a good number of them")
- be easy to evaluate by the RIPE NCC
I'd like to see some real-life ideas about WHY an entity wants to use DNS anycast here, too. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================