Subject: [Fecframe] AD Review: draft-ietf-fecframe-framework-07

From: "David Harrington" <[email-masked]>
Date: Wed, 23 Jun 2010 07:58:49 -0400

Hi,

I reviewed this document.
Overall it appears to be in good shape but needs some editorial
fix-ups.

I am new as your Responsible AD. Let's get off on the right foot. You
will find that your documents will get processed much faster if you at
least spell-check them and grammar check them and idnits check them
before sending them to me. 

I strongly recommend putting the definitions/abbreviations into
alphabetical order. That would make it easier for people to find a
definition if they are redaing later and want to doublecheck a
definition. Doing would have also helped prevent having the duplicate
definition of source block (bottom of page 6 and top of page 8).

FEC Source Packet defition includes (resp. receiver) and (resp.
received from); if you want to keep the parenthesized info here, at
least spell out response. Personally, I think the definition would be
easier to read without these parenthetical additions in the middle.
use a second sentence to say "A FEC Source Packet is also the payload
sent to a response receiver."

Code rate - I don't find "the k/n ratio, i.e." at all necessary. The
text following i.e., says it all. "k/n" is never used in the document
except here. If you really think mentioning k/n is important, then add
it after the rest of the text, with "This is often referred to as the
k/n ratio."

section 3 is also definitions; just include this paragraph in section
2.

you should have run a spell-checker on the document. There are quite a
few misspelled words.
See http://tools.ietf.org/tools/idspell/webservice

in section 4, "Since this is an interface internal" seems to be a
run-on sentence; it is a bit hard to parse and might benefit from a
rewrite into smaller sentecnes. Yu might try putting the example into
a separate sentence after this sentence. or you could change
s/explicitly, except to say that ADU/explicitly. ADU/

in 5.3, s/may eb/may be/
in 5.3, I'm not quite sure how to change "they may be buffered are
delivered"
should are be an or or an and?
in 6.3 "the a"
in 6.3 "of some kind" can proabbly be eliminated
s/then in applications/in applications/
s/length 2 bytes/length of 2 bytes/
s/construction source/construction. Source/

in 6.3.1, you mention wraparound from 65535 to 0, but there is no
place in the dcoument that says the range is 0 to 65535.

s/Configuation/Configuration/
in 6.5 "known as the FEC repair flow(s). - that's not what you called
them in the definitions section.

s/as describe/as decribed/
s/Defintion/Definition/

"for this flow definition (ie.e. tuple) - please be consistent in your
use of terminology. Use the terms defined in section 2.

in 6.5 s/may/MAY/

in 6.6, s/"name"_production/"name" production/
s/"value"_production/"value" production/

in 7, paragraph 2, I found the comaprisons of time versus block size
jarring. I am not sure hwo to best reword this. Maybe FEC i sgenerally
applied to data in relatively small blocks of time, and ... over
longer periods of time will likely ...

s/Applicatinos which used/Applications which use/

section 8 is so concise I have no idea what it means. This is a
framework. I can understand when a protocol supports specific
transports, but saying a framework does seems out of place. Please
expand this.

s/result link-layer/result of link-layer/

in section 9, s/this section implements/section 9.1 specifies/

in section10, s/distribute and decode data/distribute and decode
encrypted data/ 

Mark, can you get me a revised ID so I can request an IETF Last Call?

Chairs, we will need an expert for the "IETF Consensus" FEC Encoding
IDs. Can you send me recommendations in a separate email?

Thanks,
dbh