BTW, this came out sounding kind of grudging. I should say that my concerns in the previous review were my concerns, which may or may not have mattered, and I appreciate the authors addressing the concerns they addressed, and understand that they didn't see the other issues the way I did (or did, but addressed them differently than I would have). So when I refer to the "reasonable, if disappointing" reaction, it's me who's somewhat disappointed, and I am not suggesting that the IETF should be, and I really just shouldn't have said that in the review—sorry about that.
On Wed, Mar 1, 2023 at 7:59 AM Ted Lemon via Datatracker via dnsdir < [email protected]> wrote: > Reviewer: Ted Lemon > Review result: Ready > > In my previous review, I mentioned that the text about graph theory seemed > to > make the document harder, not easier, to understand. This was an editorial > comment, which the authors mostly ignored, which is fine. They did add an > admonition to the reader to read RFC8499 for further clarification, for > what > that's worth. > > I also mentioned that the diagrams that show the ACME process aren't > contextualized as being part of ACME, which made it hard to figure out > where > these operations were actually described in a standard. The authors added > some > text that may have been intended to address this concern, but it's not > clear, > and I don't think this suggestion has been addressed. It was an editorial > nit, > so that seems like a reasonable, if disappointing, reaction. > > I also mentioned that the text about the use of ACME for subdomains is > somewhat > contradictory, since in one place it says they are not necessary, and in > another case it gives an example that depends on them. Some text has been > added > that may have been intended to ameliorate this concern. This was a "ready > with > issues" point, meaning that I thought it should definitely be corrected. I > think this change addresses the concern. > > I also asked for a clarification in the security considerations section > (now > section 10) that the mention of using DNS updates and TSIG or SIG(0) was > needlessly prescriptive. The update softens this text and I think > addresses my > concern. > > I also pointed out an issue with the text implying that TSIG uses "DNS key > records," which it does not, and the new text no longer confuses key > records > (SIG(0)) and TSIG keys, referring to both as "credentials." This addresses > my > concern, and also includes other means of update in the concern about > credential leakage. I think this addresses my concern. > > I further requested that references be given for RFC2136 and RFC2931 since > the > mechanisms described therein were being referenced. These references have > been > added. > > So I would say at this point that the concerns I raised have been > addressed and > the document is ready to go. > > > -- > dnsdir mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsdir >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
