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

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

Dear authors, dear DPRIVE WG,

Thank you for the hard work done on this document, it was not an easy ride, but the WG has reached consensus, and the change of intended status also fits the charter.

As usual, I have done an AD review of draft-ietf-dprive-unilateral-probing-09 before going forward with the publication process (i.e., the IETF Last Call). Please find below some points, I expect a reply or an action on all of them (except when noted) before the requesting the IETF Last Call.

Regards and even if DPRIVE does not meet in San Francisco for IETF-117, I will be there, so feel free to have a chat

-éric

# 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 ;-)

# Section 1

Section 1 mentions "Internet ecosystem" while the abstract is about "DNS ecosystem", perhaps worth using the same terms ?

Is it about ` provide guidance to implementers` or more about ` provide guidance to DNS operators` or both ?

# Section 1.1

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

# Section 1.2

Is 'deployment' required in `capable of opportunistic probing deployment` ?

` DoQ, DoT, and DoH collectively` but section 2.2 states later ` This document does not pursue the use of DoH in this context`

# Section 2.1

Should there be a more suitable wording for an experimental draft than ` This protocol aims`?

In the same vein, but this time it MUST be reworded ` This protocol specifies the use of DoT and DoQ`

# 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.

Please expand ALPN at first use.

# Section 3.1

` within the span of a few seconds` is rather vague. Should this be rephrased in "less than 30 seconds" (or whatever) ? Else, I fear some comments during the IESG review ;-)

# Section 3.2

In ` The simplest deployment would simply provide a self-issued, regularly-updated X.509 certificate` is the intent to use short-lived certificates ? Or more to state "valid certificate" ? The text would benefit from clarity.

# Sections 3.4, 3.5, and 3.6

Those 3 sections introduce some context explained later in the section 4.6. Suggest adding a forward internal reference to those sub-section on 4.6 (else it looks like repetition).

# 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.

# Section 4.1

I am not a native English speaker, but I find ` the recently-good encrypted transport` weird... Is it good English ?

` falls back to Do53 for that tuple` but this won't be a tuple anymore as it is merely clientIP, serverIP.

# Section 4.2

` or worse, filters the incoming traffic and does not even respond with an ICMP port closed message` I would assume that some authoritative servers would apply rathe limiting to ICMP to prevent a reflection attack.

Is there any chance to also use an IPv6 example ? 

# Section 4.4

Unsure whether the last paragraph has any value... ` a recursive resolver implementing these strategies SHOULD also accept queries from its clients over some encrypted transport (current common transports are DoH or DoT).
` Also, is DoH in scope for the communication to its client ?

# Section 4.5

This section is somehow mixing up text where the ClientIP is required in the tuple and sometimes not. The section 4.5.1 clarifies the text of course but comes a little late for the reader. Should the text in 4.5.1 be moved to the beginning of section 4.5 ?

As for section 4.2, an IPv6 example would be more modern.

# Section 4.6

It is a little unclear whether it is the client or server in ` using IP address X`.

# Section 4.6.3.3

The reference to ECH should be normative as there is no way to implement the RECOMMENDED action of this document w/o the ECH draft. This is of course annoying as the ECH I-D seems to be lingering and this would cause a delayed cluster.

# Section 4.6.10

Only one prioritization scheme in this section while there were two in section 3.4

# Appendix B

"DoE" is not expanded (even if guessable)

Are the measurements to be done on the recursive resolver and/or the authoritative server ?

# NITS

AFAIK, 'e.g.' is always surrounded by commas. And "instead" and "for example" are also followed by a comma.

In US-English, I think it is "signaling" with a single 'el' 

# Section 4.6.12 

s/ RTT (round trip time)/ Round Trip Time (RTT)/