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

[Sergio Garcia Murillo <[e-mail]>]

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
>