Subject: [Add] DNC Discovery and Selection - Moving the idea of a new WG forward

From: "Glenn Deen" <[email-masked]>
Date: Thu, 09 Jan 2020 09:02:53 -0800

Please forgive the duplicate posting of this to the ADD list. My 
original posting yesterday was buried in the “A proposed charter for 
ACBCD” and I received the excellent advice from a number of people 
that this might get better notice if it was reposted to a fresh thread 
with some added new material.

The Essence of the original post was:

     Instead of trying to be both prescriptive and proscriptive in a 
charter for ABCD let’s step back,
     set the high level goals and boundaries for the group and then let 
the contributors, WG chairs,
     and ADs do their parts to contribute the ideas, manage the group, 
and oversee the direction and
     process adherence respectively.

Forgive my use of the fancy words “Prescribe” and “Proscribe”, I 
spent some time thinking how to describe what was triggering much of the 
concern and discussion around the various WG proposals and these two 
things seemed to be the major contributor. For the non-english speakers 
on the list:  Prescribe is telling people how they are to do something; 
Proscribe is telling people how they cannot do something.

If this was a topic area where only a small number of contributors, with 
few reviewers paying close attention to the work there is a very real 
possibility that such a small group could run amok.  However, in the 
case of Discovery and Selection of Resolvers by DNS Clients we have (1) 
a diverse set of interested parties that have already contributed drafts 
and are likely to contribute more; (2) a robust and diverse set of 
commenters and reviewers; and  (3) a good number of parties that are 
working on both implementations and deployments.    With so much 
activity and interest it’s very unlikely the WG could run amok 
especially with well chosen chairs and the ever watchful eye and helpful 
guidance of the ADs.    This doesn’t mean there aren’t potential 
dragons lurking in the focused areas of Discovery and Selection, but the 
high level of diverse engagement we have is an ideal one for the 
workgroup to thrive and succeed.

In other words, tell the WG what its high level goal is and then trust 
the people and the IETF process to do the work and get it right.

Here is a simpler WG Charter proposal:

      Produce mechanisms which will enable a DNS Client to discover the 
recursive resolvers available to
      it in the network environment it is connected to, with recognition 
that the network environment for
      a DNS Client can change overtime such as a device moving between 
different networks environments
      such as a home, an office, and a public space such as a cafe, or 
others as identified by the WG.

      Produce a framework where the DNS Client can obtain the 
information needed by the client to select
      the DNS resolvers it chooses to use.

      The WG will limit its work to the technical aspects of discovery 
and the technical aspects of the
      selection framework for DNS/53, DoH, and DoT operational 
environments.

      The WG is not chartered to work on non-technical areas such as 
policy, except the conveyance of
      whatever policy information in the selection framework to enable 
DNS Clients to make their selection.

      The WG is not charted to work on security, or privacy problems 
beyond those essential to Discovery or Selection.

      And we call it DNS-DS (DNS Discovery and Selection)

To the questions of…

1. Is X aspect of discovery included
    - the answer is it’s up to the WG.

2. Is Y element of information to be made available to the client?
    - the answer is it’s up to the WG.

3. Will the group specify what the clients preferences are?
    - No, this is out of scope.  Mechanisms to deliver information to 
the client are included, but what the client chooses to do as a result 
is out of scope.

3. Is the extended privacy of transactions and data logs and 
transactions in the recursive resolving DNS architecture included
    - Broad answer: No because such things are not about discovery or 
selection
    - Narrow answer: Except where such knowledge of such behavior is 
needed by clients to make and selection, and for the case of selection - 
then it’s up to the WG.

There is 10 weeks until IETF107 and 29 week until IETF108.   I’d 
prefer to spend that time working on these problems than trying to get 
the perfect charter perfect.

-Glenn Deen

— original post -

I’ve been working on this note for the last 2 days, going back and 
forth trying to layout a path forward for ADD/ABCD. I’m sure it is not 
perfect, but you wait for perfection you’ll never move productively 
forward. Please try to be kind when responding.

