Subject: Gen-art review of draft-ietf-rmt-bb-norm-revised-04.txt

From: Elwyn Davies <[email-masked]>
Date: Tue, 15 Apr 2008 13:50:02 +0100

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-norm-revised-04.txt
Reviewer: Elwyn Davies
Review Date:  15 April 2008
IETF LC End Date: 17 April 2008
IESG Telechat date: (if known)

Summary:
A well-written document covering some pretty complex ideas.  Technically 
ready for the IESG but a little up front explanation for the naive 
reader would help as noted below.  Referring to the RFC 3269 guidelines, 
the document seems to have covered all the (relevant) bases.  There 
might be a question mark about the suggested congestion control 
mechanisms since they are pre-standard (at best). There are also a few 
editorial nits.

[Aside: The phrase 'the creation of an "early NACK" slot for these 
historical NACKers' raised a chuckle here! Non-British readers may not 
appreciate this.]

Comments:

s1. A little more explanation of just what a NACK based protocol does 
would be helpful, together with a note on 'timer-based NACK-suppression' 
and the idea of 'repairs'  and 'repair transmission'.

s2.4: 'NACK implosion problems' - this may require a little explanation.

s2.5: 'probabilistic timer-based NACK suppression' is just a piece of 
jargon at this stage in the document as it stands. See comment on s1.  
One thought I had was to move s2 after s3, but s3 is so large that this 
may not be appropriate.

s3.2.3.1, para 1: s/affect/effect/, s/provided/providing/

s3.9: Without casting aspersions on the competence of the papers 
referenced as [TfmccPaper] and [PGMCC], the assertion that the solutions 
described in two academic papers can meet the requirements for 
congestion control might seem a little cavalier or premature

s3.11:  Since this covers one of the prime requirements of RFC 3269, it 
might sit better as a top level section even though it is short.

Editorial:
(idnits does not report any issues).

Abstract: s/negative- acknowledgment/negative-acknowledgment/

s3.1: s/theFEC/the FEC/

s3.2.1, para 2: 'to initiate the NACK processor': s/processor/processing/?

s3.2.1, para 3: 'For probabilistic, timer-base suppression':  s/base/based/

s3.2.2, bullet 1.: Define what sort of logarithm is meant by 'ln' - and 
later define 'exp()'

s3.2.2, bullet 2.: The page break between page 15 and 16 is particularly 
infelicitous!

s3.2.2: The relationship between the parameters of the C routine and the 
variables defined on the body of the text is not absolutely clear.

s3.2.2, at top of page 16: 'Alternate values may be used to for buffer 
utilization, reliable delivery latency and group size scalability 
tradeoffs':
 s/to for/for/ probably

s3.7, para 1: 'only the sender require RTT knowledge' either s/sender 
require/sender requires/ or s//senders require/

s3.7.4, last para: s/therange/the range/

s4, end of para 3: s/if this acceptable/if this is acceptable/

_______________________________________________
IETF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf