Subject: Re: [Add] Charter proposal for ADD

From: Eric Rescorla <[email-masked]>
Date: Sat, 1 Feb 2020 07:29:11 -0800

Hi folks,

I finally got around to reading this charter and while I appreciate
the effort that has gone into it, I don't think it's ready for prime
time.

The fundamental problem here is that the charter seems to be
conflating two very different types of discovery:

(1) Discovering the resolvers that are available on a specific
    network or that the network would like a given client
    to use (and potentially their policies). (as in
    draft-ietf-dnsop-resolver-information or
    draft-reddy-dprive-dprive-privacy-policy)

(2) Discovering the resolvers that a given domains would like
    you to use to resolve them and their subdomains
    (as in draft-pauly-dprive-adaptive-dns-privacy)

It's pretty hard to map these onto the list of work items.

   - define a mechanism that allows clients to discover DNS resolvers,
   including encrypted DNS servers, that are available to the client
   either on the public Internet or on private or local networks;

   - define a mechanism that allows communication of DNS resolver
   information to clients for use in selection decisions;

Perhaps the first bullet is intended to refer to (1), but the "public
Internet" text that is confusing here, because while the local network
might want to tell you about some server that happens to be on the
public Internet (e.g., it wants to point you to QuadX) that's not the
relevant point and not something that the client cares about [0].
Similarly, the second bullet point might be intended to refer to (2)
but it doesn't have anything about per-domain information, so it might
just as well refer to something like
draft-ietf-dnsop-resolver-information. So, in both cases it just seems
like this charter conflates these cases. I would suggest changing the
bullets to be more like my list above.

The third bullet seems like it is edging pretty close to the
zone of controversy:

   - develop an informational document that describes how client
   applications and systems can manage selection of DNS resolvers
   in various network environments and use cases.

I supposed if this was just a laundry list of every idea anyone
had ever thought of, that might be OK, but in my experience
documents like this (1) do some selection of the mechanisms
and (2) want to list the pluses and minuses of each mechanism
and both of these seem like a recipe for the kind of argument
that this group has been having for some time. I would propose
striking this work item entirely.

-Ekr

[0] It's possible that what this is referring to is somehow
discovering a set of viable QuadX resolvers, but that's yet
a third problem with its own solution and I doubt we are going
to be able to standardize that at all.

On Tue, Jan 28, 2020 at 7:41 AM Barry Leiba <[email-masked]> wrote:

> I have begun the chartering process with the charter below, modulo a
> small edit by me in the last paragraph.
>
> https://datatracker.ietf.org/doc/charter-ietf-add/
>
> It would be good if we could have an estimated milestone based on the
> assumption that this working group would be chartered by and meet at
> IETF 107 in Vancouver.
>
> Barry, ART AD
>
> On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly <[email-masked]> wrote:
> >
> > Hi ADD,
> >
> > As our discussion on the proposed charter has quieted down, I wanted to
> send a brief update and summary.
> >
> > The main point of discussion was the paragraph on security requirements
> that began "Any mechanisms that...". As many people stated on the previous
> thread, the necessity for security considerations and security area review
> in work produced by an IETF working group is already well-established, so
> this text is not needed specifically in this charter. There were some
> proposals to tweak the language, but on the whole, it seems that we can
> live without that paragraph.
> >
> > Jari also had a good suggestion to include a sentence about the impact
> of resolver selection (on reachability and privacy, etc). After looking at
> adding that text, I am concerned that adding it to the charter gets into
> too many details that really belong in the WG documents, particularly
> around how to assess the "privacy" implications of choosing one resolver
> over another. The charter does indicate that these mechanisms are being
> used to "provide benefits to the security and privacy of DNS data", and it
> does cover reachability with the example of "a resolver may be able to
> resolve private or local names...". As such, I'd prefer to not add any new
> sentence for now (and Jari indicated he could live with the text as is!).
> >
> > I've included the updated proposal, which matches the previous proposal
> and removes the text on security requirements. Based on the previous
> thread, this should represent the consensus of the list.
> >
> > Barry, can you help get this started in the process of chartering?
> >
> > Best,
> > Tommy
> >
> >
> >
> > Adaptive DNS Discovery (ADD)
> > ====================================
> > Proposed Working Group Charter
> >
> > Sending DNS messages over encrypted transports, as defined in DNS over
> > TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides
> > benefits to the security and privacy of DNS data. Clients, such as
> > applications and host operating systems, have started adopting these
> > protocols to provide these user benefits.
> >
> > This working group will focus on discovery and selection of DNS resolvers
> > by DNS clients in a variety of networking environments, including public
> > networks, private networks, and VPNs; supporting both encrypted and
> > unencrypted resolvers.
> >
> > Clients adopting encrypted DNS protocols need to determine which DNS
> > servers support encrypted transports, and which server to use for
> specific
> > queries if multiple servers are available. These decisions can vary based
> > on the network environment, and also based on the content and purpose of
> > the client queries.
> >
> > Network operators that start offering DNS encryption on their servers
> also
> > need a way to indicate this support to clients. Communicating information
> > about resolver configuration and behavior allows clients to make more
> > informed decisions about which DNS servers to use. For example, a
> resolver
> > may be able to resolve private or local names as a split DNS server.
> >
> > The Adaptive DNS Discovery (ADD) working group will work on the following
> > deliverables:
> >
> > - define a mechanism that allows clients to discover DNS resolvers,
> > including encrypted DNS servers, that are available to the client
> > either on the public Internet or on private or local networks;
> >
> > - define a mechanism that allows communication of DNS resolver
> > information to clients for use in selection decisions;
> >
> > - develop an informational document that describes how client
> > applications and systems can manage selection of DNS resolvers
> > in various network environments and use cases.
> >
> > This working group will coordinate with dnsop, doh, and dprive for any
> > changes required in DNS protocols. It will also work with capport to
> > ensure that solutions are applicable to captive networks.
> >
>
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 01 Feb 2020 13:36:09 -0800

