Re: [ssm] wg last call for draft-ietf-ssm-arch-03 complete

hoerdt@clarinet.u-strasbg.fr Fri, 17 October 2003 06:58 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21418 for <ssm-archive@lists.ietf.org>; Fri, 17 Oct 2003 02:58:22 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOYj-00030z-BX; Fri, 17 Oct 2003 02:58:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAOYb-00030n-Jf for ssm@optimus.ietf.org; Fri, 17 Oct 2003 02:57:53 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21389 for <ssm@ietf.org>; Fri, 17 Oct 2003 02:57:43 -0400 (EDT)
From: hoerdt@clarinet.u-strasbg.fr
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAOYX-0007SJ-00 for ssm@ietf.org; Fri, 17 Oct 2003 02:57:49 -0400
Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx with esmtp (Exim 4.12) id 1AAOYW-0007SF-00 for ssm@ietf.org; Fri, 17 Oct 2003 02:57:49 -0400
Received: from clarinet.u-strasbg.fr (clarinet.u-strasbg.fr [130.79.90.157]) by dpt-info.u-strasbg.fr (8.12.3/8.12.3/Debian-6.6) with ESMTP id h9H77Mnv005065; Fri, 17 Oct 2003 09:07:22 +0200
Date: Fri, 17 Oct 2003 08:57:31 +0200
To: Pekka Savola <pekkas@netcore.fi>
cc: Hugh Holbrook <holbrook@cisco.com>, ssm@ietf.org, supratik@sprintlabs.com
Subject: Re: [ssm] wg last call for draft-ietf-ssm-arch-03 complete
In-Reply-To: <Pine.LNX.4.44.0310170924511.21517-100000@netcore.fi>
Message-ID: <Pine.LNX.4.56.0310170847001.9554@clarinet.u-strasbg.fr>
References: <Pine.LNX.4.44.0310170924511.21517-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable

I have read the patent (very fast), and as the title seems to be
impressive, the described technology is not really related to SSM in my
opinion.  One thing that we could do is to note the differences between
SSM and this patent.  What I have notivec after a first fast reading :

- Apple propose to use another layer for Multicast, not SSM.
- Apple propose to use a network number embedded in the Multicast address,
  not SSM.
- Apple propose a scheme to allocate multicast addresses on the local
  network (because it use a network number), not SSM.

I am pretty sure that there are other differences. Theses differences
are important, enough important to make an apple "SSM" implementation not
compatible with the SSM architecture described in the drafts, is this
enough to say that the patent is irrelevant ?

Hoerdt Mickaël
LSIIT-Strasbourg

On Fri, 17 Oct 2003, Pekka Savola wrote:

> On Mon, 13 Oct 2003, Hugh Holbrook wrote:
> [...]
> > The only unclosed discussion regarding this draft surrounds the
> > intellectual property rights statement posted to the IETF web site
> > back in March (reproduced below).  There was some brief discussion of
> > it on the mailing list back in April, but we didn't really close the
> > topic, and so I'd like to bring it up again.  So, with this IPR
> > statement in mind, let me now ask anyone who has opinions on the topic
> > of whether to advance draft-ietf-ssm-arch-04.txt to Proposed Standard
> > to speak up.
> [...]
>
> I think I've said this before, but as nobody else seems to want to throw
> the first rock, let me do it.. :-)
>
> I don't think we can advance SSM unless we get a guarantee of RF licensing
> or get a reasonably sure feeling that SSM implementations would not
> infringe the patent in question.
>
> SSM is targeted as *way* too fundamental piece of technology, and locking
> out those who are unable to do non-RF licensing (e.g. different open
> source communities) is simply unacceptable.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
> _______________________________________________
> ssm mailing list
> ssm@ietf.org
> https://www1.ietf.org/mailman/listinfo/ssm
>

_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm