Re: [dns-privacy] [Gen-art] Genart last call review of draft-ietf-dprive-xfr-over-tls-09

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art