[AVT] Comments on draft-ietf-avt-rtp-dsr-codecs-00.txt

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed draft-ietf-avt-rtp-dsr-codecs-00.txt and it is in a 
mature state, however I found a few errors and have suggestion for some 
improvements.

1. Status of this memo needs updating in accordance with RFC 3667 and 
RFC 3668. This also implies changes to the copyright, and IPR section. 
Please note that the IPR disclaimer at the end is only added if any IPR 
is known for the draft.

2. Please provide correct page breaks in the next version. It appears 
that it is missing the page break markers.

3. Section 2, second paragraph, last sentence: "... and an RTP 
packetization for ES 201 108 frames is defined in [10] in IETF."
I think that " is defined in RFC 3557 [10] by IETF." is a better wording.

4. Section 2.1, third paragraph. "Then, the quantized
    vectors from two consecutive frames are put into an FP, as described
    in more detail in Section 4.1 below."

I think one should spell out FP as this is the first occurrence in text. 
So my proposal is simply:
"Then, the quantized vectors from two consecutive frames are put into an 
frame pair (FP), as described in more detail in Section 4.1 below."

5. Section 3. I think one could avoid duplication of a lot of text by 
creating a first sub chapter of section three describing common 
behaviour. To such a section I think the following parts belong:
- Sections 3.1.1, 3.2.1, 3.3.1
- Sections 3.1.2, 3.2.2, 3.3.2
- Last paragraph of sections 3.1.3.1, 3.2.3.1, 3.3.3.1
- Sections 3.1.4, 3.2.4, 3.3.4


6. Section 3.2.3.1 and 3.3.3.1: Frame description:
"At the end, each FP MUST be padded with 4 zeros to the MSB 4 bits of 
the last octet in order to make the FP aligned to the 32-bit word 
boundary."

This frame is not 32 bit aligned, I propose that you change it to "octet 
aligned".

7. Section 4. I think it will be clearer if you move the registration 
into 3 different listings. That will avoid any unclarities around what 
the sub-type is. It will also make things clearer that there is three 
MIME types. However it will be a bit wasteful.

8. Section 5.
   "Implementations using the payload defined in this specification are
    subject to the security considerations discussed in the RTP
    specification [8] and the RTP profile [9]. This payload does not
    specify any different security services."

I would propose to change the end of the first sentence to: ... security 
considerations discussed in the RTP specification [8] and any RTP 
profile, e.g. AVP [9].

Update these things I think it is in great shape for a WG last call.

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]



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