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

Matthew Lepinski <mlepinski.ietf@gmail.com> Wed, 17 April 2013 20:22 UTC

Return-Path: <mlepinski.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 727EB21E809D; Wed, 17 Apr 2013 13:22:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.238
X-Spam-Status: No, score=-3.238 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h-PJqi7GAeuT; Wed, 17 Apr 2013 13:22:19 -0700 (PDT)
Received: from mail-qe0-f41.google.com (mail-qe0-f41.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 98F0121E809B; Wed, 17 Apr 2013 13:22:15 -0700 (PDT)
Received: by mail-qe0-f41.google.com with SMTP id b10so1168241qen.28 for <multiple recipients>; Wed, 17 Apr 2013 13:22:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=f7+M9b+Udb1oRFPFNeH1OISIa9yr6cOzXVRe1oRu2CE=; b=QEmhAe46e4r8vkAXLf5RM9GgL6cd5i2pev9Q1m/h3fi0gvDZZA7UJ3qnvHlPswHTao DAEv00i2uism6BG/ObrgRfPccYgiL390DaSr3KSok2ctm0amrM9ngB7xr+aSodgbDB2m /7wswXnoxrIpAZHz6svU1a8pXqVRbAqw2KgoxraGyy8nzUzUvHgwmTrlUCqw54RxxkNk /4BoFd0LX/3EYJBzebsJx56Z5GXgLPG37XuO11s4B2MXv0ShQ/bbZpB7yZPgZgsjM/CA hcWjR7Oc1WnQdlDSf2rWmDHLUbpH8m6KRU6Ryu/UbNWT0JHZkjJSz0wtgqbwhnwhXqjl DhHQ==
MIME-Version: 1.0
X-Received: by with SMTP id s19mr2406786qao.28.1366230135078; Wed, 17 Apr 2013 13:22:15 -0700 (PDT)
Received: by with HTTP; Wed, 17 Apr 2013 13:22:14 -0700 (PDT)
Date: Wed, 17 Apr 2013 16:22:14 -0400
Message-ID: <CANTg3aBEVu1ZubJUMx=S3EbOWhPdw2=EF2KDR0e+6dQb3OYPMg@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: multipart/alternative; boundary=20cf305e1fdbe2059004da943d1e
Cc: 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: Wed, 17 Apr 2013 20:22:27 -0000

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.

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?

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.)