Comments on draft-ietf-avt-rtcpssm-06.txt
Magnus Westerlund <magnus.westerlund <at> ericsson.com>
2004-02-23 16:44:19 GMT
Hi,
Here is my comments on the draft. They are mostly editorial, there are a
few that are for discussion. see 8, 9, 13, 15, 17, 19, 20
1. You will need the new boilerplate according to RFC 3667 and RFC 3668.
2. The copyright misses any date.
3. The pages are missing the correct new-page charachters.
4. TOC: Chapter 17 is missing a space between title and number.
5. Chapter 5: Table with RTCP packet types. I think that XR is better
called "Extended Reports" instead of "RTCP Extension".
6. You are missing two RTCP packet type in this table.
FIR full INTRA-frame request 192 [RFC2032]
NACK negative acknowledgement 193 [RFC2032]
7. Section 6.2, second paragraph: "MUST not" should be "MUST NOT"
8. Section 6.2, third paragraph: "All unicast data received on this
port MUST be forwarded by the source to the group on the multicast
RTCP channel."
Is it really intended that any received packets should be forwarded? If
someone sends IP/UDP/FOO then it will be forwarded. Isn't this a
problem. I think that RTCP has pretty good heuristics for checking that
RTCP really is RTCP.
9. Section 7.1.3: The distribution buckets: Is it really intended that
the buckets shall overlap? IF both ends of any given bucket is inclusive
then any consecutive bucket will share one integer value of the bucket
range. Also how does one resolve cases when the number of possible
values are not even dividable between the buckets? I think that
consistent rules for rounding is necessary.
10. Section 7.1.5: The second last sentence uses lower case "must" where
I think it should be a "MUST".
11. Section 7.1.8: The length field. The definition is a bit confusing
"For a DNS name,
the length field indicates the number of 32-bit words making up
the string plus 1 byte and any additional padding required to
reach the next word boundary."
I would write it:
For a DNS name, the length field indicates the number of 32-bit words
necessary for the string, and 1 octet of NULL termination. The address
string is padded if not 32 bit aligned, see below.
12. Section 7.1.8: Address: If I understand it correctly, at least one
character of NULL termination is required. Please write this out.
13. Section 7.1.9: Collision SSRC:
"Each Collision SSRC is
included repeatedly in Collision sub-report blocks and sent at
least five times."
Didn't we in Minneapolis discuss this and come to the conclusion that we
did not need to repeat it five times. Instead one reports it as long as
the collision exist.
14. Section 7.1.9., collision SSRC, strange formatting on the last line
of the paragraph.
15. Section 7.1.11: RTCP bandwidth:
"This is a fraction value indicating a percentage of the
session bandwidth, expressed as a fixed-point number with the
binary point at the left edge of the field."
I think that session bandwidth is a bit unclear here, do you refer to
the RTP session bandwidth or the total RTCP bandwidth?
16. Section 7.1.11: I think you should take a little more care to avoid
splitting figures by page breaks.
17. Section 7.1.12: When is this expected to be used. When will any
receiver in the RTP session not receive the SR of a sender? I think that
any SR will need to be forwarded to the receivers for synchronization
reasons. Thus I do not understand why explicit notification of the
number of senders are needed.
18. Section 7.2, third paragraph: "If both are included, the Receiver
RTCP Bandwidth sub-report block MUST take precedence." Isn't SHALL a
better word in this context?
19. Section 7.2, seventh paragraph: May a sender of sub-report block
perform differentiated reporting using multiple report blocks, for
example report your appendix example in this way.
sub-report 1
min 0
max 8
NDB=3
sub-report 2
min 9
max 19
NDB 11
sub-report 3
min 20
max 39
NDB 5
I think a sentence making this explicitly allowed or disallowed would be
good.
20. Section 10.1: The SDP attribute is missing formal declaration, and
registration. Is is allowed to be extended?
21. Section 11.7.1, bullet B. RTSP could also use S/MIME. Currently
neither S/MIME nor TSL or SSL is defined for RTSP.
22. In the reference section all references from 10 and onwards are
missing space between numbering and author.
23. Section 16.4. What is really X? When I read it I interpreted "X
values indicate loss percentage reported," as meaning that X was
expressed in X/100 packet losses, instead of the X/256 that it really
is. Maybe not using "percentage" could make this clear.
24. IPR and Copyright Notice needs to use the new boiler plate from RFC
3667 & 3668.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
This communication is confidential and intended solely for the addressee(s). Any unauthorized review,
use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error,
please notify the sender by replying to this transmission and delete the message without disclosing it.
Thank you.
E-mail including attachments is susceptible to data corruption, interruption, unauthorized
amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable
for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/avt
RSS Feed