Hi I agree and have just updated the shepherd write-up. Late, perhaps, but better than never.
Yoav > On 8 Jan 2025, at 8:42, Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > > 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
