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

[Jeff Downs <[e-mail]>]

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.