As it standands currently there are two ABCD charter proposals [1] 
https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw 
and [2] 
https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w 
which have the same top level goal: Discovery and Selection of Resolvers 
by a DNS Client, but they differ in the specific description of 
deliverables as well as what they prescribe as the starting point and 
approach. For full disclosure I was a contributor to (1), but that said 
I see common goals exist across both which gives me hope.

The discussion seems to be stuck with people talking past one another, 
and a lack of focus on how to move forward. My intention is to try to 
break that pattern by first breaking down why this is even being 
discussed and then proposing a path forward.

Why we are discussing this
————————————

The real world deployment of the changes driven by Encrypted DNS 
technologies like DoH and DoT and other changes being proposed like 
Adaptive DNS and Ubiquitous DNS are being the need for Discovery and 
Selection of DNS Resolvers. So this is neither an academic exercise nor 
engineers wanting to change things for the sake of change.

The need for Discovery and Selection of Resolvers by a DNS Client has 
been raised on this list, at microphones, and on other lists such as the 
EDDI Encrypted DNS Deployment Initiative list and meetings. The input 
has come from a broad set of contributors that come from a wide cross 
section of the participants who care about DNS including major browser 
makers, OS makers, network operators, DNS operators, and others from 
enterprises, and dare I say even it, from users too.

We’ve even had a number of drafts submitted to DNS OPs and DNS Priv

So while I acknowledge that there is not 100% agreement on the above, as 
if there ever is in such things, there does seem to a tremendous amount 
of interest in the need for Discovery and Selection, as well as a broad 
and diverse set of contributors wanting to work on it, and we have 
groups actually working on building and deploying solutions as well.

The conclusion is that there is a community of interest, contributors, 
and adopters here, and the work is going to be done somehow and 
somewhere which leaves the question for the IETF being the outstanding 
questions of what part of that work is to be done with the IETF, what 
exactly is the scope of that work?

Having caught up on the proposals, suggestions, and comments it seems 
that perhaps the biggest barrier is in trying to create the optimized 
charter of deliverables, scope, and with prescriptive and proscribed 
approaches that satisfies the various diverse views while also trying to 
proscribe in how the WG shall do it. Essentially the various drafts have 
elements of trying preemptively manage the WG’s work before the WG has 
a change to meet and engage. Each of the proposals cites one or more 
specific drafts as the basis for the work, and that in turn seems to be 
causing a lot of the debate as that level of prescription to the WG sets 
proponents of the other approaches off.

Getting back to making progress
———————————————

I’d suggest that perhaps the approach of being too proscriptive in the 
charter is not going to succeed and instead of trying to create the 
optimal charter that assuages the various wants, fears, and hopes that 
people have put out on the list, that we alternatively it approach it a 
simpler way. - a key part of which will involve trusting the IETF 
process and ourselves to work together to consciously do the right 
thing.

Instead of trying to put just the right words into the charter have 
upfront cover every possible aspect and contingency as if the charter 
itself was code, we do the following:

(1) Create a charter with a clear, yet simple goals.

(2) Create simple clear boundaries.

(3) Let the WG members do the work of bringing together the various 
proposals and discuss and work through the use-cases, needs, and 
technical issues. Do not be overly detailed or proscriptive in the 
charter, and let it organically evolve as needed via the WG participants 
and under the WG Chairs management and oversight of the ADs. Part of the 
problems in the previous attempts has been trying to skip past this hard 
work by being proscriptive in the charter. This has resulted in 
non-productive back and forth on the list instead of focused discussion 
on the specifics in drafts.

(4) Trust in the IETF process and give the chance for the WG Chairs and 
the ADs to work together to manage the WG activity and to keep it on 
track. Give the chairs the mission and ability, under the ever watchful 
and wise guiding hands of the ADs, to manage the WG toward the focused 
goal delivering the Discovery and Selection functionality that DNS 
Clients need in deployments.

