Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07

Qin Wu <bill.wu@huawei.com> Tue, 05 February 2013 01:57 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 6027E21F855D; Mon, 4 Feb 2013 17:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.691
X-Spam-Level:
X-Spam-Status: No, score=-4.691 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUMlxZB-bogR; Mon, 4 Feb 2013 17:57:12 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B4CD21F8959; Mon, 4 Feb 2013 17:57:11 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOD92351; Tue, 05 Feb 2013 01:57:07 +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; Tue, 5 Feb 2013 01:56:09 +0000
Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 5 Feb 2013 01:57:04 +0000
Received: from w53375 (10.138.41.149) by szxeml451-hub.china.huawei.com (10.82.67.194) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 5 Feb 2013 09:56:57 +0800
Message-ID: <0F71498102964DBDB760AA72B68E8F01@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Klaas Wierenga <klaas@wierenga.net>, <draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org>, <secdir@ietf.org>, The IESG <iesg@ietf.org>
References: <78553359-298A-4E98-AE55-78D7AD4B420B@wierenga.net>
Date: Tue, 5 Feb 2013 09:56:55 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Subject: Re: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07
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: Tue, 05 Feb 2013 01:57:13 -0000

Hi,Klass:
Thank for your valuable review, your comments will be addressed in the update.
Please see my reply below.

Regards!
-Qin
----- Original Message ----- 
From: "Klaas Wierenga" <klaas@wierenga.net>
To: <draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org>rg>; <secdir@ietf.org>rg>; "The IESG" <iesg@ietf.org>
Sent: Monday, February 04, 2013 11:10 PM
Subject: secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07


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.

The draft defines three RTCP XR block types for reporting loss, duplication and discard summary statistics independent from the RTP application that is used, augmenting the ones in RFC3611.

The draft is well written and clear, and I have only minor comments/questions:

* 1.1 Summary Statistics Metrics

Since these are summary (as opposed to raw) statistics metrics, does that mean that the concerns wrt to confidentiality are somewhat alleviated? And if so, shouldn't that go in the security considerations? 

[Qin]: I prefer to keep as it does since both summary and raw face the same level confidential risk without using SRTP protection. The concern wrt to confidientiality will be addressed by security section of RFC3611,i.e., using SRTP. 

* 2.1 Standards language

Picture Type 

It is not clear from the text what Picture Type means. Are you saying that the 2 choices for Picture Type are respectively Key Frame and Derived Frame? If so, please make that more clear. Picture Type also seems a bit of a misnomer, but I guess Frame Type has unwanted connotations as well

[Qin]: Good point, I propose to change Picture Type into Frame Type although they are the same thing, in addition, I propose to change the definition of Picture Type as follows:
OLD TEXT:
"

   Picture Type

      Picture Types used in the different video algorithms are composed
      of the Key frame and Derived frames.  The Key frame is
      independently coded without prediction from other pictures and
      used as a reference frame for predicting other pictures.  Derived
      frames are predicatively coded and derived from a Key frame using
      a prediction algorithm.


"
NEW TEXT:
"
 Frame Type
 A video frame is compressed using different algorithms. 

 Frame type is used to identify different algorithms for video frames. 

 Two frame Types used in the different video algorithms are the Key 

 frame and Derived frames.  The Key frame is independently coded without

 prediction from other pictures and used as a reference frame for 

 predicting other pictures.  Derived frames are predicatively coded 

 and derived from a Key frame using a prediction algorithm.

"

* 7 Security Considerations

See my remark on 1.1

Cheers,

Klaas=