> On Feb 1, 2020, at 7:29 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> Hi folks,
> 

The first work item refers to discovery of the existence and identities of resolvers, such as DoH URI template, for both the cases you list as (1) and (2). The phrase for “public Internet” is intended to refer to resolvers that are generally available regardless of your local network connection (not cases in which your local network points to an address that happens to be QuadX); and the local and private networks refers to resolvers that are available only locally or based on some special property of the connectivity, such as a VPN or enterprise network. So this covers the use of DHCP, RA, or DNS records (as in draft-pauly-dprive-adaptive-dns-privacy) to identify resolvers.

The second work item is about defining the mechanism by which information (which could at some point include policy) about the resolver is communicated to the host. For the per-domain use cases described in draft-pauly-dprive-adaptive-dns-privacy, that information mechanism helps identify the relevant domains; it also can include draft-ietf-dnsop-resolver-information, draft-reddy-dprive-dprive-privacy-policy.

>    in various network environments and use cases.

Can you clarify what controversy you see arising from this work item? The intent here is to describe recommendations for how to work with scenarios like VPNs, captive networks, locally-hosted network content, etc, in a world where DoH is used both to local and public/remote resolvers.

> striking this work item entirely.

This is not at all intended to be a laundry list of multiple approaches to the same use cases, with plusses and minuses. The key point in the item is enumerating the *network environments and use cases* (like captive networks, say) that should be considered by clients during implementation.

Thanks,
Tommy

> On Tue, Jan 28, 2020 at 7:41 AM Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:
> https://datatracker.ietf.org/doc/charter-ietf-add/ <https://datatracker.ietf.org/doc/charter-ietf-add/>
> 
> On Mon, Jan 27, 2020 at 4:13 PM Tommy Pauly <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi ADD,
> >
> > As our discussion on the proposed charter has quieted down, I wanted to send a brief update and summary.
> >
> > The main point of discussion was the paragraph on security requirements that began "Any mechanisms that...". As many people stated on the previous thread, the necessity for security considerations and security area review in work produced by an IETF working group is already well-established, so this text is not needed specifically in this charter. There were some proposals to tweak the language, but on the whole, it seems that we can live without that paragraph.
> >
> > Jari also had a good suggestion to include a sentence about the impact of resolver selection (on reachability and privacy, etc). After looking at adding that text, I am concerned that adding it to the charter gets into too many details that really belong in the WG documents, particularly around how to assess the "privacy" implications of choosing one resolver over another. The charter does indicate that these mechanisms are being used to "provide benefits to the security and privacy of DNS data", and it does cover reachability with the example of "a resolver may be able to resolve private or local names...". As such, I'd prefer to not add any new sentence for now (and Jari indicated he could live with the text as is!).
> >
> > I've included the updated proposal, which matches the previous proposal and removes the text on security requirements. Based on the previous thread, this should represent the consensus of the list.
> >
> > servers support encrypted transports, and which server to use for specific
> > Network operators that start offering DNS encryption on their servers also
> > informed decisions about which DNS servers to use. For example, a resolver
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 07:48:02 -0800

