[secdir] Secdir review of draft-ietf-fecframe-sdp-elements-08
Nicolas Williams <Nicolas.Williams@oracle.com> Tue, 21 September 2010 22:39 UTC
Return-Path: <Nicolas.Williams@oracle.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE2B3A6847 for <secdir@core3.amsl.com>; Tue, 21 Sep 2010 15:39:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level:
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nlCtLIxQXah for <secdir@core3.amsl.com>; Tue, 21 Sep 2010 15:39:49 -0700 (PDT)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 086E83A6782 for <secdir@ietf.org>; Tue, 21 Sep 2010 15:39:48 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8LMeAqE004420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Sep 2010 22:40:12 GMT
Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8LLOEEj000646; Tue, 21 Sep 2010 22:40:10 GMT
Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 618745391285108732; Tue, 21 Sep 2010 15:38:52 -0700
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Sep 2010 15:38:51 -0700
Date: Tue, 21 Sep 2010 17:38:47 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: secdir@ietf.org, watsonm@netflix.com
Message-ID: <20100921223846.GT7857@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2010-03-02)
Subject: [secdir] Secdir review of draft-ietf-fecframe-sdp-elements-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Tue, 21 Sep 2010 22:40:00 -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. This document deals with the encoding of FEC parameters in SDP for unicast and multicast of video and other media. Modulo the COMMENTs and DISCUSSes on the datatracker, I believe this document is ready for publication. Its security considerations section appears to me to be complete. I do have one minor comment regarding this text: 5.1. Declarative Considerations In multicast-based applications, the FEC Framework Configuration Information pertaining to all FEC protection options available at the sender MAY be advertised to the receivers as a part of a session announcement. This way, the sender can let the receivers know all available options for FEC protection. Based on their needs, the receivers MAY choose protection provided by one or more FEC Framework instances and subscribe to the respective multicast session(s) to receive the repair flow(s). Unless explicitly required by the CDP, --> the receivers SHOULD NOT send an answer back to the sender specifying their choices since this can easily overwhelm the sender particularly in large-scale multicast applications. Why not "MUST NOT" instead of "SHOULD NOT"? When would a receiver ever want to send an answer back to a multicast sender? Nico --
- [secdir] Secdir review of draft-ietf-fecframe-sdp… Nicolas Williams