[apps-discuss] APPSDIR review of draft-ietf-payload-rtp-klv-03

[Aaron Stone <[e-mail]>]

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-payload-rtp-klv-03
Title: RTP Payload Format for SMPTE 336M Encoded Data
Reviewer: Aaron Stone
Review Date: Feb 6, 2012
IETF Last Call Date: unknown
IESG Telechat Date: 2012-02-16

Summary: This draft is ready for publication on the Standards Track.

Major Issues: None.

Minor Issues:

Introduction: How does the recipient know what the length of a Key is?
Reading this document as if I were going to implement the protocol, I
could not figure out how my code would figure out the length of the K
in KLV. There is a good description of discovering the length of the
Length field!

Please include a definition of "KLV universal key", as it is used in
the introduction and abstract without definition. Is there a key
registry maintained somewhere? Presumably the SMPTE maintains this
registry, rather than IANA. If so, please reference this registry.

Section 6.2: Please expand SDP upon first use.

Nits:

I wonder if RFC3551 could be an informative, rather than normative, reference.

The sections below have several spelling and grammar errors. I have
excerpted the sections, and provided [[ notes ]] in double square
brackets.


4.2.2.  KLVunit Mapping to RTP Packet Payload

   An RTP packet payload SHALL contain one, and only one, KLVunit or a
   fragment thereof.  KLVunits small enough to fit into a single RTP
   packet (RTP packet size is up to implementation but should consider
   underlying transport/network factors such as MTU limitations) are
   placed directly into the payload of the RTP packet, with the first
   byte of the KLVunit (which is the first byte of a KLV universal key)
   being the first byte of the RTP packet payload.

   KLVunits too large to fit into a single RTP packet payload MAY span
   multiple RTP packet payloads.  When this is done, the KLVunit data
   MUST be sent in sequential byte order, such that when all RTP packets
   comprising the KLVunit are arranged in sequence number order,
   concatenating the payload data together exactly reproduces the
   original KLVunit.

   Additionally, when a KLVunit is fragmented across multiple RTP
   packets, all RTP packets transporting the fragments a KLVunit MUST
   have the same timestamp.

[[ the fragment _of_ a KLVunit ]]

   KLVunits are bounded with changes in RTP packet timestamps.  The
   marker (M) bit in the RTP packet headers marks the last RTP packet
   comprising a KLVunit (see Section 4.1).  A receiver MUST consider a
   KLVunit 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 completed KLVunit; in the latter case, it
   is not.

[[ or the size of the KLVunit is satisfied by the contents of the RTP packet ]]

6.2.  Mapping to SDP

   The mapping of the above defined payload format media type and its
   parameters SHALL be done according to Section 3 of [RFC4855].

[[ Please expand the acronym SDP upon first use ]]

8.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification [RFC3550], and in any applicable RTP profile.  The main
   security considerations for the RTP packet carrying the RTP payload
   format defined within this memo are confidentiality, integrity and
   source authenticity.  Confidentiality is achieved by encryption of
   the RTP payload.  Integrity of the RTP packets through suitable
   cryptographic integrity protection mechanism.  Cryptographic system
[[ grammatical error. systems? ]]
   may also allow the authentication of the source of the payload.  A
   suitable security mechanism for this RTP payload format should
   provide confidentiality, integrity protection and at least source
   authentication capable of determining if an RTP packet is from a
   member of the RTP session or not.

   Note that the appropriate mechanism to provide security to RTP and
   payloads following this memo may vary.  It is dependent on the
   application, the transport, and the signalling protocol employed.
[[ spelling: signaling ]]
   Therefore a single mechanism is not sufficient, although if suitable
[[ Why is a single mechanism not sufficient? Why is SRTP recommended?
Suggest breaking up this sentence better explain. ]]
   the usage of SRTP [RFC3711] is recommended.  Other mechanism that may
[[ mechanisms ]]
   be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
[[ buzzword spelling: IPSec ]]
   also other alternatives may exist.

   This RTP payload format presents the possibility for significant non-
   uniformity in the receiver-side computational complexity during
   processing of SMPTE 336M payload data.  Because the length of SMPTE
   336M encoded data items is essentially unbounded, receivers must take
   care when allocating resources used in processing.  It is trivial to
   construct pathological data that would cause a naive decoder to
   allocate large amounts of resources, resulting in denial-of-service
   threats.  Receivers SHOULD place limits on resource allocation that
   are within the bounds set forth by any application profile in use.

   This RTP payload format does not contain any inheritly active
[[ spelling: inherently ]]
   content.  However, individual SMPTE 336M KLV items could be defined
   to convey active content in a particular application.  Therefore,
   receivers capable of decoding and interpreting such data items should
   use appropriate caution and security practices.  In particular,
   accepting active content from streams that lack authenticity or



Downs & Arbeiter         Expires August 4, 2012                [Page 10]

Internet-Draft       RTP Format for SMPTE 336M Data        February 2012


   integrity proteciton mechanisms places a receiver at risk to attacks
[[ spelling: protection. grammar: places a receiver at right of attack
by spoofed packets. ]]
   using spoofed packets.  Receivers not capable of decoding such data
   items are not at risk; unknown data items are skipped over and
   discarded according to SMPTE 336M processing rules.


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3551]  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
              Video Conferences with Minimal Control", STD 65, RFC 3551,
              July 2003.
[[ could be informational; the reference in Section 5 may be non-normative. ]]

   [RFC4288]  Freed, N. and J. Klensin, "Media Type Specifications and
              Registration Procedures", BCP 13, RFC 4288, December 2005.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.

   [SMPTE336M]
              Society of Motion Picture and Television Engineers,
              "SMPTE336M-2007: Data Encoding Protocol Using Key-Length-
              Value", 2007, <http://www.smpte.org>.
[[ the full spec document appears to include the year? should it be
"SMPTE-336M-2007" ? ]]


END OF REVIEW