Origin Validation Operation Based on the Resource Public Key Infrastructure (RPKI)
RFC 7115

Note: This ballot was opened for revision 22 and is now closed.

(Richard Barnes) Yes

Comment (2013-11-19 for -22)
No email
send info
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?

(Stewart Bryant) Yes

(Spencer Dawkins) Yes

(Adrian Farrel) Yes

Comment (2013-11-13 for -22)
No email
send info
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.... ?

(Brian Haberman) Yes

Comment (2013-11-18 for -22)
No email
send info
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.

(Joel Jaeggli) Yes

(Ted Lemon) Yes

(Sean Turner) Yes

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-11-20 for -22)
No email
send info
I second Al Morton's OPS-DIR feedback:
   The effort to prepare this BCP should be greatly appreciated in
   the OPS community. Thanks Randy.



Editorial:
For example, a router should bootstrap from a chache which is
s/chache/cache

(Stephen Farrell) No Objection

Comment (2013-11-19 for -22)
No email
send info
- Nice bcp, thanks. I like that you flag that it'll
evolve in the abstract.

- section 5, 5th last para: Does "the latter" here mean
"NotFound or Invalid" or just "Invalid"?  If it just
means invalid, is there a danger this might cause
someone to not acceopt NotFound announcements too soon?

Barry Leiba No Objection

Comment (2013-11-17 for -22)
No email
send info
This was a nice read; thanks for a clear, concise document.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection