Re: [ncc-services-wg] RPKI Resource Certification: building features
1) We have not implemented support for this yet. We plan to go live with the fully hosted version first and extend it with support for non-hosted systems around Q2/Q3 2011.
this is a significant slip from the 1q11 we were told in prague. care to explain.
Randy Bush who is cc-ed may be able to provide some more insight in the features offered by the ISC rpkid. I don't know whether the features mentioned by Alex in his first message will be supported by this system.
calling it isc's is a bit incorrect, but no difference. it is an open source, bsd license, i.e. free as in free, implementation of all of the rpki protocols, provisioning, up/down, publication, relying party, proto-gui to manage your resources, ... the full monty. it has been operational in a testbed with isp players from asia, the states, europe, ... for some time. randy
On 4 Oct 2010, at 23:18, Randy Bush wrote:
1) We have not implemented support for this yet. We plan to go live with the fully hosted version first and extend it with support for non-hosted systems around Q2/Q3 2011.
this is a significant slip from the 1q11 we were told in prague. care to explain.
Let me run you through the roadmap and the motivation for our choices at RIPE61. In short, everything we do is about providing *value* for our membership and the community. This means that with the resources we have, we have to make a choice between (1) offering a solution with every feature under the sun, but contains little value and usability or (2) we choose to do a phased approach where the entry barrier into the system is low, hassle is taken away from the operator, value and user-friendlyness is high while still being standards compliant and keeping the operator in the driver's seat. Soon we'll get to the full package where all options, like running your own CA, are available. It perhaps just isn't done in the order that a purist would like to see. Let me illustrate with two examples: I've delivered full day training courses on Routing Registry and DNSSEC. With the RR course, by the time I was done explaining how to use the IRRToolset to aid in making routing decisions based on the IRR, people had given up and decided that doing it manually was easier. Like you said at RIPE60: "people are voting with their feet." In the DNSSEC training, by the time I was done explaining how to do a manual key roll-over, most LIRs decided 'this is not for me, the cure is worse than the disease'. This is why I want to get back to my original point, Randy. You agreed in your first reply to me that something has to be done to create an easy way to get started with the system. We can provide a full, standards-compliant solution with up/down and every other feature, but how is that going to get all ~350,000 prefixes and ~35,000 ASs into the system with ROAs? Manually? I proposed an IRR+BGP import system as a value-added tool to help a network operator get started making ROAs. That's a pretty good starting point. Where do you suggest we go from here? Of course I appreciate everyone else's response to this thread as well! :) Cheers, -Alex
alex, i am not gonna argue with you. 96% of your users will be happy for you to do everything for them, despite the fact that the wrong holder has the keys (and, as john says, the liability). but 96% of your address space, i.e. the large holders, will want to hold their own keys and talk up/down to you and deal with publication points. kinda like the irr. so write back when you have done the full job. randy
participants (2)
-
Alex Band -
Randy Bush