On 26 Mar 2013, at 13:39, Alex Band wrote:
The cost estimate is based on treating option 2 and 3 completely individually, but there is indeed a lot of overlap in the implementation. Most of the development work goes into building the framework for associating a certificate with address space to a non-member. This means implementing both option 2 and 3 would not result in a significantly higher cost than offering just one of them. There is overlap in the running cost as well, for example in terms of support and auditing.
With regards to scaling, there are two elements to keep in mind:
a) Users requesting a certificate and entering data into the hosted RPKI system b) Users querying the RPKI repository for the content we publish
With regards to a), the current RPKI infrastructure that the RIPE NCC runs is capable of handling certificates for all members and non-members and any ROAs they might create. There is no additional scaling needed on that end.
As for b), depending on the amount of queries that our RPKI repository will receive, it will need to be scaled up. As more people enter data into the system, the usefulness of RPKI as a whole grows and with it the likelihood that people will want to query the repository. It is very hard to estimate at what pace data usage will grow, all we can say now is that the amount of queries to our repository is very low. Lastly, the RIPE NCC doesn't necessarily need to be responsible for distributing the RPKI related content set all by itself.
I hope this puts things in perspective for you.
Thanks, Alex; that helps. /Niall