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 07) | |
Type | Last Call Review | |
Team | Transport Area Review Team (tsvart) | |
Deadline | 2024-12-06 | |
Requested | 2024-11-22 | |
Authors | Aaron Gable | |
I-D last updated | 2024-12-06 | |
Completed reviews |
Tsvart Last Call review of -06
by Michael Tüxen
(diff)
Dnsdir Last Call review of -06 by Geoff Huston (diff) Secdir Last Call review of -06 by Shawn M Emery (diff) Genart Last Call review of -07 by Susan Hares Dnsdir Telechat review of -07 by Geoff Huston Secdir Telechat review of -07 by Shawn M Emery |
|
Assignment | Reviewer | Michael Tüxen |
State | Completed | |
Request | 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 07) | |
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