Skip to main content

Last Call Review of draft-ietf-avtcore-cc-feedback-message-08
review-ietf-avtcore-cc-feedback-message-08-tsvart-lc-scharf-2020-09-09-00

Request Review of draft-ietf-avtcore-cc-feedback-message
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2020-09-16
Requested 2020-09-02
Authors Zaheduzzaman Sarker , Colin Perkins , Varun Singh , Michael A. Ramalho
I-D last updated 2020-09-09
Completed reviews Secdir Last Call review of -08 by Linda Dunbar (diff)
Genart Last Call review of -08 by Paul Kyzivat (diff)
Tsvart Last Call review of -08 by Michael Scharf (diff)
Assignment Reviewer Michael Scharf
State Completed
Request Last Call review on draft-ietf-avtcore-cc-feedback-message by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/QxQkHh-7D2IqZJRPBHUS3phazqs
Reviewed revision 08 (document currently at 09)
Result Ready w/issues
Completed 2020-09-09
review-ietf-avtcore-cc-feedback-message-08-tsvart-lc-scharf-2020-09-09-00
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Major issues
-------------

None

Minor issues
-------------

1/ Section 5:

   All RTP congestion control algorithms MUST specify how they
   respond to the loss of feedback packets.

This is a process-related requirement not relevant for interoperability of
implementations. In addition, the requirement is not very specific (What would
have to be specified?). I am not sure if such a requirement in capital letters
is really needed here. This should be handled consistently in all IETF
documents.

2/ Section 11:

The Security Considerations do not discuss off-path attacks, and it is not
clear why this case is missing. Can an off-path attacker trick the sender into
sending at either an excessively high or excessively low rate?

Nits
----

1/ Abstract:

The protocol extension enables fine-grained feedback on per-packet reception
quality. The rationale is provided in Section 1 and (more comprehensively) in
Section 8. Yet, I wonder if this objective could also be made a bit more
explicit in the abstract, e.g., along the lines of the "fine-grained feedback"
wording in the first paragraph of Section 8.

2/ Section 7:

Typo in "a=ecn-capaable-rtp:"