Re: [Fecframe] Working Group Item? was: Re: draft-zixuan-fecframe-source-mi ??

[zouzixuan <tendyntu at huawei.com>]

Hi, 
  > > The focus of our draft is on backward-compatibility issue. Separate
flow is just
> an
> > option. Based on the previous discussion on the draft, now we think
defining a
> generic
> 
> What other option(s) do you propose?
Other option can be repair flow.

> Ow, I suggest the non-compatible clients to stick with the non-complicated
FEC
> scenarios. This whole stuff is not worth the effort IMO.
>

So we need to draw a conclusion on if compatibility is a worth work or not
in FEC framework. 


Zou ZiXuan, Senior Research Staff
Media & Communication Lab
HUAWEI TECHNOLOGIES CO.,LTD. 

Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
Tel: +86 0755 28789364
Fax: +86 0755 28788317
E-mail: tendyntu at huawei.com
www.huawei.com
----------------------------------------------------------------------------
---------------------------------------------------------
This e-mail and its attachments contain confidential information from
HUAWEI, which 
is intended only for the person or entity whose address is listed above. Any
use of the 
information contained herein in any way (including, but not limited to,
total or partial 
disclosure, reproduction, or dissemination) by persons other than the
intended 
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by 
phone or email immediately and delete it!

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> Sent: Saturday, October 10, 2009 3:23 AM
> To: zouzixuan; Einat Yellin (Lachover); gjshep at gmail.com
> Cc: tme at multicasttech.com; fecframe at ietf.org
> Subject: RE: RE: Working Group Item? was: Re:
> [Fecframe]draft-zixuan-fecframe-source-mi ??
> 
> > The focus of our draft is on backward-compatibility issue. Separate flow
is just
> an
> > option. Based on the previous discussion on the draft, now we think
defining a
> generic
> 
> What other option(s) do you propose?
> 
> Using a separate flow requires additional support on the clients already
> supporting the framework. Rather than wasting that energy on those
> modifications, I'd rather prefer making the non-framework clients
compatible
> with the framework if they indeed want to benefit from the framework
> features.
> 
> Ow, I suggest the non-compatible clients to stick with the non-complicated
FEC
> scenarios. This whole stuff is not worth the effort IMO.
> 
> -acbegen
> 
> > mapping information format for various ways of building source block in
> practice should be
> > the most important issue for backward compatibility. We suggest to make
> this work
> > (defining a generic mapping information format) to be a work item. We
can
> update our draft
> > to be the basis of this work.