[secdir] secdir review of draft-ietf-fecframe-pseudo-cdp-04

Klaas Wierenga <klaas@cisco.com> Fri, 28 September 2012 13:50 UTC

Return-Path: <klaas@cisco.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 08A8021F859A; Fri, 28 Sep 2012 06:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level:
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8]
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 zhl9zE6jBXHG; Fri, 28 Sep 2012 06:50:21 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id EFEAA21F84EA; Fri, 28 Sep 2012 06:50:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1343; q=dns/txt; s=iport; t=1348840220; x=1350049820; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=h4OHAWA2EYjg+FrD4RZdOD6GXRe6cJ+OTsaDw72Sw+A=; b=lkFWSiJeII9IJJIpUfU921HCjZ88JRPknAozPpK553X62zrRurucBCig L2TzkzoZGeAFxD8dz65Q9bKO8quXEfI0MaF9wtuFUMtrcUHvNux13G9Ss s8IpSSnjPHB0ZPU0p2a2WJBAstOAVDw1LWO/5hbDb9LZc0W9AxIRVKJh0 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvwEABCqZVCrRDoG/2dsb2JhbABFvhCBCII5AYIkATSHYpd0oCuQX2ADlWmFYohggWmCaQ
X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208";a="59730917"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 28 Sep 2012 13:50:19 +0000
Received: from [10.21.79.254] ([10.21.79.254]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8SDoHcH025051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Sep 2012 13:50:19 GMT
From: Klaas Wierenga <klaas@cisco.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <3883FA36-0368-48FB-AF8E-C7D23865E76E@cisco.com>
Date: Fri, 28 Sep 2012 15:50:14 +0200
To: The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-fecframe-pseudo-cdp.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
X-Mailer: Apple Mail (2.1498)
Subject: [secdir] secdir review of draft-ietf-fecframe-pseudo-cdp-04
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: Fri, 28 Sep 2012 13:50:22 -0000

Hi,

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 draft describes how Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements can be combined to defined a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows.

The draft is concise and well written, minor nits:


** the code below figure 5:
        v=0
        o=ali 1122334455 1122334466 IN IP4 fec.example.com
        s=FEC Framework Examples
        t=0 0
	….

comes out of thin air, is it supposed to be part of Figure 5 (in that case the caption is at the wrong position)? Some explanation/introduction is useful.

*** 4.  Reconstruction of Source Flows from Repair Flow(s)
*** 4.1.  Example: Multiple Source Flows Protected by a Single Repair Flow

I think for consistency with 3 and 3.1 you should have text in 4

*** Security considerations

I agree with the author that no additional security implications are introduced


Cheers,

Klaas