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

[Alissa Cooper <[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/