Adaptive DNS Discovery
charter-ietf-add-01

[Ballot comment]
We use "define a mechanism" for two work items but "describes
mechanisms" for the third -- is this intended to require exactly one
mechanism (as opposed to different mechanisms for, e.g., public Internet
and private-network resolvers) for those items?

  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.  It is chartered solely to develop technical
  mechanisms. Making any recommendations about specific policies for clients
  or servers is out of scope.

Are discussions of situations in which a given technical mechanism is
more or less useful considered to be a policy recommendation that is out
of scope?


And some (style) nits, since I can't un-notice them...

I think the semicolon in the second paragraph is better as a comma (the
part after the semicolon doesn't stand on its own).

  Clients adopting encrypted DNS protocols need to determine which DNS
  servers support encrypted transports, and which server to use for specific

Any reason to stick with "protocols" in the first instance but
"transports" in the second as opposed to just picking one for both
places?

  - define a mechanism that allows clients to discover DNS resolvers,
  including encrypted DNS servers, that are available to the client

[Similarly for resolvers/servers.]

[Ballot comment]
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.

[Ballot comment]
Just one concern about the 3rd work items ("informational document that describes how client applications and systems can manage selection of DNS resolvers") which may end up in rat hole discussions.

[Ballot comment]
I do not believe that this charter is perfect (nor that there won't be drama!), but I think that it's more than good enough to get the WG chartered, and start discussing documents...

[Ballot comment]
I do not believe that this charter is perfect (nor that there won't be drama!), but I think that it's fine to get the WG chartered.