Re: [Add] My single use case

Hi Martin,

Discovering and selecting are from my point of view, separate processes,
and learning that one resolver performs qname should be learnt during the
discovery, while the decision should be part of the selection process.

Yours,
Daniel

On Thu, Sep 10, 2020 at 11:08 AM Martin Thomson <mt@lowentropy.net> wrote:

> My preference is to tackle just this:
>
> As a new device or application, when I join a network that I have no prior
> relationship with or configuration for, I want to discover the DoT or DoH
> resolver that corresponds to the Do53 resolver offered by that network.
>
> This might need the full matrix of DoT/DoH, v4/v6, with/without a
> forwarder, but this is fundamentally just a single use case.
>
> Specifically, I want to NOT learn about whether the resolver does qname
> minimization or DoT to the authoritative or whether it does the eDNS client
> subnet or different policies with respect to what is answered or anything
> else that might make a decision to use this alternative complicated.
> Existing methods don't provide this information.  I don't want a protocol
> that does anything fancy because that makes the decision complex.
>
<mglt>
The discovery as far as I understand it is expected to be followed by a
selection process which could result in using multiple resolvers. So, it
may be possible information related to a resolver is being discovered
during the discovery. That these parameters should not influence the
discovery process is one thing, that these parameters should not be
discovered is another thing. The text seems to say the second. If you
happen to know that the resolver does qname or not will be considered by
the selection process not the discovery but one may learn it during the
discovery - at least in my opinion.
</mglt>

>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>

-- 
Daniel Migault
Ericsson