Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidr-origin-ops-23

I support the publication of this document.

The rest of this Comment is pointless nits:

---

Please expand CRL on first use.

---

s/an hierarchic/a hierarchic/

(although qualifies for :-)

---

Section 3

"seriously affects the performance" is ambiguous. Of course...

s/affects/improves/

---

Page 4

   For redundancy, a router SHOULD peer with more than one cache at the
   same time.  Peering with two or more, at least one local and others
   remote, is recommended.

Upper case RECOMMENDED?

---

Page 6

   An environment where private address space is announced in eBGP the
   operator MAY have private RPKI objects which cover these private
   spaces.  This will require a trust anchor created and owned by that
   environment, see [I-D.ietf-sidr-ltamgmt].

In an environment.... ?

Absolutely support the publication of this document.  Just a few quick points...

1. Would the 2nd paragraph of the Introduction be strengthened with a reference to the IAB statement on the RPKI (http://www.iab.org/documents/correspondence-reports-documents/docs2010/iab-statement-on-the-rpki/)?

2. The use of 10.0.666.0/24 is classic.  I hope it remains.

3. In section 6, I think the discussion of loosely consistent data could be enhanced.  It may be worthwhile to mention that never-before-seen prefixes and ASes appearing in the routing system is not a common event.  The growth rate of those two variables seem to indicate that the loose synchronization of RPKI caches should not be a problem.

Section 3:
The document uses the phrase "validated cache" (and "valid cache") without defining what the word "validated" means in this context.  If I understand correctly, the following text after "... rcynic [rcynic]." would be helpful to explain:
"""
A validated cache contains all RPKI objects that the RP has verified to be valid according to the rules for validation RPKI certificates and signed objects [RFC6487][RFC6488].  Entities that trust the cache can use these RPKI objects without further validation. 
"""

Section 3:
"... an operator MAY choose to synchronize quite frequently."
In these comments on cache synchronization, it may be helpful to note that while synchronization with public caches is expensive (requiring validation), synchronization with a trusted validated cache is much cheaper.

Section 3: 
"a router SHOULD peer with more than one cache"
Just to be clear, you're talking about peering over the RPKI-RTR protocol, not rsync, right?

Section 3:
"all sub-allocations from that block which are announced by other ASs, e.g. customers, have correct ROAs in the RPKI"
Note that the holder of the super-block can fix this problem, e.g., by issuing the necessary ROAs or issuing de-aggregated ROAs instead of a single one for the super-block.  Do you mean to have the holder of the super-block be gated on customers?  Or do you want to suggest one of these fixes?