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

["Miguel A. Garcia" <[e-mail]>]

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