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

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

Hi Murray,

Any feedback on this? How should we proceed?

Best regards
Sergio

On Thu, May 11, 2023 at 10:50 AM Sergio Garcia Murillo <
[e-mail]> wrote:

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