Re: [secdir] 答复: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12

[Matthew Lepinski <[e-mail]>]

Thank you for the prompt response. Your explanation makes sense to me.


On Thu, Apr 18, 2013 at 2:13 AM, Qin Wu <[e-mail]> wrote:

>  Thank Mattew for your valuable review. ****
>
> Please see my reply inline below.****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> *发件人:* Matthew Lepinski [mailto:[e-mail]]
> *发送时间:* 2013年4月18日 4:22
> *收件人:* [e-mail]; [e-mail]
> *抄送:* [e-mail]
> *主题:* SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12****
>
> ** **
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
>  These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
>
> Summary: In my opinion this document is acceptable. I have no concerns
> with this document.****
>
> ** **
>
> This document describes a new RTCP block for use in the RTCP eXtended
> Reporting (XR) framework. The block specified in this protocol is a
> companion to the block specified in draft-ietf-xrblock-rtcp-xr-discard.
> Where I-D.xrblock-rtcp-xr-discard allows a receiver to report the number of
> packets discarded without being used (played out), this current draft
> allows a receiver to provide additional data regarding the pattern of
> discarded packets. That is, how many of the discarded packets arrived
> during intervals of high discard rate (i.e., intervals of poor quality due
> to many discards).****
>
> ** **
>
> The document authors claim that this draft introduces no new security
> considerations beyond those described in RFC 3611 (RTCP eXtended Reports).
> I agree with this assessment.****
>
> ** **
>
> [Qin]: Thanks.****
>
> ** **
>
> I did have one minor question about Section 3.2. I admit that I am not an
> RTCP expert, but I was confused by the description of the Threshold value.
> The document says that the Threshold is calculated in the same way Gmin is
> calculated in 3611. However, in 3611 it appears that Gmin is a value
> configured by the receiver (Recommended to be 16, but can be set to any
> non-zero value the receiver desires.) Am I correct in assuming that
> Threshold is also a configured value sent by the receiver? ****
>
> ** **
>
> [Qin]: The text you are referring to (i.e., Threshold is calculated in the
> same way Gmin is calculated in 3611.) was added corresponding to PM-DIR
> review. You are right, Gmin is configuration parameter sent by the
> receiver. Gmin can be other value than 16, see RFC3611, section 4.7.1****
>
> “****
>
> If the packet spacing is 10 ms and the Gmin value is the recommended****
>
>    value of 16, the burst duration is 120 ms, the burst density 0.33,****
>
>    the gap duration 230 ms + 290 ms = 520 ms, and the gap density 0.04.***
> *
>
> ** **
>
> ”****
>
> Maybe the word “calculated” is a little misleading and can be rephrased as
> “set”, i.e.,****
>
> The threshold is set in the same way Gmin is calculated in 3611.****
>
> ** **
>
> Finally, do you expect implementations to use both the VoIP Metrics block
> and the Burst/Gap Discard block together (for the same RTP session)? If so,
> is it important that the Threshold in the Burst/Gap Discard block be set to
> the same value as the Gmin value in the VoIP Metrics block? (If there are
> any problems that would arise if the two parameters were set to different
> values, those should be mentioned. If there are no anticipated issues with
> setting the values independently, then that's fine there is no need to say
> anything more than is currently in the document.)****
>
> ** **
>
> [Qin]: The threshold in the Burst gap Discard block and VOIP Metrics Block
> should be set to the same value if both blocks report the same stream. The
> threshold in the Burst gap Discard block and VOIP Metrics Block can be set
> to different values if burst gap discard block and VOIP metrics block
> report the different stream, which is identified by different SSRC.****
>
> If burst gap block and VOIP metrics block can report the same stream, I
> think either we use Burst Gap block or we use VOIP metrics block, usually
> we will not use both together to report the same stream. ****
>
> So I think it is safe for keeping what it is currently described in the
> document as it is.****
>
> ** **
>
> ** **
>
> ** **
>