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
