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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
