Subject: [AVT] Comments on DSR drafts

From: Magnus Westerlund <[email-masked]>
Date: Tue, 28 Oct 2003 14:12:08 +0100

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.

2. You should make a reference to maxptime rather then define it 
yourself. Either RFC 3267 or make it dependent on SDP-new.

3. I think the security consideration is a bit thin. Are you really 
certain that the format does not result in any special considerations?

4. You might want to clarify in mapping MIME to SDP that even if no rate 
is given the default value must be given here.

5. What use is the NULL frame? It is defined in all drafts but not 
declared how they should be used.

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, 31 Oct 2003 11:31:48 -0600

Hi, Magnus,

Thank you very much for the feedback. Please see my comments/answers
in-line.

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

> yourself. Either RFC 3267 or make it dependent on SDP-new.

will do.

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

> is given the default value must be given here.

ok

> declared how they should be used.

It is used to signal the end of a transmission segment, per definition
in ETSI specs (it is also discussed in RFC3557). Will make it clearer in
the new drafts.

regards,
-Qiaobing