Subject: [Add] Benjamin Kaduk's Yes on charter-ietf-add-00-02: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 05 Feb 2020 23:03:41 -0800

Benjamin Kaduk has entered the following ballot position for
charter-ietf-add-00-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-add/

----------------------------------------------------------------------
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.]

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Feb 2020 23:14:53 -0800

> https://datatracker.ietf.org/doc/charter-ietf-add/

The way I read this is that the first two work items are to define protocols
and the other one is to attempt to just describe approaches the client
could take (e.g., to detect split horizon on your own) but not standardize
anything (hence not being proposed standard).

> more or less useful considered to be a policy recommendation that is out

I suspect we'll need the chairs to manage this, but my general hope would
be that we could keep any such analysis tightly focused on technical facts,
rather than having it end up in discussions of the overall merits of any
given
set of approaches.

-Ekr

> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 6 Feb 2020 11:52:47 -0500

> and private-network resolvers) for those items?

I agree with EKR's answer here, and I don't think the wording is an
issue or needs to be changed.  I think we generally understand that "a
mechanism" can encompass multiple aspects that might differ for
different networks.

> more or less useful considered to be a policy recommendation that is out

Again, i think EKR's response is right, and the chairs will be
responsible for keeping the discussion away from actual policy issues,
with backing from the AD.

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

You can un-notice them now, because I've edited them away.

Barry