I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the Security Area
Directors.  Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.

Document: draft-ietf-wish-whip-09
Reviewer: Russ Housley
Review Date: 2023-07-29
IETF LC End Date: 2023-08-08
IESG Telechat date: Unknown

Summary: Has Issues


Major Concerns:

Section 4 says:

   The HTTP POST request will have a content type of "application/sdp"

It seems to me that this ought to be a MUST statement.  Also, what
will happen if the media type is something else?  Or, what happens if
the attempt to parse the content as an SDP fails?

Section 4.1 says:

   The initial offer by the WHIP client MAY be sent after the full ICE
   gathering is complete with the full list of ICE candidates, or it MAY
   only contain local candidates (or even an empty list of candidates)
   as per [RFC8863].

I do not understand this paragraph.  The client MAY do X OR MAY do Y.
There is no context to tell why a client might want to do either X or Y.

Section 4.2 says:

   In order to reduce the complexity of implementing WHIP in both
   clients and Media Servers, WHIP imposes the following restrictions
   regarding WebRTC usage:

However, there is no clear formatting to determine where the list of
restrictions ends.  Maybe a list of bullets would be more clear.

Section 5 says:

   *  HTTP security: Section 11 of [RFC9112], Section 17 of [RFC9110],
      etc.

The use of "etc" is not going to help an implementer.  Please be complete.

Section 5: Please reference RFC 4086 for guidance on generation of random
numbers.


Minor Concerns:

Please merge the definition in Section 2 and the overview in Section 3.
Figure 1 really is needed to understand the definitions, but the
definitions come first.

The figures are not referenced from body of the document. It is best to
include a reference in the body that offers some description of what the
reader is expected to learn from the figure. When I as a Security AD, the
other Security AD was blind. The text-to-audio system that he used was
surprisingly good, but it could not handle ASCII art. The discussion of
the figures was vital to him being able to understand a document.

The following paragraph appears twice in Section 4:

   The WHIP endpoints MUST return an "405 Method Not Allowed" response
   for any HTTP GET, HEAD or PUT requests on the endpoint URL in order
   to reserve its usage for future versions of this protocol
   specification.

Section 4.2 says:

   ... sections as per [RFC8858] i.

I do not understand this reference.

Section 4.2 says:

   This version of the specification only supports, at most, a single
   audio and video MediaStreamTrack in a single MediaStream as defined
   in [[!RFC8830]] ...

Does it ever make sense for there to be zero audio and video tracks?

I do not understand this reference.  I suspect it is malformed markdown.


Nits:

Section 4: s/non graceful/non-graceful/

Section 4: s/mime type/media type/

Section 5: s/[RFC8446], [RFC8446],/[RFC8446]/

Section 5: s/enought/enough/

Section 5: s/legit/legitimate/

Section 5: s/abalanche/avalanche/

Section 5: s/currentlyrunning/currently running/