Minutes IETF103: mmusic
minutes-103-mmusic-00

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.