Dear all,
[ wearing no hats, speaking as working group participant ]
I support adoption of this document by the working group.
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.
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
Kind regards,
Job
On Fri, Mar 27, 2026 at 11:22:22AM -0700, Job Snijders via Datatracker wrote:
> This message starts a grow WG Call for Adoption of:
> draft-romijn-grow-rpsl-registry-scoped-members-01
>
> This Working Group Call for Adoption ends on 2026-04-10
>
> Abstract:
> This document updates RFC2622 and RFC4012 by specifying src-members,
> a new attribute on as-set and route-set objects in the Routing Policy
> Specification Language (RPSL). This attribute allows a specific
> registry to be defined for each member in a set, avoiding problematic
> ambiguity when resolving set members. A new validation rule allows
> gradual upgrades and backwards compatibility.
>
> Please reply to this message and indicate whether or not you support adoption
> of this Internet-Draft by the grow WG. Comments to explain your preference
> are greatly appreciated. Please reply to all recipients of this message and
> include this message in your response.
>
> Authors, and WG participants in general, are reminded of the Intellectual
> Property Rights (IPR) disclosure obligations described in BCP 79 [2].
> Appropriate IPR disclosures required for full conformance with the provisions
> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
> Sanctions available for application to violators of IETF IPR Policy can be
> found at [3].
>
> Thank you.
> [1] https://datatracker.ietf.org/doc/bcp78/
> [2] https://datatracker.ietf.org/doc/bcp79/
> [3] https://datatracker.ietf.org/doc/rfc6701/
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-romijn-grow-rpsl-registry-scoped-members/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-romijn-grow-rpsl-registry-scoped-members-01
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-romijn-grow-rpsl-registry-scoped-members-01
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
