headers
Tom Taylor | 5 Jan 2010 02:19

Working Group Last Call for draft-ietf-avt-forward-shifted-red-03.txt

This is to announce Working Group Last call for 
draft-ietf-avt-forward-shifted-red-03.txt. Subject to comments received, the 
Last Call period will expire on 18 January 2010.

Tom Taylor
AVT Co-Chair
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
https://www.ietf.org/mailman/listinfo/avt
Permalink | Reply |
headers
Colin Perkins | 18 Jan 2010 23:19

Re: Working Group Last Call for draft-ietf-avt-forward-shifted-red-03.txt

On 5 Jan 2010, at 01:19, Tom Taylor wrote:
> This is to announce Working Group Last call for draft-ietf-avt- 
> forward-shifted-red-03.txt. Subject to comments received, the Last  
> Call period will expire on 18 January 2010.

I have some minor comments.

What are the units of the "forwardshift" media type parameter? Section  
3 implies that it's RTP timestamp units, whereas the appendix suggests  
that it counts codec frames; section 4 doesn't specify a unit.

Is the intent to define this only for audio, or for other top-level  
media types? RFC 4102 defines text/red, but this draft has no  
equivalent. This draft should probably register text/fwdred and  
updated RFC4102, however if there's a good reason for only registering  
audio/fwdred, then the draft title should change to "Forward-shifted  
RTP Payload for Redundant Audio Data".

For the security considerations, this draft introduces an additional  
issue where an excessive forward shift can be signalled, as a denial  
of service. Section 8 should mention this issue, and presumably  
suggest that a receive be prepared to ignore outrageous values.

--

-- 
Colin Perkins
http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
(Continue reading)

Permalink | Reply |
headers
Qiaobing Xie | 21 Jan 2010 17:22
Picon

Re: Working Group Last Call for draft-ietf-avt-forward-shifted-red-03.txt

Hi, Colin,

Thanks for the comments. Please see my response in-line.

Colin Perkins wrote:
> On 5 Jan 2010, at 01:19, Tom Taylor wrote:
>> This is to announce Working Group Last call for 
>> draft-ietf-avt-forward-shifted-red-03.txt. Subject to comments 
>> received, the Last Call period will expire on 18 January 2010.
> 
> 
> I have some minor comments.
> 
> What are the units of the "forwardshift" media type parameter? Section 3 
> implies that it's RTP timestamp units, whereas the appendix suggests 
> that it counts codec frames; section 4 doesn't specify a unit.

It is in RTP timestamp units. Appendix text is meant to be conceptual 
and thus using codec frames. I will improve the wording to remove the 
confusion.

> 
> Is the intent to define this only for audio, or for other top-level 
> media types? RFC 4102 defines text/red, but this draft has no 
> equivalent. This draft should probably register text/fwdred and updated 
> RFC4102, however if there's a good reason for only registering 
> audio/fwdred, then the draft title should change to "Forward-shifted RTP 
> Payload for Redundant Audio Data".

Good point! I think it is a good idea to be consistent with red media
(Continue reading)

Permalink | Reply |
headers
Colin Perkins | 22 Jan 2010 16:50

Re: Working Group Last Call for draft-ietf-avt-forward-shifted-red-03.txt

Qiaobing,

The -04 version looks good to me.
Colin

On 21 Jan 2010, at 16:22, Qiaobing Xie wrote:

> Hi, Colin,
>
> Thanks for the comments. Please see my response in-line.
>
> Colin Perkins wrote:
>> On 5 Jan 2010, at 01:19, Tom Taylor wrote:
>>> This is to announce Working Group Last call for draft-ietf-avt- 
>>> forward-shifted-red-03.txt. Subject to comments received, the Last  
>>> Call period will expire on 18 January 2010.
>> I have some minor comments.
>> What are the units of the "forwardshift" media type parameter?  
>> Section 3 implies that it's RTP timestamp units, whereas the  
>> appendix suggests that it counts codec frames; section 4 doesn't  
>> specify a unit.
>
> It is in RTP timestamp units. Appendix text is meant to be  
> conceptual and thus using codec frames. I will improve the wording  
> to remove the confusion.
>
>> Is the intent to define this only for audio, or for other top-level  
>> media types? RFC 4102 defines text/red, but this draft has no  
>> equivalent. This draft should probably register text/fwdred and  
>> updated RFC4102, however if there's a good reason for only
(Continue reading)

Permalink | Reply |

Gmane