Re: [Gen-art] Gen-art review of draft-ietf-rmt-bb-fec-basic-schemes-revised-05

[Mark Watson <[e-mail]>]

Elwyn, all,

Please accept my apologies for the excessive delay in addressing these
comments. My plan for addressing these in the -06 draft is below.

Regards,

Mark


On 7/18/08 8:57 AM, "Elwyn Davies" <[e-mail]> wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> _http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> 
> Document: draft-ietf-rmt-bb-fec-basic-schemes-revised-05.txt
> Reviewer: Elwyn Davies
> Review Date: 18 July 2008
> IETF LC End Date: 29 July 2008
> IESG Telechat date: n/a
> 
> Summary:
> Nearly ready for IESG.  A few minor issues mainly with failure to
> specify encodings and a couple of corner cases. A few editorial nits
> noted below.
> 
> Comments:
> 
> s3.2.1: Need to explicitly document the encoding used for SBNs (also
> applies to s4.2.1 and s5.2.1. s5.2.1 also needs to specify encoding for
> Source Block Length).

- Add a clarifying sentence in the introduction that all integer fields are
in network byte order.
- In the individual sections, specify that the fields are 'x-bit unsigned
integers' with suitable values of x.

> s3.2.1, bottom of page 6/top of page 7: s/is processed at/to process the
> block by/ (two places) (or some such .. it doesn't read well at present).

New sentence: "The transport time of a source block includes the amount of
time needed to process the source block at the sender transport layer, the
network transit time for packets, and the amount of time needed to process
the source block at the receiver transport."

> s3.2.2.2: need to explicitly state encoding of various values (unsigned
> integers I assume). (also applies to s4.2.2.2, s4.2.2.3, s5.2.2.2

Ok. I will add a paragraph under each figure.

> s4.2.2.3:  The case where the length is zero is a lttle odd!  I think it
> would be worth explicitly stating that (either) the whole object is just
> one octet long (or) it is four octets padded with zeroes.  The latter
> case might make processing more consistent since otherwise the zero case
> is special and the only case where the object is not four octet aligned.

Ok - I believe there are no users of this field at present so it is safe to
include the padding for four-octet alignment.

> s5.1:  it is not possible to encode the source block length of 65536 in
> 16 bits unless 0 is overloaded to mean 2^^16.  This isn't specified. (I
> assume 'at most' to be read as 'less than or equal').
> 

The maximum size should be 65535.

> Editorial:
> 
> Abstract:  Need to expand FEC at least once!
> s1, 2nd para after bullets: genrally not recommended to mention WG
> s1, last para: s/listed/are listed/
> s3.2.1: Need to asociate Source Block Number and SBN explicitly (well, I
> assume that is what SBN means!).
> s3.4.1, next to last para: s/implementor of/implementor/
> s3.4.2, lastpara: s/substracting/subtracting/
> s4.4.2.2: I take the reference in the last para of the section (just
> above Fig 4) should be to s3.2.2.2.

Actually it should be to the figure.

> s10, 2nd bullet: s/th/the/
> s10, 3rd bullet: s/sis/did/
> 


_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art