Re: [Add] A proposed charter for ABCD

I believe a clarification is needed regarding the advertising of resolver capabilities. That is discovery of local resolver properties versus global resolver properties. These methods might need to be completely different (eg DHCP vs something else).

It would be good to clarify both are in scope.

Paul

Sent from my iPhone

> On Dec 20, 2019, at 10:20, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> 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.
> -- 
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add