Re: [AVT] Retransmission draft

Colin Perkins <csp@csperkins.org> Thu, 04 December 2003 15:01 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28345 for <avt-archive@odin.ietf.org>; Thu, 4 Dec 2003 10:01:20 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuyY-0003wG-68 for avt-archive@odin.ietf.org; Thu, 04 Dec 2003 10:01:06 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB4F166m015138 for avt-archive@odin.ietf.org; Thu, 4 Dec 2003 10:01:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuyU-0003ry-6j; Thu, 04 Dec 2003 10:01:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARuxj-0003hx-Un for avt@optimus.ietf.org; Thu, 04 Dec 2003 10:00:15 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28261 for <avt@ietf.org>; Thu, 4 Dec 2003 09:59:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARuxh-0002b5-00 for avt@ietf.org; Thu, 04 Dec 2003 10:00:13 -0500
Received: from dundee.dcs.gla.ac.uk ([130.209.242.163]) by ietf-mx with esmtp (Exim 4.12) id 1ARuxg-0002aT-00 for avt@ietf.org; Thu, 04 Dec 2003 10:00:12 -0500
Received: from spaatz ([130.209.242.185]:2008 helo=mangole.dcs.gla.ac.uk) by dundee.dcs.gla.ac.uk with asmtp (TLSv1:DES-CBC3-SHA:168) (Exim 4.04) id 1ARuwm-0002S5-00; Thu, 04 Dec 2003 14:59:16 +0000
Date: Thu, 04 Dec 2003 14:59:24 +0000
From: Colin Perkins <csp@csperkins.org>
To: rey@panasonic.de
Cc: avt@ietf.org
Subject: Re: [AVT] Retransmission draft
Message-Id: <20031204145924.23d2dc61.csp@csperkins.org>
In-Reply-To: <00a301c3ba6b$691c5f80$05640a0a@panasonic.de>
References: <00a301c3ba6b$691c5f80$05640a0a@panasonic.de>
Organization: http://csperkins.org/
X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386-portbld-freebsd4.9)
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

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.

-- 
Colin Perkins
http://csperkins.org/

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