Skip to main content

Last Call Review of draft-ietf-acme-ari-06
review-ietf-acme-ari-06-tsvart-lc-tuexen-2024-12-06-00

Request Review of draft-ietf-acme-ari
Requested revision No specific revision (document currently at 08)
Type IETF Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2024-12-06
Requested 2024-11-22
Authors Aaron Gable
I-D last updated 2025-06-17 (Latest revision 2025-02-26)
Completed reviews Tsvart IETF Last Call review of -06 by Michael Tüxen (diff)
Dnsdir IETF Last Call review of -06 by Geoff Huston (diff)
Secdir IETF Last Call review of -06 by Shawn M Emery (diff)
Genart IETF Last Call review of -07 by Susan Hares (diff)
Dnsdir Telechat review of -07 by Geoff Huston (diff)
Secdir Telechat review of -07 by Shawn M Emery (diff)
Assignment Reviewer Michael Tüxen
State Completed
Request IETF Last Call review on draft-ietf-acme-ari by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/SpORBHnMmGnmgIZkrbIl7tr1wno
Reviewed revision 06 (document currently at 08)
Result Ready w/issues
Completed 2024-12-06
review-ietf-acme-ari-06-tsvart-lc-tuexen-2024-12-06-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The sixth step in the algorithm described in Section 4.2 is ambiguous in my
view:

Otherwise, sleep until the Retry-After period has passed, or until the next
normal wake time, and return to Step 1.

Assume the Retry-After period is 6 hours (21600 seconds) as stated in the
example and assume that the normal wake time is 1 second. Depending on how the
sixth rule is interpreted, the client might retry in 6 hours or in one second.
Choosing the 1 second results in sending 21600 requests in 6 hours instead of
one. Therefore I think it makes sense to be more specific here such that you
send only one request...

There is one typo in Section 4.2:
regulatory enviornment -> regulatory environment