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

Sean Turner <sean@sn3rd.com> Wed, 27 April 2022 01:13 UTC

Return-Path: <sean@sn3rd.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0467C18440C for <rtcweb@ietfa.amsl.com>; Tue, 26 Apr 2022 18:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIK_G3er5uRL for <rtcweb@ietfa.amsl.com>; Tue, 26 Apr 2022 18:13:12 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE0EC184413 for <rtcweb@ietf.org>; Tue, 26 Apr 2022 18:13:12 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id i2so305302qke.12 for <rtcweb@ietf.org>; Tue, 26 Apr 2022 18:13:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RKN5SvBCsc9ytxxhQMM4EBJlLHdfYXAh0mVHQyCYV0M=; b=Ph7bvrUiw+qVRMSYAUv4noGg37vd8PFkIm8Mpd3VIOmTPjIKMsQyDUxxfvygguaL1t 3U4A1s3Kn+yVNZItA8ZiIEVWQpNJRovMx1EYkfkafo/4XEtjF/jnl67ufPm28N58neBR /6OGkGTI3oNjCiexGjIAlYmijiYoFQ4ksAQoU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RKN5SvBCsc9ytxxhQMM4EBJlLHdfYXAh0mVHQyCYV0M=; b=W6qwkENBKJwHxesGGweFT2Ikop/HH69wz1aueXPvden17ybXlUQsZJWhCxX5IEeOZt Ur4hzg17c6uhVYki/omU1RtXQP6Nu+bNBQ5fHV9Q6acmdoG260t0nDnhrkVxispCW/xC 85JA2cXqde4apg+FfbsyPfL84CEkmSgKj/s+lSENrOgvsEnT3a5O+p53al4vINC25sjz sWhu6/KfjhkqA3H5pq9ujiu3DcylpLuJz08uiiq6pYasoaYiO/7q78Xt21LPetyTltwk mNTALQpoJDtZJD27jYqndGu+PYJHFR2VdHU8WfaE6AQ/IeTcoU7jCBkVq1WpAB87c0Nn UKcg==
X-Gm-Message-State: AOAM532PMcR6X8q0PtfofrJPICEOSZpmu3X0QYrU+P1PbZxlLFieNnoL 0aG1ypfEV4Rfjca7lvmzPqbhng==
X-Google-Smtp-Source: ABdhPJzCYGaXDfL3rKwZV3/ibXBUFDXsuRMyGTA/OZh8wc5YaCqQuIRxoAgAPWcPZClXTB/A5shD4Q==
X-Received: by 2002:a37:f519:0:b0:69c:29e0:f740 with SMTP id l25-20020a37f519000000b0069c29e0f740mr14982590qkk.652.1651021990796; Tue, 26 Apr 2022 18:13:10 -0700 (PDT)
Received: from smtpclient.apple (pool-72-83-85-4.washdc.east.verizon.net. [72.83.85.4]) by smtp.gmail.com with ESMTPSA id q3-20020a37f703000000b0069f8a2d0051sm500398qkj.31.2022.04.26.18.13.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2022 18:13:10 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <bc3bed19e5be4dab967933c94708b474@huawei.com>
Date: Tue, 26 Apr 2022 21:13:08 -0400
Cc: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-uberti-rtcweb-rfc8829bis.all@ietf.org" <draft-uberti-rtcweb-rfc8829bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6497E969-738D-4079-9B61-384741162F84@sn3rd.com>
References: <bc3bed19e5be4dab967933c94708b474@huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/LmQuyK24yGkB6RIAkUS5A2q8EVM>
Subject: Re: [rtcweb] Opsdir last call review of draft-uberti-rtcweb-rfc8829bis-02
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
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: Wed, 27 Apr 2022 01:13:17 -0000

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@huawei.com> wrote:
> 
> Hi, Sean:
> -----邮件原件-----
> 发件人: Sean Turner [mailto:sean@sn3rd.com] 
> 发送时间: 2022年3月28日 21:51
> 收件人: Qin Wu <bill.wu@huawei.com>
> 抄送: ops-dir@ietf.org; draft-uberti-rtcweb-rfc8829bis.all@ietf.org; last-call@ietf.org; rtcweb@ietf.org
> 主题: Re: Opsdir last call review of draft-uberti-rtcweb-rfc8829bis-02
> 
> 
> 
>> On Mar 27, 2022, at 05:02, Qin Wu via Datatracker <noreply@ietf.org> 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