[xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06

["Alissa Cooper (alcoop)" <[e-mail]>]

I have reviewed this draft in preparation for IETF LC and I have some comments and questions before proceeding with the LC announcement.

= Section 3 =
"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.”

The analogous text in RFC 5725 specifies both the recommended behavior and the behavior that is not recommended:

"To avoid any ambiguity in the evaluation, it is RECOMMENDED that the post-repair
   Loss RLE be generated for the source packets that have no further
   chance of being repaired.  If the loss-repair method(s) may still
   recover one or more missing source packets, the post-repair Loss RLE
   SHOULD NOT be sent until the loss-recovery process has been
   completed.”

It seems like this document should also specify what is not recommended, otherwise it seems a little vague. Another approach could be to say "Thus it is RECOMMENDED that this report block should be generated only for those source packets that have no further chance of being repaired and not for any other packets."

"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 as
   the measurement timing.”

I don’t really understand what the stated ambiguity is here, or how it is addressed by including begin_seq and end_seq. As long as the “unrepaired loss count” field is defined as number of packets lost for which repair is no longer possible, what is inconsistent or ambiguous, and how does specifying the sequence number range change anything?

"Note that this metric must be measured in the primary source RTP packets.”

I’m not sure what this means.

= Appendix A =
Doesn’t it sort of defeat the purpose of the 6390 template to fill out a template with a bunch of links back to the definitions of the fields in other parts of the document, rather than putting those definitions directly in the template? I mean, isn’t the point of the template to have all of the information concisely reported in one place?


== Nits to be resolved with any IETF LC comments ==

= Section 1 =
RTCP SR/RR — expand SR/RR on first use

s/cumulative number of packet lost/cumulative number of packets lost/

s/a range of RTP application/a range of RTP applications/

OLD
The metrics defined in this document belongs to the class of
   transport-related metrics defined in [RFC6792]. And it is in
   accordance with the guidelines in [RFC6390] and [RFC6792].

NEW
The metrics defined in this document belong to the class of
   transport-related metrics defined in [RFC6792] and are specified in 
   accordance with the guidelines in [RFC6390] and [RFC6792].

= Section 3 =
s/in current RTCP interval/in the current RTCP interval/

= Section 4.2 =
s/for unilateral parameter/for unilateral parameters/