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
