Re: [sidr] RPKI <-> allocation consistency

[Stephen Kent <[e-mail]>]

Brian,

Sorry I didn't reply sooner.

I found it very difficult to follow the details of your example, but I 
think there is a higher
level consideration that makes moot a detailed analysis of optimization 
the you suggest.

In the early days of RPKI design I raised the same question that you did 
re allocation uniqueness,
and suggested that we include RP checks for overlapping allocations in 
RP software. I was told (by operators) that the old INR holder and the 
new INR holder would each need to have certs (and ROas) that are valid, 
and that encompass the INRs being moved, and that persist for some time. 
That is a fundamental reason that the RPKI does not specify that the 
allocations are "unique." The term "unique" used to appear in the text 
of several of the docs, but was removed to accommodate INR transfers.

I think the primary concern is that one cannot be confident how quickly 
all RPs will acquire all RPKI data.
Thus it seems prudent to allow for the old and new INR holders to have 
certs that contain the INRs being transferred, for these certs overlap 
in validity, and for both certs to be available via the repository 
system at the same time, for some overlap period. This enables old and 
new ROAs, which may point to the same ASN, to exist, avoiding the need 
for a flag day.

Steve