Re: [Add] A proposed charter for ABCD

[Ben Schwartz <[e-mail]>]

On Fri, Dec 20, 2019 at 10:44 AM Paul Wouters <[e-mail]> wrote:

> I believe a clarification is needed regarding the advertising of resolver
> capabilities. That is discovery of local resolver properties versus global
> resolver properties.


Could you describe the distinction you're thinking about?  What is a "local
property" of a resolver?  Or do you mean to distinguish "local resolvers"
from "global resolvers"?


> 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=
> [e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/add
>
>