Adaptive DNS Discovery
Note: This ballot was opened for revision 00-00 and is now closed.
Ballot question: "Is this charter ready for external review?"
Deborah Brungard Yes
Alissa Cooper Yes
Benjamin Kaduk Yes
Comment (2020-02-05 for -00-02)
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.]
Warren Kumari Yes
Comment (2020-01-28 for -00-00)
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...
(Mirja Kühlewind) Yes
Barry Leiba Yes
Éric Vyncke Yes
Comment (2020-02-02 for -00-00)
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.
Roman Danyliw No Objection
(Suresh Krishnan) No Objection
(Alexey Melnikov) No Objection
Alvaro Retana No Objection
(Adam Roach) No Objection
Comment (2020-02-03 for -00-00)
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.