[Gen-art] Gen-ART review of draft-ietf-payload-rtp-klv-02

Richard L. Barnes <rbarnes@bbn.com> Thu, 26 January 2012 21:11 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D72821F85FC; Thu, 26 Jan 2012 13:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.153
X-Spam-Level:
X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-yABNsAwqV6; Thu, 26 Jan 2012 13:11:45 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id B774121F85D4; Thu, 26 Jan 2012 13:11:45 -0800 (PST)
Received: from ros-dhcp192-1-51-95.bbn.com ([192.1.51.95]:62564) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1RqWbg-0002fY-IU; Thu, 26 Jan 2012 16:11:44 -0500
From: Richard L. Barnes <rbarnes@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 26 Jan 2012 16:11:43 -0500
Message-Id: <84A8BD83-8B84-4049-B9CF-1AB0E36211F9@bbn.com>
To: General Area Review Team <gen-art@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, draft-ietf-payload-rtp-klv.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-klv-02
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Jan 2012 21:11:46 -0000

I am the assigned Gen-ART reviewer for this draft. For background on 
Gen-ART, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments 
you may receive.

Document: draft-ietf-payload-rtp-klv-02
Reviewer: Richard Barnes
Review Date: 26 Jan 2011
IETF LC End Date: 27 Jan 2011
IESG Telechat date: (if known) -

Summary: 
Mostly ready, with a couple of minor comments

===== MINOR =====

Section 6.1.: Given that the KLV format can carry a variety of data types, would it be helpful for this type to have one or more parameters to describe what types of KLVs might be in the stream?

Section 8, "appropriate caution and security practices": It could be helpful to note here that it is dangerous for implementations to accept active content from streams that lack authenticity or integrity protection, since this could make them vulnerable to attacks using spoofed packets.


===== EDITORIAL =====

Section 4: It would be helpful to note a little more explicitly that a KLVunit is a sequence of KLVs, without any overall framing (thus the requirement for the marker bit / timestamp to distinguish).

Section 4.2., last paragraph: It would be helpful to note explicitly what this paragraph implies: A receiver MUST consider a KLV unit to be completed when it receives either a packet with m=1 or a packet with a new timestamp.  In the former case, the packet payload is included in the KLVunit; in the latter case, it is not.

Section 4.3.1.1., "are left to each implementation": It could be helpful to point to some ways that KLV recovery is done, as guidance to implementors. (Provided this can be done without IPR concerns.)

Section 8, "The main security considerations ... alternatives may exist": This chunk of text doesn't really add anything beyond the normal security considerations for RTP.  Suggest just adding an appropriate reference to standard RTP security practices.

Section 8, "Receivers are encouraged to place limits...": Suggest changing "are encouraged to" to "SHOULD".