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

Qin Wu via Datatracker <noreply@ietf.org> Sun, 27 March 2022 09:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 954443A1214; Sun, 27 Mar 2022 02:02:30 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Qin Wu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-uberti-rtcweb-rfc8829bis.all@ietf.org, last-call@ietf.org, rtcweb@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164837175050.30355.18155410160847059171@ietfa.amsl.com>
Reply-To: Qin Wu <bill.wu@huawei.com>
Date: Sun, 27 Mar 2022 02:02:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/6a-xbYS2dihJXRRqaGoSNDQVRNQ>
Subject: [rtcweb] Opsdir last call review of draft-uberti-rtcweb-rfc8829bis-02
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Mar 2022 09:02:31 -0000

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.

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?

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?