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

Hi Colin,

Thank you for your careful review. Please see some of my replies inline.

BR,
Rachel

> -----Original Message-----
> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Colin Perkins
> Sent: Thursday, August 27, 2015 10:36 PM
> To: Romascanu, Dan (Dan)
> Cc: xrblock
> Subject: Re: [xrblock] WGLC for 'RTCP XR Report Block for Loss Concealment
> Metrics Reporting on Video Applications'
> 
> On 13 Aug 2015, at 13:41, Romascanu, Dan (Dan) <dromasca@avaya.com>
> 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.

[Rachel]: Right. I'll change it to lower-case.

> 
> 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.

[Rachel]: I'll keep the first one and delete the latter sentence.

> 
> 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.

[Rachel]: The first "SHOULD" refers to the sender, while the latter "MUST" refers to the receivers. Maybe I should add some clarifications to this sentence?

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

[Rachel]: Right. Will fix it in the next version.

> 
> 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?

[Rachel]: It should be measured by the sender of the reporting block, so it's the RTP timestamp used by the sender of the reporting block. I all add some clarification words to it in the next version.

> 
> 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.

[Rachel]: Okay. I'll look through the whole text and fix them.

> 
> I didn't check the appendix.
> 
> Cheers,
> Colin
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock