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

[Qin Wu <[e-mail]>]

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.
> 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?

> 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?