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

[Ballot comment]
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

[Ballot comment]
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?

[Ballot comment]

- 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?

[Ballot comment]
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.

[Ballot comment]
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.... ?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-sidr-origin-ops-21, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RPKI-Based Origin Validation Operation) to Best Current Practice


The IESG has received a request from the Secure Inter-Domain Routing WG
(sidr) to consider the following document:
- 'RPKI-Based Origin Validation Operation'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Deployment of RPKI-based BGP origin validation has many operational
  considerations.  This document attempts to collect and present those
  which are most critical.  It is expected to evolve as RPKI-based
  origin validation continues to be deployed and the dynamics are
  better understood.





The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Who is the document shepherd?


Who is the responsible Area Director?
Stewart Bryant
Adrian Farrel

Explanation of Document purpose:
"Deployment of RPKI-based BGP origin validation has many operational
considerations. This document attempts to collect and present those
which are most critical. It is expected to evolve as RPKI-based
origin validation continues to be deployed and the dynamics are
better understood."

Why BCP?
The WG asked for document to be published as a BCP because it describes
the aspirational 'best common practice' intended to be used for managing
RPKI type data as an origin-as operator.

2. Review and Consensus

The document went through 20 revisions, substantial review on and off
the WG mailing list, and considerable banter at live meetings (both
official 3x/yr f2f meetings and interim f2f ones). It seemed from the
discussion that a large portion of the WG was interested in this
document moving forward and in being written in the first place,
describing expected operational practices with a new system required for
safe(r) operations of a critical part of the Internet (the routing
system) seems to have tickled the fancy of many a WG member.

the only notable parts of discussion where the number of detailed
reviews and commentaries made by members throughout the +2yr process of
writing and publishing this document.

3. Intellectual Property

All authors have confirmed there are no outstanding IPR claims for this
document.

4. Other Points

There is one downref document reference to:
draft-ietf-sidr-ltamgmt

I believe this will be fixed before publication as well. Additionally,
there are some id-nits issues which will be cleaned up prior to
publication (in like auth48 or so).

-chris
(co-chair sidr-wg)