Re: [dns-privacy] AD review of draft-ietf-dprive-unilateral-probing-09

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you for the -10 revision and its multiple changes.

Alas, it seems that some points below are not fully addressed either by email or in the I-D. See the elided text below, looking for EV>

The only critical one is the discrepancy between the shepherd's write up point 4 and the I-D appendix A. This MUST be resolved before the IETF Last Call.

(and sorry for the Outlook look of my reply ☹ ...)

Regards, I sincerely hope that this thread has improved the quality of the document.

-éric

On 17/07/2023, 14:06, "Eric Vyncke (evyncke)" <[e-mail] <mailto:[e-mail]>> wrote:

...

# Shepherd's write-ip


The shepherd's write-up states "the WG would like to ensure that this list remains in the document once it is published as an RFC" but the appendix A states "RFC Editor: please remove this section before publication". I.e., the shepherd's write-up and the I-D MUST be coherent ;-)

EV> we do need the shepherd's write-up and I-D being consistent on this point. *Let me know when either the shepherd's write-up or the I-D is modified.*

# Section 1.1

I am always uneasy with the use of BCP14 normative language outside of a standard track or BCP document.

EV> I have read Paul's reply, as long as authors are aware, let it be. Expect some non-blocking comments by some ADs during the IESG evaluation.

# Section 3

This was probably discussed over the mailing list, but must DoT & DoQ replies be also identical to Do53 replies ? The current text is a little underspecified.

Paul> The last paragraph of Section 3 says "An authoritative server implementing DoT or DoQ MUST authoritatively serve the same zones over all supported transports." How should we say that differently to be more specfied?

EV> I still find the text a little unclear about the returned DNS replies (e.g., the answer section must be identical in Do53 and DoT). I am leaving the choice to the authors about whether to add further clarification text.

# Section 3.5

Expect some comments during the IESG review if the SHOULDs do not have some wording about when the SHOULDs does not apply.

EV> thanks, Paul, for explaining the somehow convoluted/complex clause "this might be limited by e.g. not receiving an EDNS(0) option in the query". You may consider rendering it easier to parse though.

# Section 4.2

Is there any chance to also use an IPv6 example ? 

EV> Obviously, there was no chance ;-)