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

[Juliusz Chroboczek <[e-mail]>]

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