Tommy,

Thanks for your note.

Before we get into the details, I would observe that my understanding
of the charter text seems pretty divergent from your intent. I think
this is a fairly strong signal that the text needs: if a charter
doesn't describe the work to be done sufficiently precisely that
someone familiar with field can understand it, then it's not doing its
job.

With that said, now that I understand your intent, I also have severe
misgivings about some of the proposed work, as noted below.

> The first work item refers to discovery of the existence and
> identities of resolvers, such as DoH URI template, for both the cases
> you list as (1) and (2). The phrase for “public Internet” is intended
> to refer to resolvers that are generally available regardless of your
> local network connection (not cases in which your local network points
> to an address that happens to be QuadX);

I don't understand what work you are contemplating here: some sort of
public directory which lists QuadX and similar resolvers and their
properties? Is there demand for such a thing? At least from the
perspective of Firefox, I don't see how this would be useful.
Even for clients which don't intend to operate some kind of
TRR-style program, it seems clear that there are going to be
some malicious resolvers in this directory; how would you know
which ones they were?

In any case, this seems like a completely different problem
from learning the resolver offerings/preferences for a given
local network, so these should be separate work items, not
merged into one bullet.

> The second work item is about defining the mechanism by which
> information (which could at some point include policy) about the
> resolver is communicated to the host. For the per-domain use cases
> described in draft-pauly-dprive-adaptive-dns-privacy, that information
> mechanism helps identify the relevant domains; it also can include
> draft-ietf-dnsop-resolver-information,
> draft-reddy-dprive-dprive-privacy-policy.

This seems to have a specific architecture in mind which is not
necessarily the right architecture. I.e., one could define
a system in which you learn about a resolver and then learn
about its properteis from it (as you suggest here) or one in
which you learn about a resolver *and* its properties and then
decide whether to use it. This latter design is more attractive
in a number of cases, so I don't think that we ought to predecide
it in the charter.

Here too, draft-pauly and the other drafts seem designed for
totally different use cases and therefore should be seperate
work items.

> Can you clarify what controversy you see arising from this work item?
> The intent here is to describe recommendations for how to work with
> scenarios like VPNs, captive networks, locally-hosted network content,
> etc, in a world where DoH is used both to local and public/remote
> resolvers.

Well, here too, we have a lack of clarity in the text, so I
don't know what's buried in your "etc.". One case
I am concerned about is one in which the network wishes
to communicate that it wants you to use a specific resolver
but the client decides to ignore that. This is clearly
contested ground.

> This is not at all intended to be a laundry list of multiple
> approaches to the same use cases, with plusses and minuses. The key
> point in the item is enumerating the *network environments and use
> cases* (like captive networks, say) that should be considered by
> clients during implementation.

Well, the text says "hoc client applications and systems can manage",
so it's clearly rather more than just enumeration.

-Ekr

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 02 Feb 2020 12:04:22 -0800

Hi Ekr,

Thanks for the further comments!

Responses inline, but as a general comment, I think the proposed charter text is more open-ended than some of the points you’re bringing up. It intentionally is not trying to prescribe the technical solutions or how those solutions will be arranged, but rather the solution space that a working group can focus on. To that end, tweaking the wording to not imply solutions that are not meant to be implied is definitely useful, but I’m not sure it would be good to define too many protocol details in the charter text. 

> On Feb 2, 2020, at 7:48 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Tommy,
> 
> Thanks for your note.
> 
> > > On Feb 1, 2020, at 7:29 AM, Eric Rescorla <ekr@rtfm..com <mailto:[email-masked]>> wrote:
> > >

This charter isn’t proposing some public directory or list. I agree that such a list doesn’t really make sense, and I don’t know of anyone asking for that.

Your quoted text removed the portion of the response that was probably most relevant for explaining the intent: "this covers the use of DHCP, RA, or DNS records... to identify resolvers.” It’s up to whatever group forms to decide what to do, but at the most basic this would imply that a client could learn from a local network if the local resolver supports DoH, and what the DoH URI Template is for that case; and if the client device is pointed (say, by user selection) to a public resolver like a QuadX, that it could learn what the DoH URI Template for that is as well.

The point of this is to not require big lists of resolvers. The details of mechanism, though, need to be left to the group discussion.

> totally different use cases and therefore should be seperate

I agree that these details shouldn’t be predecided in the charter, and I don’t think they are. The charter proposal doesn’t preclude the mechanisms for resolver discovery and information being in the same document, or in separate documents.

