Minutes IETF99: dispatch
minutes-99-dispatch-00

#  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
https://www.ietf.org/proceedings/99/slides/slides-99-dispatch-chair-slide-deck-00.pdf

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)
https://www.ietf.org/proceedings/99/slides/slides-99-dispatch-web-packaging-00.pdf
     https://github.com/WICG/webpackage

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 us.

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 same.

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 interested?

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
obvious.

---------------------------------------------------------------------
10:10 DNS Over HTTPS - Paul Hoffman (40 min)
https://www.ietf.org/proceedings/99/slides/slides-99-dispatch-dns-over-https-00.pdf
     draft-hoffman-dispatch-dns-over-https

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
considerations.

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
privacy.

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 fork.

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 transport.

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 that?

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 can't.

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: <some question about ports>

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)
     draft-thaler-appsawg-multi-transport-uris

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
things.

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)
     draft-huang-dispatch-hybrid-video-delivery

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)
https://github.com/WICG/webpackage

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 authority.
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 problematic
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)
draft-hoffman-dispatch-dns-over-https
Magnus: how do you pick a resolver?  Privacy issues in who sees your queries.
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 doesn't?
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)
draft-thaler-appsawg-multi-transport-uris
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)
draft-huang-dispatch-hybrid-video-delivery

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