[Gen-art] Genart last call review of draft-ietf-core-target-attr-05

[Peter Yee via Datatracker]

Reviewer: Peter Yee
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-core-target-attr-05
Reviewer: Peter Yee
Review Date: 2023-08-08
IETF LC End Date: 2023-08-06
IESG Telechat date: Not scheduled for a telechat

Summary: This specification adds an IANA registry for coordinating Web Link
target attribute names, which was previously lacking. I found no problems with
this simple specification and deem it ready from my naive perspective. [Ready]

Major issues: None

Minor issues: None

Nits/editorial comments: None


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-wish-whip-09

[Dale Worley via Datatracker]

Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document:  draft-ietf-wish-whip-09
Reviewer:  Dale R. Worley
Review Date:  2023-08-08
IETF LC End Date:  2023-08-08
IESG Telechat date:  [not known]

Summary:

This draft is on the right track but has open issues, described in
the review.

The exposition could be clarified in several places.  A few of the
clarifications could be considered technical issues.  I list the
issues in textual order, with an initial summary of the most important
issues.

* Summary of the major issue:

A very important aspect of this document is that it defines the usage
of "ICE via SDP via HTTP", equivalently, "supporting ICE offer/answer
over HTTP" (as opposed to the original "ICE via SDP via SIP").  That
definition likely will have broader usage than just WHIP.  But the
document suffers from the "expert's disease", in that the authors
clearly have deep knowledge of ICE and consequently only document the
details of the ICE processing without providing any of the framework.
This leaves naive readers to reconstruct the big picture.  I was going
to add "As far as I can tell, all of the needed details are listed
somewhere in section 4", but as you can see below, once I wrote an
outline of what is needed, there are a few points that don't seem to
be specified, at least not to the point that I recognized it.)

I suggest that section 4 be organized by:

- stating that it is defining "supporting ICE offer/answer
  over HTTP" (so that it can be clearly referenced by later
  specifications)

- specifying the abstract operations involved (with the mapping to
  specific operations listed either in this list or a later list):

- - starting the ICE negotiation (via POST carrying
application/sdp)

- - updating the ICE when trickling (via PATCH carrying
application/trickle-ice-sdpfrag)

- - restarting ICE (via PATCH carrying (via PATCH carrying
application/trickle-ice-sdpfrag, but it's not clear how this is
distinguished, RFC 8840 does not specify it; perhaps because it
carries ice-ufrag/ice-pwd attributes (see section 4.1)?)

- - termination (via DELETE from the client; not clear how from the
server)

- specifying how WHIP constrains the ICE abstraction (Media server
  MUST not do trickle ICE updates, not clear if Media server MAY do
  ICE restarts, Media server MAY not support trickle ICE or ICE
  restart, etc.)

- discussion of how out-of-order requests may arise (which isn't at
  all clear to me, as requests seem to be generated only by the
  server, and carried by TCP, so they seem to be inherently
  serialized)

- discussion of how ETags MAY/MUST be handled, as that is
  comprehensible only when one looks at the serialization needs of all
  of the operations together

- specifying the particular features of each of the operations,
  including any particulars of request and response fields and what
  response codes are to be used for what error situations

* Summary of minor issues that might have technical content:

At various points in section 4 the text refers to a device sending a
request or generating a response but in many of them, the text doesn't
state whether the device is on the client or server end, or might be
both.  I assume that the nature of the operation implies what devices
might perform it based on text elsewhere, but it's hard to fully
understand on the first reading pass.  If possible, each sentence
should make this clear. -- Then again, if section 4 is reorganized to
describe generic ICE/SDP/HTTP usage, attention should be paid that the
generic usage may define how e.g. the server does an operation, even
if WHIP servers may not do that operation.

Section 4 lists a collection of 4xx and 5xx response codes to be used
in certain situations.  Are these set due to the specific semantics of
the codes or just to ensure that the recipient can tell what the cause
of the error was?  (HTTP suffers from having a large number of error
responses but all of them have vague semantics.  Unfortunately, there
doesn't seem to be an HTTP response header that can carry codes
defined for ICE usage specifically.)

Section 4 requires the WHIP server to reject certain specific request
methods, but no others.  Verify that you intend this specific
limitation.

Section 4.1 references sections 6.6.2, 2.3, and 3.1 of RFC 9110.  All
of these references appear to be incorrect, in that those sections do
not discuss the topics at hand.  Section 4.3 references section 6.4.7
of RFC 9110, which does not exist.  Some of these appear to be
referencing sections in RFC 7231, which is obsoleted by RFC 9110.

Section 4.1 talks about out-of-order PATCH