IETF-88 Vancouver, BC DISPATCH meeting Tuesday, Nov 5th, 2013, 16:10-17:10, Regency C Chairs: Mary Barnes, Cullen Jennings Notetakers: Jean Mahoney, Dan Romascanu Jabber Scribe: Jonathan Lennox Summary: --------- - SDP negotiation for Data Channel: draft-ejzak-dispatch-msrp-data-channel-00.txt draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00.txt Strong consensus on the following statement "Unfortunately, this needs to be dispatched to the mmusic WG." Actions: - Chairs: post a note saying we will dispatch draft-dawes-dispatch-mediasec-parameter to SIPCORE. [Done.] ========================= Notetaker: Jean Mahoney ========================= ======================================================== Chairs Status and agenda bash Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dispatch-0.ppt Note takers: Jean Mahoney and Dan Romascanu Jabber scribe: Jonathan Lennox Note well presented. Agenda presented. Slide - Status Since IETF-87: draft-johansson-sip-dual-stack-01 dispatched to SIPCORE WG. Current call for interest on SIPCORE WG mailing list. Other topics considered for IETF-88: http://www.ietf.org/mail-archive/web/dispatch/current/msg05084.html Most topics require further discussion and/or a clear problem statement draft-dawes-dispatch-mediasec-parameter-07.txt Proposal to dispatch this to SIPCORE but need (DISPATCH) WG feedback first. Mary - there is a bar - it must have working group discussion Jonathan Lennox - Summarize what the discussion was. Mary - The link summarizes the discussion, which was everything in the world to fix SIP. We need more people to discuss the dawes proposal. Keith - You should post to the list that we are looking for responses on it. Mary - We can take that action. Mary, to Richard, the AD - Are you ok that we dispatch dawes to SIPCORE? Richard - ok Cullen, to the room - any concerns? Room - silence Mary - we'll post to the email list. ACTION: Chairs to post to the email list that they are looking for responses on the Dawes proposal before dispatching to SIPCORE. Hadriel - Can SIPCORE reject the work? Mary - Yes, there needs to be a discussion in SIPCORE on adopting the work. ======================================================== Richard Ejzak SDP negotiation of Data Channel sub-protocols Charter: ​ http://www.ietf.org/mail-archive/web/dispatch/current/msg05072.html Document: ​draft-ejzak-dispatch-webrtc-data-channel-sdpneg/ Presentation: http://www.ietf.org/proceedings/88/slides/slides-88-dispatch-2.pdf Richard presented. Slide - Proposed Charter Richard - what's the process here? Mary described the proposed charter at a high-level. Mary - This has nothing to do with rtcweb, it's generic. Can be used by other working groups. Cullen - Is the scope right? Any comments if you want to change anything. We'll come back to this. Anyone? How many have read? Room - 5-6 people raised hands. Hadriel - Why do you need a charter or mini working group? Why isn't this in mmusic? Mary - It can be the conclusion that this work goes to mmusic. Hadriel - It looks like it should be done in mmusic. The problem is the identifier in the DataChannel, as apposed to … in rtcweb. It's equivalent to websocket in rtcweb. One example - one m= line had multiple … one for …, one for MSRP. That's wrong. Richard - hang on to that thought. I'll cover that. Cullen - let's step through the proposal, then ask the question how to dispatch the work. Hadriel - I still think it should go to mmusic. Mary - this is to inform the decision on dispatching this. Slide - Changes and open issues from draft Jonathan Lennox - The most recent version of the DataChannel doc does define an IANA registry, it doesn't define attributes. Needs to be expanded. Richard - thanks, I didn't look at it closely. It's a solvable problem. Paul K - Does the draft cover what happens for subsequent offer/answers after SCTP associations is established? Richard - yes, you have to have created a DataChannel to have created SCTP association. To create new SDP based DataChannel is through subsequent offer/answer. You have to consider stream id assignment role - if you are odd or even endpoint. Paul - I get that the offerer has to chose the numbers (even or odd rule), what about changes? Change the protocol or attributes? Can you do that? Also in the rtcweb DataChannel, they were trying to avoid conflicts between external and internal negotiation. If there is already a channel there, you get an error. Richard - To address your last concern first - if there is an error, the parent DataChannel doc will have to describe what to do. It's my assumption that it will call an API. Outside the scope. I wanted to talk more with Randall. Martin raised the point also. What was your first issue again? Paul - Changing the attributes on existing channel. Do you close the channel? Cullen - I agree it has to be solved, but it isn't the goal to solve it here. Richard - my assumption is that it will be closed. Slide - Proposed work plan Hadriel - Our role is to decide where to dispatch this - should go to mmusic. It impacts SDP. Lot of things have to be taken into account. Paul - go back to MSRP over DataChannels slide - you are asserting that this is always secure. This is specific only to SCTP and a specific stack. It needs to be used without that stack. There was a discussion in rtcweb about head-of-line blocking and solutions to that. Are the decisions there generic? Do they have to be done over here? Mary - We may do something similar if this is approved. Paul - Somehow we have answers for all the issues. I was looking at head-of-line blocking solution for file transfer. Richard - I agree on HOL blocking. Something else missing in this draft is …. Keith - I want to push back on Hadriel - it doesn't need to go to mmusic. We have an SDP directorate. Cullen - you are on that directorate right? Any thoughts? Keith - no, I'm not on the directorate. I'm not objecting to mmusic. Mary - Paul is on the directorate. Cullen - It's not true that it has to go to mmusic because it has to do with SDP. Hadriel - This changes only SDP. Mary - This is a little to big for SDP directorate. Paul - it has tight interactions with rtcweb. mary - rtcweb has rejected this, but there are other use cases for it. paul - I'm not saying taking it to rtcweb, but someplace where rtcweb people show up. Mary, Cullen - mmusic. Paul - Sending it to mmusic puts it at the end of a huge queue. I don't know where else. Mary - If there are people who want to work on it, it may be worked on first. Hadriel - it could be over SCTP without DTLS. I understood that it was DTLS. Richard - it's specific to DataChannel, it has been suggested to generalize it. Don't know the use cases. Hadriel - You should have sep m line for each one. Cullen - And which working group would discuss that? Hadriel - mmusic. Cullen - I agree with you. Lenox - Unfortunately it's mmusic. It too small for its own working group. Richard - I went to mmusic first. Hadriel - "Unfortunately it should be dispatched to mmusic." That should be the result. Mary - I don't think that these rooms are good for hums. I want a practice hum. Cullen - If know how to hum, hum now Room - hums. Cullen - that was the loudest hum ever. Cullen - I will take two hums. One in favor of the statement, then one for disapproval. The statement is: "Unfortunately it should be dispatched to mmusic." Cullen - Those who approve, hum now: Room - loud hum Cullen - Those who are opposed, hum now: Room - no hums. Cullen - it's unanimous, it goes to mmusic. ========================= Notetaker: Dan Romascanu ========================== 1. Status - Mary - http://www.ietf.org/proceedings/88/slides/slides-88-dispatch-0.ppt Other topics considered - two proposals, not enough discussions Keith Drage - post notes to the mailing list on dispatching mediasec-parameters to SIPCORE - AI for the chairs Deadlines for IETF-89 - 1/27 - start collecting 2. Richard Ejzak - SDP negotiation of DataChannel sub-protocols - http://www.ietf.org/proceedings/88/slides/slides-88-dispatch-2.pdf Mary - generic mechanism to be used by any other application, not only RTCWEB Cullen - how many people read? - 5-6 Hadriel - why need a charter? Why not in MMUSIC? Example that may be wrong - MSRP should have its own line Richard E. - wait for the presentation Richard E. - going through the presentation Data channel external negotiation Stream identifier assignment rules SDP for external negotiation Two new SDP attributes Example SDP offer Stream id assignment with SDP Changes and open issues from draft Jonathan L. - IANA registry in the data channel - can be used may need to be extended Paul K. - what happens if rules need to change after SCTP negotiation is established? Richard - if there is an error the browser will call an error to the API; Cullen - too detailed discussion MSRP over DataChannels Example SDP for MSRP over DC MSRP configurations supported Proposed work plan Paul K. - discussions in RTCWEB on head-of-the-line, fragmentation, etc? are those generic? We need those (redo, discuss new) Keith D. - Does not need to go to MMUSIC, could be done any place, use SDP directorate Chairs - not all SDP work goes to MMUSIC Paul K. - tight interaction with RTCWEB which refused it, but still has strong relation with RTCWEB, MMUSIC has a long waiting list Hadriel - can be over DTLS? Richard - can be generalized Jonathan - two small for a WG Hadriel ñ ëunfortunatelyí should be in MMUSIC Cullen - DISPATCH to MMUSIC - strong hummmm