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