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.
- [Gen-art] Gen-ART review of draft-ietf-payload-rt… Richard L. Barnes
- Re: [Gen-art] Gen-ART review of draft-ietf-payloa… Jeff Downs