Adding at least one such example on top of Job's observations, my biggest question is where the exclusion is getting implemented and whether there are consistency concerns. At least part of this question is motivated by laziness in not wanting to re-read 2622. :-)
What happens when you're talking to a bit of software expanding the sets that may not understand this new exclusion mechanism? My suspicion is you simply get the result without such exclusions. -- Jeff > On Apr 15, 2026, at 13:39, Job Snijders <[email protected]> wrote: > > Hi James, > > Interesting idea, thank you for bringing it up. > > Some years ago, as part of a tabletop exercise, I tried to imagine what > 'sets in RPKI' could look like, and from the get-go had 'exclusion' as a > feature in mind: > > > https://www.ietf.org/archive/id/draft-spaghetti-sidrops-rpki-asgroup-00.html > > but, working out the full complexities of inter-domain set theory > operations seemed daunting, and lacking architectural documents > detailing considerations around 'set exclusion' as a concept, me merely > specifying a binary encoding format was not the way to make progress. > > Please take this message as encouragement. I think that Gap analysis of > the RPSL (and proposed fixes) can in turn positively impact developments > in the space of (RPKI-based) signed routing intensions. > > Kind regards, > > Job > (no hats) > > On Wed, Apr 15, 2026 at 04:46:27PM +0000, James Bensley wrote: >> -----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 -- [email protected] >> To unsubscribe send an email to [email protected] > > _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
