[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
--