Hi Nick, Sorry for the delay in my reply.
> well, not quite true. The RIPE DB implements RPSLng which is defined in > rfc4012 and previous rfcs. The best place to get this changed might have > been at the IETF, but it's not likely that people are going to be much > interested in RPSL updates there because they're really lost interest in > RPSL in a big way. Probably GROW would be the best working group if you > want to try. See my discussion with Markus. TL;DR: - All of the 5 RIR IRR-DBs have non-standardised stuff in them. - None of them seem to have any clear documentation on how to make changes to their respective DBs (after how many years?) such as; must changes be standardised, how is it decided that a suggested change is valid, who should one talk to about these things, etc. - Having new stuff be standardised in an RFC make sense however... - As I said in my email to Markus, if we pretend I got a new draft into GROW and eventually published, "then what?". How does one get that implemented in the RIR DBs (RIPE to start with)? > RPSL is broadly based on set theory, and from this point of view, it > would certainly make sense to have an exclusion operator, at least in > theory. The problem is more that RPSL is something that doesn't work > well in practice for a number of reasons and no amount of tweaking > around the edges is going to be able to fix it. Language grammar > inflexibility is one of these areas. Another is restriction of object > scope to specific IRRDBs. Both of these issues would impact on your > suggestion. I think the 2nd part is a valid concern about object scope. The first part I find concerning. It reads to me a bit like Markus' response, that (paraphrasing) we shouldn't be trying to improve something that isn't working as well as it could, and just implement hacks to work around it. Kind regards, James Bensley (he/him) Inter.link GmbH Boxhagener Str. 80, 10245 Berlin, Germany Email: [email protected], Phone (general): (+49) 030577123821 Phone (mobile): (+49) 015792522412 Registry: Local court Charlottenburg, HRB 138876 Managing directors: Marc Korthaus, Theo Voss ________________________________________ From: Nick Hilliard <[email protected]> Sent: 25 October 2023 18:28 To: James Bensley Cc: [email protected] Subject: Re: [routing-wg] Adding an "exclude-member" field James Bensley wrote on 25/10/2023 15:44> What are you talking about? There are no standards I am aware of > which states how third part open source tools (irrd/bgpq4/irrtree) > must operate. Equally for IRR DBs. The RIPE team are able to add/edit > DB fields, based on community demand (they have done this in the past > and are open do going it again), and it is not restricted by any > standards I know of. well, not quite true. The RIPE DB implements RPSLng which is defined in rfc4012 and previous rfcs. The best place to get this changed might have been at the IETF, but it's not likely that people are going to be much interested in RPSL updates there because they're really lost interest in RPSL in a big way. Probably GROW would be the best working group if you want to try. [...]> I'm interested to here if other people are in favour of this idea or > not, and what they like / don't the like about it. Also, is it worth > discussing in person at RIPE87? RPSL is broadly based on set theory, and from this point of view, it would certainly make sense to have an exclusion operator, at least in theory. The problem is more that RPSL is something that doesn't work well in practice for a number of reasons and no amount of tweaking around the edges is going to be able to fix it. Language grammar inflexibility is one of these areas. Another is restriction of object scope to specific IRRDBs. Both of these issues would impact on your suggestion. Nick -- 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
