Minutes of Meeting: MMUSIC Working Group at IETF 103 ==================================================== The MMUSIC working group met at IETF #103 in Bangkok on Thursday November 8, 2018 from 13:50 to 14:25. The meeting was chaired by Flemming Andreasen and Bo Burman. Christer Holmberg and the chairs took notes, and Jonathan Lennox acted as Jabber relay. The meeting was broadcast live and recorded by the Meetecho team, available at: https://play.conf.meetecho.com/Playout/?session=IETF103-MMUSIC-20181108-1350 Final agenda: ------------- 13:50-14:05 Introduction and Status Update (15 mins, Chairs) 14:05-14:20 Charter Update to Combine with ICE (15 mins, Chairs) 14:20-14:50 DCSA Attribute Registration (30 mins, Roni Even) draft-ietf-mmusic-data-channel-sdpneg There were no comments on the agenda. Introduction and Status Update (Chairs) --------------------------------------- The chairs presented their slides with the agenda and an update about activities since the last meeting. Flemming: The authors of draft-ietf-mmusic-sdp-uks plans an update during next week. Christer: draft-ietf-mmusic-sdp-mux-attributes will need some small updates based on updates in draft-ietf-bfcpbis-rfc4583bis; there are some attributes in -mux-attributes with a MUX category of TBD that has a different category in -rfc4583bis. Ben Campbell (ART AD): Make sure that the WG is aware of this change, unless there are material changes, which does not seem to be the case. Charter Update to Combine with ICE (Chairs) ------------------------------------------- Ari Keranen (ICE co-chair): We're done with ICE documents. There are no new documents at this point so ICE WG is declaring success. The proposed charter change is that MMUSIC maintains ICE specifications. ICE was originally defined in MMUSIC, then further developed in the ICE WG. Ben (relaying a comment from Eric Rescorla): Do we really need to add that to the charter vs. handling it like any other extension with existing charter text? Do we have the right expertise in MMUSIC to deal with ICE core changes for example? Roni Even: If not chartered, would new ICE work go through DISPATCH WG? Ben: That depends on the change. Jonathan Lennox: A few years back there were various ICE changes/extensions proposed. Not sure what current status is. Bernard Aboba: There are proprietary extensions to ICE that have shipped in rather large scales. Ben: Is it likely those will be brought back to the IETF? Bernard: Could be. Individual drafts have been written, but don't know about plans to bring them to IETF. There are some corner cases in the drafts they are based on - would help with some chartered work to document the extensions. Ben: If we were to take that work back up - would it be considered maintenance or reworked? Bernard: Some of these things are not maintenance but fairly core to ICE and would need significant analysis. Ben: Could potentially be an ICE bis-bis? Bernard: There are probably not energy for a bis-bis at this point, but there are a number of things that would lead to important performance enhancements. Christer Holmberg: I have read a few of those drafts and they are definitely not maintenance - they are new functionality (e.g. continuous nomination). Chair: ICE extensions may have to go via DISPATCH WG anyway, no matter what WG handles ICE. Is it then worth to close ICE WG, if extensions would be provided? Ari: The ICE WG is a very small group of people, the same group of people in MMUSIC and ICE related to this work. there is not a lot of work in either group - think it makes sense to have it done in MMUSIC. Jonathan: In favor of doing it in MMUSIC, unless it seems the amount of work justifies another WG. Ben: It seems like people in general is in favor of keeping it in. I think what I hear is that MMUSIC could do small tasks, but they should not take on major new work without re-charter, and/or via DISPATCH WG, etc. Bernard: Lots of it is about performance optimization, which may not be the scope for MMUSIC and don't know if MMUSIC has the right expertise and desire to engage in it. Ben: How many people were active in ICE that don't also come to MMUSIC? Ari: Haven't followed MMUSIC closely lately. We can always pull people from different communities, if needed. For transport related extensions, we will anyway need transport expertise. Ben: Have the chairs agreed on the proposal? Chairs: Yes. Bernard: In case people want to make a speed optimization, an example activity would be a hackathon where people can prove the performance enhancements are actually real - needs to be some empirical evidence. Ben: Add a sentence to the charter proposal that any new ICE extension need demonstrated interest and value. Jonathan: Leave out the ICE history part in the charter update. Chairs: Noted. DCSA Attribute Registration (Roni) ---------------------------------- The latest version should address most of the comments given, mainly by Ben. There was an open question from Roni on what to do with the SDP dcsa attribute defined in draft-ietf-mmusic-data-channel-sdpneg: The current IANA considerations introduces a new dcsa usage level in the IANA SDP att-field registry. The proposal is to define a new registry "att-field (dcsa level)". There is no option to add a usage level to the current "att-field" registries. Martin Thomson: Do we use this attribute to signal datachannel priority in RTCWEB? Jonathan: No. RTCWEB doesn't use this for priority. Flemming (as individual): draft-ietf-mmusic-rfc4566bis is already covering the IANA registry rewrite. Ben: Is this part of the RTCWEB dependency cluster (C238)? Roni: No. There are only CLUE dependencies to this draft. Ben: Assuming the registries are created in -rfc4566bis, the way forward for this issue is for -sdpneg to reference -rfc4566bis, which probably needs to reference -sdpneg as well - so we have a new mini-cluster.