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 <tjw.i...@gmail.com>, Suzanne Woolf < suzworldw...@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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop