Re: [secdir] secdr review of draft-ietf-avtext-rtp-duplication

Colin Perkins <csp@csperkins.org> Tue, 04 February 2014 18:05 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEFA1A0155; Tue, 4 Feb 2014 10:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKPcMS55tnsf; Tue, 4 Feb 2014 10:05:12 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DE61A0135; Tue, 4 Feb 2014 10:05:12 -0800 (PST)
Received: from [130.209.247.112] (port=56241 helo=mangole.dcs.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <csp@csperkins.org>) id 1WAkMu-00088b-Lv; Tue, 04 Feb 2014 18:05:09 +0000
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <6BE7194C-1E4F-46AB-B3E1-082A05579B4F@comcast.net>
Date: Tue, 4 Feb 2014 18:05:20 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <90488B49-3048-4D96-A0D6-D5BB249C868A@csperkins.org>
References: <6BE7194C-1E4F-46AB-B3E1-082A05579B4F@comcast.net>
To: David Harrington <ietfdbh@comcast.net>
X-Mailer: Apple Mail (2.1827)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
X-Mailman-Approved-At: Tue, 04 Feb 2014 10:14:15 -0800
Cc: secdir@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-avtext-rtp-duplication.all@tools.ietf.org
Subject: Re: [secdir] secdr review of draft-ietf-avtext-rtp-duplication
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Feb 2014 18:05:14 -0000

On 4 Feb 2014, at 02:54, David Harrington <ietfdbh@comcast.net>; wrote:
> 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.
> 
> 
> From a security perspective, I believe this draft is Ready for publication.
> 
> Comments:
> I am not an expert is RTP, RTCP, and related protocols. I assume this is a valid extension based largely on the authorship by Ali Begen, and suggestions by Magnus Westerlund.
> 
> I have a concern with section 3.4, which lists two states that are REQUIRED to exist for this specification, and then discusses that other approaches could work but would require an additional specification. Doesn’t that make this appropriate for SHOULD rather than REQUIRED terminology?

The intent is to say, “You are currently required to do X or Y, but future extensions to this specification may relax condition Y given appropriate signalling”. We can try to clarify, if that’s not clear.

> in section 4.2, "We require …"; does the protocol specification REQUIRE this?

Changing “We require out-of-band signalling” to “Out-of-band signalling is needed” would cover the intended meaning, and avoid the potential confusion.

-- 
Colin Perkins
http://csperkins.org/