[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 (PDT)
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