> On 13 May 2015, at 11:42, Job Snijders <[email protected]> wrote: > > On Tue, May 12, 2015 at 03:58:31PM +0200, Alex Band wrote: >> We've been getting a lot of requests to make processed RPKI data >> easily available in existing (RPSL based) workflows. This is why we >> added the ability to export all ROAs as route: objects in the latest >> release, version 2.19. Practically, this means that running an RPSL >> export will give you almost 450,000 highly reliable, cryptographically >> validated route: objects. >> >> This functionality should be considered beta for now, because we would >> like to get your feedback on the notation and the way we de-aggregate >> ROAs into route: objects based on the specified maximum prefix length. > > Interesting! I was considering writing a script to do this, but the NCC > beat me to it! :-) > >> The format looks like this: >> >> route: 193.0.12.0/23 >> origin: AS3333 >> descr: exported from ripe ncc validator >> mnt-by: NA >> created: 2015-05-07T10:01:56Z >> last-modified: 2015-05-07T10:01:56Z >> source: ROA-RIPE-NCC-RPKI-ROOT > > Wouldn't it make sense to align the "created:" date with something more > specific to the ROA rather then the export date?
sure > Another consideration might be to create a "expiry-date:" derived from > the ROA's expiry date for easy debugging purposes. Adding a new > attribute should not have adverse effects on the generation of > prefix-filters in the toolchains I am familiar with. It would require a bit more work but along that thought we could sure do something like this: created & last-modified: signing time of the ROA embedded certificate (it cannot be modified without re-signing) expiry-date: expiry date of the ROA embedded certificate last-validated: date and time of validation We haven't done anything like this yet, because we wanted to be sure that there is operational value for having this first. So please let us know! Kind regards, Tim > > Kind regards, > > Job >