The reason this is listed as separate from discovering the existence of resolvers is to be clear that having a way to look up the properties of a resolver is something that may be desirable even for cases in which clients already have some hardcoded list of resolvers they know about. For example, if like Firefox, a browser knew about some public trusted resolvers, being able to query those resolvers about information such as keys for making oblivious queries is something that ought to be done in a standard fashion.

I definitely think that in many cases, the existence and applicability of a resolver should be done in the same step, but the details should be worked out by the group, not dictated by a charter.

> but the client decides to ignore that. This is clearly

Got it. Yes, I imagine that if a group tried to give recommendations around whether or not clients can ignore network policy, it would be difficult to quickly come to an agreement. However, I don’t think that (a) a charter should make it out of scope to touch on that topic if the group decided that it actually could do useful work there, or that (b) a charter should preclude the group from working on the recommendations and descriptions for cases that are not as contentious that still need explanation, such as how to deal correctly with captive networks, VPNs, and private networks.

> so it's clearly rather more than just enumeration.

Yes, indeed. My point here was that any document here wouldn’t be enumerating *possible approaches*, as you suggested, but would be enumerating the *network scenarios* clients need to handle.

Clients managing selection of resolvers would, for example, include the fact that a probe for a captive portal trigger page needs to use the locally-provisioned DNS resolver, even if user-facing traffic is otherwise bound to some other encrypted public resolver.

Thanks,
Tommy

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 20:41:01 -0800

On Sun, Feb 2, 2020 at 12:04 PM Tommy Pauly <[email-masked]> wrote:

> Responses inline, but as a general comment, I think the proposed charter
> text is more open-ended than some of the points you’re bringing up.
>

Yes. I am arguing against that. A charter is a contract between the WG and
the IESG and contracts need to be crisp. This is not.

It intentionally is not trying to prescribe the technical solutions or how
> those solutions will be arranged, but rather the solution space that a
> working group can focus on.
>

Yes, but I don't agree that we should be working in some of the space this
lays out.

To that end, tweaking the wording to not imply solutions that are not meant
> to be implied is definitely useful, but I’m not sure it would be good to
> define too many protocol details in the charter text.
>

I'm not trying to define protocol details.

>
> > > On Feb 1, 2020, at 7:29 AM, Eric Rescorla <ekr@rtfm..com
> <[email-masked]>> wrote:
> > >
> This charter isn’t proposing some public directory or list. I agree that
> such a list doesn’t really make sense, and I don’t know of anyone asking
> for that.
>
> Your quoted text removed the portion of the response that was probably
> most relevant for explaining the intent: "this covers the use of DHCP, RA,
> or DNS records... to identify resolvers.” It’s up to whatever group forms
> to decide what to do, but at the most basic this would imply that a client
> could learn from a local network if the local resolver supports DoH, and
> what the DoH URI Template is for that case;
>

Yes, this makes sense.

and if the client device is pointed (say, by user selection) to a public
> resolver like a QuadX, that it could learn what the DoH URI Template for
> that is as well.
>

Why would you want this and why would you trust the network for that
information?

The point of this is to not require big lists of resolvers. The details of
> mechanism, though, need to be left to the group discussion.
>

Of course, but if we don't have any ideas that make sense, then the work
shouldn't be chartered.

> I agree that these details shouldn’t be predecided in the charter, and I
> don’t think they are. The charter proposal doesn’t preclude the mechanisms
> for resolver discovery and information being in the same document, or in
> separate documents.
>

It's not an issue of documents, but of work items.

The reason this is listed as separate from discovering the existence of
> resolvers is to be clear that having a way to look up the properties of a
> resolver is something that may be desirable even for cases in which clients
> already have some hardcoded list of resolvers they know about. For example,
> if like Firefox, a browser knew about some public trusted resolvers, being
> able to query those resolvers about information such as keys for making
> oblivious queries is something that ought to be done in a standard fashion.
>

> I definitely think that in many cases, the existence and applicability of
> a resolver should be done in the same step, but the details should be
> worked out by the group, not dictated by a charter.
>

My point is that your charter strongly pushes this particular detail in one
direction.

> Got it. Yes, I imagine that if a group tried to give recommendations
> around whether or not clients can ignore network policy, it would be
> difficult to quickly come to an agreement. However, I don’t think that (a)
> a charter should make it out of scope to touch on that topic if the group
> decided that it actually could do useful work there,
>

I strongly disagree here. The charter should, in fact, rule out the most
controversial topics precisely because even having the group try to decide
whether it could do useful work on them  is itself going to be distracting.

