Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-h264-05.txt

[Colin Perkins <csp at csperkins.org>]

On Friday 30 April 2004 16:33, Magnus Westerlund wrote:
...
> If more people has comments they are appreciated if they can be sent no
> later than monday. I will try to do a update in the beginning of the
> next week, and submit that as soon as possible.

I have a few comments:

 - In Section 3, I agree with the likely initial applications of the 
   payload format. I would suggest adding text to note that the format
   is not limited to these applications, however.

 - The last paragraph of Section 5.1 mentions that the RTCP jitter
   statistic is not trustworthy. It would be more accurate to say
   that the RTCP jitter is not a trustworthy indication of network
   performance.

 - Table 1 should make explicit reference to NAL unit types 0, 30 and 31, 
   even if just to indicate that they are undefined.

 - A number of places talk about "optional" MIME parameters, but would be
   better using the RFC 2119 "OPTIONAL" language. For example:
    - Section 5.4, last paragraph on page 14
    - Section 5.5, second paragraph
    - Section 6.1, second paragraph on page 28
    - Section 6.2, first paragraph
    - Section 6.3
    - Section 6.4
    - Section 7.2
    - Section 8.2.1, 4th bullet point

 - In Section 5.4 (last paragraph on page 14) it states that `"No" in the
   "type 1-23" row indicates that an RTP payload cannot contain a single
   NAL unit whose type is in the range of 1-23, inclusive'. Please clarify
   what this refers to.

 - Section 5.5, second paragraph, is unclear what is done if the MIME
   parameter is not present.

 - The last paragraph of Section 5.7 mentions that Section 5.7.1 and 5.7.2
   define the three different types of aggregation unit. Should this be the
   four different types?

 - In Section 5.7.1, I would recommend moving the paragraph starting "The
   DON field specifies the value of the DON for the first NAL unit in an
   STAP-B...." to be immediately after Figure 5.

 - In Section 5.7.1, could an example of an STAP-A packet be provided?

 - In Section 5.7.2, is it correct that the DOND field is unsigned?

 - In Section 5.7.2, you might consider splitting the long paragraph on
   page 22, perhaps starting new paragraphs with "The structure of the
   multi-time aggregation units..." and "The timestamp offset field MUST
   be set..."

   If this was done, I would also move the contents last paragraph on page
   21 to the end of the first on page 22 (immediately after "...whereby n 
   can be 16 or 24").

 - In Section 5.7.2, an example of an MTAP24 would be valuable

 - In Section 5.8, the penultimate paragraph mentions that "A FU payload
   MAY have any number of octets and MAY be empty". Can you clarify when
   an FU payload may be empty, and why that is useful?

 - Section 6.1, second bullet point on page 28, should be clear that NAL
   units are duplicated in the application, not be generating duplicate
   RTP packets. Similarly, the discussion of gateway devices later in the
   Section should explain how the gateway aggregates/deaggregates NAL units
   without breaking RTP when gatewaying between IP networks with different
   MTU size (it will be an RTP translator, and will need to rewrite RTCP)

 - It may be appropriate to move Section 7 to be an appendix?

 - In Section 7.2, it's unclear where the 4th paragraph fits?

 - In Section 8.1, please clarify how the "max-dpb" parameter relates to
   the jitter buffer size, if at all? Similar for the deint-buf-req, 
   deint-buf-cap and int-buf-time parameters (this is mentioned at the
   end of page 40, but this is not obviously related to the earlier 
   definitions). 

 - In Section 8.1, please clarify how the "max-br" parameter relates to
   congestion control, if at all?

 - In the encoding considerations for the MIME type, may wish to note that
   file formats are defined elsewhere?

 - Section 8.2.2, first bullet point on page 44, suggest clarifying that
   "...the answerer must either maintain all configuration parameters or
   remove the media format..." is a MUST?

 - Section 8.2.2, second bullet point on page 44, similarly suggest that
   "The offerer must assume that the answerer supports the same
   configuration and basic capabilities that it is offering" should be a
   MUST?

 - Section 8.2.2, second bullet point on page 44: this is different from
   normal offer/answer usage. Do you have buy-in from the SIP community?

 - Is there any need to discuss use with RTSP in Section 8.2.2 or 8.2.3?

 - The draft needs to discuss congestion control, either within Security
   Considerations, or as a separate section.

Finally, the document could do with careful proof-reading for spelling and 
grammar mistakes.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt