Re: [Gen-art] Genart last call review of draft-ietf-tsvwg-fecframe-ext-04

Christer, thanks for your review. Vincent, thanks for your response. I entered a No Objection ballot.

Alissa

> On Sep 19, 2018, at 8:30 AM, Vincent Roca <vincent.roca@inria.fr> wrote:
> 
> Hello Christer,
> 
> Thanks a lot for the review.
> 
>> Le 14 sept. 2018 à 18:26, Christer Holmberg <christer.holmberg@ericsson.com> a écrit :
>> 
>> 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?
> 
> 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;
> 
> 
> 
>> 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.
> 
> Agreed. Update is the right term.
> 
> 
>> 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.
> 
> Done.
> 
> Cheers,
> 
>   Vincent
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art