Minutes IETF99: dnsop
minutes-99-dnsop-03

dnsop-ietf99-minutes-2.txt

DNSOP WG
Thursday 20 July 2017Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf
<suzworldwide@gmail.com> Minutes taken by Paul Hoffman Text from the slides is
not reproduced here

DPRIVE on IETF network: Warren Kumari
        Pretty picture of the IETF use
        Open errata on RFC 8078, needs feedback

draft-bellis-dnsext-multi-qtypes and draft-wkumari-dnsop-multiple-responses:
Wes Hardaker
        If the client knows it has multiple questions:
        draft-bellis-dnsext-multi-qtypes If the server has a better idea of
        what you want than you do: draft-wkumari-dnsop-multiple-responses Happy
        eyeballs applies to both drafts Paul Hoffman: Likes both Shane Kerr:
        Likes multi-qtypes, both are OK Ralph Weber: Questions on multi-qtypes
                There is no need for either
        David Lawrence: Likes multiple-responses
        Ondrej Surey: Missing description of smart attackers
        Olafur Gundmunsson: If we open the question, there will be other ideas
        coming
                Has an experiment that will result in a draft
        Andrew Sullivan: Disagrees that these are optimizations
                Change the architectural assumptions of the DNS
                We need a focused discussion on that
        Paul Wouters: Likes both
                Simplify the ANAME with special processing
        Kazunori Fujiwara: Wants to compare all of proposals
        Ray Bellis: Objects to Olafur's comment
                Wants to hear more from Andrew
        Mukund S: Prefers smart clients to smart servers
        Jim Reid: Would like objective data to indicate whether it is worth the
        effort
                Warren promised data
        Matt Pounsett: Likes both drafts
                Maybe can do both changes in a single draft
                Wes: They depend on who has the knowledge

draft-bellis-dnsop-xpf: Peter van Dijk
        Substantial changes since previous version
        Ondrej S: Why not EDNS0?
                If there is a TSIG over the query, that will break
        Sara Dickenson: Client subnet is informational
                Violates basic principals
                Directly injects metadata into questions
                Needs more privacy concerns
                Say we're going to violate privacy
                Maybe consider encryption between trusted parties
        Daniel Kahn Gilmore: Agreed with Sara
        Warren Kumari: Wouldn't have done client subnet if they had thought
        about privacy

draft-wkumari-dnsop-extended-error: David Lawrence
        Paul W: The signaling bits are not protected by crypto
        Olafur: People have wanted this forever; should do it
        Jim: Great ideas
                Maybe lightweight codepoint allocation
                Be careful of codes that will cause further action of recursive
                servers David: Talking to IANA how expert review happens
        Petr Špaček: Needs implementation in clients or it is useless
        Andres Schultz: Need vendor values
        Ralf: Can be used for many things

draft-tale-dnsop-edns0-clientid: David Lawrence
        This is obviously PII
        Everything that Sara said about XPF applies here
        Customer will do this regardless of whether or not this is adopted
        Paul W: Doesn't like people coming to the WG and saying "we'll do it
        anyway"
                We should stop accepting these
        Sara: Likes documenting what we are do
                Do as informational
                Likes the way the draft is organized
                Need to be careful about where we draw the line of documentng
                things we don't like
        Peter VD: People are squatting on points; please do it
        Ralph: This needs to be done
        Stephane: Has too many privacy issues, doesn't want it adopted
                Won't review
                Privacy should be in control of the user, not the administrator
                David: Wants to see people make more conscious decisions in the
                life
        Daniel: Appreciates desire to document privacy violations
                Doesn't like the flexibility of the suboptions
                Where do we draw the line on which info do we not transmit on
                the DNS?
        Paul W: No one knows the difference of Informational RFCs
                David: There are actually DNS full standards
                        We should be better about pushing to full standards

draft-edmonds-dnsop-capabilities: Robert Edmonds

draft-huque-dnssec-alg-nego: Shumon Huque
        Francis Dupont: Not clear which is stronger: use "preferred"
                Shumon: Either have client preference, or zone operator
                specifies
        Ondrej S: If we all move to EC crypto, is this a problem?
                Shumon: Still might have reasons to transition to new algs
                Ondrej: Maybe the size isn't a problem
        Stephane: This ID could fit in draft-edmonds-dnsop-capabilities
                Think about that before going forwards on this draft
        Ralf: This makes DNSSEC a hell of lot more complicated
                Would rather work with what we have
        Petr: This will be a nightmare because it blows up the number of
        possibilities ?: Likes the idea, gives more flexibility to DNSSEC
        Olafur: Horrible idea
                Delay DNSSEC deployment
                We already have techniques to determine how many resolvers do
                what algorithms Causes delay of DANE deployment