Dan, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-4-17, at 12:43, Dan Romascanu via Datatracker <noreply@xxxxxxxx> 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. > > 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' > > 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. > > 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? > > 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/? > > 5. I assume that Section 20 - Changelog will be removed before publication > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
