[sidr] grandparenting

[Stephen Kent <[e-mail]>]

OK, I just got around to reading this doc, and I have several observations:

In the introduction (Section 1) the first example is:

    provider A allowed a child, C, to move to
    other provider(s) and keep their [sic] address space, either temporarily or
    permanently, and C's child, G, wished to stay with provider A.

This seems like a poor example, absent additional info about the 
nature of the contractual arrangement between C and G. It might be 
the case that the arrangement allows G to opt out of having C 
advertise the address space that C received from A and sub-allocated 
to G, but that was not stated. If that option is not part of the deal 
between C and G, then G may have no basis for asking A to advertise 
this space, right?  So, it would help to have more details in this 
example to make sure we're not suggesting that the RPKI be used to 
circumvent an agreement.

I think the second, more generic example, is better, but it too could 
use some tweaking. The situation here is one in which a resource 
holder (C) is a player in the RPKI, but does not want to assume 
responsibility for managing resources that it sub-allocates, e.g., to 
G, AND it has no objection to this function being provided by the 
resource holder from which C receives its allocation. I agree with 
Wes's example. G may be looking to outsource management of its RPKI 
functions, but not change service providers. That has different 
implications for how this process is managed, and who does it. For 
example, G might hire someone
to manage RPKI functions for it, and that need not be A, IF C is willing to
issue a CA cert to the 3rd party selected by G. This would be invisible to RPs,
if it is managed in the way I mentioned, whether the service is 
provided by A or Z.


Section 3 talks about A having to verify that G is the holder of the 
resources in question. It omits a discussion about A verifying with C 
that C does not object to A inserting itself into the hierarchy in 
this fashion, essentially between C and G. The initial example fro 
Section 1 is used here and, again, I think it needs additional text 
to state assumptions as I noted above. I worry about the statement 
"Although A has the rights over their child's, C's, resources, it 
would be prudent and polite to ensure that C agrees to A forming a 
relationship to G." This implies details of the relationship between 
A and C that have not been stated.

I also would have imagined a different technical proposal here. For 
example, A might reissue a certificate to C removing G's prefix(es) 
at some  point in this process (consistent with a "make before break" 
model). This would ensure that C does not reallocate the prefix that 
A is now managing directly in its relationship with G. Also, removing 
that prefix would prevent C from issuing a ROA for the subsuming 
address space, causing G's traffic to be directed to C, if 
more-specific routes for G disappear. Yes, there needs to be a time 
overlap for this, but not suggesting this as the preferred end state 
is likely to confuse matters.

The text here suggests that A might issue EE certificates and ROAs on 
behalf of G. I'd suggest it would be much cleaner for A to create a 
CA certificate representing G and the issue EE certificates and ROAs 
(and manifests and CRLs) relative to that CA, if G does not wish to 
operate its own CA. Since these certificates contain no names, A is 
not impersonating C or G by doing this, and it makes for a cleaner 
distinction between the resources that A is managing in the normal, 
hierarchic fashion, and the ones that are being treated specially.