...

Loose mode RPKI: - verified or unknown less-specific route is preferable to failing more-specific

Or said otherwise when choosing route from Adj-RIBs-In to Loc-RIB longest match is not done to whole population, population is first divided to 'verified', 'unknown' and 'failed' routes, and longest match is done for each sub-population in order, until match is found.

Of course, a PRO you are seeking to achieve is: If Org. A is parent and upstream of Org. B, and Org. A has created a ROA for its own less specific, while no ROA has been created (due to negligence, oversight, etc.) for the suballocation (more specific) of Org. B, and if Org. A happens *not* to announce its less specific, then Org. B's announcement of the more specific from its own AS will be treated softly. That is, Org. B's announcement will be 'Invalid' but nevertheless the route is accepted/installed by any receiving AS that is using the 'Loose' mode. This is the benign/beneficial use of 'Loose' mode. But the CON here is: For instance, Org. C owns a prefix but has not yet deployed any services using it. Org. C created a ROA (perhaps even an ROA with AS0) purely with the intent to make sure that no one else can get away with announcing any subprefix (more specific) under its prefix unless they have a ROA for the subprefix. The 'Loose' mode obviously defeats this. Some Org. D can maliciously announce a subprefix under Org. C's prefix, and get away with it due to the 'Loose' mode. So there will be this tension between the PRO and CON of your 'Loose' mode. I think, 'Loose mode', if used at all, should not be used beyond a short grace period. Beyond the grace period, network operators and their customers will be well advised to adhere to the following from RFC 7115: "Before issuing a ROA for a super-block, an operator MUST ensure that all sub-allocations from that block that are announced by other ASes, e.g., customers, have correct ROAs in the RPKI." Sriram