>> "We observe that a Route can be Matched or Covered by more than one >> ROA. This procedure does not mandate an order in which ROAs must be >> visited; however, the "validation state" output is fully >> determined." >> Is there guidance on this in one of the other documents? If so, >> please reference it here. Does longest-match still apply? This seems >> a fairly big question to simply leave open to implementation. >> Please apply cluebrick liberally if I'm being thick. > > >I looked around in sidr-usecases and origin-ops, but couldn't find an >example. May be we should add one. But is there anything that you are >specifically worried about? All that the text says is that ordering is >not relevant. It's a classic OR operation for the match.
I agree that it is an "OR" operation in general. Let me just note that in Section 7.2 in the sidr-usecases document, we talked about use cases when a cert expires or a CRL is received that affects a ROA and in turn affects an existing BGP update that was validated with support of that ROA. Then the relying party should check if there is another ROA (or another entry in ROA white-list) for a parent (i.e., less specific) prefix that may sustain the "Valid" status for the update in question. Perhaps the sidr-pfx-validate document should also talk about what the algorithm should do in reaction to a cert expiry or CRL receipt or an RPKI-rtr withdraw message (for a ROA white-list entry)? Sriram _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
