This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg] Adding "::" notation to RIPE DB
- Previous message (by thread): [routing-wg] Adding "::" notation to RIPE DB
- Next message (by thread): [routing-wg] Adding "::" notation to RIPE DB
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sander Steffann
sander at steffann.nl
Mon Nov 7 15:40:49 CET 2022
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
- Previous message (by thread): [routing-wg] Adding "::" notation to RIPE DB
- Next message (by thread): [routing-wg] Adding "::" notation to RIPE DB
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]