RE: [AVT] Retransmission draft

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: Thursday, December 04, 2003 3:59 PM
> To: rey@panasonic.de
> Cc: avt@ietf.org
> Subject: Re: [AVT] Retransmission draft
>
>
> José,
>
> [cc list trimmed]
>
> --> José Rey <rey@panasonic.de> writes:
> > in the past weeks I had some intensive internal discussions
> on the matter
> > of the potential IPRs on the RTP retransmission draft. As a WG
> > participant I perfectly understand and respect the comments
> and interests
> > expressed by you and others of the AVT group. In order to
> keep the good
> > working spirit in AVT it is my strong intention to adress
> these comments
> > in the best possible way by taking the interests of all
> parties involved
> > in this work into account.
> >
> > Matsushita has published an IPR statement that it is
> prepared to grant a
> > license on reasonable, nondiscriminatory terms and conditions (in
> > accordance with paragraph 10.3.3 of the RFC 2026) on any
> part that is
> > included into the RTP retransmission standard and that Matsushita
> > possibly holds IPRs on. Providing a royality-free license
> to open-source
> > developers will unfortunately lead to a situation where
> Matsushita will
> > lose any rights on their IPRs in most cases. Taking into
> account the work
> > and effort (we started with the retransmission draft in AVT
> more than 2.5
> > years ago) we spent into this draft, this is not acceptable for
> > Matsushita.
> >
> > On the other hand, we believe that the situation for open-source
> > developers is quite easy to solve by other means. First of
> all they are
> > not in any way'forced' to implement RTP retransmission. It
> is just an
> > optional repair mechanism for the RTP protocol, as
> described in RFC2354.
> > In order to solve the problems that RTP retransmission
> tries to solve,
> > there are other solutions available from the AVT group which are not
> > encumbered by IPRs, e.g. RFC2733 and draft-ietf-avt-ulp-08.txt. This
> > makes the implementation of the RTP retransmission solution purely
> > optional and easily avoidable to everyone.
>
> Provided it is clear that the mechanism is encumbered, yes.
>
> > In order to make this situation clear to anybody who reads the RTP
> > retransmission draft, we suggest to add a paragraph at the
> very beginning
> > of the draft. This paragraph will make implementors aware of the
> > situation that the solution described in this draft is possibly
> > encumbered by IPRs. Furthermore it will point implementors to
> > non-IPR-encumbered solutions as above, which may perfectly be used
> > instead of RTP retransmission.
>
> Without seeing the wording of this paragraph, I can't give a
> definitive
> answer, but that would largely address my concerns.
>

right, how about this:

"This document provides an RTP packet retransmission mechanism for repair of
streaming media.  The purpose of this paragraph is to make the reader aware
that the retransmission mechanism described in this document may be
encumbered by patent applications filed from Matsushita.  For details on the
IPR statement, please visit the IETF IPR web page
http://www.ietf.org/ietf/IPR.

However, packet retransmission is not the only means for streaming clients
and servers to cope with packet losses.  A detailed description of options
for repair of streaming media is given in RFC2354.  Therefore, implementers
of this protocol shall take into account that there are in fact other
mechanisms, such as forward error correction (FEC) or packet interleaving
that represent an alternative to solve the problems packet retransmission
tries to solve.    In particular RFC2733 and RFC2198 present FEC and
redundant packet transmission schemes that might well fit to the needs of
the implementer. "

José
> --
> Colin Perkins
> http://csperkins.org/

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt