Note: This ballot was opened for revision 02 and is now closed.
Agree with other comments, a BCP status seems more appropriate.
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.
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].“
I am doubtful that RFC 2119 is the only Normative Reference.
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.
[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.
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".