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@xxxxxxxx> wrote: > > 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 > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
