Hi Sara,
Thank you for the response and for addressing the nit-comments in my review. All seems fine to me now from my end.
Regards,
Dan
On Tue, Apr 20, 2021 at 11:51 AM Sara Dickinson <sara@xxxxxxxxxxx> wrote:
On 17 Apr 2021, at 10: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.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/?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 publicationI’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?RegardsSara.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
