Subject: Genart last call review of draft-ietf-tsvwg-fecframe-ext-04

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Sep 2018 09:26:07 -0700

Reviewer: Christer Holmberg
Review result: Ready with Nits

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-tsvwg-fecframe-ext-04
Reviewer: Christer Holmberg
Review Date: 2018-09-14
IETF LC End Date: 2018-09-24
IESG Telechat date: Not scheduled for a telechat

Summary: The document is well written, but there is an issue regarding backward
compatibility that I want the authors to address.

Major issues:

Q1_MAJ:

Regarding backward compatibility, it's difficult for me to parse the second
bullet in Section 1.

The text seems to assume that SDP, and RFC 6364, are used to negotiate FEC.
But, RFC 6364 is only an informative reference, and I assume FEC does not even
mandate SDP?

Is there a generic requirement that the endpoints must negotiate the usage of
this mechanism before it is used? Or, can the mechanism be used towards an
endpoint that does not support it?

Minor issues:

N/A

Nits/editorial comments:

Q2_ED.

The document uses "extends RFC 6363" terminology in a couple of places. I
suggest to use "updates" instead.

Q3_ED.

Section 1 says:

     'This document is fully backward compatible with [RFC6363] that it extends
     but does not replace."

I don't think you need the "extends but does not replace" part.

---

From: Vincent Roca <[email-masked]>
Date: Wed, 19 Sep 2018 14:30:09 +0200

Hello Christer,

Thanks a lot for the review.

> Le 14 sept. 2018 à 18:26, Christer Holmberg <[email-masked]> a écrit :
> 

You’re right, the use of SDP is not mandatory, I’ve used a shortcut that may be
wrong in some environments. In fact the only application I have in mind, 3GPP MBMS,
relies on SDP to carry the so-called « FEC Framework Configuration Information » that
includes the FEC Scheme identifier, hence the mistake.
Also, this is not, strictly speaking, a negotiation since there is usually no feedback.
The sender uses one or more FEC Scheme(s), the receiver chooses to join or not
(hopefully there will be a repair flow it can process).

OLD:
   o  any receiver, for instance a legacy receiver that only supports
      block FEC schemes, can easily identify the FEC Scheme used in a
      FECFRAME session thanks to the associated SDP file and its FEC
      Encoding ID information (i.e., the "encoding-id=" parameter of a
      "fec-repair-flow" attribute, [RFC6364]).  This mechanism is not
      specific to this extension but is the basic approach for a
      FECFRAME receiver to determine whether or not it supports the FEC
      Scheme used in a given FECFRAME session;

NEW:
   o  any receiver, for instance a legacy receiver that only supports
      block FEC schemes, can easily identify the FEC Scheme used in a
      FECFRAME session.  This is made possible with the FEC Encoding ID
      that identifies the FEC Scheme used and which is carried in the
      FEC Framework Configuration Information (see section 5.5 of
      [RFC6363]).  For instance, when the Session Description Protocol
      (SDP) is used to carry the FEC Framework Configuration
      Information, the FEC Encoding ID can be communicated in the
      "encoding-id=" parameter of a "fec-repair-flow" attribute
      [RFC6364].  This mechanism is the basic approach for a FECFRAME
      receiver to determine whether or not it supports the FEC Scheme
      used in a given FECFRAME session;

> suggest to use "updates" instead.

Agreed. Update is the right term.

> I don't think you need the "extends but does not replace" part.

Done.

Cheers,

   Vincent