* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Dnsop Status Pages

Domain Name System Operations (Active WG)
Ops Area: Benoit Claise, Warren Kumari | 1999-Jun-03 —  
Chairs
 
 


IETF-99 dnsop minutes

Session 2017-07-18 1550-1750: Congress Hall II - Audio stream - dnsop chatroom
Session 2017-07-20 1810-1910: Grand Ballroom - Audio stream - dnsop chatroom

Minutes

minutes-99-dnsop-05 minute



          dnsop-ietf99-minutes-1.txt
          
          DNSOP WG
          Tuesday 18 July 2017, 15:50-17:50 CEST (UTC+2)
          Congress Hall II
          Tim Wicinski , Suzanne Woolf
          Minutes taken by Paul Hoffman
          Text from the slides is not reproduced here
          
          Updates of Old Work
              Lot in the queue
          
          TSIG vulnerability
              DNS vendors got together on Sunday to talk informally
              Decided that there needed to update RFC 2845
              RFC 2845 doesn't cover all the cases
              Will start on a -bis version
          
          draft-ietf-dnsop-terminology-bis; Paul Hoffman
              No slides
              Will be bringing up topics that were punted in RFC 7719
              Wants lots more review
              Please open issues on the GitHub repo (but Paul will endter them
              if they
                  come from the mailing list)
          
          draft-ietf-dnsop-dns-capture-format: Jim Hague
              Paul: What is the reason for things being mandatory?
                  Jim H: To make reconstruction possible
                      That's the only one
              Jim Reid: Any news on IPR?
                  Jim H: Copyright is from ICANN, talk to Terry Manderson
              Stephane Bortzmeyer: Maybe have two profiles, one with mandatory
              one with
                  nothing mandatory
                  Jim H: Maybe need more than two, but we can't know that now
                      Need to handle optional data in some other means
              Roy Arends: Happy user of the format
                  Is there a mailing list?
                  Jim H: Use the dns-stats mailing list
                  Sara Dickenson: Wants to see more traffic on the DNSOP mailing
                  list of
                      specific use cases
          
          draft-ietf-dnsop-rfc5011-security-considerations: Wes Hardaker
              Mike St. Johns: "30 days" is used twice in RFC 5011 for different
              things
              Mike: The sum of a wall clock time and an interval is a wall
              clock time
              Warren KUmari: We are not "adding" anything
              Olafur Gudmundsson: This is worst case times
              Tim: Used interval times in an earlier RFC
              Suzanne: This could be ready for WG Last Call
          
          draft-ietf-dnsop-aname: Peter van Dijk
              Ondrej Sury: Finds the draft confusing
                  Peter: Agrees that the draft has grown in bad ways, and will fix
              Stephane: This is just for HTTP, but supports the draft anyway
              Benno Overeinder: Has a concern that when the zone owner is not the
              zone operator
                  Wants a security consideration about online signing because of
                  the difference
                  Peter: We are stretching the definition of "offline", should
                  be fixed
              John Levine: Never wants to do online signing, hopes that this can
              settle it
                  Has a concern that people will want SRV records and/or MX
                  and would
                      want to sweep them in as well
                  Peter: That would take the draft further from the current
              Ondrej ?: Doesn't like the idea of online signing for everything
                  Would prefer draft was more explicit that you don't need to do it
              Andrew Sullivan: Concerned that people are saying that it is too
              complex
                  Document should say why this is hard
                  This will help explain the tradeoffs that were chosen, get quicker
                      convergence
          
          draft-ietf-dnsop-session-signal: Sara Dickinson
              Christian Huitema: QUIC does not guaranee the order, but neither
              does UDP
              Stuart Cheshire: There may be operations that create state that
              must be
                  done before following ones
              Christian: Can do this in different ways
              Stuart: Push notification need ordering
                  If we use a transport that gives ordering
                  Christian: You are mandating a sequencing transport
              Ted Lemon: Session signally carries state
                  You either have order, or not
                  Sara: We need to make this clearer
              Andrew: There were other uses for this
                  Maybe use DNS Update type ordering
              Petr Špaček: Current session signaling draft creates DNS v2 and uses
                  original DNS v1 as a transport. Clean break would be better.
              Ondrej S: Torn about the new format
                  People who are not here won't know about the new format
                  But breaking this barrier would let us fix things that we did
                  wrong in the past
                  Doesn't like breaking all extensions by "I'll do it as a TLV
                  as well"
              Ted: Duplication is a real issue
                  EDNS0 sucks, it is hard to work with, it is an RR
                  This is for representing things not an RR
                  Totally flexible format
                  You would have to be really broken if you tried to parse this
                  as DNS
              Matt Pounsett: TLVs separate the control plane from data plane,
              which is good
                  Concerned with embedding DNS messages in TLVs
                  Sort of a layer violation
              Stuart: Thought we were embracing this document, not changing it
                  An EDN0 is neither an RR nor not an RR
                  The Wireshark decoder has to display different things for
                  that record
                      Caches need to know not to use the TTL
              Francis Dupont: This is a totally new protocol, and start from scratch
                  So don't reuse anything
              Tom Pusiteri: Likes the TLV format because it makes you think
              separately
              Suzanne: Good fodder for an interim
              Tim: We want to make sure that people see that we're making breakage
          
          draft-woodworth-bulk-rr: David Lawrence
              Peter vD: BULK doesn't work for secondaries
              Ralf Weber: This has some odd side-effects
              Paul Wouters: Can you see the difference between PTR records and
              John L: This is less horrible than previous version
                  There are other things like this that no one asked to standardize
                  Why don't you just write this for yourselves?
                  If you do this, you have to do online signing, don't ask people
              Ondrej S: Agrees with John
                  Maybe add a new DNSKEY type that is for online/offline key
              Andrew: The reason not to "just do this with all your friends"
              is to make
                  more competition and have a better ecosystem
                  David: My employer can do this already, but multi-vendor would
                  be better
          
          draft-tale-dnsop-serve-stale: David Lawrence
              Ralf Weber: Huge deviation was what the protocol was supposed to
              be doing
                  Write more up on the requirements
                  Far too detailed for deployment
                  Maybe not be standards track, should be experimental
                  This is just one approach
                  Warren: If other implementations want to describe how to do this,
                  that's great
                  Ralf: Let implementors do it different ways
                  David: Maybe lay out at least one way
              Benno: Similar questions about IPR
                  OpenDNS has some
                  Warren: Not clear if it applies
              Ondrej S: Agrees with Ralf
                  Doesn't think hard timers are correct
                      Should be derived from original TTL
                      Should not stretch a 30-second TTL to a week
              Giovani Moura: This seems useful after some changes
          
          draft-muks-dnsop-dns-opportunistic-refresh: Stephen Morris
              Suzanne: We need reviewers
              Lars-Johan Liman: This is only relevant when you're talking to
              authoritative
              Ondrej S: Only marginally useful
              Roy Arends: Loves the idea
              Matt: Seems like it might be useful
                  Worried about extending TTL on NS records or RRSIG
              Warren: This is really cool
                  Not sure if it all that useful because you have to look into
                  the zone
              Alex: Finds this interesting
                  Could you simulate this
                  Maybe have an EDNS that returns the timestamp
              Shane: Can look at authoritative server log and estimate the value
              this would have had
                  If you have access to large authoritative logs, talk to me so
                  we can
                  do more measurements
              Jim R: Maybe use a timestamp
              Ralf: There are servers that have no idea of serial or last update
                  Stephen: This is completely optional
          
          



Generated from PyHt script /wg/dnsop/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -