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

Qin Wu <bill.wu@huawei.com> Thu, 18 April 2013 06:14 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CF621F8F4F; Wed, 17 Apr 2013 23:14:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.629
X-Spam-Level:
X-Spam-Status: No, score=0.629 tagged_above=-999 required=5 tests=[AWL=-1.821, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VZLDPC2OJXF; Wed, 17 Apr 2013 23:14:01 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 339ED21F8F1A; Wed, 17 Apr 2013 23:14:00 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY36730; Thu, 18 Apr 2013 06:13:58 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Apr 2013 07:13:42 +0100
Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Apr 2013 07:13:54 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.113]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.01.0323.007; Thu, 18 Apr 2013 14:13:48 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Matthew Lepinski <mlepinski.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12
Thread-Index: AQHOO6lNkdOgkRpj0UCIzqzcZ8nnjpjbekQw
Date: Thu, 18 Apr 2013 06:13:47 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA43A4C890@nkgeml501-mbs.china.huawei.com>
References: <CANTg3aBEVu1ZubJUMx=S3EbOWhPdw2=EF2KDR0e+6dQb3OYPMg@mail.gmail.com>
In-Reply-To: <CANTg3aBEVu1ZubJUMx=S3EbOWhPdw2=EF2KDR0e+6dQb3OYPMg@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.149]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA43A4C890nkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org" <draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org>
Subject: [secdir] 答复: SecDir Review of draft-ietf-xrblock-rtcp-xr-burst-gap-discard-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Apr 2013 06:14:02 -0000

Thank Mattew for your valuable review.
Please see my reply inline below.

Regards!
-Qin
发件人: Matthew Lepinski [mailto:mlepinski.ietf@gmail.com]
发送时间: 2013年4月18日 4:22
收件人: secdir@ietf.org; iesg@ietf.org
抄送: draft-ietf-xrblock-rtcp-xr-burst-gap-discard.all@tools.ietf.org
主题: 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.