BGPsec Router Certificate Rollover

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

Warren Kumari Yes

(Alia Atlas) No Objection

Deborah Brungard No Objection

Comment (2017-11-29 for -03)
No email
send info
Agree with other comments, a BCP status seems more appropriate.

(Ben Campbell) No Objection

Comment (2017-11-29 for -03)
No email
send info
Did the working group consider making this a BCP? It describes operational practices, not protocol.

-1: The draft contains a number of instances of "must" and "should" in lower case. If those are correct, please consider using the boilerplate from 8174.

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

Comment (2017-11-07 for -03)
No email
send info
This document really reads like it should be an informational document, or maybe a BCP. Further, the shepherd write-up says "Internet Standard final status" but I see Proposed Standard in the datatracker...? I would recommend to go for BCP if the wg can agree to that.

Also, should ietf-sidr-rtr-keying maybe be a normative reference, or is this just one example? The use of this reference in section 3.1 isn’t clear to me with this respect:
„The key rollover process is dependent on the key provisioning mechanisms adopted by an AS [I-D.ietf-sidr-rtr-keying].“

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2017-11-21 for -03)
No email
send info
I am doubtful that RFC 2119 is the only Normative Reference.

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Comment (2017-11-28 for -03)
No email
send info
   BGPsec router certificate with a new public key and the time a BGPsec
   router begins to use its new private key).  This can be due to a need
   for a BGPsec router to distribute BGPsec updates signed with a new
Nit "the period between the time when an AS distributes ...."

   Protection against withdrawal suppression and replay attacks:  An AS
         may determine withdrawn BGPsec updates are being propagated
         instead of the most recently propagated BGPsec updates.
Nit: may determine that.

   certificate used for signing updates in transit is expected to live
   longer than the one used for signing origination updates.
Why is it unimportant to worry about replays on transit updates? As I read the references it's just that changing the transit key is expensive, right? But I'm not sure why that means you don't have to do it.

Alvaro Retana No Objection

Comment (2017-11-28 for -03)
No email
send info
[I'm not making this point as DISCUSS because it should be very easy to address, and the authors have already agreed to the change in response to Mirja.]

I think that the reference to I-D.ietf-sidr-rtr-keying should be Normative.

(Adam Roach) No Objection

Comment (2017-11-29 for -03)
No email
send info
Thanks for a well-written document with clearly spelled-out rationale and explanations.

I agree with others that this document looks like a BCP rather than a standards track document; in particular, the following language is pretty compelling:

   This document does not contain a protocol update to either the RPKI
   or BGPsec.  It describes a process for managing BGPsec router
   certificates within the RPKI.

I also found a nit in Section 2: "In particular, if the AS suspects that a stale BGPsec updates is being distributed..." Either remove "a" or change "updates" to "update".