hi john, sorry to disturb your cruise. as you know, from the get go, the hierarchic nature of the pki has worried the ops folk involved. this is why documents such as draft-ietf-sidr-rpki-origin-ops-00.txt say things such as RPKI-based origin validation has been designed so that, with prudent local routing policies, there is no liability that normal Internet routing is threatened by unprudent deployment of the global RPKI, see Section 5. ... 5. Routing Policy Origin validation based on the RPKI merely marks a received announcement as having an origin which is Validated, Unknown, or Invalid. How this is used in routing is up to the router operator's local policy. See [I-D.pmohapat-sidr-pfx-validate]. Reasonable application of local policy should be designed eliminate the threat of unroutability of prefixes due to ill-advised or incorrect certification policies. As origin validation will be rolled out over years coverage will be spotty for a long time. Hence a normal operator's policy should not be overly strict, perhaps preferring valid announcements and giving very low preference, but still using, invalid announcements. Some may choose to use the large Local-Preference hammer. Others might choose to let AS-Path rule and set their internal metric, which comes after AS-Path in the BGP decision process. Certainly, routing on unknown validity state will be prevalent for a long time. Until the community feels comfortable relying on RPKI data, routing on invalid origin validity, though at a low preference, may be prevalent for a long time. Announcements with valid origins SHOULD be preferred over those with unknown or invalid origins. Announcements with unvalidatable origins SHOULD be preferred over those with invalid origins. Announcements with invalid origins MAY be used, but SHOULD be less preferred than those with valid or unknown. of course, in the US, this will not prevent litigation. nothing will. it's a mental disease. randy