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

[Christer Holmberg <[e-mail]>]

Hi Harald,

*FIRST*, in order to clarify for the community what the JSEP/BUNDLE misalignment is about, because it is not that clear in the text that was added to the specs: the misalignment is regarding the sending
of the *initial answer*, and *subsequent offers and answers*. BUNDLE says that in such offers and answers all bundled m- lines (except the tagged m- line) contain port zero and a bundle-only attribute.
JSEP says that in such offers and answers all bundled m- lines contain the negotiated bundle port.


*SECOND*, your ”RTCWEB was not made aware” claim is not true.

- Once the BUNDLE change had been done, RTCWEB was made aware that JSEP had to be updated: https://mailarchive.ietf.org/arch/msg/rtcweb/B38bsRBAzfpJmBOCpnNCxM0wDbc/
Unfortunately, that update was never done, and that wasn’t detected until recently.

- draft-ietf-rtcweb-sdp, which is a RTCWEB WG deliverable, *is* aligned with BUNDLE.


*THIRD*, I don’t understand your comments regarding the MMUSIC WG. Cross-participation goes both ways, MMUSIC was chartered to work on a number of documents needed by RTCWEB, anyone could participate in the work, and anyone following the mail discussions would have been aware of the change.

However, arguing about who should have done and known what is not going to solve the misalignment. The charter should be about fixing the BUNDLE/JSEP misalignment, and I haven’t seen anyone objecting to that.


Regards,

Christer





From: mmusic <[e-mail]> On Behalf Of Harald Alvestrand
Sent: tiistai 26. tammikuuta 2021 11.07
To: [e-mail]
Subject: Re: [MMUSIC] [rtcweb] Updating JSEP and BUNDLE


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]<mailto:[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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/rtcweb



_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic