Re: [dns-privacy] [Ext] WGLC : draft-ietf-dprive-unilateral-probing

["George (Yorgos) Thessalonikefs" <[e-mail]>]

Hi Paul, authors,

On 26/05/2023 20:00, Paul Hoffman wrote:
> On Apr 14, 2023, at 11:14 AM, Brian Haberman <[e-mail]> 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