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 <[EMAIL PROTECTED]>
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
------------------- --------
[EMAIL PROTECTED] [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
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
