Hi Paul, authors,
On 26/05/2023 20:00, Paul Hoffman wrote:
On Apr 14, 2023, at 11:14 AM, Brian Haberman <br...@innovationslab.net> wrote:
All,
An update on the status of this draft. I have asked the authors to review
all the feedback, provide the mailing list with responses to the comments, and
then publish a new version.
We believe that -06 deals with all of the WG Last Call issues raised, except one. We
didn't understand "## E" in Yorgos' message from April 7. Yorgos: could you
reformulate that concern based on the -06 draft?
That concern remains the same. I was trying to address two different
sections with the same problem at once and as a result my text was not
clear enough.
I will try to streamline it:
0. I assume that the query is already sent to all destinations that
unilateral probing allows.
1. When a Do53 reply comes in, the following text in section
"4.6.2. Receiving a Response over Do53" applies:
...
If R is successful:
...
For each supported encrypted transport E:
If Q is in E-queries[X]:
Remove Q from E-queries[X]
2. Thus Q is removed from E-queries[X]
3. When a DoQ/T reply comes in, the following text in section
"4.6.9. Receiving a Response over Encrypted Transport"
applies:
If Q is not in E-queries[X]:
Discard R and process it no further (do not respond to a
encrypted response to a query that is not outstanding)
Otherwise:
Remove Q from E-queries[X]
Set E-last-activity[X] to T5
Set E-last-response[X] to T5
The result is that the metrics will not be updated for the
encrypted replies, especially when we assume that Do53 replies will
be faster in a probing scenario. So the first probe reply (encrypted
or not) shadows the other available ones. Admittedly missing
E-last-activity and E-last-response is not that serious but still feels
wrong.
I believe the correct approach is to always update the corresponding
timers when an encrypted response is received.
And a notice for "Appendix A. Early Implementations" and Unbound, the
experimental implementation was more of an exploratory move to see what
needs changing in Unbound for probing to happen, rather than an actual
implementation. The last state of that was Unbound always working for
the unhappy path ;) and falling back to Do53.
I would either remove the Unbound mention altogether or note it as in
experimental implementation state for DoT.
Best regards,
-- Yorgos
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
