DNSOP WG
          IETF 104
           March 2019, 13:50-15:50 local time
          Chairs: Tim Wicinski, Suzanne Woolf, Benno Overeinder
          Minutes: Paul Hoffman
          Text from slides not reproduced here
          
          Session 1
          
          Administrivia
              See slides
              ANAME authors may be reducing scope of document
          
          DNS-SD Document Updates; Stewart Chesire
              Will take more things to the WG list, wants more review from DNSOP
              folks
          
          IETF Hackathon: Everything DNS; Sara Dickinson
              Paul: Encourages people to come because it helps you when you are
              doing code
              Suzanne: Because the DNS lives in the real world, the hackathon is
              especially important
          
          draft-ietf-dnsop-multi-provider-dnssec; Pallavi Aras and Shumon Huque
              Shumon: Not ready for WG last call because there is a bunch of
              pending issues
              Jan Vcelak: Definitely looking for more input
              Shumon: Would like new draft to be ready for next meeting
              Willem Toorop: What are the colors of the keys?
                  Blue is private key
              John Reed: Is this intended for steady-state, or transitioning?
                  Shumon: Was for steady-state, but now moving to transitioning
                  John: Will this help get rid of 6761 and non-cooperating operators
              Christian Grothoff: Have you thought about threshold signatures
                  Shumon: Will do
              Tim: REGEXT is looking at registry handoff, also a side meeting on
              registry lock
              Mike StJohns: What if different providers are signing different parts?
                  Shumon: Each provider is signing the whole zone
                  Pallavi: Each signer needs to do NSEC or NSEC3, but not different
              Shumon: What about response size? Only changes DNSKEY records
              Petr Špaček: Does this affect aggressive NSEC?
                  Jan: yes
          
          draft-ietf-dnsop-7706bis; Paul Hoffman
              Wes Hardaker: Why is the root special?
                  Paul: Root is not special
              Wes: Seems useful to do pre-caching for any zone.
              Paul: Examples in Appendix showing how to do for other zones
              Wes: Root Zone List not correct
                  Paul:  Please send email
              Andreas Schulze:  Anyone can try and see if it works.
                  Paul: Should be for zone administrators who want this served
                  this way.
              Matt Pounsett:  Listing non-ICANN or ICANN projects, side projects
              come and go. Perhaps discuss these projects are ephemeral.
                  Paul: Off-boarding is really important for this.
              Chairs: HyperLocal date?
                  Paul: I don't predict well
              Paul: Knowing when a service stops working is really important
          
          draft-ietf-dnsop-dns-tcp-requirements; Duane Wessels
              Slides were originally for tcpm WG (TCP Maintenance)
              Sara: There are also privacy concerns with TFO
                  Yes to promoting TLS
                  Do you want to talk about DSO? Will send text
              Wes: 7706 code snippets
              Petr: From flag day, operators said this was not Internet Standard
                  Suzanne: Chairs will follow up on that
              Suzanne: Have people tested this?
                  Sara: DNS Privacy web site has some data on that for open source
                  implementations
          
          draft-livingood-dnsop-dont-switch-resolvers; Jason Livingood
          draft-livingood-dnsop-auth-dnssec-mistakes; Jason Livingood
              George Michaelson: When the signalling mechanism is SERVFAIL, how
              do I know?
                  Have to have extended errors
              Tim: Can they be combined into one?
                  Jason: Yes
              Jim Reid: Supports
                  Validating resolvers that will soft-fail: needs wording
              Matthijs Mekking: One document
              Ralf Weber: Could be split into different sections
              Warren Kumari: Who is the actual audience?
                  Jason: Lots of people outside the IETF read RFCs
              Stéphane Bortzmeyer: Lots of people who talk to users read these
              documents
              Tim: Audience is network operations people who aren't obsessed with
              DNS like we are
              Matt Pounsett: Should work on it.
              Peter Koch: RFCs don't reach the right audience
                  Paul: IETF Blog helps
              Joe Abley: Old RFCs get use
              Petr: Supports draft
              Dan York: Likes these kind of drafts
                  We can point to RFCs
              Tim: We can bring this to NANOG
              Suz: Customer Support folks at operator shops care about these
              Dan: You want a small number of best practices documents
              Matthijs: Would prefer one document because they are intertwined
              Benno: Go for one document, then call on mailing list
          
          draft-lhotka-dnsop-iana-class-type-yang; Ladislav Lhotka and Petr Špaček
              Andrew Sullivan: Has opinions on IANA registries
                  Do not get out of sync with IANA registry
                  You will run into things that are deprecated
                  Everything that is marked as "obsolete" is treated as "deprecated"
                      You don't have to care about these
              Draft will be reviewed by YANG doctors
              Wes: Did you consider RFC 6168?
                  Ladislav: This can be a difficult process
                      This is just types that can be used in other places
                  Wes: Think about TSIG keys
          
          
          Session 2
          "New work day"
          
          draft-moura-dnsop-authoritative-recommendations; Giovane Moura
              George: R2: Disagrees that the study is representative because uses
              RIPE Atlas
              Wes: Asks whether we should bring to the WG, or remove some
              recommendations
              Lars-Johan Liman: What status do you want?
                  Giovane: Informational, not BCP
              Liman: Suggestions or things to think about; not recommendations
                  Customers will insist that "we much have this" and lose diversity
                  Giovane: Reproducing the recommendations
                  Liman: Not buying into that; needs to be observations
                  Wes: Will think about it
              Stéphane: Thought it was good research
                  Concern that this is only for big authoritative servers, not
                  even medium-sized zone
                  Wants title changed to make the scope narrow
                  Giovane: Will change
              Peter van Dijk: Question about R5
              Joe: Has read four of these papers
                  Really about anycast, not about DNS
                  Quite nuanced and subtle observations that are in context,
                  but this document makes broad claims
                  Don't think it is sensible to expand the papers
                  Would prefer that this was a "literature review"
                  These are too broad and across the board
              Peter Koch: 15 years ago, Lixia had a draft on TTLs
                  WG could not agree on this
                  Drop R5 from the document
                  Open to making papers more accessible, but not to be
                  recommendations or observations
                  Wants more diversity of papers
              Benno: Wants more discussion on mailing list
          
          draft-sury-toorop-dns-cookies-algorithms; Willem
              Paul: Why SipHash?
              Ondřej Surý: Already used everywhere even though new
              Peter Lexis: License is public domain
              Benno: Will send out call for adoption, feels positive vibes
              Warren: Make sure security groups and CFRG know
          
          draft-stw-6761ext; Suzanne Woolf
              Warren: Would be nice if we could avoid the .onion discussion again
                  Wants to work on this so we only do it once
              Jim: Good to not use DNSOP in the review, but needs a review process
                  Expert review panel?
                  Would be good to have some visibility
                  Need to think about liason with ICANN
                      Worried about double-dipping or gaming of ICANN process
                      Doesn't want people coming to IETF to circumvent ICANN process
              Paul Wouters: Froze 6761 with selectively allowing others
                  If we do not update 6761, we must move it to historic
                  Suzanne: Want the process to not look arbitrary
              Christian Grothoff: Has proposal to overwrite root zone
                  Has done usabilty studies to show that this works
              Wes: How to have input from ICANN is important
                  Note to chairs: don't let this drop, critical to solve
              PeterK: Missing a recommendation: makes the name special, doesn't
              allocate the name
                  If you have a name, you can make it special
                  Doubts that DNSOP is the right venue, but doesn't have a
                  better one
                  IETF and ICANN have tried hard to coordinate
                  Example of corp/home/mail
              Stéphane: Doesn't solve the real problem
                  When people from outside to reserve TLDs
                  We can talk to ICANN
                  Draft doesn't solve the problem: it gives advice to people who
                  already know about it
              Suzanne: "single label names" or not
                  Are people asking for the name to be delegated in the DNS with
                  specific behavior, or that the name be instantiated
                  Distinct cases
                  Other approaches are welcome
                  Warren will decide how to move forward
              Warren: Would the WG please consider working on it?
          
          draft-brotman-rdbd; Stephen Farrell and Alex Brotman
              Brian Dickinson: Explicit declaration of non-mapping vs. missing
              declaration of mapping
                  Defensive records saying that there are no other zones
              Alexander Mayrhofer: How can this work without semantics?
                  There are other mechanisms, such as meta-tags
                  Stephen: Trying to not do semantics
                  Alexander: Makes this useless
              Jim: Not sure the DNS is the place for this kind of semantics
                  How is this different than DNAME?
              Joe: Thinks the cesspool is fine
                  The current mechanisms are terrible and inaccurate
                  What incentive does the domain name holder to have to publish
                  these?
                  Alex: When people want to look legitimate
              Matt: Hard time seeing use cases
                  Boils down to interpretation by anti-abuse researchers
                  What will the absence of records mean? Could be messy
                  More semantics
              John Reed: Which direction should it be?
                  Lists can get real big real fast
                  How to make sure it's gone on both ends when the relationship ends
              Murray Kucherawy: Need to address unidirectional cases may be attacks
              Sam Weiler:
                  First party sets proposals
                  Signing is crazy
              Warren: Not sure if it should be in the DNS
                  Would like to disavow: more useful
              Dan York: Thanks for bringing it here
                  Have you spoken other vendors who might implement this?
                  What prevents less ethical people from claiming
              Murray: Has application in DBOUND
          
          ANAME discussion; Matthijs Mekking
              Wants discussion to be about current draft, or maybe a reduced scope
              Willem: Likes current draft, wants to implement it
              Brian: Issues that authoritatives must act in a way that resolvers
              used to do
                  Won't scale, is an existential threat to authoritative servers
                  Interferes with geo-ip that they have implemented
                  Recursives scale by queries, authoritatives scale by zone
                  Changes business model in a bad way
                  Matthijs: New document would need to deal with authoritative
                  aspects
                      Similar to DNSSEC for geoip
              Shane Kerr: People have implemented things just like this, it scales
              Matt: This sort of thing does work
                  Had to do ramp-up and back-off strategies
                  Did simulations up to 10m zones
              Petr: Two documents: how to do zone transfer, rest
                  Allow people to use multiple providers
              Olli Vannoja: Doesn't think it breaks DNSSEC
              Brian: Being offered by vertical integration suppliers, not
              authoritatives
              Matt: No
              Benno: Easier for two documents, but wants to hear more on the list
              Tim: Brian is incorrect
                  One document is OK
                  This scales, everybody does it
              Tony Finch: Would like more comments on the list from people who
              are already do this