![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
No worries on the delay... you should see some of mine ;-) /Elwyn Mark Watson wrote:
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.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.2Ok. 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 Gen-art at ietf.org https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Ietf mailing list Ietf at ietf.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.