(5) Remove any boiler plate or unneeded assertions, comments, guidance, 
as well as anything that it obvious. A great example of something 
obvious is saying in the charter that the WG will coordinate with other 
groups or security area, because quite obviously they will, for there 
isn’t any other choice is the WG is actually going to produce 
documents that have a hope of getting approval in the IESG.

If we did that then this is how this 5 points could play out:

Clear, yet simple goal such as:

The WG will work on the problems of Discovery and Selection of Recursive 
Resolvers by DNS Clients.

The goals of the group are to:

(1) Produce mechanisms which will enable a DNS Client to discover the 
recursive resolvers available to
it in the network environment it is connected to, with recognition that 
the network environment for
a DNS Client can change overtime such as a device moving between 
different networks environments
such as a home, an office, and a public space such as a cafe, or others 
as identified by the WG.

(2) Produce a framework where the DNS Client can obtain the information 
needed by the client to select
the DNS resolvers it chooses to use.

Simple clear boundaries, such as:

The WG will limit its work to the technical aspects of discovery and the 
technical aspects of the selection framework
for DNS/53, DoH, and DoT operational environments.

The WG is not chartered to work on non-technical areas such as policy, 
except the conveyance of whatever policy
information in the selection framework to enable DNS Clients to make 
their selection.

The WG is not charted to work on security, or privacy problems beyond 
those essential to Discovery or Selection.

Let the WG do the work

This means the WG won’t be told via that charter what WG drafts or 
architectures it must start from.

The WG would open the floor to drafts for consideration that cover both 
proposals for Discovery or Selection,
As well a problem statement drafts and use-case drafts that would 
present the functional needs and considerations
that the Discovery mechanisms, and Selection framework would need to 
satisfy.

This will be drive the discussion hopefully to be technical and about 
specifics and get away from the ADD list issues.

Trust in the IETF process

Hopefully the ADs will appoint WG chairs that are willing to stay above 
the fray and focus on managing the WG process.

Remove any boiler plate or unneeded assertions, comments, guidance, as 
well as anything that it obvious.

See the above proposal under point (1) Clear, yet simple goal.

This is a technical working group that will be run with hands on 
supervision. The charter isn’t a legal statue
that we need to avoid legal loopholes in, it’s not going to litigated, 
and the AD’s and IESG can always
Choose to refine the mission or even close the WG if it goes off the 
rails. We have a tried and proven
process to manage this sort of work; Let’s use it and get to work.

This all comes together in the shaved down WG charter proposal:

The WG will work on the problems of Discovery and Selection of Recursive 
Resolvers by DNS Clients.

The goals of the group are to:

(1) Produce mechanisms which will enable a DNS Client to discover the 
recursive resolvers available to
it in the network environment it is connected to, with recognition that 
the network environment for
a DNS Client can change overtime such as a device moving between 
different networks environments
such as a home, an office, and a public space such as a cafe, or others 
as identified by the WG.

(2) Produce a framework where the DNS Client can obtain the information 
needed by the client to select
the DNS resolvers it chooses to use.

The WG will limit its work to the technical aspects of discovery and the 
technical aspects of the selection framework
for DNS/53, DoH, and DoT operational environments.

The WG is not chartered to work on non-technical areas such as policy, 
except the conveyance of whatever policy
information in the selection framework to enable DNS Clients to make 
their selection.

The WG is not charted to work on security, or privacy problems beyond 
those essential to Discovery or Selection.

** that’s it folks **

And we call it DNS-DS (DNS Discovery and Selection)

Are there interesting topics and aspects of DNS being left out of this? 
Absolutely, and for those there is DPRIV and DNS-OPS etc. They remain 
the places to discuss those other things as appropriate. This WG is just 
about D&S.

Time is ticking away and IETF107 in Vancouver is now only 10 weeks away. 
We could spend 10 more weeks talking past one another, or we could 
settle on what needs to be done, hopefully get the ADs/IESG to buy in, 
and get down to work.

-Glenn Deen

[1] 
https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw
[2] 
https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w