Adaptive DNS Discovery
charter-ietf-add-01

No objection to external review, but I think there are some issues
that are likely to come up in that review that we can work to head
off now. If we don't, then we'll probably end up with a less-than-
productive working group.

I'll start by stating the obvious: the problem space that this working
group is establishing itself in is incredibly contentious, and finding
consensus on just about anything in this space has been elusive. Because
of this, I think we need to take special care to scope the work in a way
that keeps it off of the highly disruptive "third rail" topics that
have plagued conversations to date.

I can appreciate that the charter has undergone many iterations to arrive at
its current form, but still think that the working group would be well served
by some additional tightening up of the description of the deliverables.

Based on Tommy's most recent explanations of the intention of the three
cited deliverables, I would like to propose some re-scoping for the
purpose of making success more likely.

> - 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;

Branching out to solved problems, like generic DNS resolver discovery,
seems like it's carving out a much larger space than this working group
is intending to address. If the notion is to develop, say, a replacement
for DHCP or RA messages, then this phrasing makes sense. But if that's
the case, then I think we need to have a pretty serious conversation
with the associated protocol stakeholders in the INT and RTG areas.

Yes, I know that's not the intention, but it's what the words literally say.
We should make them say what they mean.

Based on the recent on-list conversation, I'm pretty sure the intention
here is to describe how a client can transition from knowing how to
contact a DNS server over an unencrypted channel to knowing how to
contact it over an encrypted channel. I *think* we can capture this
with something more along the lines of:

- define a mechanism that allows clients to discover how to contact
  known DNS resolvers over an encrypted channel, including resolvers
  provided by the local network, by a public DNS provider, or by way
  of an access technology like a VPN.

The second bullet seems good to me, although I do take EKR's point that
breaking these up into two deliverables does seem to prejudge the outcome
in a way that may not be useful. It might alleviate concerns if the second
bullet debiased this with a phrase like "...a mechanism, which may or may not
be the same as the mechanism mentioned above, ..."

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

Here I agree with both EKR and Éric that the described work is open-ended
enough to result in unproductive and likely toxic interactions. It would
be my strong recommendation to strike it from the charter at this time,
with an intention of re-visiting it if the working group is able to
productively make headway on the less-contentious issues called for by
the other deliverables. It may well be that this community finds a
positive way of interacting by solving the concrete discovery
mechanisms described above, and can then leverage the relationships
and trust they build during that exercise to succeed where conversations
have so far been fruitless. But I fear that putting this on the plate
as part of the first tranche of work is likely to lead to the same
acrimony that has dogged this endeavor in the past.