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

[Qiaobing Xie <[e-mail]>]

Hi, Magnus,

Thank you very much for the comments. I am updating the draft with your comments. Please see 
my detailed responses in-line.

Magnus Westerlund wrote:

> 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.

updated.

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

will double check that.

> 
> 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.

ok.

> 
> 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."

ok

> 
> 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

That's a great suggestion. I like it.

> 
> 
> 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".

good catch. will fix.

> 
> 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.

changed per suggestion.

> 
> 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].

ok.

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

Great. I will have the revised I-D submitted very soon.

regards,
-Qiaobing

> 
> 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