Re: [dispatch] dispatch 94 meeting notes - raw

["A. Jean Mahoney" <[e-mail]>]

Thanks for the correction!

On 11/5/15 6:42 PM, Bob Briscoe wrote:
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>> --
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/