Hello Christer, Thanks a lot for the review. > Le 14 sept. 2018 à 18:26, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> 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
