> On 17 Apr 2021, at 10:43, Dan Romascanu via Datatracker <nore...@ietf.org> > wrote: > > Reviewer: Dan Romascanu > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-dprive-xfr-over-tls-09 > Reviewer: Dan Romascanu > Review Date: 2021-04-17 > IETF LC End Date: 2021-04-20 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > Ready with nits. > > This document specifies XFR-over-TLS (XoT) i.e. the use of TLS, rather than > clear text, to prevent zone content collection via passive monitoring of DNS > zone transfers. This is a very clear and well-written document. I had to do > further reading to understand some of the specified or referred concepts and > mechanisms, but after doing it all aligned nicely. I especially appreciate the > inclusion and level of detail of Section 7 which explains the updates to the > existing specifications, including the RFCs updated by this document and > clarifies the issues of backwards compatibility. There are a few nits that I > suggest to address before publication.
Hi Dan, Many thanks for the review. > > Major issues: > > Minor issues: > > Nits/editorial comments: > > 1. In Section 3: > >> XoT: Generic XFR-over-TLS mechanisms as specified in this document > > What does 'Generic' mean here? Are there also non-generic / specific > mechanisms > similar to XoT that should be referenced? If not, consider dropping ‘Generic' It was intended to mean that the term applied to both IXFR and AXFR-over-TLS… I propose updating the text to the following: “XoT: XFR-over-TLS mechanisms as specified in this document which apply to both AXFR-over-TLS and IXFR-over-TLS" > > 2. In Section 5 there are two Design Considerations labelled both Performance. > Is this the intent? If yes, maybe they should be grouped together. If not > maybe > at least one of the name may be changed. Good point - they are now grouped them together. > > 3. Should not the fact that implementations MUST use TLS 1.3 or higher, which > is specified in Section 8.1, be also mentioned in the Introduction? Yes - the last paragraph is now update to add that. > > 4. Section 9 uses in one instance the term 'multi-master'. Can an alternative > term be considered, taking into account the work summarized in I-Ds such as > https://datatracker.ietf.org/doc/draft-knodel-terminology/? > <https://datatracker.ietf.org/doc/draft-knodel-terminology/?> Thanks for spotting this. I suggest simply removing that text as I think term multi-primary in the title should be enough given our terminology section. > > 5. I assume that Section 20 - Changelog will be removed before publication I’ve added text to request this, just to make sure. I’ve published a -10 version the draft including these changes which I hope addresses your issues? Regards Sara.
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
