Subject: Genart last call review of draft-ietf-rmcat-sbd-10

From: Dan Romascanu <[email-masked]>
Date: Fri, 02 Mar 2018 00:37:24 -0800

Reviewer: Dan Romascanu
Review result: Almost 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

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

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

Summary:

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.