Re: [Add] Agenda and Revised Charter for the ABCD BoF

[Patrick McManus <[e-mail]>]

This charter just seems like a suggestion for a perpetual forum to argue
and, afaict, isn't actually expected to produce anything.. it just has some
things that if they were published would belong in the proposed wg.

Please don't make us collectively relive the ADD side meeting every full
meeting.

My suggestion: If the proponents believe that a group can publish a
document on (e.g.) "Communicating configuration between the network,
operating system, and applications" please write a charter with that as the
goal of the group and the BoF can do the usual thing of deciding whether
that is a problem worth solving, is well understood, and has a chance of
success. If it works out - recharter the group for new work.

As is the charter fails those tests by putting everything in scope but
requiring nothing at the same time.

-Patrick


On Thu, Nov 14, 2019 at 1:14 PM Ben Schwartz <bemasc=
[e-mail]> wrote:

>
>
> On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber <[e-mail]> wrote:
>
>> Moin!
>>
>> On 13 Nov 2019, at 2:32, Ben Schwartz wrote:
>> > Please review the agenda and proposed charter, and join us next week
>> > for a
>> > full discussion.
>>  From the proposed charter:
>> > This working group will consider technical drafts on DNS client
>> > configuration, especially with a focus on the following items where
>> > technical consensus seems obtainable:
>> >
>> > - Communicating configuration between the network, operating system,
>> > and
>> > applications
>> > - Discovery of resolvers and their capabilities and behaviors
>> > - Query routing in a multi-resolver environment
>> This is ambiguous.
>
>
> I think this is very closely related to the next entry on the list, so we
> should understand them together.  Perhaps they should be combined
>
>
>> If it describes the current /etc/resolv.conf that’s
>> fine,
>
>
> That would be in-scope (and there has been some innovation here related to
> retry behavior, load spreading, etc. which could be documented).
>
> but I fear that it describes something where you ask “resolver
>> A” for example.com and “resolver B” for example.net.
>
>
> I think designs of this kind would also be in-scope.
>
>
>> I don’t think that there is consensus for such an approach.
>>
>
> I don't think there is a single approach here; it seems to me that there
> is a vast range of possible client behaviors related to multiple
> resolvers.  Recommending a single behavior universally might be
> controversial, but I think there is plenty of room for productive technical
> discussion in this area without triggering reflexive disagreement.
>
>
>> > - Multiple non-equivalent query paths, such as split-horizon DNS or
>> > geo-sensitive answers
>>
>
> As an example of the kinds of issues that come up here, consider Mozilla's
> default behavior [1], in which an NXDOMAIN response from the primary
> resolution path triggers a retry of the query on a second resolution path.
> This is an interesting choice with particular privacy, security,
> compatibility, and performance properties.  Perhaps it's worth specifying
> this solution in more detail, or perhaps defining a range of solutions with
> different properties.  I believe we can discuss the properties of different
> stub state-machines without debating Mozilla's method for choosing the
> primary resolver.
>
> [1]
> https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-firefox-handle-split-horizon-dns
> <https://support..mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-firefox-handle-split-horizon-dns>
>
>
>> > - Local DNS caches (e.g. partitioning, use of stale records)
>> > - Resilience and fault-tolerance (e.g. single points of failure)
>> > - Support for debugging and analysis
>> > - DNS Push (accepting responses to queries that have not yet been
>> > issued)
>> Same thing I don’t think that there is consensus on this.
>
>
> We don't need consensus that a topic is worthwhile in order to include it
> in a working group charter.  We merely need to believe that there is some
> positive interest and potential for a technical consensus to emerge without
> derailing the working group's other topics.
>
>
>> I personally
>> think it is a bad idea, but I seem to recall from earlier discussions
>> that others agreed with me. IMHO this belongs in the relevant, but more
>> challenging for  consensus building category.
>>
>
> I don't think this topic is particularly controversial, and versions of
> this idea have been considered previously without major incident, e.g.
> [2].  This is purely a performance question; there is little security
> relevance, because we are speaking about answers delivered from the same
> resolver and query path as all the other DNS responses.
>
> In any case, RFC 8484 DoH already defines DNS Push (Section 5.3), along
> with some rules about when it cannot be used.  It does not, however,
> provide any additional guidance that might support practical use, and has
> some significant limitations.  Including this topic would allow us to
> improve the specification of DNS Push, or indeed deprecate it if that is
> the technical consensus.
>
> [2] https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05
>
> So long
>> -Ralf
>> —--
>> Ralf Weber
>>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>