Last Call Review of draft-ietf-rmcat-sbd-10

Request Review of draft-ietf-rmcat-sbd
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-03-16
Requested 2018-02-16
Authors David Hayes, Simone Ferlin, Michael Welzl, Kristian Hiorth
Draft last updated 2018-03-02
Completed reviews Secdir Telechat review of -10 by Watson Ladd (diff)
Genart Last Call review of -10 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-rmcat-sbd-10-genart-lc-romascanu-2018-03-02
Reviewed rev. 10 (document currently at 11)
Review result Almost Ready
Review completed: 2018-03-02


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-rmcat-sbd-10
Reviewer: Dan Romascanu
Review Date: 2018-03-01
IETF LC End Date: 2018-03-16
IESG Telechat date: 2018-04-05


Almost Ready

This is an interesting and well-written document. The method described in the document have a proposed status of Experimental that seems appropriate, and I liked the fact that the expected feedback from the experiments is mentioned in Section 6. I believe that the document is almost ready for publication from the Gen-ART perspective, but lacks reference and relation to existing work in the IETF related to the definitions and measurement methods for metrics like packet loss or one-way delay. Adding this information would make clear what is currently missing and why this work is needed. 

Major issues:

1. The document does not refer or relate to existing work in the IETF. Metrics like packet loss or one-way-delay have been defined in IETF WGs like IPPM and dealt with in real-time applications context by XRBLOCK. For example Packet Loss is defined by  RFC 2680, OWD by RFC 7679. Are these applicable? What is missing and why new work is necessary? I assume that there are good answers to these questions, but these are not included in the document. 

Minor issues:

1. It would be useful to explain what the authors mean in this document by 'signal' as the usage of the term is different than in other context. For example in section 1.2, or more specifically in section 1.2.1 where a sentence like 'Packet loss is often a relatively rare signal.' is hard to understand without such context explanation. 

Nits/editorial comments: 

1. Several acronyms are not expanded at first occurrence - for example, but not limited to: RTP, ECN, etc.