On Thu, Jan 2, 2025 at 2:49 PM Éric Vyncke via Datatracker <nore...@ietf.org> wrote:
> É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 > " > Right, usually this would be how we have been representing the GET method examples in RFC see : draft-ietf-httpapi-api-catalog-08 <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-api-catalog-08#appendix-A.1> I would say it should look like this GET /acme/renewal-info/ <https://example.com/acme/renewal-info/> aYhba4dGQEHhs3uEe6CuLN4ByNQ.AIdlQyE HTTP/1.1 Host: example.com Accept: application/json I have added the Accept looking at section 4.2 where an example response is given. If the renewal-info is only accessible via secure connection then this specification must mandate that separately and need not to be in the example URI. //Zahed > > 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
