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

Hi Juliusz,

I have opened one issue for each of your comments on the github issue
tracker. Let's continue the discussion there.

https://github.com/wish-wg/webrtc-http-ingest-protocol/issues

Best regards
Sergio

On Wed, Jun 29, 2022 at 10:34 PM Juliusz Chroboczek <jch@irif.fr> wrote:

> > Hi! We are going to extend the WG last call period by two weeks because
> > of the low number of reviews.
>
> I support advancing the draft.  I have some minor editorial nits, and one
> objection (see Section 4.5), which you will find below.
>
> # Abstract
>
> The abstract doesn't read like an abstract, it's more like an
> introduction.  While it contains interesting material, I think most of the
> discourse should be moved into the introduction and the abstract rewritten.
>
> # Introduction
>
> SDI is mentioned without being either expanded or introduced.  I suggest
> simply removing the mention, the nature of the cable is irrelevant here.
>
> "It is the adoption..."  I think there's something wrong with the syntax
> of this sentence.
>
> # 4. Protocol operation
>
> I feel there's some normative language missing here.  For example, is the
> use of ICE consent freshness a MUST?  (I assume it is.)
>
> # 4.1 ICE and NAT support
>
> Is it legal for a server to support Trickle ICE but not ICE Restarts?  If
> that's the case, then the use of 405 is somewhat misleading, since the
> PATCH method is allowed, just not for ICE Restarts.
>
> > Entity-tag validation MUST only be used for
>
> I think this should be "must", not "MUST".
>
> # 4.3 Load balancing
>
> "WHIP endpoints and media servers may not be colocated..."  I suggest
> "might" instead of "may".
>
> "WHIP clients SHALL support HTTP redirection via the 307 Temporary
> Redirect response code..."  This is too specific -- clients should obey
> any redirect code.
>
> # 4.4 TURN/STUN
>
> "the WHIP endpoint MAY also include the ICE server configuration on the
> responses to an authenticated OPTIONS..."  Two nits here:
>
>   (i)  what if the WHIP resource does not require auth?
>
>   (ii) why is this optional?  It would seem to me that it's perfectly
>        trivial to implement.
>
> # 4.5 Authorization
>
> "In case the WHIP client is not configured to use a bearer token the HTTP
> Authorization header must not be sent in any request."  This would seem to
> say that HTTP Basic is not allowed, and neither any future auth mechanisms
> that would use the Authorzation header.  I feel this is an arbitrary
> prohibition, and one that I disagree with.
>
> # 4.6 Simulcast
>
> Simulcast, K-SVC: I think these need references.  I, for one, have no
> idea what is "K-SVC".
>
>
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>