[secdir] SECDIR review of draft-ietf-xrblock-rtcp-xr-burst-gap-loss-08
Chris Lonvick <clonvick@cisco.com> Mon, 18 March 2013 20:27 UTC
Return-Path: <clonvick@cisco.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 1F86221F9135; Mon, 18 Mar 2013 13:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 aRaNNXXLVmUF; Mon, 18 Mar 2013 13:27:38 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id A6F8221F8F4F; Mon, 18 Mar 2013 13:27:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1778; q=dns/txt; s=iport; t=1363638458; x=1364848058; h=date:from:to:subject:message-id:mime-version; bh=1ABfMKyAP2Q6IPO15zAHUUBy++N8fWGZPG0+GIHb3+g=; b=R9girF5kpVq2g7ATKzMw4D5hwZoXBSCEx+3jXa2qOs5HahzUMmagg+6c AcHCJylM6S66GeBK9dkT/s5RS0R/+Q1kJV1ep4hZgi4g/53KpBOq8dtm1 qY3TC7woTOJHoYqYVi77IyEad+L5v1RnmrgFd5cSjUC8v8JU6V8NqENd3 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EANl3R1GrRDoJ/2dsb2JhbABDxncWdIJjAoF+iCXCEpJcA4h1nmuDKg
X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="73366187"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 18 Mar 2013 20:27:38 +0000
Received: from sjc-xdm-114 (sjc-xdm-114.cisco.com [171.71.188.119]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2IKRcFI021337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Mar 2013 20:27:38 GMT
Date: Mon, 18 Mar 2013 13:27:38 -0700
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
Message-ID: <alpine.LRH.2.00.1303181321400.15558@sjc-xdm-114.cisco.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: [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: Mon, 18 Mar 2013 20:27:39 -0000
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