Re: on the opportunity to design an alternative to FLUTE

Dear Stephan, everybody,

Just to make it clear: the decision belongs to the group, hence this 
"call for opinion".
Your opinion is welcome as well as the opinion of other participants.

A few __technical__ points I see in favor of an alternative along the 
lines of the original
FCAST (the one sketched in March 2000):

1- There are situations where all receivers are supposed to get all the 
objects sent during
  the session (rather than selecting a subset of the objects received as 
made possible by
  FLUTE). In that case, having meta-data appended to the file and 
delivered as a single
  aggregate object:
   1.1- is more efficient from a transmission perspective since it 
removes the interdependency
   between the reception of the object and the reception of the metadata 
if they are
   delivered separately. Typically with FLUTE, the FDT Instance needs to 
be delivered
   regularly (at carousel startup and periodically later on). With a 
solution that appends
   metadata to the file, once the object is decoded the receiver has 
whatever he needs
   to exploit it, and the metadata needs to be delivered only once (or 
at least as many
   times as the object itself, be it because of the repair redundancy 
added or because of
   several carousel transmission cycles).
   1.2- is more efficient from an error recovery perspective, since the 
metadata benefits
   naturally from the FEC protection of the object it belongs to (when 
used). This is not
   the case with FLUTE.

2- FLUTE has been designed to work on top of ALC. We can probably design an
  application that runs on top of both ALC and NORM (in fact I did it 
before).
  Honestly speaking, the same can perhaps be done with FLUTE, but it has 
not been
  considered so far and I don't expect any update of FLUTE to do that.

Now we can also discuss about __IPR aspects__ since it is common 
practice for working
groups to have a look at IPR details and get an opinion of its content.

As already explained, the foundations of the FCAST proposal come from a 
public
document that has been published three years before the patent priority 
date...
Concerning the possible extensions on top of this underlying proposal, 
we clearly need to
be more careful... But the design team (assuming the RMT group approves 
this initiative)
might also decide to stick with the basic scheme only. And somebody else 
might also
come with another brand new technique.

Besides there are situations where there's no need to follow any 
standard, and where
proprietary solutions are perfectly suitable. In that case the designer 
will probably prefer
solutions that are not been subject to any IPR disclosure (which of 
course does not mean
there is none, but no matter what you do, there will always be risks). 
This is all the more
true as in these situations, IPR negotiations are more complex (as I 
understand, correct
me if I'm wrong) than in case of well recognized standards where all 
proponents benefit
from global patent pool negotiations.

Having said that, FLUTE remains a great, useful, technology, with 
several commercial
perspectives of which many of us benefit, including myself. Don't 
misunderstand me, it
has never been my intention to deny this point, and __I'm still a FLUTE 
supporter__
for all situations where it makes sense.

Hope it clarifies my position.

Regards,


  Vincent.

NB: thanks for catching the error, RFC 3979 is the appropriate RFC.

Stephan Wenger wrote:

> Hi Vincent, folks,
> I believe I have said this in Prague already: it is somewhat tricky  
> to design around a well written patent or patent application  
> (especially if there is still a chance for the alarmed rightholder to  
> amend the claims).  I do not encourage such an attempt.  Let me  
> suggest to base a decision predominantly on potential technical  
> merits of a FLUTE successor, rather than attempting an arms-race with  
> lawyers on patent coverage.
> This is going to be my last statement on this matter.
> Cheers,
> Stephan
> P.s.: I work for Nokia, the company which has made an IPR disclosure  
> towards FLUTE-revised.
> P.p.s.: instead of RFC3667, you may wish to cite the up-to-date  
> patent policy document (RFC3979), or use the generic designation  
> (BCP79).
>
>
> On Dec 4, 2007, at 5:12 PM, Vincent Roca wrote:
>
>> Hello,
>>
>> During the RMT meeting, today morning, it was decided to ask the  RMT 
>> members
>> their opinion on the opportunity to continue the work on an  
>> alternative to FLUTE
>> for which an IPR has been disclosed in June 2006 (see below for the  
>> details).
>> If feasible, this alternative application could be designed so that  
>> it works on both ALC
>> and NORM.
>>
>> If it turns out that there is an interest, the sub-question is the  
>> following:
>>  Are there volunteers to work on the subject in order to design an  
>> alternative that
>>  bypasses the FLUTE patents?
>>
>> Don't hesitate to speak up.
>> Cheers,
>>
>>  Vincent.
>>
>>
>> ** Nokia's IPR disclosures  related to FLUTE:
>> https://datatracker.ietf.org/ipr/733/
>> but also:
>> https://datatracker.ietf.org/ipr/517/   (FLUTE and SDP)
>> https://datatracker.ietf.org/ipr/635/   (file aggregation for FLUTE)
>> https://datatracker.ietf.org/ipr/731/   (RFC 3926)
>> https://datatracker.ietf.org/ipr/102/   (the original IPR  
>> disclosure, Feb. 2003)
>>
>> ** IETF position W.R.T. IPR:
>> http://www.ietf.org/rfc/rfc3668.txt?number=3668
>> ** Minutes of IETF67 RMT meeting, where this point has been raised
>> (see item 6, "open discussion"):
>> http://www3.ietf.org/proceedings/06nov/minutes/rmt.html
>>
>> **More information on the FCAST proposal is available here:
>> http://www3.ietf.org/proceedings/07mar/slides/rmt-0/sld1.htm
>> http://tools.ietf.org/html/draft-roca-rmt-newfcast-00
>>
>>
>> _______________________________________________
>> Rmt mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/rmt
>
>