[Add] What to do in this potential working group

[Jari Arkko <[e-mail]>]

I’ve been on vacation and doing some other things for the last couple of weeks, and now I’ve been trying to read the mailing list discussions. Not easy!

Let me try another angle into the discussion and see if it’s helpful.

Much of the discussion has been about the conflicts between people’s different use cases or trustworthiness perceptions for different entities. “I trust industry X more than industry Y” or “I need to perform <thing> which conflicts what you’re trying to do prevent <another thing>”. And the various details of performing those <things>.

There’s been not so much discussion about concrete things where IETF can help, or discussion about understanding and agreeing where our agreements and disagreements lie, or where the factual things end and opinions begin.

So how about looking at this first by understanding what kinds of things we might actually agree on, and acknowledging what we disagree on? For instance, I think there are helpful small things that I don’t think are hugely controversial, better discovery mechanisms for instance. Similarly, I don’t think we will find an agreement whether one trusts an ISP more or less than a large Internet company (because it depends, duh). But we might find agreement on some more structural things, such as what factors have an effect, and what good solutions look like. For instance, while we might differ on what services we consider trustworthy, to me it seems obvious that creating a single entity that has access to all users’ DNS queries is potentially very dangerous architecture for the Internet. Too attractive target for governments to tap, for instance. 

We might also agree on principles, such as the ones about user configuration taking precedence over network configuration.

We do disagree on how to handle filtering use cases, enterprise networks, how to deal with CDN localisation and other operational use cases. Some of these things people care deeply about. And we might disagree on what the advice is on split DNS.

In any case, to start with the parts that we possibly do agree on, there is at least a beginning of a list of work items. For instance:

* Improved mechanisms for discovery and selection of encrypted DNS transports
* Best operational practices for running an encrypted DNS transport service (possibly subdivided for the type of deployment, e.g., ISP or global service)
* Recommendation for precedence of configuration mechanisms
* Recommendation that having devices or apps “call home” for every user action to a centralised global service is bad practice and should be avoided

Jari