ietf
[Top] [All Lists]

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

2008-11-03 12:41:15
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" <elwynd(_at_)googlemail(_dot_)com> 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/



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Gen-art review of draft-ietf-rmt-bb-fec-basic-schemes-revised-05, Mark Watson <=