Subject: [AVT] Re: Review requested: draft-ietf-avt-smpte-rtp-07.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Feb 2007 11:32:04 -0500

Ladan Gharai, a member of our AVT Review Team, has reviewed 
draft-ietf-avt-smpte-rtp-07.txt and has generated these comments. 
Thanks, Ladan.

---------------------------------------
Ladan wrote:

Hi:

I have reviewed  draft-ietf-avt-smpte-rtp-07. Overall the draft is in
good shape, most of the comment below are minor or are requests for
more clarification in the text:

cheers,
ladan

page 3: in the introduction there is mention of the SMPTE time code
in a simple counter format, but then there is no discussion of how
such a counter would be represented in RTP/RTCP - does the draft
foresee that there will never be interest in using the counter form
of the time-code with RTP/RTCP? it seems to me that discussing the
counter form in the draft would make it more complete,

page 8: this is more of a question: are the same dropped frames
applied to NSTC, PAL and also HDTV video formats?

page 8: an additional example with dropped frames would be helpful to
understanding the example

page 9:  the draft would be more complete with a breakdown of what
the full SMPTE 12M time code looks like - i.e.  in the example of
full time code SMPTETC packets in section 5.3.    Also does the SMPTE
time code use BCD or is it binary? (section 5.1 says "A full
binary ....")

page 9: section 5.3: are RTCP minimum time intervals sufficient to
send the time-codes when needed? or will the sender need to over ride
the RTCP intervals to send the time-codes at particular times?

page 11: why is only the long form of the extension associated with
an offset? would the short form not benefit from an offset (perhaps
even an 8 bit one?)  -- also an drawing of how the RTP packets would
look like in both cases would be beneficial here.

page 13: section 7 says: "The RTCP packets (or the in-band codes)
need not use the same RTP timestamp as the sender report (or
transmission time) in the same RTCP packet."

           In the case of the RTCP packets, this makes sense. However
for the in-band mode, the short form relies on the RTP timestamp of
the RTP packet (and it has no offset) so it not clear how it could be
sent "ahead of need."

page 14: " ... it is hard to see" -> "... there are no".  If, indeed,
there are no security considerations, or else they should be listed.

nits and organizational changes:
----
- make first character in section heading all caps (or not). in the
text and the Table of contents. Right now its inconsistent across the
draft:
      page 2: Requirements notation -> Requirements Notation
      page 7: Signaling (setup) information -> Signaling Setup
Information
      page 9: In-stream information -> In-stream Information

page 3: "This specification enables ..." -> "This memo specifies ..."
or "This document defines how ..."

page 5: referencing sections 5.3 and 5.4 from "The first can be ..."
and "The second ..." would make the draft easier to understand.

page 7: "time-code-second" -> "time-code second"

page 8:  in:
                      extensionattributes = frameduration "/"
framesperscecond drop
does frameduration refer to frame_duration in 1. on page 7? why is
the same syntax not used? (same thing with framespersecond)

page 10: "... defined above." -> "... defined in Section 5.1"

On Jan 8, 2007, at 11:18 PM, Tom-PT Taylor wrote:

> Hi, folks.
>
> draft-ietf-avt-smpte-rtp-07.txt is in WGLC but has so far drawn no  
> comments. Would you care to have a look at it?
>
> Thanks,
> Tom
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt