Hi, That is great, thank you for the quick reply. Best, Meral
> -----Original Message----- > From: Vincent Roca [mailto:[email protected]] > Sent: October-09-12 11:08 > To: Meral Shirazipour > Cc: Vincent Roca; [email protected]; > [email protected]; > The IESG > Subject: Re: Gen-ART Last Call review of draft-ietf-fecframe-ldpc-02 > > Hello, > > The -02 to -03 changes are the result of comments from IANA and Barry Leiba. > > Concerning Section 7.1 "Operational Recommendations", changes were > essentially motivated by recent advances with our LDPC-Staircase codec (new > figures), and a comment from Barry concerning the inappropriate use of MAY. > > Hope it clarifies. > Cheers, > > Vincent > > > > 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
