[GROW] Re: draft-bensley-rpsl-exclude-members

[Nick Hilliard <[e-mail]>]

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.

Some blue-sky, stream-of-consciousness thoughts:

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).

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.

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'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.

Nick

James Bensley wrote on 15/04/2026 17:46:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Dear Working Group Members,
>
> Please find below a newly submitted document: "Explicitly excluding objects from RPSL sets".
>
> The purpose of this document is to address the issue faced by many operators today; namely that AS-SETs and ROUTE-SETs contain member entries which are undesirable for one reason or another, but the set owner has no method to exclude these unwanted members from their own set because they are deep within the set hierarchy.
>
> I have spoken to several people in the community who suffer from this problem and would like something done about it. In the long term we hope to phase out IRR based filtering, but we are many years away from that, so in the mean time we’d like to improve the situation until such time.
>
> Feedback and support from the community is appreciated.
>
> https://datatracker.ietf.org/doc/draft-bensley-rpsl-exclude-members/
> https://www.ietf.org/archive/id/draft-bensley-rpsl-exclude-members-00.html
>
> With kind regards,
> James.
> -----BEGIN PGP SIGNATURE-----
> Version: ProtonMail
>
> wsG5BAEBCgBtBYJp38DUCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
> aW9ucy5vcGVucGdwanMub3Jnx8IJuTw/8rwqhuttwtzev2/G6pRZyujogxsc
> gPMJ50MWIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAi9cP/RJhqcE0KUP9QR8s
> /Q6S2iMBdn78ay9AlacMzyvH2rT5/9f9ld6X3WI10/TFAvYaTpk57KeRZDL2
> wwJZagIusJ1K4uhxDTzKU8OYLE3buH1+2U5kysxBmmW3nQQzdvPkAGFKaAhl
> 5Hpxd0q59p8RsmaumBRIWbDOHYq3YA6Ps3CNoBS2zh3hx6LDEDzm0Kr8g6El
> CkFdBq2rQFuvq8ZLR8nQ1aUhFGS7G1xxPES/2jLOjnf1A9E8Fp//QsP1FONN
> OttVKHFVaSbV72Cp3H1+qAqlcJ+qlZ0xAH2R6bAYQUbC+rU09LhYSF1q1krq
> IfZCvoHgrg6f5xkjOZH4yau3i17hEL/8yBTaYxMeNiCQE7BT4yd5YTMhgHKw
> RdjNJlS29i1ksYcB4cUNrx41JWUt8m/XRvY5tLfI277gWlPasehRfRXvebVF
> T/Gha3ar5FeXVgtnkl5suH4vYdjI8RaRcA3wqrXs/oGDkzl73Zjp/FXdNUQc
> Z1xK2XqjgPnL6AQkL4Ybh+5BR0pOePladBwB+dxWeE05GF0HMfBsJCKw20Yc
> T/xQP0WJU6ZPKG1ET8RNKdpIA93tHthHymU+MWC//dUdB6+uZlmv2GlC2Y2T
> +2dSe3iKvpo0/l4uiWM9OccJ7UYkk8De420E9XRxMyCypQyf1VVb0GgLCAFN
> xXxR8fO/
> =AkAY
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> GROW mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]