Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03

[Colin Perkins <[e-mail]>]

On 28 May 2014, at 14:12, Romascanu, Dan (Dan) <[e-mail]> wrote:
> This is a Working Group Last Call for the Internet-Draft ‘RTP Control Protocol (RTCP) Extended Report (XR) for Post-Repair Loss Count Metrics’ - http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-03.txt.
>  
> Please send your comments to the WG mail list before 6/11 COB. If you are happy with the current I-D and support sending it to the IESG for consideration as Standards Track document please send a short mail stating  this.

I think this metric is appropriate, and the document is generally in good shape. I support publication. However, I do have some minor comments:

- The 2nd paragraph of the Introduction includes the text “When comparing this metric with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as noted in [RFC5725]: Some packets will not be repaired in current RTCP interval. Thus it is RECOMMENDED that this report block should be generated for those source packets that have no further chance of being repaired. But a potential ambiguity may result from sequence number range inconsistent. The sequence number range reported by RTCP SR/RR may contain some sequence numbers of packets for which repair might still be possible. To address this issue, we use begin sequence number and end sequence number to explicitly indicate the actual sequence number range that this RTCP XR report block reports on.” This text is entirely appropriate, and needs to be in the draft, but it doesn’t read like introductory material, since it specifies requirements. I suggest this part of the 2nd paragraph of the Introduction move into Section 3 of the draft (with the remainder of the 2nd paragraph of the Introduction staying where it is). 

- The 2nd paragraph of the Introduction concludes by stating that “metrics in this report block MUST NOT be directly compared with the pre-repair loss metric of [RFC3550]”. Can you explain why not? Surely the entire point of this metric is to directly compare the pre-repair and post-repair loss, to see how well a repair scheme is working?

- Section 2 contains a reference to [RFC2119]. The references have [KEYWORDS] but not [RFC2119].

- Section 5 contains references to [I-D.ietf-avtcore-srtp-not-mandatory] and [I-D.ietf-avtcore-rtp-security-options]. Neither appears in the References section. Both have now been published as RFCs.

Colin


-- 
Colin Perkins
http://csperkins.org/