[routing-wg] Adding "::" notation to RIPE DB

I would look at the precedent of things like RIPE-NONAUTH for time and duration. 

Sent via RFC1925 compliant device

> On Nov 9, 2022, at 8:02 PM, Netmaster (exAS286) <netmaster at as286.net> wrote:
> 
> James Bensley wrote on Wednesday, November 9, 2022 5:42 PM:
>> Only when RIPE DB users start to update their AS-SET members field and add
>> a source tag would operators with legacy IRRd versions start to have issues,
>> and then they would have to update. But before that happens we can publicise
>> the upcoming changes and give people a fair warning, we can try to provide
>> resources on what the changes are, why they are beneficial [...]
> 
> How many *years* you think is a "fair" warning before others have to accept,
> that their own tooling breaks? (There's more than bgpq4 and IRRd and code
> doing !i queries). 
> 
> Two, six or more than ten? 
> 
> Don't get me wrong, I like the idea to ensure, the right AS-SET is being
> used and I know the pain, if not. Getting AS-SETs unique across all RRs or
> being able to clearly identify the right RR to use would be great. (Even 
> though I would assume adoption might take -after the warning period- still
> many years for a significant amount of updated AS-SETs to be seen.)
> 
>> Firstly, I don't think we should be trying extra hard to maintain backwards
>> comparability with IRRd v2/v3. If one allows customer/user inertia and/or
>> ineptitude to steer the ship, Windows XP would still be in wide spread use,
>> IPv6 adoption would never become wide spread, and so on.
> 
> Breaking things just "because it helps" might not be the best choice. And
> your example about XP is not right. Because your proposal comes closer to
> turn off v4 (before a v6 stack was available for XP).
> 
> I think we should try extra hard to maintain backward compatibility and only
> if most agree, there's no other way and breaking things is the only way to
> go forward and this saves the world, then it should/might happen. 
> 
> I think goal you like to achieve, the approach likely will not materialize
> soon or at all. There might be and should be other ways ...
> 
> 
> Markus
> 
> -- 
> 
> To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://mailman.ripe.net/