Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-atrac-family-10.txt

[Mitsuyuki Hatanaka <actech at jp.sony.com>]

Dear Colin,

Thank you for your comments.
We'll reconsider and revise soon.

Best regards,
Mitsuyuki Hatanaka

At 18:56 07/09/24 +0100, Colin Perkins wrote:
>Hatanaka-san,
>
>On 23 Aug 2007, at 03:00, Mitsuyuki Hatanaka wrote:
>> We have submitted our revised internet draft as
>> "draft-ietf-avt-rtp-atracx-family-10.txt".
>> You will be able to get it from the on-line Internet-Drafts  
>> directories.
>>
>> The revised points are as follows.
>> (1) The description of decoder control was added in section 4.5.2,
>>     in response to the case that the number of base and enhancement
>>     layer incoming packet is not identical at the presentation time
>>     in scalable multi-session streaming.
>>
>> (2) The explanation of "Marker" was modified in Section 5.2.
>>
>> (3) The description of "Timestamp" for ATRAC Advanced Lossless
>>     was added in section 5.2.
>>
>> (4) The description of "Subtype name" was deleted correspinding to
>>     the elimination of vendor tree registration for ATRAC3, ATRAC-X  
>> and
>>     ATRAC Advanced Lossless in Section 7.1, 7.2 and 7.3 respectively.
>>
>> (5) The description of "rate" for ATRAC3 was added in Section 7.1.
>>
>> (6) The description of "Security Consideration" was modified from
>>     Section 7.1 through Section 7.3.
>>
>> (7) Referenced standard information was modified in Section 9.
>
>Thank you for submitting this update. I've reviewed it carefully, and  
>have found some minor issues, which it would be good to address:
>
>(1) Section 4.5.2: The -10 draft adds a restriction that, when using
>     multi-session streaming, the RTP sequence numbers should match  
>across
>     layers. Why is this? Since frames are identified by the RTP  
>timestamp,
>     I would think it better to align timestamps across layers.
>
>(2) Section 5.2: In the definition of the marker bit usage, remove  
>the text
>     "The details of usage SHALL be defined by the RTP profile used",  
>since
>     this draft defines the usage itself.
>
>(3) Section 5.2: Add a note that the SSRC, CC, and CSRC fields are  
>used as
>     defined in RFC 3550.
>
>(4) Section 5.3.1: The terminology in this section is inconsistent, with
>     some parts using "packet" and some using "frame". Please update  
>this
>     to use "frame" throughout for consistency with the rest of the  
>draft.
>
>(5) Section 5.3.2.1: Please change "It provides..." to "This payload  
>format
>     provides..." for clarity.
>
>(6) Section 7.6: How is multi-session transport signalled in SDP? The
>     mechanism in draft-schierl-mmusic-layered-codec-04.txt would seem
>     to be appropriate. Can you add some discussion, and a reference?
>
>(7) Section 7.8: Please update the examples to be complete (valid) SDP
>     files, rather than m= line fragments.
>
>(8) Section 8: Need to specify the top-level media types that are to be
>     registered, i.e. "Three new media subtypes, for audio/ATRAC3,
>     audio/ATRAC-X and audio/ATRAC-ADVANCED-LOSSLESS are requested..."
>
>Once these changes are made, I believe this draft will be ready for  
>working group last call.
>
>Regards,
>-- 
>Colin Perkins
>http://csperkins.org/
>
>
>
> 


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt