BGPsec Router Certificate Rollover
draft-ietf-sidrops-bgpsec-rollover-04

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".

I am doubtful that RFC 2119 is the only Normative Reference.

[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.

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.

Agree with other comments, a BCP status seems more appropriate.

   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.

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].“