or that (b) a charter should preclude the group from working on the
> recommendations and descriptions for cases that are not as contentious that
> still need explanation, such as how to deal correctly with captive
> networks, VPNs, and private networks.
>

Well, I'm not sure there is a "correct" answer for any of these. Also,
what's a "private network"? If you mean "enterprise network", then this is
in fact a very contentious case.

> Yes, indeed. My point here was that any document here wouldn’t be
> enumerating *possible approaches*, as you suggested, but would be
> enumerating the *network scenarios* clients need to handle.
>

> Clients managing selection of resolvers would, for example, include the
> fact that a probe for a captive portal trigger page needs to use the
> locally-provisioned DNS resolver, even if user-facing traffic is otherwise
> bound to some other encrypted public resolver.
>

This is a perfect example of what I am concerned about, which is not just
about listing the cases but proposing solutions. As it happens, I don't
think there's much controversy about this particular one (and i agree that
the solution you propose is likely correct), but there may well be about
others. And some of the other environments are much less obvious.

-Ekr

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 02 Feb 2020 21:18:30 -0800

> On Feb 2, 2020, at 8:41 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> and if the client device is pointed (say, by user selection) to a public resolver like a QuadX, that it could learn what the DoH URI Template for that is as well.
> 
> Why would you want this and why would you trust the network for that information?

Just to clarify, I didn’t mean that information about public resolvers would come from the local network. The information should certainly be trusted, and not just second-hand. Proposals that can be more trusted are learning it from other HTTPS connections, or having DNSSEC signed records. Other good options probably exist too.
 
> 
> 
> Got it. Yes, I imagine that if a group tried to give recommendations around whether or not clients can ignore network policy, it would be difficult to quickly come to an agreement. However, I don’t think that (a) a charter should make it out of scope to touch on that topic if the group decided that it actually could do useful work there,
> 
> I strongly disagree here. The charter should, in fact, rule out the most controversial topics precisely because even having the group try to decide whether it could do useful work on them  is itself going to be distracting.
> 
> or that (b) a charter should preclude the group from working on the recommendations and descriptions for cases that are not as contentious that still need explanation, such as how to deal correctly with captive networks, VPNs, and private networks.
> 
> Well, I'm not sure there is a "correct" answer for any of these. Also, what's a "private network"? If you mean "enterprise network", then this is in fact a very contentious case.

By “private network”, I did mean enterprise networks (or any network that has names that resolve only on the network, and not publicly). While there may be disagreement about some of the details there, it is a very important topic to consider. There are ways to make these deployments work well with clients that use DoH to public servers, and it should be in scope for the group to address that solution space.

> This is a perfect example of what I am concerned about, which is not just about listing the cases but proposing solutions. As it happens, I don't think there's much controversy about this particular one (and i agree that the solution you propose is likely correct), but there may well be about others. And some of the other environments are much less obvious.

Right, I chose an example that is pretty cut-and-dry. Of course, discussion around other topics should be managed so as not to spiral, but it’s not clear that the charter should prohibit any area of discussion.

I’ll let the IESG review chime in more on the scope they prefer for the charter, at this point.

Tommy

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 2 Feb 2020 21:28:30 -0800

On Sun, Feb 2, 2020 at 9:18 PM Tommy Pauly <[email-masked]> wrote:

> Right, I chose an example that is pretty cut-and-dry. Of course,
> discussion around other topics should be managed so as not to spiral, but
> it’s not clear that the charter should prohibit any area of discussion.
>

Well, the entire point of *any* charter is to rule out specific areas of
work. And in this case that's particularly important to avoid a replay of
the past year.

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Tue, 4 Feb 2020 11:33:06 +0000

With one minor tweak, I support the proposed charter and am willing to work on the suggested deliverables. Thanks for putting this together Tommy.

IMO "develop an informational document that describes how client applications and systems can manage selection of DNS resolvers in various network environments and use cases” might be too ambitious for a single document. It might be better to say “develop a set of informational documents..” in case it turns out that precisely targeted documents for specific use cases -- split DNS, enterprise networks, coffee shop captive portals, home nets lurking behind NAT, etc -- are more digestible than one document which tries to cover all possible scenarios.

