Hi Tom, Thank you for the nice Gen-ART review. Please see my replies inline starting with "[Rachel]".
BR, Rachel > -----Original Message----- > From: Tom Taylor [mailto:[email protected]] > Sent: Thursday, December 25, 2014 10:42 AM > To: Gen Art; > draft-ietf-xrblock-rtcp-xr-post-repair-loss-count....@tools.ietf.org; > [email protected]; [email protected]; Dan Romascanu > Subject: Last Call Review: > draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07 > > 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". [Rachel]: This report block introduces two metrics : "unrepaired loss count" which is specified as the total number of packets finally lost after applying loss-repair methods. And "repaired loss count" is specified as the total number of packets which are fully repaired after applying loss-repair methods. And in this sentence, I meant "repaired loss count" because this metric is used to help calculating pre-repair loss count (pre-repair loss count = unrepaired loss count + repaired loss count). Maybe the name of "unrepaired loss count" is confusing. Would it better changing to "post-repair 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." > [Rachel]: Right. Will fix it in the new version. > 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. [Rachel]: I agree with you that these two should be informative. > > 4) Appendix A: The "Units of Measurement" are packets. [Rachel]: According to RFC6390, Section 5.4.5, there's an example to show how to define a metric. Here's how it defines the "Units of Measurement": " Units of Measurement: This metric is expressed as a fixed-point number with the binary point at the left edge of the field. For example, a metric value of 12 means a loss rate of approximately 5%. " I consulted it to specify mine. > > > 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. [Rachel]: Okay. All the above nits will be fixed. > > 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. [Rachel]: Good suggestion. > > 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 ...". [Rachel]: Okay. So you're suggesting to break the big paragraph into 3 small ones, right? > > 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 [Rachel]: Okay. Will do. > bit positions are given in octal -- the first time I've seen that in a > document, but > it's OK with me. [Rachel]: This draft is just an RTCP XR extension to augment the report blocks defined in RFC3611. So the format is just in a manner consistent with other RTCP XR packets. All the RFCs produced in XRBLOCK wg specifying new report blocks have the same pattern. That's why I think it doesn't need to be clarified in this draft. > > 5) Section 5, third line: s/confidentially/confidentiality/ [Rachel]: Okay. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
