Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE

[Harald Alvestrand <[e-mail]>]

Magnus:

1) IETF is most successful when it creates fora that are focused on 
delivering a product. Using long-lived, generic review mechanisms such 
as MMUSIC has a long history of failure; in particular, this particular 
BUNDLE change was done in MMUSIC without making RTCWEB aware of the 
introduced incompatibility, showing that MMUSIC failed to achieve IETF 
coordination on the issue, despite RTCWEB being the only significantly 
affected IETF WG, and the fact that RTCWEB was the cause of the BUNDLE 
work being started at all.

2) Anyone from MMUSIC is welcome to be part of the RTCWEB discussion on 
the subject. That's how cooperation between IETF WGs is supposed to be 
achieved: By cross-participation.

The solution to this problem needs IETF (rough) consensus. This includes 
the participants of MMUSIC, but does not, and should not, as far as I 
can tell, require that the particular subgroup of the IETF that 
self-identifies as "MMUSIC" have consensus on the issue.

I take my part of the blame (as listed co-author on BUNDLE) for not 
reviewing the change properly and realizing the JSEP impact of the 
change. But you certainly cannot argue that the history is a good 
argument that introducing a formal depenency on MMUSIC increases the 
chance of success for this particular endeavor.

(I have long argued that long-lived fora like MMUSIC should have the 
name of "WG" taken from them and explicitly be barred from taking on new 
work; these long-lived fora serve a very important purpose as 
institutional memory, but their success rate on involvement with new 
work is not something that impresses me.)

Harald

On 1/25/21 5:50 PM, Magnus Westerlund wrote:
> Hi,
>
> I am cross posting this to MMUSIC as BUNDLE was a MMUSIC document, and this
> issue has to my understanding still not been conveyed to the MMUSIC WG
> partipants.
>
> First, I am a bit concerned that this is done in a RTCWeb WG without any
> requirement on interaction with MMUSIC. BUNDLE is a general SDP O/A mechanism
> and not specific to RTCWebs usage in JSEP. Thus, I am worried about that changes
> are applied to BUNDLE that works fine for JSEP, but affect the interoperability
> with general case SDP O/A usages.
>
> Secondly, the citiation below includes the following: "... and existing browser
> implementations." I think that gives an impression that RTCWeb browser
> implementations can be used trump over general SDP O/A interoperability and also other implementation, even of WebRTC, that this alignment fix could potentially impact.
>
> Thus, I would prefer a different wording than referring to a statement that was
> intended to be informative that there exists an issue. I would notet that the
> statement was quickly written, that a limited set of people had any chance to
> see prior to its publication.
>
> In addition I think the scope can be narrowed even further than to just the
> Bundle-only part of BUNDLE and JSEP, to only the aspect that is missaligned.
>
> Cheers
>
> Magnus Westerlund
>
>
>
>
> On Fri, 2021-01-22 at 17:35 -0800, Murray S. Kucherawy wrote:
>> Colleagues,
>>
>> In the final run-up to publication of C238, it was observed that the JSEP and
>> BUNDLE documents contradict each other in a significant way.
>>
>> Rather than send them back to the working group to resolve, delaying
>> publication further for an unknown duration, the authors and Area Directors
>> involved reached consensus to publish the entire cluster as it was originally
>> approved, with a note added that acknowledges the contradiction (without
>> proposing solutions), and stating that the IETF will quickly take up the work
>> to publish updates.  The specific text is visible as Section 1.3 of RFC 8829
>> and 1.4 of RFC 8843.
>>
>> The IESG intends to reconstitute the RTCWEB working group to resolve this
>> contradiction, with a scope to resolve only that specific issue and publish a
>> couple of document updates.  The plan is to have this rechartering in place in
>> time for a meeting at IETF 110 in March.
>>
>> Below is the proposed re-chartering for the RTCWEB working group.  Feedback on
>> this is welcome, either on the [e-mail] list, to me privately, or to
>> the IESG.  We will start the formal process of review and approval on the next
>> IESG telechat, and have already requested a session during IETF 110 to get the
>> work going.
>>
>> -MSK, ART AD
>>
>> --
>>
>> The RTCWEB working group was originally chartered to standardize mechanisms
>> that provide direct interactive rich communication using audio, video,
>> collaboration, games, etc. between two peers' web-browsers, without requiring
>> non-standard extensions or proprietary plug-ins.  The result was a set of RFCs
>> from RTCWEB, in addition to many other RFCs from other working groups, all of
>> which are interrelated and had to be published together in what the RFC Editor
>> refers to as a “cluster”.  In the end, that cluster comprised more than 40
>> RFCs and was finally published in January 2021.
>>
>> During the run-up to publication of the cluster, a contradiction was
>> identified between what became RFCs 8829 and 8843.  A description of this
>> contradiction was added to both documents to highlight the problem, and state
>> our intention to proceed with publication but quickly initiate an effort to
>> publish updates to the affected documents.
>>
>> The key part of the added text was as follows:
>>
>> “The specific issue involves the handling of "m=" sections that are designated
>> as bundle-only, as discussed in Section 4.1.1 of [RFC 8829].  Currently, there
>> is divergence between JSEP and BUNDLE, as well as between these specifications
>> and existing browser implementations …”
>>
>> The working group is being reconstituted to take up this contradiction, come
>> to consensus on a resolution, and issue Standards Track updates for those two
>> documents.  Updating any other document, or taking up any other issue, is out
>> of scope and will require IESG approval via rechartering.
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic