-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Friday, April 3rd, 2026 at 11:37, Job Snijders <[email protected]> wrote: > I'd also like to express some caution: I'm not yet convinced it should > be published as RFC. My lived experience with extending RPSL, is that > the devil always is in the details. By and large extending RPSL has > proven to be unreasonably hard. Incremental deployment and backwards > compatibility will need to be careful considered and tested. Having said > that, I do appreciate that the authors already gave special attention to > backwards compatibility and included some considerations! It would be > good to get a feel for the value of this concept in a mixed deployment > environment. I think this is best done by collaboratively working on > this specification as working group document.
Hey Job,
We are working on another draft which also extends RPSL. Before starting on the
other draft, I asked in the RIPE Routing WG if these RSPL syntax changes could
be made without an RFC, the overwhelming response from the community was "no".
So here we are. I think the way forward, as you say, is to ensure we provide
something doesn't change existing syntax and is fully backwards compatible.
That is definitely our goal here. With the $dayjob hat on, we're happy to run
this and test this idea in our production network.
> A small suggestion for section 3.2: "Automatic generation of (mp-)members".
>
> When generating {mp-,}members: attributes from src-members, it might
> be good to have the specification suggest a comment is also generated
> alongside the {mp-,}members: attributes to aid debuggers and hint on
> where data came from. Here is an example of what it could look like:
>
> route-set: RS-EXAMPLE
> members: 192.0.2.0/24 # Synthesized from src-members
> mp-members: RS-OTHER, 2001:db8::/32 # Synthesized from src-members
> src-members: 192.0.2.0/24, RIPE::RS-OTHER, 2001:db8::/32
> source: EXAMPLE
>
> Or alternatively, something could be done with 'remarks:'?
>
> The above suggestion is inpired by the IRRd v4 convention where a RPSL
> comment is used to provide some additional context around RPKI-based
> synthesized route/route6 objects, see this example:
>
> $ whois -h rr.ntt.net 2001:67c:208c:: | grep source
> source: RIPE
> source: RPKI # Trust Anchor: ripe
>
+1, very practical idea.
Cheers,
James.
-----BEGIN PGP SIGNATURE-----
Version: ProtonMail
wsG5BAEBCgBtBYJp2hQaCRCoEx+igX+A+0UUAAAAAAAcACBzYWx0QG5vdGF0
aW9ucy5vcGVucGdwanMub3Jn+O7lsQk2fLd/eYKkK41vaRtGnrOIP+JEKOQ8
je3uP+0WIQQ+k2NZBObfK8Tl7sKoEx+igX+A+wAAEFcQAK/7qsQ0nMhSyeVo
P+cPiMTA1fCvCXUokOW5HZkA3girRgu3VpFpVnn9weUpJvVH9hHci9DY2FTn
/3DbMwTIp8LrONE+aH8dyD6THGU5D1JdM9w/ZNTkx2gcH3jyIo1ZZD7HK5rY
6VfOS/d+PJuVG46fpcYusmezOYdw6YHPjj0wNyG55JV5+pQuwx7wwojyd/Uo
tj0RrfChIRaOB4uOq/lsynR4k7YT7eNGS/GU/V8njOptvZH8S1vyxIxVy0yM
P49kE3vFueZDCcJQKESk0a2YX3lJXVyquIDTVGiwoP1VRKhEdfAsLY7Is3tI
ossy8oE0z2db3k3Ull7eU6OA0sWI+y3e4E5o3lfjcPd8lHFBT2w4AZ0Os3l+
vBY9fwEQxOUJT9LhZQSJpWr71v+/EgoXTcsM7uJ+B613NoCE4wmJRw+KuSsL
ddER4DVMMli13pEF7+fa0gHwT9AtA9LYq5KnLGwOGtH48qkSLYKW//ii+fz0
05V8V5wggFXcb3BQsFLuTX5fcuiqD0TkM6R0o0NvF3NFEstsxDINfjronOl1
Hs7/WY5Ft6X1Nsf66j+KbMjYtWR4r81cjGPwWGL6odMTe4xvMeoGHYF0eUjX
Gicwq/VBBix+JEPdFdhe7YqxWPcydQYGDdUfTUmkrRtajnSgOlA1WNzv1znB
H/nGNyhF
=4waJ
-----END PGP SIGNATURE-----
publickey - [email protected] - 0x3E936359.asc
Description: application/pgp-keys
publickey - [email protected] - 0x3E936359.asc.sig
Description: PGP signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
