Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'

[Colin Perkins <[e-mail]>]

On 13 Aug 2015, at 13:41, Romascanu, Dan (Dan) <[e-mail]> wrote:
> We start a Working Group Last Call for the document ‘RTCP XR Report Block for Loss Concealment Metrics Reporting on Video Applications'. Please let us know if you believe that this document is ready to be submitted to the IESG for consideration as Proposed Standard. Please send your comments, questions and concerns to the WG mail list before September 4, 2015. If you have read the document and you did not find any problems your input is also welcome. If you are aware about any relevant IPR please take the appropriate actions as per RFC 3979.
>  
> The document is available at https://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-video-lc-01.txt.

I think this is generally in good shape, but some of the definitions at the start of section 4 are unclear. Comments follow:

Section 1.1 uses "MUST" before the RFC 2119 terms have been defined.

Section 4: the first paragraph of this section says twice that a video loss concealment report block SHOULD be sent in the same packet as a Measurement Information Block. It probably only needs to say this once.

Section 4: the first paragraph, says that the video loss concealment report block "SHOULD be sent in the same packet as a Measurement Information Block", then says that the video loss concealment report "MUST be discarded" if the measurement period, included in the Measurement Information Block is not present. The later "MUST" seems to contradict the earlier "SHOULD" strength requirement. 

Section 4: the description of the fields following Figure 1 does not mention the RSV field. 

Section 4: some fields are defined as being measured in RTP timestamp units. Which RTP timestamp is used here? That used by the sender of the video loss concealment block, or that used by the source on which it is reporting?

The following lines contain uses of lower-case RFC 2119 keywords, which could cause confusion:

129:   endpoint or terminal may not see loss occurring between the probe and
130:   the endpoint, and may also not be fully aware of the specific loss
198:   another. Simple decoders may simply re-use the pixels that were in
199:   the missing area while more complex decoders may try to use several
207:   A decoder may user the undamaged pixels in the video frame to
208:   estimate what the missing block of pixels should have.
212:   The sender may encode the message in a redundant way so that receiver
216:   encoder may select a crucial area of an original video frame, extract
248:   discarded. It should be noted that the metrics in this report block
268:   |                  Mean Frame Freeze Duration (optional)        |
367:      Mean Frame Freeze Duration shall be calculated by summing the
369:      number of events. This metric is optional. It only exists
384:      a video frame is totally lost, a value of 0xFF shall be used for
408:      macroblocks, a value of 0, shall be used for the frame when
465:   An attacker may put incorrect information in the Video Loss
468:   Implementers should consider the guidance in [RFC7202] for using
470:   the implementation should apply encryption and authentication to the
658:      frame is decoded and rendered for playout. The metric shall be
700:      video frame is totally lost, a value of 0xFF shall be used for the
742:      there are no concealed macroblocks, a value of 0, shall be used

I suggest the text is either rephrased to avoid these, or they are replaced by the upper-case versions.

I didn't check the appendix.

Cheers,
Colin



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