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

["Murray S. Kucherawy" <[e-mail]>]

Sorry I missed this earlier.

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

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

OK, I think you might consider adding text to this effect.  If you're going
to make it a normative almost-requirement, it's good to explain to
implementers why, and/or what happens if they don't.


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

I think the suggestion I made would suffice: At a minimum, be explicit that
you're importing the security consideration of the layer below.  Adding
some text about the security issue you just identified would also be
helpful.


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

Let me ask a couple of people and get back to you.

-MSK