Subject: [AVT] Re: Comments on DSR drafts

From: Magnus Westerlund <[email-masked]>
Date: Mon, 03 Nov 2003 09:34:16 +0100

Hi Qiaobing,

See comments inline.

Qiaobing Xie wrote:

> Hi, Magnus,
> 
> Thank you very much for the feedback. Please see my comments/answers
> in-line.
> 
> Magnus Westerlund wrote:
> 
>>Hi Qiaobing,
>>
>>I have looked at your three dsr drafts:
>>  draft-ietf-avt-dsr-es202050-01.txt
>>  draft-xie-avt-xdsr-es202211-00.txt
>>  draft-xie-avt-xadsr-es202212-00.txt
>>
>>1. My first comment is that these three draft could easily be folded
>>into a single draft. To my understanding they have a lot in common. The
>>only real difference is the actual internal frame format and that 050
>>have shorter frames then 211 and 212. Then there is the need define
>>individual MIME types for each. However this seems to be about all.
>>Having a single draft will reduce the workload on IESG and RFC editor
>>slightly. It will also make it less RFC to keep track of.
> 
> 
> I talked with Steve C. about this a year ago. At that time, the
> front-ends were at very different maturity levels in ETSI. So we agreed
> to create separate draft for each front-end. Now things have progressed
> and my understanding is that all three front-ends above are finalized in
> ETSI. So, I think to combine them may be a good thing to do.
> 
> We can either merge 050 and 212 into one draft (since they are more
> logically related) and leave 211 stand-alone, or fold all three into one
> draft. I will double-check with my ETSI colleagues about this and if
> there is no other issues, will release merged version after this IETF
> meeting.
> 

I think they from an RTP transport perspective are all the same and 
therefore could be had in one specification.

> 
>>3. I think the security consideration is a bit thin. Are you really
>>certain that the format does not result in any special considerations?
> 
> 
> Besides defining their specific frame bit-format, these payload
> definitions do not add anything else to the standard RTP functions (they
> may be one of the most straightforward RTP payloads). I really do not
> see any special security issues introduced. I'd appreciate for any input
> on this.
> 

Okay, good. There is no DSR frame that can creates unusual high 
processing requirements on receiver side?

Except for the merger there seem to be few problems with these formats. 
I would some more revisions to get the editorial nits right. I spotted 
some minor editorial things, I didn't comment on them due to that I saw 
the need to merge the document and that process will probably reveal 
them and create some other instead.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 07 Nov 2003 18:05:25 -0600

Hi, Magnus,

Magnus Westerlund wrote:
...
> therefore could be had in one specification.

Ok, I will merge the three into one draft after the IETF.

> processing requirements on receiver side?

To my knowledge the values in a DSR frame (mostly indexes of a small,
fixed size codebook) are not capable of creating this type of threats.

regards,
-Qiaobing