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

Sean Turner <sean@sn3rd.com> Wed, 27 April 2022 01:39 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 00175C19E0D3 for <rtcweb@ietfa.amsl.com>; Tue, 26 Apr 2022 18:39:10 -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=ham 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 Rilzm0Lys5Ya for <rtcweb@ietfa.amsl.com>; Tue, 26 Apr 2022 18:39:06 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 D0FF9C185767 for <rtcweb@ietf.org>; Tue, 26 Apr 2022 18:39:06 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id b189so342590qkf.11 for <rtcweb@ietf.org>; Tue, 26 Apr 2022 18:39:06 -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=RtbPHn+6Z7jah7Ak/5QyPb0opk5IT2F1XH3Dl2TVQ1c=; b=gyEeTHuFaMqw7lqQtvS5P7cOLaP1fFT0R3oMt/y6d18yE024GZMcW7KdcedL8tWHWF YYlxKlhwKFWJtR0C41d95xXg5H8XekiecvWW9JFr5nsZWNNdDMh0PNfRRIXvaYBSfpkC YWHCSyTBpguusTh9VPlY6LQzd7i4mzoIu6b5A=
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=RtbPHn+6Z7jah7Ak/5QyPb0opk5IT2F1XH3Dl2TVQ1c=; b=H8aS8Unb2VVOiAbMcNIHYOzfABpH94iZtg8XSC0f5tTIhpQNRgTeY3/+uhzlMYera8 SEQ5agy71OVn7GLdM+plGfgVOgMc9UrWMlMuIFcpko1bXl+pvfMhXctR5Gkuk3EObAXS 0SY5DEFo3Voqn+9/Lvr77KymM8LWF67w+SUxGE7FRLHFMVpfwwkc0PMGSySrsnQDN8vm NFjJmkCXnPhhk/YYD+vKdrpmhmXjeDgt3nERfNdY/YXtwtNWy3FwQ6Vw3SHtbFGHrTu8 6b7D/LS1ruzrm8vTiTJsbZiRsZn0SqScDeKyn0bW0fhQPywDB9M6SE99BsDcyfqx9YLu RFVg==
X-Gm-Message-State: AOAM5336MS3RJmSHxIrZkE6z0hhEfvmYqcJyonADYUaSmYv8927ZDyx9 7lxnETfylzcOkRDsjh9ik7rnOQ==
X-Google-Smtp-Source: ABdhPJxNd3mdh9RFaaiZ7FGpQg/MFaHz8LVuVuo5tRH3IJZcKOpenDoQW/O7b3SMPg2fOFsBSRpr4w==
X-Received: by 2002:ae9:e518:0:b0:69f:8dc5:c173 with SMTP id w24-20020ae9e518000000b0069f8dc5c173mr25359qkf.421.1651023545619; Tue, 26 Apr 2022 18:39:05 -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 f25-20020a05620a15b900b0069f78e60ee9sm1717012qkk.105.2022.04.26.18.39.04 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Apr 2022 18:39:05 -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: <HE1PR07MB4441FFA95E0F0733ED2B6B1F93F09@HE1PR07MB4441.eurprd07.prod.outlook.com>
Date: Tue, 26 Apr 2022 21:39:02 -0400
Cc: Joel Halpern <jmh@joelhalpern.com>, "last-call@ietf.org" <last-call@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, RTCWeb IETF <rtcweb@ietf.org>, "draft-uberti-rtcweb-rfc8829bis.all@ietf.org" <draft-uberti-rtcweb-rfc8829bis.all@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <39CFF823-5113-4B26-ADD6-05830C5D37DF@sn3rd.com>
References: <164840334560.25727.8727238035250838155@ietfa.amsl.com> <320CCABF-5283-4B07-B637-FC03F582CA2D@sn3rd.com> <72fa004c-cdd8-807d-1ba6-4ba2b3b15969@joelhalpern.com> <HE1PR07MB444195619B7E78EF95184FC4931E9@HE1PR07MB4441.eurprd07.prod.outlook.com> <3BD1DD31-5248-4B91-B06E-F6376E694492@cisco.com> <HE1PR07MB4441FFA95E0F0733ED2B6B1F93F09@HE1PR07MB4441.eurprd07.prod.outlook.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Cullen Jennings (fluffy)" <fluffy=40cisco.com@dmarc.ietf.org>, Harald Tveit Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/pMagWl3oMkxOtjgSCtLKusqeG0Q>
Subject: Re: [rtcweb] [Last-Call] [Gen-art] Genart 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:39:11 -0000

Hi! I would really love to give our AD a revised version of this I-D soon.

> On Apr 17, 2022, at 12:37, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi,
> 
>> I feel very strongly that we must reference a stable version or else there is no way to know what is reviewed. The w3c spec was not approved before and was a draft
>> so it was hard but at this point I think the REC version is the correct references. 
> 
> I don't object to referencing a specific version - I actually agree.
> 
> My question is why JSEP uses an INFORMATIVE WebRTC reference WITH a version, while other RTCWEB RFCs use NORMATIVE WebRTC references WITHOUT a version...

