[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [209.85.128.41]) 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 10.224.105.83 with SMTP id s19mr2406786qao.28.1366230135078; Wed, 17 Apr 2013 13:22:15 -0700 (PDT)
Received: by 10.49.81.209 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.)
- [secdir] SecDir Review of draft-ietf-xrblock-rtcp… Matthew Lepinski
- [secdir] SecDir Review of draft-ietf-mpls-tp-ring… Tina TSOU
- [secdir] 答复: SecDir Review of draft-ietf-xrblock-… Qin Wu
- Re: [secdir] SecDir Review of draft-ietf-mpls-tp-… Yaacov Weingarten
- Re: [secdir] 答复: SecDir Review of draft-ietf-xrbl… Matthew Lepinski