there was once a time, I liked your brief statements. This one is now so brief and cryptic that I simply don't fully get the message between the lines.

i suspect the problem here is not brevity but rather understanding of the origin validation work and perception of the social and technical function of the ncc.

...

https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-re...

...

We are considering changing the interface to make ROAs only valid for a limited time, for example one year. This means that at least once a year, ROAs need to be reviewed and renewed by the operator, giving them a chance to compare the ROAs against real-world BGP.

we think you should be doing something annually. so to force you into doing so, we will break your network unless you do it. fracking brilliant!

let us remember that, once upon a time, ripe and the ncc had an oft- repeated statement that they were not at all involved in routing. this was seen as good. to me, it still is. unfortunately, because it is based on authentication of the address allocation hierarchy, the rpki involves the rirs and nirs. as this hierarchy is used to authenticate *routing* objects, rpki roas, this involves the rirs/nirs in routing. the statement i quoted from the url above is a really scary example of an rir saying they will use a threat to routing to *encourage* what they see as desirable social behavior. i am utterly uninterested in whether that social behavior is desirable or not. i am exceedingly disturbed that a threat to my routing is used to affect social behavior. and remember, a roa is not even allocation certification. it is an object i ask to have created to express an aspect of my routing policy. a mediocre anolog: should all route: and route6: objects be deleted from whois/irr if they have not been updated in a year? randy

On 24 Feb 2012, at 11:18, Randy Bush wrote:

ok, so that was not what one would call a delicate statement of the problem. :)

my apologuies to alex. he just finished applying the clue by four in IM. of course, there is a serious problem he is trying to address.

Thanks Randy. The problem poor RPKI data quality. I realize its not up to the RIR to fix user mistakes, we're just trying to help. The problem could solve itself: if operators would start relying on the RPKI data set and give the invalid announcements a lower pref (or even drop them) then operators who created the bad ROAs would be pressured to fix their mistakes. The concern is that nobody would start using a data set with this quality in the first place. The implementation that we've done with the hosted RPKI platform was geared towards creating a low entry barrier into the system. Members don't have to worry about any of the crypto aspects, but solely focus on entering data. ***In the hosted RIPE NCC RPKI system, a certificate and all of its child objects are automatically renewed every year without any user intervention and interaction, for as long as the member is the holder of the related resources.*** It's this aspect that we feel we've taken too far. When using a package like rpkid, the user is more involved and things actually expire if you don't do something periodically. In short: the proposal is not to *delete* ROAs, it's about stopping fully automated renewals. If folk think that's a good idea, of course we would implement various alerts, well ahead of time, that user attention is required. Of course we will also put effort in education, and providing a playground for testing. -Alex