I didn’t do an exhaustive search, but I did note that
RFCs 8825, 8827, and 8834 refer to the the W3C specification normatively as follows:
https://www.w3.org/TR/webrtc/
There is no chance that there is any energy whatsoever to go back and change those three to refer to a specific version. So I think we will need to call those done.

For this I-D, I originally submitted the following PR to update the reference to the final recommendation.  I have updated that PR to also move the reference to be normative. See:

https://github.com/rtcweb-wg/jsep/pull/1024

Is there any objection to moving the reference to normative?

>> So it should reference https://www.w3.org/TR/2021/REC-webrtc-20210126
> 
> RFC 8829 references https://www.w3.org/TR/2020/PR-webrtc-20201215/. I just want to verify that there is no text etc in 8829bis that is not aligned with 20210126.

Harald or Cullen can one of you comment on this? The vast majority of PRs merged into the 202110126 version were marked as editorial.

spt

> Regards,
> 
> Christer
> 
> 
> 
>> On Mar 29, 2022, at 6:39 AM, Christer Holmberg <mailto:christer.holmberg=40ericsson.com@dmarc.ietf.org> wrote:
>> 
>> Hi,
>> 
>> A couple of comments:
>> 
>> First, in general, if we are going to update the reference version, we need to verify that we don’t break anything.
>> 
>> Second, most of the RTCWEB RFCs referencing the WebRTC spec seem to reference *without* a version (i.e., https://www.w3.org/TR/webrtc/). Many RFCs also reference to RFC 8825 for WebRTC, and RFC 8825 also reference WebRTC without a version.
>> 
>> So, is there a reason why we would use a version in JSEP, while not in other RFCs? Note that often the WebRTC reference is Normative.
>> 
>> I do understand that JSEP is very closely linked to WebRTC, why there might be a need to reference a given version. But, then again, we need to make sure that updating the version does not break anything.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Gen-art <mailto:gen-art-bounces@ietf.org> on behalf of Joel M. Halpern 
>> <mailto:jmh@joelhalpern.com>
>> Sent: Tuesday, March 29, 2022 6:08:37 AM
>> To: Sean Turner <mailto:sean@sn3rd.com>
>> Cc: mailto:last-call@ietf.org <mailto:last-call@ietf.org>; mailto:gen-art@ietf.org 
>> <mailto:gen-art@ietf.org>; RTCWeb IETF <mailto:rtcweb@ietf.org>; 
>> mailto:draft-uberti-rtcweb-rfc8829bis.all@ietf.org<draft-uberti-rtcweb-rfc882
>> mailto:9bis.all@ietf.org>
>> Subject: Re: [Gen-art] Genart last call review of 
>> draft-uberti-rtcweb-rfc8829bis-02
>> 
>> Thanks Sean.  I finally concluded that was the intent.  And I think 
>> technically it says so.
>> If you could look at making that more clear early, it would probably 
>> help those readers who are not as familiar with the cited W3C API.
>> 
>> Yours,
>> Joel
>> 
>> On 3/28/2022 10:47 PM, Sean Turner wrote:
>>> 
>>> 
>>>> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker <mailto:noreply@ietf.org> wrote:
>>>> 
>>>> Reviewer: Joel Halpern
>>>> Review result: Ready with Issues
>>>> 
>>>> I am the assigned Gen-ART reviewer for this draft. The General Area 
>>>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>>>> the IESG for the IETF Chair.  Please treat these comments just like 
>>>> any other last call comments.
>>>> 
>>>> For more information, please see the FAQ at
>>>> 
>>>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>>> 
>>>> Document: draft-uberti-rtcweb-rfc8829bis-02
>>>> Reviewer: Joel Halpern
>>>> Review Date: 2022-03-27
>>>> IETF LC End Date: 2022-04-05
>>>> IESG Telechat date: Not scheduled for a telechat
>>>> 
>>>> Summary: This document is ready for publication as a Proposed Standard.
>>>> However, there are some issues that should be considered before final approval.
>>>> 
>>>> Major issues: None
>>>> 
>>>> Minor issues:
>>>>    I found myself confused as a reader about one aspect of this document  The
>>>>    document seems to describe both the Interface to the JSEP and the details
>>>>    of what the underlying system must do in response to JSEP operations.  The
>>>>    later is described very well and clearly.  The former is described quite
>>>>    vaguely.  I suspect that the assumption is that the required parameters are
>>>>    described in the W3C documents.  But it is hard to tell, and the only
>>>>    formal reference is a vague citation in the introduction to an outdated W3C
>>>>    specification.  A little more clarity on how an implementor is supposed to
>>>>    know what actual interface objects, methods, and parameters they need to
>>>>    provide would be helpful.  Also, the reference should be updated to
>>>>    whatever is the current W3C specification.
>>> 
>>> Will check on updating the reference. I would be floored if we couldn’t point to it.
>>> 
>>> The basic idea here is that the W3C WebRTC spec is API and this is the protocol spec.
>>> 
>>>> Nits/editorial comments:
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> _______________________________________________
>> Gen-art mailing list
>> mailto:Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
>> --
>> last-call mailing list
>> mailto:last-call@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call
>