[Gen-art] Genart last call review of draft-ietf-sidrops-cms-signing-time-06

[Gyan Mishra via Datatracker <[e-mail]>]

Reviewer: Gyan Mishra
Review result: Ready

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-cms-signing-time-??
Reviewer: Gyan Mishra
Review Date: 2024-03-07
IETF LC End Date: 2024-03-11
IESG Telechat date: Not scheduled for a telechat

Summary:

In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as
Cryptographic Message Syntax (CMS) protected content types by way of a standard
template (RFC 6488). That template includes an optional CMS signing-time
attribute, representing the purported time at which the object was signed by
its issuer. At the time when the standard template was defined, rsync was the
only distribution mechanism for RPKI repositories.¶

Since the publication of the standard template, a new, additional protocol for
distribution of RPKI repositories has been developed: the RPKI Repository Delta
Protocol (RRDP). While RPKI repository operators must provide rsync service,
RRDP is typically deployed alongside it as well, and preferred by default by
most Relying Party (RP) implementations. However, RP implementations also
support fallback to rsync in the event of problems with the RRDP service. As
deployment experience with RRDP has increased, the usefulness of optimizing
switchovers by RPs from one mechanism to the other has become apparent.¶

This document describes how Publishers and RPs can use the CMS signing-time
attribute to minimize the burden of switching over from RRDP to rsync.
Additionally, this document updates RFC 6488 by mandating the presence of the
CMS signing-time attribute and disallowing the use of the binary-signing-time
attribute.¶

The draft is well written and is ready for publication.

Major issues:
None

Minor issues:
None
Nits/editorial comments:
In section 2.2 talks about file comparison and says

Old

If a file is found in DIR that is identical to the sender's file, the file will
NOT be transferred to the destination directory.

New

If a file is found in DIR that has the identical size to the sender's file, the
file will NOT be transferred to the destination directory.