Last Call Review of draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07
review-ietf-xrblock-rtcp-xr-post-repair-loss-count-07-genart-lc-taylor-2014-12-25-00
Request | Review of | draft-ietf-xrblock-rtcp-xr-post-repair-loss-count |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2014-12-26 | |
Requested | 2014-12-15 | |
Authors | Rachel Huang , Varun Singh | |
I-D last updated | 2014-12-25 | |
Completed reviews |
Genart Last Call review of -07
by Tom Taylor
(diff)
Secdir Last Call review of -07 by Scott G. Kelly (diff) Opsdir Last Call review of -07 by Tina Tsou (Ting ZOU) (diff) |
|
Assignment | Reviewer | Tom Taylor |
State | Completed | |
Request | Last Call review on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 07 (document currently at 11) | |
Result | Ready w/issues | |
Completed | 2014-12-25 |
review-ietf-xrblock-rtcp-xr-post-repair-loss-count-07-genart-lc-taylor-2014-12-25-00
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/