[AVT] RE: Comments on draft-ietf-avt-rfc2429bis-00.txt

["Even, Roni" <[e-mail]>]

Magnus,
Most of my comments are inline

As for comment 21 - I would like to take out the MaxBR since I do not think
it is needed. The bW can be specified using b= with AS and also using RFC
3556  and draft-ietf-mmusic-sdp-bwparam-05.txt 

Thanks
Roni

*************************************
Roni Even
VP Product Planning
Polycom Israel

Tel: [phone]
Cell: [phone]
email:[e-mail]
*******************************************


-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]]
Sent: Friday, January 30, 2004 4:55 PM
To: [e-mail]; [e-mail]
Subject: Comments on draft-ietf-avt-rfc2429bis-00.txt


Hi

Here is my comments on the update of RFC 2429. A lot of comments are 
similar to the ones for draft-ietf-avt-rfc2032-bis-00.txt.

1. Please try to submit documents with correct document dates, this says 
november.
RE: OK

2. In section 1, declare the intentions that this will update RFC 2429.
RE:OK

3. Conventions used in this document is missing. RFC 2119 pointer, and 
probably some other things should be here.
RE:OK

4. Section 2: fifth paragraph: Here I think one today should put in 
pointers at RTCP feedback.
RE: OK, I will add a reference for RTCP feedback as a method for back
channel.

5. Please work through and upgrade where appropriate to normative language.

6. Section 3: There should somewhere in the format specification be a 
note about that the usage of the timestamp make the RTCP jitter 
calculation to be less useful as it introduces jitter before transmission.

RE: I am not sure I understand, but is it special for H.263 or general RTP
issue.


7. Section 3. Payload type: Please update the text with reference to 
profiles and usage of dynamic payload types.

RE: OK


8. Section 5.1: Reserved bits: I think it is appropriate to add: "MUST 
be ignored by receivers."

RE: OK

9. Section 5.1: PLEN: "If PLEN>0, the extra picture header
   is attached immediately following the rest of the payload header."
I don't think it is clear enough what attached immediately following the 
rest of payload header. Is this before or after the other video 
redundancy coding header extension?

RE: I think it is clear from the first two paragraph of section 5

10. Section 6.1: What is the start code bit order?

RE: There is a general question if we need to have text that duplicate H.263

11. Section 8.1, This registration updates the previous registered 
version in RFC 3555. please spell this out.

RE:OK

12. Section 8: Again the space separated list needs to be replace with 
semicolon separated.

RE: So you want the parameters in the a=fmtp line to be comma separated
instead of space separated. I am not sure, I see the parameters as space
separated while values for the parameters are comma separated, example is :
CIF=4  QCIF=3 SQCIF=2 CUSTOM=360, 240, 2

13. Section 8.1: all parameters needs values, and default 
interpretations. Some parameters could be changed into values for a new 
aggregating parameter.

RE: I am not sure I understand. The parameters are optional so they may be
specified or not. Some parameters like CIF have values that are specified if
the parameter is specified, but there is no default value.

14. There is need for RFC editor consideration.

15. Section 8.1.1: In the Author/Change controller a stray ">"

RE: OK, Thanks

16. Section 8.1.1: PAR: It does not define how the values are separated, 
colon maybe.

RE: OK

17. Section 8.1.2: I don't know if you can make a parameter registration 
though reference.

RE: I assume you mean for the interlace parameter, I will get the text from
annex X but I thought that it is better to reference then to copy from the
other spec.

18. Section 8.2.1: Please change the title of  "... options with SIP" to 
Offer/Answer.
RE: OK


19. Section 8.2.1: The order of the pictures size is not defined within 
the MIME parameter space at all. I think it belongs there if it is needed.

RE: OK, I will move the  text on the order of the picture sizes.

20. Section 8.2.1: The example using picture sizes: The definition of 
custom does not declare that space is allowed in the comma separated list.

RE: OK, I will cancel the spaces.

21. Section 8.2.1: MaxBR and BPP: "MaxBitRate is video
   decoder property, hence it differs from SDP b : bandwidth-value
   attribute which refers more to application's total bandwidth (an
   application consists often of both audio and video)."

What the b= SDP parameter refers to depends on the modifier, CT, AS, RS, 
RR. So I think you need to be a bit more specific here.

See in the top.

22. Section 9. I thought that most video codecs contains some 
non-uniform processing depending on input. Is this not at least a small 
threat of DOS.

RE:The text is from the original RFC

23. Section 9: I am missing the following topics: Integrity, and 
Authentication. Congestion control on best effort networks is also a 
consideration as the codec can after all produce a rather high bandwidth.

RE: I will add a sentence about congestion. In general all these issues are
general to RTP and I will write the right reference

24. Section 11, belongs in the conventions section in the beginning.

RE: I will check why it is here

25. Should RFC 2190 be declared historic?

RE: Yes, I think tat was the agreement

26. What MIME type should be recommended to support in this new version.

RE: I would like to use the old MIME types H.263-1998 and H.263-2000 and
just add the optional parameters

27. What is the interoperability status on all parts of this specification?

RE: I will write about backward compatibility and how to use the new
parameters.

28. The new parameters and possibly some other changes needs 
interoperability statements.



29. Section 12: The numbering of the changes are strange.
RE: Saw it, I will check and fix

30. Please get the correct contact information for the previous authors. 
And contact them to in regards to there possible interaction with this 
specification in the future.
RE: OK


31. Please get correct page breaks.

Cheers

Magnus Westerlund 

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt