Re: [xrblock] [Gen-art] Last Call Review: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-07

[Jari Arkko <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art