[AVT] Comments on draft-ietf-avt-rfc2032-bis-00.txt

[Magnus Westerlund <[e-mail]>]

Hi,

I have read this draft and have some comments.

1. All pages are missing the right page break codes.

2. Section 1. In the introduction I think the document should explain 
its status as being an update to RFC 2032. Isn't the intention to go to 
draft standard. I think this should be explained.

3. After Section 1. I am missing a "Conventions used in this document" 
section. This should mention RFC 2119 and also other conventions, like 
abbreviations, and that any picture is called frames that also is 
written somewhere else. The text in the document must also be updated 
using the normative language.

4. Section 2.1: Section 2.1, first paragraph: "Each MB carries
   information on a group of 16x16 pixels: luminance information is
   specified for 4 blocks of 8x8 pixels, while chrominance information
   is given by two "red" and "blue" colour difference components at a
   resolution of only 8x8 pixels." This sentence is strange. I think it 
means that within each MB of 16x16 pixels the luminance information is 
encoded for each pixel, sub divided into four 8x8 groups. While the 
chromiance information is subsampled, for 2x2 pixels, resulting in color 
resolution of 8x8 within the MB.

5. Section 2.1, The start code is specified as being 15 zeros and a 
single 1, I think one should clarify if this is bits or bytes.

6. Section 2.1. The start code bit-order is not obvious, as it is 
sometimes later in shortened form is represented as 10000000.

7. Section 3.1: The payload type specification. I think we should use 
some of the more explicit text, referring to profiles or dynamic 
allocation. Also the reference is wrong, it should be RFC 3551.

8. I haven't found any place requiring video data from different frames 
to be in separate RTP packets, however it seems a necessary restriction.

9. Section 3.1, The payload header I and V bits: Are these parameters 
not more suitable to be in a MIME parameter? I understand that we can't 
remove them.

10. Section 3.1: I am missing a more explicit section about what is 
allowed to place in the data part of the payload.

11. Section 4: I think this section should be brought up to current 
level by referencing the relevant techniques in published or on its way 
RFCs, like the FIR in the feedback specification. Also NACK formats, etc.

12. Section 4.1: The relation for these with the RTCP feedback document 
should be spelled out.

13. Section 4.1, second paragraph:
"   The H.261-specific control packets differ from normal RTCP packets in
   that they are not transmitted to the normal RTCP destination
   transport address for the RTP session (which is often a multicast
   address).  Instead, these control packets are sent directly via
   unicast from the decoder to the coder.  The destination port for
   these control packets is the same port that the coder uses as a
   source port for transmitting RTP (data) packets.  Therefore, these
   packets may be considered "reverse" control packets."

should this usage be allowed to continue, or should it be deprecated? It 
seems to have issues in relation to signalling, DOS, congestion control 
that will have to be explained in the updated version. Does 
implementations exist of this?

14. Section 5.1 the RTCP packet types registration, should probably be 
updated and included in this document?

15. Section 5: The parameters should be included in a semicolon 
separated list, not space separated. See RFC 3555.

16. Section 5.1.1: All the ANNEX values need to have values, otherwise 
they do not adhere to syntax. Therefore as they are binary, I can see 
two alternatives, either all get a 0 or 1 value, with a default of 0, 
i.e. not used. Or we create one parameter "annexes" which contain a list 
of the used annexes.

17. The document is missing clear RFC editor statements when it at least 
uses a replacement rule for the RFC number.

18. Section 5.1.1: The "author/Change controller" string has a stray ">".

19. Section 5.2: Again the space separated list, needs to be a semicolon 
separated list.

20. Section 5.2: Please write up offer/answer considerations.

21. Section 6. I think the security consideration needs to be expanded 
on in regards to the following topics:
- The non-uniform decoder processing based on input, making DOS attacks 
possible.
- The FIR and NACK issues, see rtcp feedback draft.
- Congestion control, especially in regards to FIR and NACK
- Integrity protection
- Authentication

22. If this document is intended to go to draft, which I hope, the 
interoperability should be investigated. However it must not necessary 
go into the draft.

23. Section 8, Should become section 2, with another name.

24. Section 9. The second bullet is missing numbering. Also in regards 
to the optional new parameters, how does they effect interoperability.

25. Shouldn't there be at least an informative Reference to RFC 2032?

26. Authors list. you needs to dig up contact information for the other 
authors, Christian can't be a problem. If you fail you will have to 
remove them from the author list, and instead credit them somehow else. 
They must also agree to be ready to sign of the document when it is time 
for the authors 48 hours.






-- 

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