Re: [Wish] WG Last Call for draft-ietf-wish-whip

[Sean Turner <[e-mail]>]

FYI - in case you missed it.

> On Jun 30, 2022, at 07:57, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
>  
> Personally I am fine having the discussions on Github.
>  
> Regards,
>  
> Christer
>  
> From: Wish <[e-mail]> On Behalf Of Sergio Garcia Murillo
> Sent: torstai 30. kesäkuuta 2022 13.25
> To: Christer Holmberg <christer.holmberg=[e-mail]>
> Cc: Sean Turner <[e-mail]>; WISH List <[e-mail]>
> Subject: Re: [Wish] WG Last Call for draft-ietf-wish-whip
>  
> Hi Christed,
>  
> I have opened one issue for each of your comments on the github issue tracker too as I have done with Juliusz. Are you ok to continue the discussion there or would you prefer to continue by email?
>  
> https://github.com/wish-wg/webrtc-http-ingest-protocol/issues
>  
> Best regards
> Sergio
>  
>  
> On Thu, Jun 30, 2022 at 11:40 AM Christer Holmberg <christer.holmberg=[e-mail]> wrote:
> Hi,
> 
> I have read the draft. Based on my comments below, I think it still need some work.
> 
> I also read the review comments provided by Juliusz, and I pretty much share those.
> 
> ---
> 
> Q0.1: GENERAL (Editorial)
> 
> When you refer to other protocols etc (e.g., WebRTC, JSEP, HTTP, RTMP, RTSP, SIP, SDP, SDP Offer/Answer, XMPP) please include a reference.
> 
> ---
> 
> Q0.2: GENERAL (Editorial)
> 
> I think the draft shall contain some actual examples: HTTP message examples, SDP Offer/Answer examples, etc. 
> 
> ---
> 
> Q0.3: GENERAL (Editorial)
> 
> Offer/Answer has only been standardized for SDP (and, one may claim, for JSEP). I think you need some text on how you are now defining the usage of Offer/Answer (if only for a specific use-case) with HTTP.
> 
> ---
> 
> Q1: Abstract (Editorial)
> 
> I think the Abstract is too long (I think Juliusz gave the same comment). You don't need the background and justification in the Abstract - just say what the document does. The rest can be moved to the Introduction.
> 
> ---
> 
> Q2: Abstract (Editorial/Technical)
> 
> The text says:
> 
>    "These protocols are much older than webrtc and lack by default some
>    important security and resilience features provided by webrtc with
>    minimal delay."
> 
> I assume you refer to RTMP, which is mentioned in the previous Section.
> 
> Doesn't RTMPS solve some of the security issues?
> 
> But in general, if you want to put up WHIP against RTMP, I think you need a little more text.
> 
> Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is
> no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
> 
> ---
> 
> Q3: Abstract (Editorial/Technical)
> 
> The text says:
> 
>    "The media codecs used in older protocols do not always match those
>    being used in WebRTC, mandating transcoding on the ingest node,"
> 
> I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
> 
> ---
> 
> Q4: Introduction (Editorial/Technical)
> 
> The text says:
> 
>    "while RTCWEB standardized the signalling protocol itself (JSEP, SDP O/A)"
> 
> JSEP is not a singlalling protocol, and RTCWEB did not standardize any SDP O/A signalling.
> 
> ---
> 
> Q5: Introduction (Editorial/Technical)
> 
> The text says:
> 
>    "RTSP, which is based on RTP and maybe the closest in terms of features to webrtc,
>     is not compatible with WebRTC SDP offer/answer model."
> 
> I think I commented on this earlier, but what is the "WebRTC SDP offer/answer model"?
> 
> ---
> 
> Q6: Introduction (Editorial/Technical)
> 
> The text says:
> 
>    "In the specific case of ingest into a platform, some assumption can
>    be made about the server-side which simplifies the webrtc compliance
>    burden, as detailed in webrtc-gateway document
>    [I-D.draft-alvestrand-rtcweb-gateways]."
> 
> draft-alvestrand-rtcweb-gateways has been replaced by draft-ietf-rtcweb-gateways. 
> Having said that, the latest version of the gateways draft is from 2016, I doubt
> the draft will ever be published as an RFC. As you have it as a Normative reference, 
> that means this draft would also end up in a misref state forever...
> 
> Related to that, you should look whether all your references really need to be Normative. In the case of the gateway draft for example, I assume it could be Informative.
> 
> ---
> 
> Q7: Introduction (Editorial)
> 
> The text says:
> 
>  "o  As easy to use as current RTMP URIs."
> 
> It says a little strange to say that a protocol is as easy to use as curent RTMP URIs.
> 
> ---
> 
> Q8: Section 4.2 (Technical)     
> 
> The text says:
> 
>    "Unlike [RFC5763] a WHIP client MAY use a setup attribute value of
>    setup:active in the SDP offer, in which case the WHIP endpoint MUST
>    use a setup attribute value of setup:passive in the SDP answer."
> 
> First, check whether it would be useful to also reference RFC 8842.
> 
> Second, I think it is a BAD idea to go against the "MUST use setup:actpass" text in RFC 5763. Since you specify that the answerer MUST use setup:passive, there is no reason why the offer couldn't use setup:actpass, following the standard.
> 
> ---
> 
> Section 4.4 (Technical)
> 
> The usability of the ICE server configuration seem to go far beyond WHIP. Also, in my opinion the way you configure your STUN/TURN servers is slightly outside the scope of core WHIP.
> 
> But, assuming you want to keep the text:
> 
> First, you should add references to where the STUN- and TURN server URIs are defined.
> 
> Second, I believe Link URIs have to be enclosed by < and >.
> 
> Third, I think the "ice-server" value is misleading. An ICE server is not the same thing as a STUN/TURN server. You don't even have to use ICE in order to support STUN/TURN.
> 
> Fourth, related to the third issue, perhaps you should use the "urn:ietf:params:whip:" appendix also for the STUN/TURN servers? 
> 
> Fifth, you say that not all webrtc implementations may allow STUN/TURN server re-configuring after the offer has been created. But, does WebRTC even define a mechanism to programmatically configure the servers? If so, please add a reference. If not, please indicate that.
> 
> ---
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> From: Wish <[e-mail]> On Behalf Of Sean Turner
> Sent: keskiviikko 29. kesäkuuta 2022 17.31
> To: WISH List <[e-mail]>
> Subject: Re: [Wish] WG Last Call for draft-ietf-wish-whip
> 
> Hi! We are going to extend the WG last call period by two weeks because of the low number of reviews. Please note that you can also say that you are fine with the I-D progressing.
> 
> Cheers,
> spt
> 
> > On Jun 9, 2022, at 12:29, Sean Turner <[e-mail]> wrote:
> > 
> > This email starts the working group last call for "WebRTC-HTTP ingestion protocol", located here:
> > 
> >    https://datatracker.ietf.org/doc/draft-ietf-wish-whip/
> > 
> > Please review the I-D and send your comments to the list before 24 June 2022. You can also submit issues and pull requests via the GitHub repository that can be found at:
> > 
> >    https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9c47019017a08f6b&q=1&e=7185441c-1942-4161-8d74-02bdfa708a9b&u=https%3A%2F%2Fgithub.com%2Fwish-wg%2Fwebrtc-http-ingest-protocol
> > 
> > Thanks,
> > Nils and Sean
> > wish Chairs
> 
> -- 
> Wish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wish
> 
> -- 
> Wish mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/wish