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
