[Sidrops] Re: Call for WG Adoption of draft-snij-sidrops-constraining-rpki-trust-anchors

[Tony Tauber <[e-mail]>]

I appreciate the problem and the proposed solution as well as the
evolutionary vision that is expressed.

I support adoption.

Thanks,
Tony

On Wed, Jan 21, 2026 at 1:36 PM Job Snijders <[e-mail]> wrote:

> Hi John,
>
> On Tue, 20 Jan 2026 at 18:32, John Kristoff <jtk=
> [e-mail]> wrote:
> > On Mon, 19 Jan 2026 13:46:55 +0100
> > Luigi Iannone <[e-mail]> wrote:
> >
> > > Title: Constraining RPKI Trust Anchors
> >
> > Are there risks of stale or divergent, to the point of being
> > operationally problematic, constraints at the RPs? In other words,
> > could this lead to something akin to statically deployed bogon
> > filters? If I'm interpreting the text correctly, this depends on how
> > and where the EE certificates are maintained?
>
> https://datatracker.ietf.org/doc/html/rfc8416.html#section-6
>
> The constraints content is controlled by the RP operator. What those
> entities configure their constraints to be is up to them. In this sense
> the concept is not so different from /etc/pf.conf, /etc/nftables.conf or
> /etc/rpki/skiplist, or the selection of TALs an RP instance uses.
>
> I've seen some operators prefer to deploy by hand, and some automate via
> apt update, some sysupgrade, some fetch updates via EPEL. I imagine
> implementers could offer the operators knobs to configure self-expiry of
> constraints content.
>
> The goal of this document primarily is to specify where in the RPKI
> validation process constraints are attached as information policy, and
> as secondary goal is an standard format for interexchange to express
> constraints and make communication about constraints monitoring easier.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>