a configuration that allows stale VRPs to be used for x time

[ties]

SAVNET at IETF114:

"RPKI data may just blip out of existence"

I was wondering if there are use cases where you may want to keep RPKI data that temporarily is unavailable around for RTR clients. This would prevent short publication issues at repositories from affecting the RPKI objects available.

A union over historic data feels like a data stream that may have use cases

[partim]

First, apologies for the inexcusably late reply!

Here’s my thinking with regards to data becoming unavailable: RTR has the expire interval, so actually failing to serve data if there isn’t any might be a better strategy – the unavailability becomes visible in the router monitoring etc. However, if that isn’t desired, we can add a config option to the RTR and HTTP targets to enable serving data until it has expired.

This would require tracking the expiry of the data of each unit – and determine it for source units in the first place – but that should be easy to add.

[ties]

For rtr inputs, the expire interval should handle this. But, I've seen json content going from full to empty. The units may handle this nicely though.

[partim]

Actual empty JSON content (i.e., it’s a valid JSON file but the respective member arrays are empty) should probably be treated as switching to an empty set? Non-parseable JSON (either not JSON or not following the schema) should probably be leading to the unit going stale and the expiry handling taking over?

[ties]

Actual empty JSON content (i.e., it’s a valid JSON file but the respective member arrays are empty) should probably be treated as switching to an empty set? Non-parseable JSON (either not JSON or not following the schema) should probably be leading to the unit going stale and the expiry handling taking over?

True!