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