Dear Peter, My apologies for the late reply, somehow failed to reply to this email. Thank you for your patience and review! Please see below. On Sun, Apr 06, 2025 at 11:56:33PM -0700, Peter Yee via Datatracker wrote: > Document: draft-ietf-sidrops-rpki-crl-numbers-04 > Reviewer: Peter Yee > Review Date: 2025-04-06 > IETF LC End Date: 2025-04-03 > IESG Telechat date: 2025-05-22 > > Summary: This document changes RFC 6487 so that the CRL Number extension is > essentially considered superfluous. There are some minor issues in the document > that could be addressed. [Ready with issues.] > > Major issues: None > > Minor issues: > > Page 3, section 1.3, 3rd bullet item: Erratum 3205 adds the text “The > extensions mentioned above MUST NOT appear more than once each” to the > paragraph in question. The update of that paragraph occurs in section 3.1 of > this draft. Nowhere in that paragraph does it make any mention of multiple > occurrences of CRL Number. It does add new strictures on checking CRL Number > (non-critical and less than or equal to 2^159-1), but neither of those > seemingly has anything to do with multiple occurrences, so I am no unsure how > this draft has integrated that erratum. I think Erratum 3205 is resolved, because of this wording change: "An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. [snip] No other CRL extensions are allowed." was changed to: "An RPKI CA MUST include exactly two extensions in every CRL that it issues: an Authority Key Identifier (AKI) and a CRL Number. [snip] No other CRL extensions are allowed." (Note the change from: 'two' -> 'exactly two') Having said that, my command of the English language is somewhat limited. Is "exactly two" and then the enumaration of which two, a good way of describing that extensions do not appear more than once? > Page 5, 2nd bullet item prior to section 3.2: what happens if the CRL Number > doesn’t meet these criteria? Then the CRL is invalid, just like if the wrong CRL version were to be used. The Relying Party instance should continue to use cached versions of the objects associated with the CA instance at hand, until such time as they become stale or they can be replaced by objects from a successful fetch. (This follows from RFC 9286 section 6.6) > Nits/editorial comments: > > Page 6, 1st paragraph, 1st sentence: change “determinining” to “determining”. > Change “resouce" to “resource”. These have been fixed and will be visible in -05 https://github.com/job/draft-rpki-crl-numbers/pull/16/commits/6f1b87f0c1d9cd8b12cb111d765abfc166adf73a Thank you for your time Kind regards, Job -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
