[secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07

Klaas Wierenga <klaas@wierenga.net> Mon, 04 February 2013 15:10 UTC

Return-Path: <klaas@wierenga.net>
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 E21E321F88B6; Mon, 4 Feb 2013 07:10:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKQvxNxHm1MG; Mon, 4 Feb 2013 07:10:26 -0800 (PST)
Received: from out27-ams.mf.surf.net (out27-ams.mf.surf.net [145.0.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2C02921F869C; Mon, 4 Feb 2013 07:10:25 -0800 (PST)
Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r14FAOnl017704; Mon, 4 Feb 2013 16:10:24 +0100
Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=dhcp-10-61-105-5.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from <klaas@wierenga.net>) id 1U2Ng5-000H8M-Cz; Mon, 04 Feb 2013 16:09:49 +0100
From: Klaas Wierenga <klaas@wierenga.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <78553359-298A-4E98-AE55-78D7AD4B420B@wierenga.net>
Date: Mon, 4 Feb 2013 16:10:22 +0100
To: draft-ietf-xrblock-rtcp-xr-summary-stat.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
X-Antivirus: no malware found
X-Bayes-Prob: 0.0229 (Score 0, tokens from: @@RPTN)
X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6
X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default)
X-Canit-Stats-ID: 0uIUfaokh - c9c07018cc70 - 20130204 (trained as not-spam)
X-Scanned-By: CanIt (www . roaringpenguin . com)
X-Mailman-Approved-At: Mon, 04 Feb 2013 07:11:59 -0800
Subject: [secdir] secdir review of draft-ietf-xrblock-rtcp-xr-summary-stat-07
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, 04 Feb 2013 15:10: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.

The draft defines three RTCP XR block types for reporting loss, duplication and discard summary statistics independent from the RTP application that is used, augmenting the ones in RFC3611.

The draft is well written and clear, and I have only minor comments/questions:

* 1.1 Summary Statistics Metrics

Since these are summary (as opposed to raw) statistics metrics, does that mean that the concerns wrt to confidentiality are somewhat alleviated? And if so, shouldn't that go in the security considerations? 

* 2.1 Standards language

Picture Type 

It is not clear from the text what Picture Type means. Are you saying that the 2 choices for Picture Type are respectively Key Frame and Derived Frame? If so, please make that more clear. Picture Type also seems a bit of a misnomer, but I guess Frame Type has unwanted connotations as well

* 7 Security Considerations

See my remark on 1.1

Cheers,

Klaas