Re: on the opportunity to design an alternative to FLUTE

Vincent,

I would be interested in contributing to an FCAST update as I can, 
particularly wr2 to point #2 below that it could be applied to NORM 
as well.

best regards,




At 4:03 AM +0100 12/6/07, Vincent Roca wrote:
>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
>>
>>
>
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt


-- 
Brian
__________________________________
Brian Adamson
<mailto:[email protected]>