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.holmb...@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....@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-boun...@ietf.org> on behalf of Joel M. Halpern 
>> <mailto:j...@joelhalpern.com>
>> Sent: Tuesday, March 29, 2022 6:08:37 AM
>> To: Sean Turner <mailto:s...@sn3rd.com>
>> Cc: mailto:last-c...@ietf.org <mailto:last-c...@ietf.org>; 
>> mailto:gen-art@ietf.org 
>> <mailto:gen-art@ietf.org>; RTCWeb IETF <mailto:rtc...@ietf.org>; 
>> mailto:draft-uberti-rtcweb-rfc8829bis....@ietf.org<draft-uberti-rtcweb-rfc882
>> mailto:9bis....@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:nore...@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-c...@ietf.org
>> https://www.ietf.org/mailman/listinfo/last-call
> 

_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to