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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf