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

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 16 Apr 2022 22:35:39 +0000

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. 

So it should reference https://www.w3.org/TR/2021/REC-webrtc-20210126

There is a good list of the history of the W3C drafts for interested at 

https://www.w3.org/standards/history/webrtc

> On Mar 29, 2022, at 6:39 AM, Christer Holmberg <christer.holmberg=[email-masked]> 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 <[email-masked]> on behalf of Joel M. Halpern <[email-masked]>
> Sent: Tuesday, March 29, 2022 6:08:37 AM
> To: Sean Turner <[email-masked]>
> Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; RTCWeb IETF <[email-masked]>; [email-masked]<[email-masked]>
> 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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 17 Apr 2022 16:37:29 +0000

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

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

Regards,

Christer

> On Mar 29, 2022, at 6:39 AM, Christer Holmberg <mailto:christer.holmberg=[email-masked]> wrote:
> 
> Hi,
>  
> A couple of comments:
>  
> From: Gen-art <mailto:[email-masked]> on behalf of Joel M. Halpern 
> <mailto:[email-masked]>
> To: Sean Turner <mailto:[email-masked]>
> Cc: mailto:[email-masked] <mailto:[email-masked]>; mailto:[email-masked] 
> <mailto:[email-masked]>; RTCWeb IETF <mailto:[email-masked]>; 
> mailto:[email-masked]<draft-uberti-rtcweb-rfc882
> mailto:[email-masked]>
> >> On Mar 27, 2022, at 13:49, Joel Halpern via Datatracker <mailto:[email-masked]> wrote:
> >>
> >> Reviewer: Joel Halpern
> >> 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.
> >>
> mailto:[email-masked]
> mailto:[email-masked]