Re: [dispatch] dispatch 94 meeting notes - summary

[Mary Barnes <[e-mail]>]

Thank you Jean - this is awesome!

Mary.

On Thu, Nov 5, 2015 at 12:00 AM, A. Jean Mahoney <[e-mail]>
wrote:

> Hi all,
>
> Below are summary notes from the meeting in Yokohama.
>
> 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
>
>
> Mary announced that DISPATCH now has three chairs. Murray Kucherawy has
> joined from the former Apps area.
>
> The agenda was updated with the removal of the HTTP problem statement
> presentation.
>
> Mark Nottingham announced that he was updating RFC 5988, Web Linking
> (draft-nottingham-rfc5988bis), and would bring it to the list when it was
> ready.
>
> ACTION: Mark Nottingham to bring RFC5988bis to the list when ready.
> DONE:
> https://mailarchive.ietf.org/arch/msg/dispatch/t7M03TQsr8qScwkxxkY9sTirwnc
>
> Mary reminded the room that Dispatch has earlier deadlines for IETF
> meetings. However work can be dispatched on list, and doesn'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
>
>
> Robert Sparks pointed out that red text in otherwise black text was not an
> effective highlighting mechanism for people with colorblindness.
>
> Barry Leiba emphasized that DISPATCH would not do any standards work. The
> only work would be simple administrative tasks like creating drafts for
> IANA registration.
>
> Alissa Cooper thought the wording "The privacy of the network" was strange
> and will send text.
>
> ACTION: Alissa Cooper to send feedback on the Charter to the list.
> DONE:
> https://mailarchive.ietf.org/arch/msg/dispatch/ldp8MwSy6NOoEafVOs3YbXautO0
>
> Murray said that people liked the Monday appsawg meeting when WGs gave
> status, and that there will be an ART area general meeting to summarize wg
> status in Buenos Aires. Ben Campbell clarified that the summaries will
> cover new work and highlights, not everything worked on since the last
> meeting.
>
> No one else had comments on the 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
>
>
> Martin Thomson had a correction for slide 8: Approach Continued, saying
> that we rely on authenticated signaling channel for DTLS-SRTP.
>
> Jonathan Lennox said that the point of opportunistic security was that,
> although it might allow MITM, it was better than nothing.
>
> Magnus Westerlund wasn't sure if MIKEY would work.
>
> ACTION: Verify which, if any, MIKEY modes work.
>
> Jon said that the weakest security option could be picked and it could be
> problematic. Alan said the draft could use feedback on the security options
> and it listed alternatives, not preferences. Jon wanted to ensure all
> options listed were appropriate.
>
> Jonathan requested that the motivational text include why no one uses
> Cap-Neg, which had the same goal as this draft, and asked if this document
> would obsolete Cap-Neg.
>
> Cullen, as chair, said that the draft would be dispatched, and although a
> charter was included in the presentation, a working group was not going to
> be created.
>
> Alan asked for solid reviews.
>
> Roni Even said that RFC 5763 would need to be updated.
>
> Christer Holmberg supported this work, saying that it goes hand-in-hand
> with DTLS-SDP.
>
> Richard Barnes was uncomfortable with including SDES in the options and
> would prefer it removed. He did not believe the draft should be a BCP since
> anything in the middle could downgrade the security. He also felt that, due
> to differences between AVP and SAVP, complexity would be introduced.
>
> Alan pointed out that most secure devices use SDES and that restricting
> SDES would leave them out.
>
> Jonathan Lennox pointed out a limitation with early media.
>
> ACTION: Alan to document the early media limitation.
>
> A participant from Deutsche Telekom supported this work, and spoke against
> Cap-Neg.
>
> Jonathan and Christer said that the work should be done in MMUSIC. Cullen
> didn't want the room to focus on where the work should be done, but on
> whether the work should be done.
>
> Charles Eckel supported this work, and said that he had an implementation.
>
> Mary, as chair, took a hum:
>
> Should we do the work in the ART area? many hums and hums in the Jabber
> room.
>
> Should we not work on this problem? one hum
>
> RESULTS of hum: strong consensus for the ART area doing the work.
>
> Richard reiterated that the middle could force security down and said
> allowing calls to go through can create barriers to implementing security
> since it doesn't motivate people to fix the security issue. Richard
> recommended creating minimum security requirements.
>
> Jon wanted the ability to vote security options "off the island", but
> understood Alan's response to SDES. Jon said that the negotiation mechanism
> could be separate from a security BCP.
>
> Richard did not want the draft to be considered a BCP, and wanted caveats
> that it was a transition technology.
>
> Charles said that causing calls to fail will cause security not to be
> turned on. When both sides can support it, it can be turned on without
> disrupting calls.
>
> Alan Ford supported this work.
>
> Jonathan mentioned an extension [ajm: that I missed], but Alan said that
> it didn't solve the problem.
>
> Richard pointed out that web browsers show open or closed lock icons to
> indicate the security state; phones don't have those icons. Cullen and Mary
> said some do. Richard wanted it to be clear that the user may not receive
> indication of the security state.
>
>
> ---------------------------------------------------------
> 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
>
>
> Mark said that there was support in apps-discuss, but no one wrote the
> draft, but W3C wants it to happen now and they wrote the draft.
>
> John Levine, Sean Leonard, Tony Hansen asked if there was a community that
> wanted it and would implement it. Wendy Seltzer said there was an active
> web fonts group in W3C that want to use this and was working on drafts.
>
> Martin said that fonts were approaching Turing complete and suspicion was
> warranted. Richard said that browsers determine if content is safe based on
> media type, and that it may not be safe to put fonts in a primary content
> type.
>
> Barry said that fonts fit the model of a top level type. Barry supported
> the work and it would go to a new working group. The work had to be
> standards track.
>
> Murray and Cullen, as chairs, said that the next step is for people
> interested in the work to create a charter. Then the chairs would look at
> the charter. Mark was happy with the plan.
>
> ACTION: People interested in font Primary Content type to create a charter
> for the work.
>
>
> ---------------------------------------------------------
> draft-west-webappsec-csp-reg
>
> Mark asked if draft-west-webappsec-csp-reg, which is requesting a registry
> for CSP directives, could be AD sponsored.
>
> Murray, as chair, felt that the draft fell under house-keeping and could
> be done in DISPATCH. Barry, as AD, said that he would let the chairs
> decide, and would AD-sponsor if they decided not to handle it in DISPATCH.
> Alissa, as AD, saw no reason to do the work in the independent stream.
> Richard was fine with doing the work in DISPATCH.
>
> ACTION: WG to review draft-west-webappsec-csp-reg and send comments to the
> list.
>
> ACTION: Mark to send a pointer to the list.
> DONE:
> https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0
>
>
> ---------------------------------------------------------
> 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
>
>
> Mary, as chair, pointed out that the presentation was informational, and a
> decision was not needed.
>
> Richard asked if the application needed to do anything. Koen said only TCP
> stacks needed to be updated to support scalable TCP.
>
> Ben thought it was interesting, but that the room could not determine cost
> or implications. He felt it was a TSV topic. Koen agreed.
>
> Bob Briscoe clarified that scalable TCP can only be used in a data center,
> since it's too aggressive, and pushes other traffic out of the way. The
> queuing system would enable use outside of the data center.
>
> ACTION: Bob Briscoe to send pointers to the list.
> DONE:
> https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc
>
>
> ---------------------------------------------------------
> Wrap-up
>
>
> Cullen announced that draft-west-webappsec-csp-reg, which was just
> dispatched, was already in LC.
>
> Richard said that the work was dispatched with dispatch.
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>