Re: [dns-privacy] Opsdir last call review of draft-ietf-dprive-unilateral-probing-11

[Brian Haberman <[e-mail]>]

Dhruv,
      Thanks for the comments. The authors will address these comments 
and get back to you with any follow-ups.

Regards,
Brian

On 8/26/23 9:49 AM, Dhruv Dhody via Datatracker wrote:
> Reviewer: Dhruv Dhody
> Review result: Has Nits
> 
> # OPSDIR review of draft-ietf-dprive-unilateral-probing-11
> 
> I have reviewed this document as part of the Operational directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written with the intent of improving the operational aspects of
> the IETF drafts. Comments that are not addressed in the last-call may be
> included in AD reviews during the IESG review.  Document editors and WG chairs
> should treat these comments just like any other last-call comments.
> 
> The document is clear and well-written. The motivation is described well. The
> guiance is clear. I have some minor comments and nits.
> 
> ## Minor
> 
> - Section 4.6.1, in the below text, does "persistence" play no role when you
> say "regardless of how long in the past that was"?
> ~~~~
>     *  E-status[X] is success, and (T0 - E-last-response[X]) <
>        persistence
> 
>     This indicates that one successful connection to a server that the
>     client then closed cleanly would result in the client not sending the
>     next query over Do53, regardless of how long in the past that was.
> ~~~~
> 
> - Section 4.6.5, in the text "if Q is not present in any other *-queries[X] or
> in Do53-queries[X]", does Do53-queries not part of *-queries? If this is not
> true perhaps please explain early on what *-queries mean. (Note there are other
> instances of this as well)
> 
> - Section 6.2, suggest to state clearly why modeling the probability is listed
> under privacy consideration. This is not clear from the current text.
> 
> - Appendix A, any reason not to follow RFC 7942?
> 
> - Appendix B, considering expanding this more on how would you judge this
> experiment to be a success and perhaps move to standards track?
> 
> ## Nits
> 
> - Abstract, shouldnt "underlying transport" be "underlying encrypted transport"?
> 
> - Section 1.2, add DoH
> 
> - For the quotes in Section 2.2
>      - It is better to state the RFCs where these quotes originate.
>      - You could also use visual cues via blockquotes
> 
> - Section 3, you expand DoT and DoQ here but, they have already been used
> without expansion in 2.2
> 
> - Section 4, s/in failed resolutions or significant delay/in failed resolutions
> or significant delays/
> 
> Thanks!
> Dhruv
> 
>