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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]