Elwyn, Pekka, et al, FYI, I have finally posted an updated version of the NACK-Based Reliable Multicast Building Blocks document: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-norm-revised-05.txt This update addresses the comments you raised including removal of references to "Router Assistance" discussion, updates to the Security Considerations and references using the suggestions of George Gross and others, various areas requiring clarification as pointed out and all of the comments that Elwyn raise below. best regards, Brian Adamson At 1:50 PM +0100 4/15/08, Elwyn Davies 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-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/ -- Brian __________________________________ Brian Adamson <mailto:adamson@xxxxxxxxxxxxxxxx> _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf