On 14 Mar 2013, at 15:44, Jim Reid <jim@rfc1035.com> wrote:
On 14 Mar 2013, at 12:20, Gert Doering <gert@space.net> wrote:
On Thu, Mar 14, 2013 at 12:41:33PM +0100, Andrew de la Haye wrote:
2) A PI End User requests a resource certificate through their sponsoring LIR and gets access to the ROA management system themselves, or delegates management to the sponsoring LIR
3) A PI End User requests a resource certificate directly from the RIPE NCC, without becoming a member, and obtains access to the ROA management system
Supporting both 2) and 3) seem to make sense to me.
To avoid creating a high workload, 3) would need to be done in a mostly automated fashion - similar to what is happening today: if the sponsoring LIR sets up a mntner object that permits the end user to create their own route:/route6: objects, the end user can create "old-style" route authorization without involving the NCC. Something like this, sort of "between 2) and 3)" - the sponsoring LIR creating an access code of some sorts, and the end user using that to talk to the NCC systems.
Could it actually be that straightforward? It seems unlikely, though I hope otherwise.
Just to clarify option 3: a Resource Certificate is not for identification purposes, nor does it contain identity information; this is what the Registry is for. All that the RIPE NCC needs to ensure is that we issue a certificate to the party who has authoritative control over the address space. Establishing this could be done using the maintainer of the relevant INETNUM object, for example, which means it could be implemented in an automated fashion, as Gert suggests. It all depends if that is "good enough". Every additional check that is required, such as submitting paperwork, will add to the complexity, cost and labour involved, but could very well be worth the effort. All of this will be evaluated and taken into account when taking the decision on the actual implementation. Cheers, Alex