Hi Sasha, > You could work around this by adding the prefixed and non-prefixed name, > but that will produce inconsistent results depending on a prefix-aware > set resolver, and risks duplicate records getting out of sync.
Maybe something could be automated on the server side (which in this case would mean RIPE DB), but I have the feeling that this would get ugly pretty fast (add a new qualified-member: attribute which auto-generates a member: attribute?). > Other than that, the only way I see is to first enable support for this > in common AS set resolver code, and only support its use in objects once > resolver updates are widely deployed. But that will take quite some > time. It’s not terribly complex to add support to IRRD v4, but then we > will need all operators to upgrade, and some are still on v2/v3. There > will also be custom internal set resolving code in some organisations. This would definitely be the cleanest way forward, but as you say it will take a long time (decades?)… I’m torn between the quick solution and the clean solution. Does anybody have better ideas? Cheers, Sander -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
