Last Call Review of draft-ietf-sidrops-rrdp-desynchronization-01
review-ietf-sidrops-rrdp-desynchronization-01-genart-lc-sarikaya-2024-08-12-00

Request Review of draft-ietf-sidrops-rrdp-desynchronization
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-08-20
Requested 2024-08-06
Authors Job Snijders , Ties de Kock
I-D last updated 2024-08-12
Completed reviews Genart Last Call review of -01 by Behcet Sarikaya (diff)
Secdir Last Call review of -01 by Tim Hollebeek (diff)
Assignment Reviewer Behcet Sarikaya
State Completed
Request Last Call review on draft-ietf-sidrops-rrdp-desynchronization by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/np1NqEtmaI01NJWL2fAAKuWk1X4
Reviewed revision 01 (document currently at 03)
Result Ready w/nits
Completed 2024-08-12
review-ietf-sidrops-rrdp-desynchronization-01-genart-lc-sarikaya-2024-08-12-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-sidrops-rrdp-desynchronization-??
Reviewer: Behcet Sarikaya
Review Date: 2024-08-12
IETF LC End Date: 2024-08-20
IESG Telechat date: Not scheduled for a telechat

Summary:The document describes an approach for RPKI Relying Parties to detect a
particular form of

RPKI Repository Delta Protocol (RRDP) session desynchronization and recover.

Major issues:

Minor issues:

Nits/editorial comments:
The document is short, well-written but has a few nits.
in section 3.1 it says
Using its previously recorded state (Section 3.1)

I don't understand (Section 3.1) here, it is already in Section 3.1.

The document is Informational and it is expected to become Informational RFC,
then RFC 3967 rules should hold. This means that the document is describing a
non-IETF protocol. I wonder if that is that the case?

BTW, Relying Parties means essentially Service Providers.