Yoav, Thanks for your reply, I agree with your reasoning, but it should have been in the shepherd’s write-up to enlighten the ADs when doing their review ;-) (I prefer to read a statement rather than making a guess).
Regards -éric From: Yoav Nir <ynir.i...@gmail.com> Date: Wednesday, 8 January 2025 at 05:15 To: Eric Vyncke (evyncke) <evyn...@cisco.com> Cc: The IESG <i...@ietf.org>, draft-ietf-acme-...@ietf.org <draft-ietf-acme-...@ietf.org>, <acme-cha...@ietf.org>, acme@ietf.org <acme@ietf.org>, g...@apnic.net <g...@apnic.net> Subject: Re: Éric Vyncke's Discuss on draft-ietf-acme-ari-07: (with DISCUSS and COMMENT) Hi, Éric. Thanks for the review. As to your coment, ARI is an extension to RFC 8555 which is standards track. There are also some implementations for it, so “Proposed Standard” is, in my opinion, the right status. It’s too mature for “Experimental”. Hope this helps Yoav > On 2 Jan 2025, at 15:49, É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 > " > > 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
