Subject: [Add] ADD Planning for IETF107

From: "Deen, Glenn" <[email-masked]>
Date: Fri, 6 Mar 2020 23:57:45 +0000

Hi ADD list,

The ADD WG was created officially just a little less than a month ago, but there are a lot of previous drafts and thoughts that are going give the group an early boost hopefully.

The final ADD charter (https://datatracker.ietf.org/wg/add/about/) is a narrow charter with only 3 deliverables that are broken out below.  We encourage everyone to give the final charter as approved by the IESG a read to understand the focus and scope of the WG.

ADD Charter Deliverables:
====================

       Define a mechanism that allows clients to discover DNS resolvers
       that support encryption and that are available to the client
       either on the public Internet or on private or local networks.

       Define a mechanism that allows communication of DNS resolver
       information to clients for use in selection decisions. This could be
       part of the mechanism used for discovery, above.

       Develop an informational document that describes mechanisms for
       clients to detect specific network environments (such as captive portal
       and split horizon) and to use that information to inform their DNS
       configuration.

Drafts and Materials
=================
There are a number of documents that have been submitted to ADD, its predecessor ABCD and other WGs and one of the first tasks for the WG is to get documents that are focused on the deliverables.    For those of you who have already written drafts we ask that you please review your drafts against the limited scope of the charter and produce a new document focused on the ADD scope.    For those of you who have been waiting for the WG to form, now is the time to begin writing, again keeping an eye on the focused scope of the ADD charter and so producing drafts that try their best to not stay outside the charter.

We tried to identify all the various drafts that are in some part related to ADD’s deliverable and came up with the following 3 groups of documents – see below.  (if we missed one please let the chairs know. There are a lot of email threads to mine so it’s very likely we did miss some – so don’t be shy).

The chairs plan is to have the WG try to initially focus on developing 1 or 2 documents which pull together the ideas that have already circulated in the cited drafts along with new ideas that are needed.   So please get drafting and submitting.

We don’t need all of the above done before the IETF107 cut off on Monday March 9, this is just the start of the group and it will understandably take time to think through what is appropriate to pull into a new draft for just ADD and what to put elsewhere. Don’t scramble to get drafts in - submit when you are actually ready.

Again, we’re not pulling all these drafts into ADD;  We ask the authors to break out the ADD relevant info in a new draft and submit to ADD.

Resolver Information

1.    draft-ietf-dnsop-resolver-information.  [https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/]

2.    draft-sah-resinfo-doh [https://datatracker.ietf.org/doc/draft-sah-resinfo-doh/]

3.      draft-reddy-dprive-dprive-privacy-policy [https://datatracker.ietf.org/doc/draft-reddy-dprive-dprive-privacy-policy/]

4.    draft-grover-add-policy-detection [https://datatracker.ietf.org/doc/draft-grover-add-policy-detection/]

Resolver Discovery

5.    draft-pauly-dprive-adaptive-dns-privacy [https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/]

6.    draft-peterson-doh-dhcp [https://datatracker.ietf.org/doc/draft-peterson-doh-dhcp/]

7.  draft-reddy-dprive-bootstrap-dns-server [https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server]

8.    draft-btw-add-home [https://datatracker.ietf.org/doc/draft-btw-add-home/]

Considerations, Architecture, Background , Reference etc.

 9.     draft-arkko-abcd-distributed-resolver-selection [https://datatracker.ietf.org/doc/draft-arkko-abcd-distributed-resolver-selection/]

10.    Paul Hoffman – local and internet policy implications of encrypted DNS  [https://www.icann.org/en/system/files/files/octo-003-en.pdf]

11.  RFC8384 DNS Queries of HTTS (DoH) [https://datatracker.ietf.org/doc/rfc8484/]

   - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 Draft Agenda for IETF107 (a mix of in person and mostly-remote presentations)
====================

1.      Agenda Bash

2.      Introduction to ADD WG    10 min [Chairs (in person/remote)]

3.      draft-arkko-abcd-distributed-resolver-selection 30 min [Jari/Ted (remote/in person) ]

4.      discovery-selection directions  30 min [Tommy Pauly (remote) ]

5.      draft-btw-add-home 30 min [ TDB (remote)]

6.      ADD mic-line Q&A [10 min] [Chairs et al]

Because a so much of this is being done remotely, each talk has been given a generous 30 min to cover presenting, questions, and extra time to deal with any technical issues.

Thanks,
Your friendly ADD chairs David Lawrence and Glenn Deen ([email-masked]<mailto:[email-masked]>)

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Mar 2020 00:34:51 +0000

FWIW, I consider draft-ietf-dnsop-resolver-information and draft-sah-resinfo-doh to be as much about discovery of secure resolvers as they are about resolver information. That is, if you know the address of your current resolver, you can ask it "are you my secure resolver" using those protocols.

Separately, I don't understand the inclusion of draft-arkko-abcd-distributed-resolver-selection in the agenda for this WG. The document gives its scope as:
   This memo discusses whether DNS clients can improve their privacy
   through the potential use of a set of multiple recursive resolver
   services. 
This doesn't seem like it is about resolver discovery or resolver information, but instead about resolver assignment (probably by an application or OS). I like many of the ideas in the draft, but they don't seem to be home here.

--Paul Hoffman