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

[Job Snijders <[e-mail]>]

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