[Add] A proposed charter for ABCD

[Ben Schwartz <[e-mail]>]

Hello ADD list,

Based on the feedback from the ABCD BoF at IETF 106, and with additional
input from chairs and area directors from relevant working groups, the ABCD
BoF chairs have drafted the following updated charter for a working group.
Please review it and share your perspective.

Tommy Pauly has recently posted a charter text proposal that considers
closely related issues. This is not a competition, so please avoid “voting”
for one proposed text over the other.  The text of any final charter will
be written by the IESG.  To help them judge whether a working group should
be formed, and how it should be chartered, the most productive input would
be to know which elements of each text you find valuable (if any), and
which you would like to see changed in any final charter.

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

Proposed charter text:

This working group will focus on DNS client side topics, particularly
discovery and selection of resolvers. This complements existing DNS-related
working groups, which are responsible for improvements to the DNS protocol
itself, and for operational questions that are principally of interest to
DNS server operators.

The working group is chartered to develop an extensible protocol for a DNS
client to learn detailed information about a resolver, based on
draft-ietf-dnsop-resolver-information, which will be transferred from
dnsop.  Relying on this new protocol where appropriate, the working group
should produce standards-track, informational, or experimental documents
that provide the following items, using the drafts in brackets as input
(with no obligation to adopt them):
 * methods for a recursive resolver to advertise support for an alternative
transport protocol [draft-sah-resinfo-doh],
 * methods for a recursive resolver to indicate that it will sometimes
return DNS results that are different from the global DNS
[draft-grover-add-policy-detection],
 * methods for improving user privacy by avoiding DNS queries that leak
information or directing them to a server that will have this information
anyway [draft-pauly-dprive-adaptive-dns-privacy], and
 * a format for describing the client’s DNS configuration, suitable for
diagnostics and debugging.

Where possible, any mechanisms that specify exchange of information between
clients and resolvers should provide the security properties expected of
IETF protocols, e.g., confidentiality protection, integrity protection, and
authentication with strong work factor.  Each specification must clearly
indicate under what circumstances and assumptions these properties are or
are not provided.

This working group will coordinate and share WGLC announcements with the
following working groups: dnsop, capport, dprive, dhc, and homenet. The
working group will also coordinate with the Security Area, and will be
assigned a security advisor.

P.S. One note regarding this proposal: the chairs of the doh working group
expect that doh would be closed if a new working group were chartered in
this manner or similar.