speaking as regular ol' member On Oct 30, 2014, at 11:59 AM, Geoff Huston <[email protected]> wrote:
> >> On 29 Oct 2014, at 10:17 am, John Curran <[email protected]> wrote: >> >> On Aug 11, 2014, at 11:58 AM, Tim Bruijnzeels <[email protected]> wrote: >>> … To be honest, I get a bit confused as to whether we are considering the case of planned transfer actions, or some unanticipated reduction in a certificate's resources. If we're talking about the planned case, then: > > If I understand your note here, you are suggesting that the CA issues a new > cert for the to-be-transferred resource and revokes and reissues the original > "omnibus" cert to have all the resources minus the to-be-transferred > resource. Yes? Or, as another idea, leave the original certificate in place but also issue two certificates, one for the retained space, one for the transfer space. If I'm planning on transferring some of my resources, I could request my parent do this. If I have sub allocated some of those to-be-transferred resources to customers, then I'd be quite remiss if I were not mentioning this to my customer who was just about to lose some of their resources. So maybe I'd reissue certs to customers who had exclusively retained space under the new cert with only retained space, same for the about to be transferred space. The customers who have a mix of retained and transferred space are in a pickle of my own making, and I should work with them closely. Before I do the transfer. I think the RPKI structures work if I create the needed certs in the fate-sharing part of my customer cone. (Maybe even a hint of gr**dp*r*ting). I consider this similar to RIPE's instructions to their members to retain their authority over their sub allocated space, carefully setting the mtn-by, mtn-lower, mtn-route, etc.. Of course, that's from my reading of the RIPE documentation, so I could be wrong about that. Working the process out for planned transfers would be valuable. --Sandy, speaking as a regular ol' member
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
