Hi, Thank you for the changes and v04. I also assume the changes v02->v03 in Section 7.1's examples were based on LC reviews.
Best Regards, Meral --- Meral Shirazipour Ericsson Research www.ericsson.com > -----Original Message----- > From: Vincent Roca [mailto:[email protected]] > Sent: October-09-12 09:23 > To: Meral Shirazipour; The IESG > Cc: [email protected]; [email protected] > Subject: Re: Gen-ART Last Call review of draft-ietf-fecframe-ldpc-02 > > Hello Meral, > > Thanks a lot for your review. Please, find our answers below. > > > Document: draft-ietf-fecframe-ldpc-02 > > Reviewer: Meral Shirazipour > > Review Date: 2012-10-01 > > IETF LC End Date: 2012-10-01 > > IESG Telechat date: NA > > > > > > Summary: > > This draft is almost ready for publication as a standard track RFC, but I > > have > some comments. > > > > Nits/editorial comments: > > [Page 3], Section 1, "ALC [RFC5775]", please spell out ALC: "Asynchronous > Layered Coding (ALC)" > > Done. > > > > [Page 3], Section 1, "NORM [RFC5740]", please spell out NORM: "NACK- > Oriented Reliable Multicast (NORM)" > > Done. > > > > [Page 4], line 3, ALU is first used, please spell out: "Application Data > > Unit > (ADU)", or move section "3.3 Abbreviations" to the beginning. > > Done. > > > > [Page 4], Section "3.1. Definitions", after the ":" for all definitions, > > please > start with capital letters or with lower case (for consistency please choose > one) > > Right, this is not consistent. Moved everything to lower case letters. > > > > [Page 5], for "ADU Block", it would clearer to have Flow ID, Length and > Padding fields in parenthesis next to F[], L[], and Pad[] respectively. > > Done. > I also realized we were using the term FID[i] twice to denote the F[i] field > in > section 4.3 "Source block creation". > We corrected to use F[] throughout the document. > > NEW: > ADU Block: a set of ADUs that are considered together by the > FECFRAME instance for the purpose of the FEC scheme. Along with > the flow ID (F[]), length (L[]), and padding (Pad[]) fields, they > form the set of source symbols over which FEC encoding will be > performed. > > > [Page 5], after "FEC Framework Configuration Information" please add > "(FFCI)". > > Done. > > > > [Page 5], section 4.1, "G MUST be equal..", please define G in section "3.2. > Notations". > > Added. > > > > [Page 9], last sentence, "Each ADUI contributes to exactly one source symbol > to the source block.", it is clearer to say "...of the source block." > > Done > > > > [Page 15], Section 6.1.1, "(e.g., before versus after FEC protection, and > > within > the end-system versus in a middlebox)", please rephrase if possible, this is > not > very clear. > > Done. > > NEW: > > (e.g., is encryption applied before or after FEC protection, within the > end- > system or in a middlebox) > > > > [Page 19], reference [SIMPLE_RS] is now at version 03. > > Now in version -04. Updated. > > > > [Page 19], reference [RFC5053]: title is missing "for Object Delivery" > > Exact! Fixed. > > > > -Overall for clarity, please adapt one method for spelling out acronyms > (either in one section in intro, or throughout the text as they are first > used; but > not both). > > I think it's homogeneous now. > > > > -Overall for clarity, some line feed would be useful in section 5. > > I've added the <?rfc rfcedstyle="yes"?> magic directive, and now lists are > much > more readable. > I've also changed the style of lists for "symbols", and it also helps making > it > more readable. > > > > > Best Regards, > > Meral > > > > --- > > Meral Shirazipour > > Ericsson Research > > www.ericsson.com > > > > -- > > Cheers, > > Vincent, on behalf of the authors _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
