Sorry for taking so long to get back to this. I put the resulting changes in this PR: https://github.com/rtcweb-wg/jsep/pull/1025 more info below. > On Mar 29, 2022, at 07:25, Qin Wu <bill.wu@xxxxxxxxxx> wrote: > > Hi, Sean: > -----邮件原件----- > 发件人: Sean Turner [mailto:sean@xxxxxxxxx] > 发送时间: 2022年3月28日 21:51 > 收件人: Qin Wu <bill.wu@xxxxxxxxxx> > 抄送: ops-dir@xxxxxxxx; draft-uberti-rtcweb-rfc8829bis.all@xxxxxxxx; last-call@xxxxxxxx; rtcweb@xxxxxxxx > 主题: Re: Opsdir last call review of draft-uberti-rtcweb-rfc8829bis-02 > > > >> On Mar 27, 2022, at 05:02, Qin Wu via Datatracker <noreply@xxxxxxxx> wrote: >> >> Reviewer: Qin Wu >> Review result: Has Issues >> >> I have reviewed this document as part of the Operational directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written with the intent of improving the >> operational aspects of the IETF drafts. Comments that are not >> addressed in last call may be included in AD reviews during the IESG >> review. Document editors and WG chairs should treat these comments just like any other last call comments. >> >> RFC8829 defines JSEP protocol and describes the mechanisms for >> allowing a JavaScript application to control the signaling plane of a >> multimedia session via the interface specified in the W3C >> RTCPeerConnection API. This document is RFC8829bis and provides update >> to RFC8829 to address inconsistency between JSEP and SDP BUNDLE protocol. >> >> Major issue: >> I am not against deprecating "max-bundle" and replacing it with >> “must-bundle”, but Since there is inconsistency between JSEP and SDP >> BUNDLE protocol, regarding bundle-only "m=", I think it is the fault >> of both JSEP and SDP BUNDLE protocol. the best way is both JSEP and >> SDP BUNDLE protocol should make bis documents in parallel, to make >> sure consistently issues get resolved. The draft >> said: “ The former concern was addressed via an update to [RFC9143] ” >> Where is the document specifying update to RFC9143? Without RFC9143bis >> to be proposed on the same table, I am not sure how we can prevent >> inconsistency issue between this RFC8829bis and the future RFC9143bis from happening again. > > It’s possible the s1.3 explanations is not clear and we were maybe a little overzealous with our reference updates. When RFC 8829 (JSEP) was published, there was a contradiction regarding bundle-only "m=“ sections between JSEP and BUNDLE (as specified in RFC 8843). This contradiction was explained in s1.3 of RFC 8829. RFC 9143, which updates RFC 8843) and this I-D are the “fix". Maybe this would be clearer: > > When [RFC8829] was published, inconsistencies regarding BUNDLE > operation were identified with regard to both the > specification text as well as implementation behavior. The former > concern was addressed via an update to BUNDLE, see [RFC9143]. > > [Qin Wu] Thanks for proposed change for clarification, I think you address my confusion. Now that I have re-read it - it would have definitely confused me too. >> Minor issue: >> The draft said: >> “ >> When [RFC8829] was published, inconsistencies regarding BUNDLE >> [RFC9143] operation were identified with regard to both the >> specification text as well as implementation behavior. ” What is the >> difference between specification text and implementation behavior? Why >> specification text can not specify the standard behavior for the endpoints implementation? > > The differences were as noted in the remainder of the para. > > [Qin Wu] After I re-read RFC9143 and this draft, I believe you are right. > But one minor suggestion is, to make clear which specification you are referred to when you said > "Marking "m=" sections as bundle-only as indicated by the specification" as follows > " > it was observed that some implementations implemented the > "max-bundle" bundle policy defined in [RFC8829] by assuming that > bundling had already been negotiated, rather than marking "m=" > sections as bundle-only as indicated by **the specification** > " > this specification or something else? Make sense? I hoping that if do the substation that s/the specification/the BUNDLE specification makes it clearer. >> RFC8829 said: >> “ >> JSEP prescribes that said "m=" sections should use port zero and add an >> "a=bundle-only" attribute in initial offers, but not in answers or subsequent >> offers. BUNDLE prescribes that these "m=" sections should be marked as >> described in the previous point, but in all offers and answers. Most >> current browsers do not mark any "m=" sections with port zero and >> instead use the same port for all bundled "m=" sections; some others >> follow the JSEP behavior ” If both JSEP protocol and SDP BUNDEL >> protocol define consistent standard behavior, browser implementation >> follows standard behavior defined in JSEP and SDP BUNDEL protocol, >> implementation inconsistency will automatically go away, no? I am not sure I answered this, but I think that this is the hope after the update. spt -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
