Re: [dispatch] dispatch 94 meeting notes

Jean,

See one correction inline... (just before wrap up)...

On 05/11/15 06:01, A. Jean Mahoney wrote:
> Hi all,
>
> Below are my raw notes. Comments I missed are marked with ellipses (...)
>
> Thanks,
>
> Jean
>
>
> DISPATCH WG - IETF 94 -  November 2015
>
> Wednesday, July 22, 2015
> Location: Room 502
>
> Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy
>
> Note takers: Jean Mahoney and Richard Barnes
> Jabber Scribe: Jonathan Lennox
> Jabber log: http://www.ietf.org/jabber/logs/dispatch/2015-11-04.html
>
> ---------------------------------------------------------
> 13:00-13:10  Agenda and Status
> Presenter: Mary Barnes
> Presentation: 
> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf
>
> slide 1: Title
>
> Mary - We now have three Chairs. Murray has joined since we've added 
> Apps.
>
> slide 2: Note well
>
> slide 3: Agenda
>
> Mary - the agenda has been updated. HTTP problem statement will not be 
> presented.
>
> slide 4: Other topics
>
> Cullen - Mark Nottingham to talk about a W3C/IETF joint doc.
>
> Mark Nottingham - I'm updating RFC 5988, Web Linking 
> (draft-nottingham-rfc5988bis), I will bring to dispatch when ready.
>
> slide 5: Deadlines
>
> Mary - Note that Dispatch has earlier deadlines for meetings. However 
> we can dispatch on the list, and don't have to wait for a meeting.
>
>
>
> ---------------------------------------------------------
> 13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG)
> https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk 
>
> Presenter: Mary Barnes
> Presentation: 
> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf
>
>
> slide 6: Updated DISPATCH WG Charter
>
> Mary - New items highlighted in red.
>
> Robert Sparks - don't use red to highlight text.
>
> Mary - why?
>
> Cullen - doesn't work with colorblindness.
>
> Barry Leiba - To be clear, we will not do any standards work here, 
> just simple admin stuff like putting out docs to get IANA 
> registration. No standards work.
>
> Alissa Cooper - on the guiding principles, "The privacy of the 
> network"? That's kinda weird. I may suggest an editorial change.
>
> Murray - Appsawg isn't meeting this time. There are 3 docs left and 
> then we close down the wg. Feedback received on appsawg - people liked 
> the monday meeting. We'll reinstate that in Buenos Aires - there will 
> be an ART area general meeting to summarize wg status.
>
> Ben Campbell - the summaries will over new work and highlights, not 
> summarizing everything worked on since the last meeting.
>
> Mary - any other comments on the charter?
>
> No other comments on charter.
>
>
>
> ---------------------------------------------------------
> 13:25-13:55 An Opportunistic Approach for Secure Real-time Transport 
> Protocol
> Presenter: Alan Johnston
> Document: http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/
> charter proposal: 
> https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g
> Presentation: 
> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-0.pdf
>
>
> slide 1: Title
>
> slide 2: Opportunistic Security (OS)
>
> slide 3: History of this Topic
>
> slide 4: Acknowledgement
>
> slide 5: Why now?
>
> slide 6: Why not just publish draft-kaplan-mmusic-best-effort-srtp?
>
> slide 7: Approach
>
> slide 8: Approach Continued
>
> Martin Thomson - a correction: we rely on authenticated signaling 
> channel for DTLS-SRTP.
>
> Jonathan Lennox - the point of opportunistic security, it might allow 
> MITM but better than nothing.
>
> Jon - they could still sign if they resurrected ...
>
> Magnus Westerlund - I don't know if MIKEY works. It's listed in the 
> draft.
>
> Alan Johnston - some MIKEY modes may work, maybe not all.
>
> Magnus - that needs to be checked.
>
> Jon - something can get to pick the weakest security, this is 
> problematic.
>
> Alan - could use feedback on that option. The draft just lists 
> alternatives, not preferences.
>
> Jon - need to make sure that all 4 options are appropriate, then. Or 
> vote them off the island.
>
> Alan - or let the implementors pick.
>
> slide 9: Example: Success
>
> slide 10: Example: Failure
>
> Jonathan - everyone hates cap-neg. You could solve this problem with 
> cap-neg, but no one does. This was the original motivation for 
> cap-neg. Provide some history on it, add to motivation text.
>
> Cullen as chair - We will dispatch the draft, not create a wg. The key 
> question is, do we want to proceed with something of this shape? Can 
> we not discuss the details of the charter, just talk about whether we 
> work on this? Then can discuss details. Skip to slide 15.
>
> slide 11: Charter Text 1/4
>
> slide 12: Charter Text 2/4
>
> slide 13: Charter Text 3/4
>
> slide 14: Charter Text 4/4
>
> slide 15: Needed Next Steps
>
> Alan - the draft needs solid reviews.
>
> Roni Even - We'll need to update 5763 - best effort with cap-neg.
>
> Christer Holmberg - I support this. We'll need to connect it to 
> DTLS-SDP, they go hand in hand.
>
> Richard Barnes - I tried to get some security guys here. We missed the 
> opportunity to call security recommendations downgradable security. 
> Anyone in the middle can force things to the weakest security, which 
> should not be best practice. In the security considerations, we should 
> capture that you should be ok with weakest option. It makes me 
> uncomfortable to include SDES in here. I would feel better if it 
> removed. I'm concerned - there's a diff between AVP and SAVP - we may 
> adopt complexity.
>
> Alan - Most secure devices out there use SDES. Restricting SDES would 
> leave them out.
>
> Jonathan Lennox - second best current practice. early media - can't 
> distinguish between SDP .... With DTLS - you can tell.
>
> Alan - We need to document the early media limitation.
>
> Jonathan Lennox - probably best wg for this is mmusic. ...
>
> ??? from DT - we support this work. We have some use cases where it's 
> more important to get the call through than to secure it. cap-neg is 
> additional work. We don't want cap-neg. It's easier to support this.
>
> Christer - The work should be done in mmusic. It's offer/answer for 
> opportunistic security.
>
> Cullen as chair - Don't focus on where it gets done. Should we do it?
>
> Jonathan Lennox - Can this draft obsolete cap-neg?
>
> Cullen - cap-neg can be obsoleted all by itself. It doesn't need 
> another draft to obsolete it.
>
> Charles Eckel - I would like to see this work happen. It has worked 
> well for us. We didn't want to bring it to the IETF.
>
> Mary as chair - Let's take a hum:
>
> Should we do the work in the ART area? many hums
>
> Should we not work on this problem? one hum
>
> Cullen - strong consensus for: we should be doing this work.
>
> RESULTS of hum: strong consensus for the ART area doing the work.
>
>
> Richard - In the middle they can force things down. It creates 
> barriers to implementing security. In the community that wants to move 
> to a secure state, create minimum security requirements. We don't 
> treat HTTPS as mixed content - we want people to fix them. If the call 
> completes even if security doesn't' happen, no motivation to fix.
>
> Jon - If we can vote somethings off the island. I understand your 
> response to SDES. That will be the tough discussion. We can create a 
> negotiation mechanism that is different from a BCP.
>
> Richard - This should not be considered a BCP. This should be heavily 
> caveated as a transition tech.
>
> Charles - Securing the media won't be turned on because calls will 
> fail because the security fails. You can turn it on and it will work 
> sometimes, in the future you can turn it on. Both sides support it, 
> and turn it on and it never comes into play.
>
> Alan Ford - I support this work
>
> Jonathan Lennox - seems like an easy extension. ...
>
> Alan - that's different and doesn't solve our problem.
>
> Richard - we've had opportunistic security proposals for web. Browsers 
> show lock icons. Do you get the lock icon if it's secured? Phones 
> don't have such icons.
>
> Cullen / Mary - some do.
>
> Alan - you give no indications to the user.
>
> Richard - maybe we can be clear about that.
>
> Jonathan Lennox - there were hums for doing the work in the jabber room
>
>
> slide 16: Path Forward
>
>
>
> ---------------------------------------------------------
> 13:55-14:10 HTTP problem statement
> Presenter: Mark Nottingham
> Document: 
> https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt
>
>
> Not covered
>
>
>
>
> ---------------------------------------------------------
> 14:10-14:25 The font Primary Content type
> Presenter: Mark Nottingham on behalf of W3C
> Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00
> Presentation: 
> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-3.pdf
>
> slide 1: Title
>
> Font media type  - top level
>
> slide 2:
>
> Formats for fonts
>
>
> slide 3:
>
> Martin - on the first point, fonts are approaching turing complete. 
> Suspicion is warranted.
>
> slide 4:
>
> Mark - There was support in apps-discuss, but no one wrote the draft. 
> W3C wants it to happen and they wrote the draft.
>
> John Levine - media types need someone to implement them. What's their 
> plan?
>
> Mark - W3C community seems keen. They want a unique place for font 
> formats.
>
> Levine - If no one has an implementation plan, it won't be used. 
> Here's an example. application/gzip didn't exist until a few months 
> ago when someone needed. If there are people ready to implement it - 
> that 's great.
>
> Mark - i's my impression but don't know.
>
> Sean Leonard - I've had to implement a top level media type. This is 
> the 3rd attempt for font media type. I question the interest to get it 
> all the way to though to publishing. The barrier to register top level 
> media type is too high. Need to think about it before issuing the 
> registration. For example text/plain. Have a short draft about it first.
>
> Richard - about who wants this, mixed content specs, active and 
> passive content is based on top level media type. Browsers determine 
> if its safe based on media type. This may not be a safe thing to put 
> in there.
>
> Look forward to the media session.
>
> Wendy Seltzer - there's an active web fonts wg. They would like to use 
> this. They have been working on drafts.
>
> Tony Hansen - It does need the relevant community to actually finish 
> the work. If they don't, then it doesn't happen, plain and simple.
>
> Barry - the model for when you want a top level type. There's 
> something common with some subtype. Fonts fit in that model. The fact 
> is that people are looking at this, then let's do this.
>
> Mark - so the W3C needs to participate.
>
> Sean Leander - where does this work fit?
>
> Barry - AD sponsored or WG. Since nothing fits, it would go to a new 
> working group. Has to be standards track.
>
> Murray - next step is to work on the charter.
>
> Cullen - forming a working group shouldn't be hard or complicated.  
> Need people interested in the work and working on the charter. Then 
> the chairs will look at the charter. Then get the draft going forward. 
> Happy? You don't look happy.
>
> Mark - I'm happy.
>
> Cullen - For the minutes: Mark's happy.
>
> ACTION: People interested in font Primary Content type to create a 
> charter for the work.
>
>
> Mark - there's another draft by Mike West 
> (draft-west-webappsec-csp-reg) requesting a registry for CSP 
> directives. Very simple and straightforward. W3C doesn't have a 
> registry capability. Can that be AD sponsored?
>
> Murray - I think that falls under house keeping and can be done in 
> DISPATCH.
>
> Barry - I'll let the chairs decide and I'll AD sponsor if not.
>
> Alissa - I just opened the draft, I see no reason to do this in 
> independent stream.
>
> Cullen - read and send comments to the list.
>
> Richard - seems fine to me.
>
> Mary - Mark, send mail to the list point to the draft.
>
> ACTION: Mark to send a pointer to the list.
> DONE: 
> https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0
>
> ACTION: WG to review and send comments to the list.
>
> ---------------------------------------------------------
> 14:25-14:40  Ultra Low Latency for realtime applications
> Presenter: Koen De Schepper
> Proposal (including related drafts):
> https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 
>
> Presentation: 
> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-2.pdf
>
> slide 1: Title
>
> slide 2: Super Fast Internet?
>
> slide 3: Super Fast User Experience
>
> slide 4: Better TCP Exists, but is not compatible with the current 
> Internet
>
> slide 5: Comparison of Classic TCP and Scalable TCP Cloud Hosted 
> Interactive Panoramic Video
>
> slide 6: Comparison of Classic TCP and Scalable TCP Cloud Hosted 
> Interactive Panoramic Video
>
> slide 7: Comparison of Classic TCP and Scalable TCP Cloud Hosted 
> Interactive Panoramic Video
>
> slide 8: Why Dispatch?
>
> slide 9: Simple Solution in the network: DualQ AQM provides low 
> latency marking and Compatibility
>
> slide 10: Demo on a Real BB Residential Testbed
>
> slide 11: Demo on a Real BB Residential Testbed
>
> slide 12: Improved Web browsing Experience
>
> slide 13: HTTP Adaptive Streaming (HAS) Experiments
>
> slide 14: HTTP Adaptive Streaming (HAS) Experiments
>
> slide 15: Using Just a Scalable TCP connection for Realtime and 
> interactive services?
>
> slide 16: Questions
>
> Mary - this is just a informational thing, not a decision.
>
> Richard - what does this look like from an app point of view?
>
> Koen - TCP stacks are upgraded to support this. The Windows data 
> center server does this. Only a change in the operating system, apps 
> don't have to set anything. It's easy.
>
> Ben - it's interesting. This room can't just the cost or implications, 
> though. This is a TSV thing.
>
> Koen - it's a transport area decision. Agree.
>
> Andrew Allen - Does it require support at both ends?
>
> Koen - Yes
>
> Andrew - You were talking about other improvements that can't be used? 
> Are there other solutions?
>
> Koen - I was talking about this - scalable TCP, but it can't be used yet.
>
> Bob Briscoe - you missed this point - this can only be used in a data 
> center, they are too aggressive, they push other traffic out of the 
> way. With the queueing system, you would be able to use it.
>
> Cullen - send the pointers to the list so people can learn more.
>
> ACTION: Bob Briscoe to send pointers to the list.
> DONE: 
> https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc
I sent a better link to the ML during the session, which includes the 
videos shown during the presentation:
<http://riteproject.eu/dctth/>

Bob

>
>
> ---------------------------------------------------------
> Wrap-up
>
>
> Cullen - draft-west-webappsec-csp-reg, which was just dispatched, is 
> already in LC.
>
> Murray - wrote the draft, put in LC, dispatched in less than 2 weeks.
>
> Richard - dispatched with dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/

Re: [dispatch] dispatch 94 meeting notes - raw