Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

[Tim Bruijnzeels <[e-mail]>]

Hi again,

> On 25 Mar 2023, at 12:20, Tim Bruijnzeels <[e-mail]> wrote:
> 
> Merging the VAPs from multiple ASPA objects for the same CAS can be done as follows. The RPKI Relying Party (Validator) creates two sets of providers ASNs, one for IPv4 and one for IPv6. Any provider ASN in any of the VAPs that is found to have no afiLimit is added to both sets. If there is an afiLimit then the provider ASN is added to the corresponding set only. Duplicates are ignored (i.e. these are sets). At the end of the process a new VAP can be created. Any provider ASNs that are found in only one of the two sets get the corresponding afiLimit. Any provider ASNs that are in both sets get no afiLimit.
> 
> To the authors mainly: please let me know if the above procedure is incorrect. All the more reason for documenting it I would say ;)

Okay, on re-reading my own suggestion let me try to rephrase it in an outcome-driven way, rather than specifying an algorithm which may not be the most efficient.

When merging two VAPs the resulting VAP should have all provider ASNs found in either original VAP. In case the provider ASN is present in both original VAPs the resulting set's corresponding provider ASN should use a value for the afiLimit that includes the original attestations. If afiLimit was absent in either original VAP then it must also be absent in the result. If the two original VAPs used different (complementary) afiLimits, then the intend was to declare the provider for both IPv4 and IPv6 and the resulting VAP must not use an afiLimit. If the afiLimit was the same in both original VAPs then of course the resulting VAP must use the same limit.

Tim