Subject: [Rmt] on the opportunity to design an alternative to FLUTE

From: Vincent Roca <[email-masked]>
Date: Wed, 05 Dec 2007 02:12:24 +0100

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-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 4 Dec 2007 19:24:31 -0800

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:

> their opinion on the opportunity to continue the work on an  
> alternative to FLUTE
> If feasible, this alternative application could be designed so that  
> it works on both ALC
> and NORM.
>
> https://datatracker.ietf.org/ipr/102/   (the original IPR  
> disclosure, Feb. 2003)
>

---

From: Vincent Roca <[email-masked]>
Date: Thu, 06 Dec 2007 04:03:36 +0100

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.