Re: [Gen-art] Gen-ART review of draft-ietf-avt-smpte-rtp-13.txt

[Cullen Jennings <[e-mail]>]

Folks,

Can you take a look at these and let me know how we should proceed.

Cullen

On Sep 15, 2008, at 2:43 AM, Miguel A. Garcia wrote:

> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draft-ietf-avt-smpte-rtp-13.txt
> Reviewer: Miguel Garcia <[e-mail]>
> 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
> -------------------    --------
> [e-mail]       [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.
>
> /Miguel
> -- 
> Miguel A. Garcia
> [phone]
> Ericsson Spain
>

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art