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