Thanks for your review Tom (and on Dec 25, of all days!) Rachel et al - thanks for the responses and edits. Are we happy now, and are all the necessary changes in the new -08 version?
Jari On 25 Dec 2014, at 04:41, Tom Taylor <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 > Reviewer: Tom Taylor > Review Date: 2014-12-24 > IETF LC End Date: 2014-12-26 > IESG Telechat date: 2015-01-08 > > Summary: This document is mostly to publish as a Proposed Standard, with > minor issues verging on editorial corrections. > > Major issues: None. > > Minor issues: > > 1) Second paragraph of Introduction: last sentence introduces the "repaired > loss count". I found this confusing. Figure 1 shows you really meant > "unrepaired loss count". > > 2) First paragraph of Section 3, third sentence: the ending currently reads: > "Some packets will not be repaired in the current > RTCP interval." > I think your point is that some of these could be repaired later, so I > suggest the text should be extended: > "Some packets will not be repaired in the current > RTCP interval, but could be repaired later." > > 3) I question whether RFCs 4588 and 5109 are normative for this document, but > I know this sort of thing is a difficult decision and I'll accept whatever > the final outcome is. > > 4) Appendix A: The "Units of Measurement" are packets. > > > Nits/editorial comments: > > 1) First paragraph of introduction: > s/contains/contain/ at end of first line. > > Fourth sentence: > > OLD > > However, this metric is measured on media stream before > any loss repair mechanism, e.g., retransmission [RFC4588] and Forward > Error Correction (FEC) [RFC5109], is applied. > > NEW > > However, this metric is measured on the media stream before > ^^^ > any loss repair mechanism, e.g., retransmission [RFC4588] or Forward > ^^ > Error Correction (FEC) [RFC5109], is applied. > > I would break this paragraph into three parts. The first three sentences > introduce the existing metric. The next two sentences, from "However, ..." to > "... [RFC3550].", introduce the problem. The following two sentences, from > "Consequently ..." through "... higher overhead.", give an attempted > solution. The final sentence, I think, is the motivator for this document and > I would merge it into the next paragraph. > > 2) First paragrpah of Section 3: again, I suggest it be broken into three > parts. The second part would begin with "Thus it is RECOMMENDED ...", and the > third with "The sequence number range ...". > > 3) The sentence preceding Figure 1 should identify "Figure 1" explicitly (via > XML2RFC cross-reference if that is what you are using). It should also note > that bit positions are given in octal -- the first time I've seen that in a > document, but it's OK with me. > > 5) Section 5, third line: s/confidentially/confidentiality/ > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
