Hi Nick, Thanks for providing some feedback.
On Thursday, April 16th, 2026 at 15:57, Nick Hilliard <[email protected]> wrote: > So, yes. RPSL did try the set theory thing and in theory this idea could be > workable, maybe. > > Flicking back through rfc2622, I'm reminded of the horrors of mbrs-by-ref. I > know it's inexcusably poor taste, but I can't help wondering whether you > should also include a excl-mbrs-by-ref? Probably better to leave this for an > April 1 RFC. I have a split opinion on this - it seems like a valid request to me, but few initial thoughts are: 1. I can use the proposed exclude members field to exclude anything, included sets included by mbrs-by-ref (although not as efficiently, I would have to specify each RPLS key to excluded, so it would just be an efficiency gain to excl-mbrs-by-ref, but that leads me to 2...) 2. Some sort of excl-mbrs-by-ref might exclude too much, I only want to exclude some stuff covered by the maintainer so I'll still need to fall back to the proposed exclude members field to do a partial exclude? 3. My understanding is that mbrs-by-ref isn't used that much, so is this worth it? This is off the top of my head and not thought through in depth. I can try and pull up some numbers on mbrs-by-ref usage if you think it worthwhile? > Firstly, any output is going to be acutely dependent on how > draft-romijn-grow-rpsl-registry-scoped-members operates. I haven't got to > that yet in my ietf draft consumption backlog, but my first thoughts would be > that the source:: scope would need to be applied aggressively to child > objects (maybe it is already). Due to being a co-author of draft-romijn-grow-rpsl-registry-scoped-members, that is fully catered for in this document. > There's plenty of scope for exclusion to create operational problems. E.g. > what happens when you have different sets which reference each other and then > one of them is configured to include the other as an exclusion? There's no > shortage of foot-guns here. I have tried to think about this; I couldn't come up with a foot gun scenario, and I had already thought through stuff like order-of-operations type stuff that might arise. See section "3.3. Cumulative Excludes", if I've missed some scenario which leads to a new foot gun I haven't foreseen, please let me know, I obviously want to avoid that. > A complete set theory implementation would ideally include operators for > union, intersection, complement and all that. You can synthesize it kinda > with a simple exclusion mechanism, but I wonder about data consistency and > general flexibility. > > There are two main problems with RPSL. One is grammar flexibility, of which > there is very little, which is why any extension needs a new key mechanism > defined. The second is that it inherently requires symbolic expressions, > which increases the complexity of the parser. > > So, if I were approaching this - which I'm not - I'd might be tempted to look > at this from the point of view of pure set theory and design a key which > allowed complex set manipulation grammar. I.e. create a full mechanism for > symbolic manipulation of as-sets. Any existing code implementation already > needs to deal with a good deal of symbolic manipulation, so this may not be > as problematic as it seems at the outset. I'm split on this, like the earlier point - I see it as a valid point, but like the earlier point, it's not clear to me how worthwhile this would be. I think most people are only interested in including everything in set X, and for some of us, to then exclude a few bits (hence the document). I'm not aware of people with more syntactically advanced use cases (I'm happy to be corrected here). > I'd also ditch extending route-set objects - no-one uses them really. Also > draft-romijn-grow-rpsl-registry-scoped-members does not apply to route-sets, > so you'd have a lot of work to do if you wanted to make this work properly. Happy to :D My opinion was that route sets are basically dead, but I felt that if I left them out, the first feedback I'd get is from the one network still using them "WHY U NO ROUTE SETS!!!". With kind regards, James.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
