Detecting RRDP Session Desynchronization
draft-ietf-sidrops-rrdp-desynchronization-04

Yes

John Scudder
Warren Kumari

No Objection

Deb Cooley
Erik Kline
Francesca Palombini
Gunter Van de Velde
Jim Guichard
Mahesh Jethanandani
Murray Kucherawy
Orie Steele
Paul Wouters
Roman Danyliw
Zaheduzzaman Sarker
Éric Vyncke

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

John Scudder
Yes
Warren Kumari
Yes
Deb Cooley
No Objection
Comment (2024-10-14) Not sent 
Clear and well written.  I liked the example, it helped to understand how a de-synchronization can be detected.

update on 14 Oct:  I still think this is clear and well written.
Erik Kline
No Objection
Francesca Palombini
No Objection
Gunter Van de Velde
No Objection
Comment (2024-08-29 for -02) Not sent 
Nice written document. Thank you
Jim Guichard
No Objection
Mahesh Jethanandani
No Objection
Murray Kucherawy
No Objection
Comment (2024-09-05 for -02) Sent 
Question #11 in the shepherd writeup is incomplete.  Why is this Informational and not Proposed Standard?

Why the bare SHOULDs in Section 4?  What happens if I don't do what they say?  Readers could benefit from some more complete guidance here.  I concur with Eric's observations.  Moreover, if this is only Informational, do we really need BCP 14 for this work?

Thanks for including Appendix B.
Orie Steele
No Objection
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment (2024-09-03 for -02) Sent 
Thank you to Behcet Sarikaya for GENART review.

** I’m having trouble understanding how this document should be used since it is informational and doesn’t update RFC8182. Specifically:

-- Is this an operational practice that ideally all RPKI RP should be deploying while waiting for a protocol update?

-- Are there “RPKI operations” that rely on there not being immutability (so only some RPKI RPs should adopt it)?

-- Is there a reason why this document doesn’t update RFC8182 to require that the “immutability of RRDPs should not be violated”? or updated RFC8182 to require this type of checking should be done?

-- Is this updated to RFC8182 being worked on?  Could it be referenced?

** Section 2.
   A
   future update to [RFC8182] should set a hard rule to establish that
   the immutability of RRDP files must not be violated after
   publication, and that RPs should check for unexpected mutations.

I was surprised that an information document and one not updating RFC8182 has commentary on how a protocol mechanism in a proposed standard should be updated.  Is this text really needed?
Zaheduzzaman Sarker
No Objection
Éric Vyncke
No Objection
Comment (2024-08-31 for -02) Sent 
Thanks for an easy to read useful document.

Thanks for Chris Morrow for the shepherd's write-up (even in the absence of the intended status).

I find it weird to have 'detecting' in the title and not 'recovery' while section 4 is about recovery and the abstract also contains 'recovery'. 

In the last paragraph of section 3, should there be any guidance about `the number of Delta Files to process before switching` ?

Finally, BCP 14 terms are only used in the very short section 4 about recovery, and I wonder whether using plain "should" (w/o BCP14) would be better.