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

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rmcat-nada-11
Reviewer: Joel Halpern
Review Date: 2019-08-05
IETF LC End Date: 2019-08-12
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as an Experimental RFC

Major issues:
   It is unclear reading this RFC how the observation information is to be communicated from the receiver to the sender.  At first I thought it was to use the RTP Receiver report.  But there is no description of how to map the fields to that report.   Then section 5.3 describes requirements for a reporting mechanism, but does not seem to actually define one.   Thus, I am left unclear how independent interoperable implementations of this draft can be created.

Minor issues:
    The document has 7 front page authors.   The shepherd writeup does not comment on this. 
    The shepherd writeup seems quite sparse.  II would have expected some reference to the experimental behavior described in the draft.

    This comment is just to confirm that I am reading the draft correctly.  It looks like when the observed delay cross the delay boundary, the reporting system reports using a smaller delay than actually approved (slightly more than 1/9th of observed delay when delay is 3*QTH).  I presume this is intentional, and that the various analysis pointed to evaluate the risks of such false reporting?

    Is it intentional in section 4.3 in the pseudo-code that the rate clipping (to keep the rate between RMIN and RMAX) is only applied to the gradual rate change, not to the accelerated rate change?  The later code says that the clipping is always applied, which is what I would expect.

Nits/editorial comments: