I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-payload-rtp-klv-02 Reviewer: Richard Barnes Review Date: 26 Jan 2011 IETF LC End Date: 27 Jan 2011 IESG Telechat date: (if known) - Summary: Mostly ready, with a couple of minor comments ===== 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? 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. ===== 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). 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. 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.) 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. Section 8, "Receivers are encouraged to place limits...": Suggest changing "are encouraged to" to "SHOULD". _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf