Éric Vyncke has entered the following ballot position for draft-ietf-acme-ari-07: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-acme-ari/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-acme-ari-07 CC @evyncke Thank you for the work put into this document. I can easily imagine that it is really useful. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Yoav Nir for the shepherd's detailed write-up including the WG consensus ***but it lacks*** the justification of the intended status. Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), thanks for having considered his int-dir review: https://datatracker.ietf.org/doc/review-ietf-acme-ari-07-dnsdir-telechat-huston-2024-12-15/ https://datatracker.ietf.org/doc/review-ietf-acme-ari-06-dnsdir-lc-huston-2024-11-23/ I hope that this review helps to improve the document, Regards, -éric ## DISCUSS (blocking) As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is just a request to have a discussion on the following topics: ### Section 4.1 I think that the example is wrong for HTTP request, rather than ``` GET https://example.com/acme/renewal-info/ aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE ``` it should probably be " GET /acme/renewal-info/ aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE Host: example.com " Also in this section, should the note about prefixing a "00" when the serial number is a negative number be more than a simple note but normative ? Or if this is per default in ACME, adding a reference ? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS (non-blocking) ### Lack of HTTP-dir reviews I can only regret that there was no HTTP directorate review for this document as one of my DISCUSS and one of my COMMENT are related to HTTP. ### url should be in uppercase I have detected some "url" that should be "URL" as it is an acronym. ### Section 4.2 Is the first `Conforming clients SHOULD provide this URL to their operator` correct ? I would assume that this JSON reply is sent by the ACME server and not by the client. Is the `Retry-After` the most suitable HTTP header ? I.e., while RFC 9110 section 10.2.3 is not really specific, [Mozilla spec](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After) seems to indicate that it is not appropriate for a 200 response code. As I am not an HTTP expert, I am ready to be corrected of course but I would think that using a new key in the returned object would be neater. ## NITS (non-blocking / cosmetic) ### Appendix A It seems that the year of this certificate is 0000, was it the intent ? ### Section 4.2 Suggest to use a more recent date (rather than 2021) in the example. _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
