Document: draft-ietf-avt-smpte-rtp-13.txt Reviewer: Miguel Garcia Review Date: 2008-09-12 IETF LC End Date: 2008-09-19 Summary: The draft is almost ready, but I have: - One issue for IESG discussion, based on the guidelines given in RFC 2026. - One minor issue with the IANA registration (which is not complete/correct). - Some other editorial details that will improve readability. Please consider these comments at your own discretion. Comments: - This draft makes a normative reference to two specifications that are not widely available. These are references [SMPTE-12M] and [SMPTE-EG40]. These are the URLs to those specifications: http://store.smpte.org/product-p/smpte%200012m-1-2008.htm http://store.smpte.org/product-p/eg%200040-2002.htm According to RFC 2026 Section 7.1.2, the IESG may request that not widely available specifications are published as informational RFCs. I am bringing this issue to the IESG's attention: this Internet-Draft relies on two normative not widely available specifications. Minor comments: - Section 9, IANA considerations, is not clear, and I believe IANA has not done the right registration, if we consider IANA comment in the data tracker: https://datatracker.ietf.org/idtracker/draft-ietf-avt-smpte-rtp/comment/85556/ The problem lies in the registration in the RTP Compact Header Extensions. IANA should register the full URI, but since the instructions are far from clear, IANA has not registered this full URI. So, I suggest to replace the two paragraphs in the IANA considerations section with the following text, and the contact IANA once more to modify the registration in the RTP Compact Header Extensions: The RTCP packet type used for SMPTE time-code needs to be registered, in accordance with section 15 of [RFC3550]. IANA is instructed to add a new value to the RTCP Control Packet types subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data: abbrev. name value Reference _________ _________________________ ________ _________ SMPTETC SMPTE time-code mapping yyy [RFC-avt-smpte-rtp-13] Note: it is suggested that IANA allocates the value 194. Additionally, IANA is instructed to register a new extension URI to the RTP Compact Header Extensions subregistry of the Real-Time Transport Protocol (RTP) Parameters registry, according to the following data (split in two lines for formating purposes): Extension URI Description ------------------------------------- ----------------- --------- urn:ietf:params:rtp-hdrext:smpte-tc SMPTE time-code mapping Contact Reference ------------------- -------- singer at apple.com [RFC-avt-smpte-rtp-13] Editorial comments: - The last paragraph in Section 3 (Design Goals) contains a normative statement. I thought that Section 3 would be informative in nature, therefore, I was surprised to find normative statements here, specially those that assume that the reader has understood the rest of the draft (the meat). I would suggest to move this normative statement, or perhaps the whole paragraph, to somewhere else in the draft. - Section 4, first paragraph. The text reads: If the recipient must ever calculate time-codes based on the RTP times, then some setup information is needed. This MUST be sent out- of-band, for example in a SIP offer/answer exchange. Since this is a general header extension [hdrext], appropriate signaling for those header extensions should be used. It is not clear *how* is this setup information sent. In particular, it is not clear the relation of the "general header extension" and how to signal this setup information in SDP. Then later, I figured it out. I think this paragraph ought to say that since SMPTE time-codes reuses the general mechanism for RTP header extensions, and since this general mechanism defines a new 'extmap' SDP attribute for additional signaling, then this draft uses the 'extmap' in SDP. Perhaps a reference to Section 5 in RFC 5285 will also help. - Section 4, first paragraph, add an informative reference to RFC 3264 when the draft mentions "SIP offer/answer exchange". - Section 5.3. It would be nice to add captions to figures, so that other documents, if needed, can refer to "Figure x in RFC yyyy". - Section 5.3. I didn't understand the difference in figures between lines marked as "+-+-+-..." and those marked as "+=+=+=..." In particular, both figures contain a word named "RTP timestamp", but the underlying line is different in each figure. - Section 5.3. I was a bit confused with the second figure. Basically, at first sight, I couldn't identify which are the 64 bits of the full time-code. Then I realized this must be the last two 32-bit words, but the fact that in the figure these two words are split (with a line), made me doubt. So, some reads might interpret that one word is "Full 8-byte" and the other "SMPTE 12M timecode". My recommendation to make it clear is to remove the line "+-+-+-+..." that separates these two words. For example: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC |PT=SMPTETC=194 | length=4 | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SSRC of packet sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | RTP timestamp | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Full 8-byte | | SMPTE 12M timecode | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ - Section 5.4, first paragraph, add a reference to "RTP header extension". - Section 7, 4th paragraph, replace "in this draft" with "in this document". - Section 12, Reference [hdrext] is now RFC 5285. - Section 12. Reference SMPTE-12M refers to a specification dated in 1999. It seems that this specification is no longer available and has been replaced by a new version dated 2008. The reference should probably be updated.