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

Dispatch Status Pages

Dispatch (Active WG)
Art Area: Adam Roach, Alexey Melnikov, Ben Campbell | 2009-Apr-14 —  

IETF-99 dispatch minutes

Session 2017-07-17 0930-1200: Congress Hall III - Audio stream - dispatch chatroom


minutes-99-dispatch-00 minute

          #  Summary of Decisions and Next Steps
          ## Web Package
          * Discuss on art@ietf.org email list.
          * Focus on requirements use cases and how to split up work.
          ## DNS over HTTP
          The Art ADs will talk to Int and Sec ADs about relation to dprive. Don't
          have an answer now.  Many people willing to do work on this and
          significant interest in doing it.
          # Raw Notes #1
          09:30 Administrivia - Chairs (5 min)
               Agenda bashing; blue sheets; jabber scribe; note taker
          Mary Barnes presented chair slides.
          slide 1: Title
          slide 2: Administrivia
          Note takers: John Levine, Jean Mahoney
          Jabber scribe: Rich Salz
          slide 3: NOTE WELL
          This is the old NOTE WELL slide
          slide 4: NOTE WELL, in other words
          slide 5: Deadlines for IETF 100
          Mary: Charter proposals don't have to be formal - need a problem statement
          - what problem do you want to solve?
          slide 6: Working With Deadlines
          slide 7: A Reminder about Mailing Lists
          09:35 Updates from Area Directors - ADs (5 min)
          slide 8: Updates from Area Directors
          Ben Campbell: The CELLAR meeting is happening this IETF. It's like a
          solar eclipse, it's a once in a lifetime occurrence.
          Murray Kucherawy: appsawg is closed.
          09:40 Web Packaging - Jeffrey Yasskin (30 min)
          Jeffrey Yasskin presented.
          Mark Nottingham: First I thought - just do it in the w3c, but after
          some thinking, some work can be done here. Some history - W3C TAG has
          a doc that covered this but died. It's not the first time this has been
          proposed. I can see a place for this work in the IETF. Split this into
          components. A format to persist HTTP requests/responses. Need to assert
          that a request/response pair is from an authority. Then there's the glue
          that ties that to your work cases. The first two components are protocol -
          could do that here. the gluey stuff can be done in W3C. First two items
          can go to the ...
          Cullen Jennings: By gluey stuff, do you mean signatures?
          Mark: No, that's #2. We're talking about it in HTTPBIS right now. ...
          Cullen: What should be done here?
          Mark: we can ... We can assert that request/response pair came from an
          authority. But how browsers can support those - that's out of scope for
          Murray: This is all in HTTP? or other WG?
          Mark: My kind co-chair pointed out that ... There are pit falls around
          use cases. This is HTTP.
          Murray: you would recharter?
          Mark: Sure we can do it. We don't recharter much. We just determine
          whether we want to work on new drafts. Don't know if that surprised our
          AD or not. Making this protocol neutral would be a mistake.
          Phillip Hallam-Baker (PHB): Is there a proper specification for MHTML?
          Jeffrey: No.
          PHB: You need to fix that. I don't think this should go into HTTP. We're
          already doing two sessions here. Packaging is separate. I'm working on
          something related: think about having everything encrypted and stays
          encrypted. I'm doing this. I'm not using the encryption you know. We
          can talk offline.
          Jeffrey: The first two cases don't work with encryption.
          PHB: I've got it running.
          Magnus Westerlund: Have you read out-of-band encoding? It's solving the
          Martin Thomson: This has been pitched umpteen times. This isn't about
          packaging. It's about the 2 use cases that Mark mentions. Having to guess
          what someone might ask for and when - is a challenge. Lot of debate
          about push and getting it to work. In a narrow context maybe. Another
          ... we've tilted at the signatures windmill. I don't have the stomach
          for it anymore. If we can work out the preservation problem ... maybe.
          Eric Rescorla (ekr): It was a hack in PUSH. Request and response are
          milliseconds apart. Passivation - here's like the request that ... that's
          an odd structure for what's basically a zip file. It makes sense in
          push. You have very preprocessed data. Treating it like a stored http
          session. I don't know why that's an attractive solution. Security -
          the http credentials are there for you to sign for the long term. If
          you allow the https signature to span weeks, it creates weaknesses.
          Daniel K Gillmor (DKG): The idea that you are shipping web-based
          apps. There's a long history with linux distributions, ... they still
          get it wrong with dependencies. You mentioned downgrade attacks.
          Jeffrey: It's not designed fully.
          Daniel: And this is not designed fully in Debian, and it's not designed
          fully for other distributions, etc., and they are centralized. You are
          talking distributed. Look at folks who have prior art. Language-based
          package distribution. Linux distribution systems 10 years ago.
          Patrick McManus: IETF is not the right venue for this ...
          Murray: Alexey, what are you thoughts?
          Alexey: If this goes to HTTPBIS, I will have some say. We need more
          fleshed out proposal to what the work looks like. I don't want to answer
          yet. Could go to an existing WG, and WGs to be created. Are people
          Cullen: OK, one or more working groups. Let's hear people at the mic
          and then take a hum.
          Mark: I don't think we should bring into HTTP now. Need more careful
          description of use cases and breaking down how to solve the use
          cases. Won't talk at HTTP this week. Love to talk about this. We should
          also talk to W3C before we take it on.
          Martin: Mark has captured my thoughts - I want clarity in requirements. We
          have a big ball of wax and a big ball wax to address it. Framing as
          packaging is problematic.
          DKG: I wanted to clarify my thoughts - if you define signature formats
          without understanding what needs to be signed, or not signed - you build
          a dangerous thing.
          Jeffrey: ... defines a packaged ...
          Murray: You can discuss on the art mailing list first.
          Ben Schwartz: This is relevant to my needs and applications, it serves
          people ...
          Paul Hoffman: People misinterpret signed packages. It sounds like you
          are mimicking ... If you had given the query at this time, you would have
          gotten this - and froze it. If you close and open the browser hours later
          - some things would have changed and maybe died. If the signature says
          to you ... For the hum - ask, if you saw one of these things, would you
          be able to use it. I can use it if it was unsigned. Signing will be easy
          to misinterpret.
          ekr: Just start with use case and requirements doc. Chop the bottom of
          the doc off.
          Cullen: The feedback I'm hearing - There's work to be done, but not
          start working group today. The question we have - we'll discuss on the
          work list. Who will work on this? (about 10 hands). Alexey?
          Cullen - anyone have problems with discussion on the mailing list? And
          if there's lots of discussion, we'll move it to a separate mailing list.
          Rich Salz: People in the Jabber room are saying have a bof.
          Cullen: That's an option or dispatch. When we look at it, it will become
          10:10 DNS Over HTTPS - Paul Hoffman (40 min)
          Magnus: how do you control the resolver?
          Patrick: the bootstrapping of finding the DNS server?
          Magnus: is it the site ...
          Patrick: one use case - instead of a stub. Bootstrap through an OS. ... It
          applies in the browser context. Could be an application-specific
          configuration. Discovery problems are out of scope for this.
          Magnus: the privacy aspects of this mechanism, who has control of which
          HTTP server responds and where it gets cached.
          Patrick: The clients have this problem right now. This work doesn't sort
          out which DNS server is used. To use data from this mechanism will require
          further work in HTTP. This is how to carry DNS info in HTTP. That's the
          extent of it.
          Magnus: I'm worried about punting on the use of this and the privacy
          Paul: it's no different from what it is going now.
          Patrick: it's an improvement for privacy.
          Mark: I think it's good, and well scoped and it's good to punt on the
          use right now. I have feedback.
          Patrick: Feedback on http on this would be good.
          Mark: there's discussion on jabber on why h2 and not legacy. I think
          it's good to specify a version, be careful with language, though, http1
          is still in use, it's not legacy.
          Patrick: ...
          Mark: what if peers downgrade to http1? That may happen.
          Dave Lawrence: I agree with Mark on this is good and I like what is going
          so far. I don't agree on punting on the use cases. DNS encapsulation
          format will be tempting for browser vendors for pushing more DNS data
          down the pipe. Needs to be clarified. What are we doing via ...
          Paul: do you want to see more in this draft?
          Dave: Acknowledge the issue. It's a competing idea. The issue needs to
          be identified and implications.
          Ted Hardie: If you find your DNS server by an existing server and treat it
          as recursive. Why doesn't it fold into dprive? When you blend with http
          services, it becomes a dprive mechanism that doesn't use dprive. What
          doesn't work in dprive and why?
          Paul: this isn't simply about privacy, which is the goal of dprive. It
          would require rechartering dprive.
          Ted: you are creating a new substrate for the DNS protocol that provides
          Keith Moore: this seems like a can of worms. My concern is that it forks
          DNS. A special set of DNS servers intended for web applications. You are
          providing a web specific interface to DNS. Doesn't have to be used like
          that. DNS is already polluted enough as it is. Interception proxies,
          servers that only serve parts of domains. I don't want to see another
          Patrick: web apps are near and dear to my heart - my hope that OS
          libraries will do this. But you get better mixing with http traffic,
          which has strong properties, better privacy properties.
          Paul: this is not intended to do the split you are worried about it. Could
          be same server with the same data. It would be easy to add for another
          Keith: I'm worried about unintended consequences.
          From the jabber room: John Klensin
          MIC: I'm trying to figure out what it would mean to use content
          negotiation to select variants (as one of the slides indicated) given
          that the DNS does not support a "give me all the aliases for this
          name" function (much less their properties).  The draft talks about
          alternatives, but doesn't seem to say.  Could you talk a bit more about
          Paul: content negotiation is not for different names, its for the format -
          wire format or JSON. If it's not clear in the draft it should be, he's
          right you don't get to say.
          Yoav Nir: ... why is that?
          Paul: with regular DNS - can see the DNS traffic and block it. With
          dprive, you can tell it's a DNS session, and block it. With this you
          Nir: trying to get past evil firewall.
          Paul: not the only use case, but yes.
          Nir: the same firewalls will negotiate client servers down to http1. If
          this draft won't accept http1 -
          Patrick: We can talk about it in the draft.
          Nir: When is post used?
          Patrick: ... enables media negotiation in a better way. The other has
          better caching properties. In scope for discussion and building consensus
          John Klensin: MIC: Thanks.  And, yes the draft says "alternative" but
          the slide said "variants" and that term has taken on a special meaning
          where the DNS is concerned. "alternatives", but the slide said "variants"
          which has taken on a special meaning WRT the DNS.
          DKG: I support this work. Having something like Doe(?) would be
          useful. I'm concerned about content negotiations. You can't validate
          DNSSEC over JSON, only over wire format.
          Paul: if someone wanted to create a smaller and different format they
          can. Mandatory to implement will be wire format.
          DKG: ... useful simplification to get this out the door. The non-UDP
          wire format doesn't have a way to handle DNSSEC signatures. I'm
          glad that discovery is not in this. I'm not sure about arbitrary end
          points. ... .wellknown. I appreciate http2.
          ekr: I'm sad that we're talking about this as we are finishing
          dprive. It's a superset of dprive. Want to push on mixture on DNS and
          http. Maybe with google you can get this.
          Patrick: any widespread CDN
          ekr: because Akamai serves Facebook ... ?
          Paul: ... your connection in the coffee shop.
          ekr: the coffee shop controls my IP address, not the Akamai servers. What
          actual settings does this happen in?
          Paul: we don't have it now, but could with CDNs.
          Patrick:  ... more than a tunnel.
          ekr: I'm not sure this is a good way of hiding the traffic. You're lying
          that you doing DNS.
          Paul: I'm using 443.
          ekr: the enforcer ...
          Paul: if you are on 443, you may be pushing more than pictures of cats,
          you may be doing something else.
          Jonathan Lennox:
          ekr: want to see use case descriptions for dprive ++ and ... They have
          different security requirements. ... pushing the resolver into the
          browser. back to the hypothetical.
          Bron Gondwana: Thunderbird doesn't do DNS lookups. 2nd point ... 3rd
          point - wire format will be more difficult to do, unlike JSON. Having
          a format that's easier to implement would be good.
          Ben Schwartz - there are 2 - open resolve, dns.google.com, an argument
          for standardization.
          Jonathan: Can a java script implementation can do this without the
          browser knowing?
          Paul: yes.
          Murray: want to talk about next steps.
          Cullen: we're struggling here - how much this relates to dprive and how
          much in new wg, or not doing it. AD?
          Alexey: Art ADs will talk to Int and Sec ADs about dprive. Don't have
          an answer now. It's clear there is some interest. Need to find a place
          for it.
          Cullen: show of hands willing to read drafts and do work. Wow - tons.
          ARTAREA Session
          10:50 BoF Summaries - various artists (5 min)
          Murray: didn't get replies from bof chairs. Anyone want to talk about
          these? (No one volunteered)
          BANANA - BANdwidth Aggregation for interNet Access (int)
          IDEAS - IDentity Enabled Networks (rtg)
          IASA20 - IASA 2.0 (gen)
          NETSLICING - Network slicing (ops)
          10:55 New Working Group Summaries -various artists (5 min)
          DCRUP - DKIM crypto update
          Murray: upgrading size of keys and how to move them. May only meet once
          or twice it its lifetime. Meets Thursday.
          Rich (?): we've shifted the meeting time and it shares a time with DMARC,
          it will now start at 10:30
          11:00 Using URIs With Multiple Transport Stacks - Dave Thaler (15 min)
          Jonathan: maybe SIP is an anti-pattern, transport=tcp.
          Dave: the argument for the anti-pattern, the ... (info is for the
          server? the client has already made a transport choice.) point is talked
          about in the doc.
          Carsten: why need them for the protocol that runs over CORE, it sees
          something like transport in the URI, it confuses them.
          Dave: The point of the doc is not to make recommendations, just document
          ways to solve it and document the tradeoffs.
          PHB: we have a doc that describes how to use SRV records for discovery. I
          like the idea of taking all the cruft and explaining it. Every wg
          has a discussion on discovery. I'd like to come to an agreement on
          how to do it. When I define a web service, I get my name, my URI, my
          ... prefix. ... I don't want a URI that has the same name. I want one
          solution for discovery.
          Dave: challenge on finding one solution.
          Keith: I feel like I've gone back to 1993. This is the URN problem
          again. The result, sad to say, was to create a huge mess. I want
          to believe it's over with, but it's not. I don't want to discourage
          you. There's something dangerous here or elusive about the problem
          space. Everyone looks at the layer of indirection and then projects
          ideas of what they want on it. Hard to create anything coherent. When
          you define an identifier scheme, and then later you try to change what
          it means. For example, IPv4 addresses - Class A, B or C, and remaining
          bits. And we had to change classes, and now we have NATs. Adding Layers
          of indirection break things. URNs let you tell the difference between
          schemes, how do you keep people from inserting layers of indirection?
          John Klensin MIC: Dave, seems to me that halfway to your 4th approach
          is to focus on identification the resource and go with URNs, allowing
          the protocol to be sorted out as part of the resolution mechanism..
          but that is still a URI, not a different mechanism
          Mark: it's appropriate to give this kind of advice. There are
          cases that are different. Different requirements from different
          protocols. Documenting these tradeoffs is important. I encourage you to
          look into this area. This is part of a larger problem, which is how to
          identify protocols.
          Dave: there are 2 audiences - IETF, and the other for people who don't
          have permanent schemes.
          Murray: This is an art area discussion, it's not being dispatched.
          Alexey: Can it be done in dispatch? There's an exception for IANA-related
          Chairs: no.
          Mary: do you want to AD sponsor it?
          Barry Leiba: Do we just want an informational doc, or do we want to come
          up with an answer with a BCP? I'm leaning toward BCP, and AD sponsoring
          it won't do it.
          Dave: 2 efforts - updating requirements for permanent registration ...
          Adam Roach: Get input from the art community on the art mailing list. Then
          we can circle back.
          PHB: mapping the swamp is a good way to start to find the path.
          11:15 Hybrid Video Content - Roni Even (10 min)
          Cullen: of the people who build these systems, are they willing to
          switch systems to use a new IETF solution? Are there people who will
          participate? (3 people raised hands).
          Magnus: this is too fluffy. It's a question of which of several different
          problems - how to invoke multicast from browsers? does the multicast
          transfer protocols have the right features? do the meta data in MPEG...?
          It's easy to step over borders, and the people are in other fora.
          Roni: we need to understand the generality, source to receiver. I don't
          think it's been discussed in IETF. We can start with more info on the
          structure. If there is no interest, no point of writing docs.
          Keith: I started out thinking that this is an MPEG problem. There may
          be role for collaboration between MPEG and IETF. Best you can hope for
          is some sort of MPEG ... if the format is not amenable to slicing and
          dicing, not much you can do.
          Roni: trying to see how to transfer in a better way. We see this problem
          in live video, MPEG doesn't address this issue. Need to provide the
          whole view.
          Murray: we should encourage discussion on art list.
          11:25 Open Microphone/AOB
               (remaining time; TBD)
               Possible topics:
               - TBD
          Volker Birk: We've implemented opportunistic encryption of chat
          messages and email. We are trying now to get what we are doing into an
          open standard. Maybe you want to have a look at what we're doing. We
          have a protocol stack that syncs keys and trust, and addresses and
          schedule. Internally in our database, peer-2-peer, always local. we
          are using URI schemes that are not standardized.  We have message
          formats that are not available in openPGP and SMIME. We have
          ... (https://www.ietf.org/mail-archive/web/saag/current/msg07789.html)
          Murray: Submit drafts if you have any and then post to the art list.
          Matthew Miller: You should contact the XMPP standards foundation.
          # Raw Notes #2
          09:30 Administrivia - Chairs (5 min)
          Agenda bashing; blue sheets; jabber scribe; note taker
          09:35 Updates from Area Directors - ADs (5 min)
          APPSAWG is finally closed
          09:40 Web Packaging - Jeffrey Yasskin (30 min)
          Mark Nottingham: W3C has thought about this and worked on it, can see
          work at IETF.  Suggest breaking up into components.  We do a format
          for http req/resp pairs, way to assert that pair(s) came from an
          Browser behavior is not us.  Could do it in httpbis.
          Don't make it protocol neutral.
          Phil H-B: Is there a spec for mhtml?  There should be.
          Jeff: no.
          Martin Thompson: not a bad packaging, how it work with server push.
          Signing is hard, perhaps too hard.
          ekr: risk if packaged and stored for a long time
          Dan Gillmor: question about package ecosystem management, long history
          of this and the dependencies
          are always wrong
          Mcmanus: parts are OK for httpbis
          Alexey: need more fleshed out proposal before dispatching
          Mark Nottingham: too early to charter now, need to talk to W3C
          Andrew Sullivan: sounds like it needs a BOF
          Thompson: more clarity on requirements, framing as packaging is
          DKG: signature without knowing what needs to be signed would be bad
          Ben Schwartz: relevant to me, serve people cut off from standard Internet
          PHoffman: concerns about signed packages, resources go dead, signature
          can be misinterpreted
          ekr: better to start with use case, then decide what addresses what
          fluffy: hands to show interest?  Some.  Discuss it on ART.
          10:10 DNS Over HTTPS - Paul Hoffman (40 min)
          Magnus: how do you pick a resolver?  Privacy issues in who sees your
          McManus: out of scope, same issue as picking a DNS server now
          Mark Nottingham: generally support.  Can peers agree to downgrade to
          http 1.x
          Tale: need to look at use cases
          Ted Hardie: why isn't this in dprive?  What does this solve that dprive
          Paul H: this isn't just about privacy
          Ted: this is a new substrate that provides privacy, which is like dprive
          Keith Moore: can o' worms, could fork DNS
          Yoav: why is H2 more resilient?
          Paul: can't see what's in a session, can't tell DNS from other traffic
          Yoav: consider allowing http 1
          DKG: support for privacy properties, prune non-mandatory formats
          ekr: too bad this wasn't earlier and part of dprive
          Bron G: use case: Thunderbird which doesn't have cross-platform DNS,
          wire format is a lot harder than JSON
          Ben Schwartz: there are at least two incompatible versions of this now,
          needs standardization
          ?: idea that javascript can do this without browser knowledge?
          Paul: yup.
          Alexey: ART and SEC will be talking about this
          Show of hands, lots of them.
          ARTAREA Session
          10:50 BoF Summaries - various artists (5 min)
          10:55 New Working Group Summaries -various artists (5 min)
          dcrup exists
          11:00 Using URIs With Multiple Transport Stacks - Dave Thaler (15 min)
          Carsten: why coap doesn't have transport
          Dave: doc is currently just a collection of what people do now
          PHB: would like to solve the discovery problem once and for all
          K Moore: it's 1993 again, this is the URN problem, each new layer of
          indirection breaks stuff
          Klensin:  focus on identification the resource and go with URNs, allowing
          the protocol to be sorted out as part of the resolution mechanism. but
          that is still a URI, not a different mechanism
          Mark Nottingham: documenting these tradeoffs is important, part of larger
          problem about how to identify protocols
          Alexey: could we do this within DISPATCH? Chairs: no.
          Barry Leiba: is this informational or do we want an answer?
          Dave: split info from answer
          PHB: mapping out the swamp precedes draining the swamp
          Barry: OK so long as mapping doesn't wear us out
          11:15 Hybrid Video Content - Roni Even (10 min)
          Chairs: is there interest?  Some.
          Magnus: several different questions here
          Keith: might be a role beyond MPEG
          Chairs: discuss on ART
          11:25 Open Microphone/AOB
          Volcker Berg: Pretty Easy Privacy doing opportunistic encryption of
          jabber, try it
          maybe you'll like it.  Stack to synchronize keys and trust
          Chairs: write a draft
          Matt Miller: look at XMPP standards foundation

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