Re: [sidr] about grandparenting

["Murphy, Sandra" <[e-mail]>]

speaking as a regular ol' member:

On Tuesday, August 14, 2012 10:07 AM, Andy Newton [[e-mail]] said

>I'm not speaking for anybody but me here, but I would think 
>that the notion of RIRs issuing "operational" ROAs would be 
>a BIG layer 9 issue.


Given all the caveats below.

If you believe RIRs should not issue ROAs, what would be your preferred method to deal with that: (a) relying party policy - reject ROAs signed by x,y,z keys, (b) cert policy - some words in the CP (c) operational - registries promise not to implement a feature in their code that would allow this (d) contractual - the registry agreement promises that they will not do this,  (e) technical - some bits in the RPKI objects, etc.


(Why did you speak of an "operational" ROA?  What would a non-operational ROA be?)


List of caveats:

I presume you aren't implying that you think the RIRs will be the only or the primary members of the RPKI hierarchy.

And of course you are not speaking of the IANA objects that are now published as an RFC.

And of course you are not speaking of RIRs that have decided to run a hosted service for their members, where code on the RIR system is actually doing the signing operations that create ROAs that their members have requested.

And of course you are not speaking of RIRs who hold address space for their own operational purposes, eg for registry servers and such.

In the spirit of the IANA objects, I can see a potential of an RIR signing a ROA for the /8 from which they are allocating (or v6 equivalent) to keep bogus superblock announcements from being accepted.

--Sandy, speaking as regular ol' member