Subject: [AVT] Working Group Last Call for draft-ietf-avt-forward-shifted-red-03.txt

From: Tom Taylor <[email-masked]>
Date: Mon, 04 Jan 2010 20:19:02 -0500

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 18 Jan 2010 22:19:30 +0000

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/

---

From: Qiaobing Xie <[email-masked]>
Date: Thu, 21 Jan 2010 10:22:12 -0600

Hi, Colin,

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

Colin Perkins wrote:
>> draft-ietf-avt-forward-shifted-red-03.txt. Subject to comments 
>> received, the Last Call period will expire on 18 January 2010.
> 
> 
> What are the units of the "forwardshift" media type parameter? Section 3 
> implies that it's RTP timestamp units, whereas the appendix suggests 

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.

> 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 
types and the same benefits also apply to text redundant. I will add 
wording for registering text/fwdred and updating RFC4102.

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

Agreed. Will add wording to that effect.

regards,
-Qiaobing

---

From: Colin Perkins <[email-masked]>
Date: Fri, 22 Jan 2010 15:50:38 +0000

Qiaobing,

The -04 version looks good to me.
Colin

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

>> 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.
>
>> 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 types and the same benefits also apply to text redundant. I  
> will add wording for registering text/fwdred and updating RFC4102.
>
>> 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.
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

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