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

[Magnus Westerlund <[e-mail]>]

Hi Harald,

Let me clarify. My first issue was about the process up to this point that no
one had taken the time to actually inform the participants on the MMUSIC WG
mailing that one specification developed by the WG had an issue in relation to
another one done in RTCWeb when in AUTH48. Independently of where that work
shold be done to fix this, I think there exists a need to inform people about
this plan. And when publishing that plan only to RTCWeb mailing list that got me
annoyed. 

Secondly, I can definitely live with the work being done in a revivied
specifically charted RTCWeb WG. However, SDP Offer/Answer is used in several
places for different usages. Something which was considred very much when
developing BUNDLE. Thus, I think it is relevant that RTCWeb will keep MMUSIC
informed about their work. So that RTCWeb doesn't end up missing an important
aspect of this, a run into issue when forming the IETF consensus needed to
publish this document. 

Cheers

Magnus Westerlund


On Tue, 2021-01-26 at 10:07 +0100, Harald Alvestrand wrote:
> 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
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic