Re: [secdir] SECDIR review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08

Qin Wu <bill.wu@huawei.com> Thu, 21 March 2013 11:13 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 5553921F9014; Thu, 21 Mar 2013 04:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.037
X-Spam-Level:
X-Spam-Status: No, score=-3.037 tagged_above=-999 required=5 tests=[AWL=1.809, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 zIlGuW0Wd5s3; Thu, 21 Mar 2013 04:13:37 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43221F8A4E; Thu, 21 Mar 2013 04:13:37 -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 AQY28656; Thu, 21 Mar 2013 11:13:34 +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, 21 Mar 2013 11:13:34 +0000
Received: from SZXEML418-HUB.china.huawei.com (10.82.67.157) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 11:13:33 +0000
Received: from w53375 (10.138.41.149) by szxeml418-hub.china.huawei.com (10.82.67.157) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Mar 2013 19:13:28 +0800
Message-ID: <C8D9396C95454F3F8E332149669F6959@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Chris Lonvick <clonvick@cisco.com>, iesg@ietf.org, secdir@ietf.org, draft-ietf-xrblock-rtcp-xr-burst-gap-loss.all@tools.ietf.org
References: <alpine.LRH.2.00.1303181321400.15558@sjc-xdm-114.cisco.com>
Date: Thu, 21 Mar 2013 19:13:28 +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-burst-gap-loss-08
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, 21 Mar 2013 11:13:38 -0000

Hi, Chris:
Your proposed change looks good to me, thanks!

Regards
-Qin
----- Original Message ----- 
From: "Chris Lonvick" <clonvick@cisco.com>
To: <iesg@ietf.org>; <secdir@ietf.org>; <draft-ietf-xrblock-rtcp-xr-burst-gap-loss.all@tools.ietf.org>
Sent: Tuesday, March 19, 2013 4:27 AM
Subject: SECDIR review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08


> Hi,
> 
> 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.
> 
> I don't see any problems with this.  The only nit that I found was that I 
> couldn't fully understand a part of section 3.2.
> 
>   Loss and Discard Combination flag (C): 1 bit
> 
>       The 'C' flag is used to indicate whether combining loss/discard
>       report is needed.  This field MUST be set to '1' if the burst gap
>       loss report is present in conjunction with the burst gap discard
>       report in the same compound RTCP packet and MUST be set to '0'
>       otherwise.  If the burst gap discard is not sent with the burst
>       gap loss, then the receiver MUST discard the burst gap loss with
>       'C' flag set to 1.  If the 'C' flag is set to 0, then receiver
>       MUST NOT discard the burst gap loss Metrics Block when the burst
>       gap discard is not received.
> 
> Maybe something like the following:
> 
> The 'C' flag is used to indicate whether the loss/discard report is 
> combined with the burst gap loss report in the same compound RTCP packet. 
> The value MUST be set to '1' if the loss/discard report and the burst gap 
> loss report are combined.  Otherwise, the value MUST be set to '0'.  If 
> the burst gap discard is not sent with the burst gap loss, then the 
> receiver MUST discard the burst gap loss with 'C' flag set to 1.  If the 
> 'C' flag is set to 0, then receiver MUST NOT discard the burst gap loss 
> Metrics Block when the burst gap discard is not received.
> 
> 
> Best regards,
> Chris