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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
