[xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10: (with DISCUSS and COMMENT)

["Benoit Claise" <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The following MUST versus RECOMMENDED is still an issue

  post-repair loss count: 16 bits

      Total number of packets finally lost after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      This metric MUST NOT count the lost packets for which repair might
      still be possible. 

This goes against

2. Interval report

   Some implementations may align the begin_seq and end_seq number with
   the highest sequence numbers of consecutive RTCP RRs (RTCP interval).
   This is NOT RECOMMENDED as packets that are not yet repaired in this
   current RTCP interval and may repaired in the future will not be
   reported in subsequent reports.


I understand the explanations you provided in the past. The only logical
solution is to change the "MUST NOT" with "NOT RECOMMENDED"


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



Thanks, the draft improved.
However, There are still sentences that I had to read multiple times, to
"get" them. I believe that I have spent enough time on this draft by now.
So will not comment on those.

-

   in 6 still to be repaired lost packet = cumulative number of packets
   lost - cumulative post-repair loss count -  cumulative repaired loss
   count

"in 6"?

- Why doesn't this section 3 mention "repaired loss count"?