Subject: [AVT] Comments on draft-ietf-avt-rtcpssm-06.txt

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Feb 2004 17:44:19 +0100

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: [email-masked]

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt