Re: [Wish] Publication has been requested for draft-ietf-wish-whip-08

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

Hi Murray,

Thank you very much for your review, comments inline below

On Thu, May 4, 2023 at 7:17 AM Murray S. Kucherawy <[e-mail]>
wrote:

>
> * Near the end of Section 4.1, there's an "ice" that should be "ICE".
>

Good catch! changed here:
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/9d6efda0beedd56220c4dff20ff2dc38de100e8f


> * There are lots of SHOULDs that could benefit from some explanation of
> when one might not do what the SHOULD says (or do what the SHOULD NOT
> says).  Since you're giving implementers a choice here, some advice about
> that choice would be good to include.  Or maybe some of these SHOULDs
> really ought to be MUSTs?  Same goes for RECOMMENDED.  For instance in
> Section 4, you have "The SDP offer SHOULD use the "sendonly" attribute.
> Why?  Or why would I not?  What if I don't?
>

In WHIP we are reusing the WebRTC/SDP/RTP specifications, and defining how
those specs are used to establish a streaming session. As SDP O/A is a
negotiation between the client and the server, there are some options that
while there are not the correct ones according to our intended usage (like
sending "sendonly" as direction on the SDP offer), they are not "illegal"
in the WebRTC/SDP specs. For example, if you build a WHIP client on a
browser, the default direction on the offer will be "sndrcv", and the
server should be ready to accept it. The MUST is on the server side that
has to answer with a "recvonly" direction always. So in this particular
case, the direction sent by the client is a bit irrelevant, but the proper
value semantically is "sendonly", that's why it is a SHOULD and not a MUST.


> * This is a pretty thin Security Considerations section.  Is that really
> all there is?  Shouldn't we at least say something like "As this protocol
> is built entirely atop SDP and (things), the security considerations of
> those protocols apply here as well."?  It's pretty unusual to claim
> (expressly or by omission) that a new protocol has absolutely no security
> concerns.
>

Definitely the section would require a rewrite, however the intent would be
the same. We are "just" specifying the usage of well known protocols
(webrtc, SDP, https,.. ) so we are not introducing any new attack surface
that was not already covered in those. The only point that could be new to
this protocol is explaining the security of the rest api calls with the
bearer token, any suggestion on how this could be rewritten?


> * In Section 6.4.1, there's no longer an "Applications Area Director".
> Suggest the following:
>
> Decisions made by the designated expert can be appealed to an Applications
> and Real Time (ART) Area Director, then to the IESG. The normal appeals
> procedure described in BCP 9 is to be followed
>

Thank you very much, applying it here:
https://github.com/wish-wg/webrtc-http-ingest-protocol/commit/e1bd984aa5793ede13859fd36fd74d2791b8b34e


> * Sections 6.3 and 6.4 confuse me, though this is possibly just my
> inexperience with URN namespaces talking.  It looks like you're creating a
> registry for IANA to manage, but doing it completely outside of the pattern
> RFC 8126 describes.  Given the reference to RFC 3553, I'm guessing this is
> somewhat normal, though I wonder why RFC 2434 wasn't used.  Is that all
> correct?
>

I don't have much knowledge about the urn ietf namespace, but the ones on
the RFC 2434 don't seem appropriate to me and the only one that seems to be
active at IANA are the "urn:ietf:params:" namespaces specified in rfc3553:
https://www.iana.org/assignments/params/params.xhtml#urn-subnamespaces

I used the SCIM registry as an example when writing the WHIP registry , but
it is also used by the rtp header extension registry. Is there anyone that
we could ask to confirm if this is ok?

Best regards
Sergio