Re: [rtcweb] Opsdir last call review of draft-uberti-rtcweb-rfc8829bis-02

[Sean Turner <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Hi, Sean:
> -----邮件原件-----
> 发件人: Sean Turner [mailto:[e-mail]] 
> 发送时间: 2022年3月28日 21:51
> 收件人: Qin Wu <[e-mail]>
> 抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> 主题: Re: Opsdir last call review of draft-uberti-rtcweb-rfc8829bis-02
> 
> 
> 
>> On Mar 27, 2022, at 05:02, Qin Wu via Datatracker <[e-mail]> 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