Last Call Review of draft-ietf-payload-flexible-fec-scheme-16
review-ietf-payload-flexible-fec-scheme-16-genart-lc-shirazipour-2019-02-21-00

Request Review of draft-ietf-payload-flexible-fec-scheme
Requested revision No specific revision (document currently at 20)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-02-01
Requested 2019-01-18
Authors Mo Zanaty , Varun Singh , Ali C. Begen , Giridhar Mandyam
I-D last updated 2019-02-21
Completed reviews Secdir Last Call review of -16 by Radia Perlman (diff)
Genart Last Call review of -16 by Meral Shirazipour (diff)
Tsvart Last Call review of -16 by Dr. Bernard D. Aboba (diff)
Secdir Telechat review of -17 by Radia Perlman (diff)
Assignment Reviewer Meral Shirazipour
State Completed
Request Last Call review on draft-ietf-payload-flexible-fec-scheme by General Area Review Team (Gen-ART) Assigned
Reviewed revision 16 (document currently at 20)
Result Ready w/nits
Completed 2019-02-21
review-ietf-payload-flexible-fec-scheme-16-genart-lc-shirazipour-2019-02-21-00
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-payload-flexible-fec-scheme-16

Reviewer: Meral Shirazipour
Review Date: 2019-01-31
IETF LC End Date: 2019-02-01
IESG Telechat date: NA

Summary: This draft is ready to be published as Standards Track RFC .
Major issues:

Minor issues:

Nits/editorial comments:
-Section 1.1.1 Title "One-Dimensionsal "--->"One-Dimensional"

-[Page 14] 3.2.  , "signficant"--->"significant"

-[Page 16], 4.2.1.  , "pakcets"--->"packets"

-[Page 35], 6.3.1.  , "reciever"--->"receiver"

-[Page 35], 6.3.1.1.  , "signficant"--->"significant"

-[Page 43], 7., "several Sesssion "--->"several Session "

-Section 8, "an application should avoid
   sending/receiving FEC repair streams if it knows that sending/
   receiving those FEC repair streams would not help at all in
   recovering the missing packets. It is RECOMMENDED that the amount
   and type (row, column, or both) of FEC protection is adjusted
   dynamically based on the packet loss rate and burst loss length
   observed by the applications."

How would the application know that sending/receiving those FEC repair streams
would not help at all? any rule of thumb to add here?

Best Regards,
Meral
---
Meral Shirazipour
Ericsson
Research
www.ericsson.com