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

Jeff Downs <jeff_downs@partech.com> Thu, 02 February 2012 18:58 UTC

Return-Path: <jeff_downs@partech.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 E598F21F8534; Thu, 2 Feb 2012 10:58:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
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 VtyJOYHlMvYs; Thu, 2 Feb 2012 10:58:38 -0800 (PST)
Received: from imail2.partech.com (imail2b.partech.com [192.133.62.26]) by ietfa.amsl.com (Postfix) with ESMTP id D97A121F8508; Thu, 2 Feb 2012 10:58:31 -0800 (PST)
Received: from eclipse.partech.com (eclipse.partech.com [172.16.8.4]) by imail2.partech.com (8.13.1/8.12.11) with ESMTP id q12IwJkN024248; Thu, 2 Feb 2012 13:58:19 -0500
Received: from beasley.parcorp.local (beasley.partech.com [172.16.16.70]) by eclipse.partech.com (8.12.9/8.12.9) with ESMTP id q12IwAbs025706; Thu, 2 Feb 2012 13:58:18 -0500 (EST)
Received: from [192.168.167.155] ([192.168.167.155]) by beasley.parcorp.local with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 13:56:56 -0500
Message-ID: <4F2ADC65.2010700@partech.com>
Date: Thu, 02 Feb 2012 13:56:37 -0500
From: Jeff Downs <jeff_downs@partech.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <84A8BD83-8B84-4049-B9CF-1AB0E36211F9@bbn.com>
In-Reply-To: <84A8BD83-8B84-4049-B9CF-1AB0E36211F9@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Feb 2012 18:56:58.0356 (UTC) FILETIME=[70828B40:01CCE1DC]
X-Mailman-Approved-At: Thu, 02 Feb 2012 11:05:55 -0800
Cc: jimsgti@gmail.com, General Area Review Team <gen-art@ietf.org>, abegen@cisco.com, IETF-Discussion Discussion <ietf@ietf.org>
Subject: Re: [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, 02 Feb 2012 18:58:39 -0000

Richard and all:

I am one of the co-authors of the above named draft.  Thank you for the 
review and comments on the draft.

After discussion with the document shepherd and the WG co-chair, we 
decided to incorporate some of the suggested changes into a new revision 
(-03) of the draft.  This new revision was uploaded to the IETF 
datatracker yesterday and is available now:
http://tools.ietf.org/html/draft-ietf-payload-rtp-klv-03

Please see below for specifics on how each of the Gen-ART comments were 
addressed.

Again, thank you for the review and comments.

Jeff Downs
PAR Government Systems



On 1/26/2012 4:11 PM, Richard L. Barnes wrote:
 > ===== 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?

The widely varied nature and use cases of this format do not lend very 
well to specific parametrization describing the data. KLV, by its very 
nature, is self-identifying through the use of universally unique keys.
No changes were made to the draft in this regard.

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

Text has been added to draft revision -03 in Section 8 to describe this 
scenario and to caution implementers.


 > ===== 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).

Text has been added to the preface of Section 4 to further clarify this 
in draft revision -03.

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

The suggested text has been added to draft revision -03 at the end of 
Section 4.2.

 > 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.)

In the interest of keeping the draft simple and focused on carriage 
within RTP specifically, I have not added guidance on KLV recovery 
techniques.  Techniques for this are not inherently unique to the 
carriage of KLV data over RTP (that is, such techniques can be applied 
to any KLV data where known damage/loss has occurred), and thus we feel 
this is outside the scope of this document.

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

This text comes directly from the template data in 
http://tools.ietf.org/id/draft-ietf-payload-rtp-howto-01.txt
To keep the reviewed draft in line with the template, no edits have been 
made here relevant to this comment.

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

This change has been incorporated into revision -03 of the draft.