The recent comments about avoiding contentious issues in the new WG are well intentioned. Though I think they’re been over-stated. Given recent experiences, I very much doubt anyone will be stupid enough to come to the new WG and propose working on topics that are likely to create trouble and/or fail to make progress. Besides, there would be plenty of objections (and therefore no consensus) if they tried. Next, if it later transpired some work item did end up drifting into that territory, we should be able to rely on the WG co-chairs and/or the overseeing AD to intervene and ensure common sense prevails. It’s not unknown for IETF WGs to have contentious or unproductive discussions and charter wording hasn’t made much difference to that.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 4 Feb 2020 13:38:07 +0100 (CET)

> Il 04/02/2020 12:33 Jim Reid <[email-masked]> ha scritto:
> 
>  

I'd like to join in thanking Tommy, Glenn, Ben, the BoF chairs and everyone that has worked to advance the text. There are things in this charter that I would have written differently, starting from the name - while I see the merits of the "adaptive DNS" idea, I also think that spreading out DNS resolution queries to multiple servers at once would be a policy nightmare in terms of data protection, GDPR compliance, jurisdiction etc., and would create pushback against deployment. Still, I want to work with people that have other views and try to find common ground on a number of things on which this looks possible, so I am in favour of proceeding under the current charter.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: <[email-masked]>
Date: Tue, 4 Feb 2020 12:59:24 +0000

I'm too in favour of this proposed charter and am willing to work on the suggested deliverables

With thanks to all who have contributed so far...

Regards

Bob

-----Original Message-----
From: Add <[email-masked]> On Behalf Of Vittorio Bertola
Sent: 04 February 2020 12:38
To: Jim Reid <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: Re: [Add] Charter proposal for ADD

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange [email-masked] Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Andrew Campling <[email-masked]>
Date: Tue, 4 Feb 2020 13:44:01 +0000

On Tue, Feb 4, 2020 at 11:33 AM Jim Reid <[email-masked]> wrote:

> IMO "develop an informational document that describes how client applications and systems can manage selection
> of DNS resolvers in various network environments and use cases” might be too ambitious for a single document. It
> might be better to say “develop a set of informational documents..” in case it turns out that precisely targeted
> documents for specific use cases -- split DNS, enterprise networks, coffee shop captive portals, home nets lurking
> behind NAT, etc -- are more digestible than one document which tries to cover all possible scenarios.

I'm in favour of the charter proposed by Tommy Pauly, with the amendment of the third deliverable into a set of informational documents rather than a single item, as suggested above, and am willing to work on the suggested deliverables.  There is clearly work to be done here; I'm confident that leadership by the co-chairs and AD will help address the potential issues that some have flagged on the list without the need to engage in open-ended wordsmithing of the charter.

Andrew

---

From: "Arnaud.Taddei.IETF" <[email-masked]>
Date: Tue, 04 Feb 2020 14:27:52 +0000

I am in favor of this charter too and will do my best to support and review

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

---

From: "Normen B. Kowalewski" <[email-masked]>
Date: Wed, 5 Feb 2020 01:41:33 +0100

Dear Tommy,

and all others, who took the time and effort to refine the charter to this
point, many thanks for your work.
I support the charter, and also consider the tweak that Jim has proposed as
useful.

With best regards,

Normen Kowalewski

-----Ursprüngliche Nachricht-----
Von: Add [mailto:[email-masked]] Im Auftrag von Jim Reid
Gesendet: Dienstag, 4. Februar 2020 12:33
An: Tommy Pauly
Cc: ADD Mailing list; Barry Leiba
Betreff: Re: [Add] Charter proposal for ADD

With one minor tweak, I support the proposed charter and am willing to work
on the suggested deliverables. Thanks for putting this together Tommy.

IMO "develop an informational document that describes how client
applications and systems can manage selection of DNS resolvers in various
network environments and use cases” might be too ambitious for a single
document. It might be better to say “develop a set of informational
documents..” in case it turns out that precisely targeted documents for
specific use cases -- split DNS, enterprise networks, coffee shop captive
portals, home nets lurking behind NAT, etc -- are more digestible than one
document which tries to cover all possible scenarios.

The recent comments about avoiding contentious issues in the new WG are well
intentioned. Though I think they’re been over-stated. Given recent
experiences, I very much doubt anyone will be stupid enough to come to the
new WG and propose working on topics that are likely to create trouble
and/or fail to make progress. Besides, there would be plenty of objections
(and therefore no consensus) if they tried. Next, if it later transpired
some work item did end up drifting into that territory, we should be able to
rely on the WG co-chairs and/or the overseeing AD to intervene and ensure
common sense prevails. It’s not unknown for IETF WGs to have contentious or
unproductive discussions and charter wording hasn’t made much difference to
that.