[dispatch] dispatch 94 meeting notes - raw

"A. Jean Mahoney" <mahoney@nostrum.com> Thu, 05 November 2015 06:02 UTC

Return-Path: <mahoney@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3A61B3A19 for <dispatch@ietfa.amsl.com>; Wed, 4 Nov 2015 22:02:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4ChElyB9JOH for <dispatch@ietfa.amsl.com>; Wed, 4 Nov 2015 22:01:59 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E82B1B2F6E for <dispatch@ietf.org>; Wed, 4 Nov 2015 22:01:59 -0800 (PST)
Received: from dhcp-24-116.meeting.ietf94.jp (t20010c4000003024403981f85519aab8.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:4039:81f8:5519:aab8]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA561vKM047852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dispatch@ietf.org>; Thu, 5 Nov 2015 00:01:58 -0600 (CST) (envelope-from mahoney@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host t20010c4000003024403981f85519aab8.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:4039:81f8:5519:aab8] claimed to be dhcp-24-116.meeting.ietf94.jp
To: DISPATCH list <dispatch@ietf.org>
From: "A. Jean Mahoney" <mahoney@nostrum.com>
Message-ID: <563AF0D4.40308@nostrum.com>
Date: Thu, 05 Nov 2015 15:01:56 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/61GU6sFHvrhqbeTSIzGlBbN_pMM>
Subject: [dispatch] dispatch 94 meeting notes - raw
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Nov 2015 06:02:02 -0000

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


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