[DNSOP] Minutes from Thursday Meeting

[tjw ietf <[e-mail]>]

Thanks again to Mr, Hoffman from keeping copious notes.  They are uploaded
here:
Minutes IETF99: dnsop
<https://www.ietf.org/proceedings/99/minutes/minutes-99-dnsop-04.txt>

and I included them below for the time-constrained.   Please send any
corrections to the chairs.

thanks again

tim

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


dnsop-ietf99-minutes-2.txt


DNSOP WG
Thursday 20 July 2017Tim Wicinski <[e-mail]>, Suzanne Woolf <
[e-mail]>
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