Re: [Softwires] France Telecom's IPR Statement about 4rd

Rémi Després <despres.remi@laposte.net> Wed, 10 April 2013 07:23 UTC

Return-Path: <despres.remi@laposte.net>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522F821F8AF8; Wed, 10 Apr 2013 00:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cr+M8w3eBrle; Wed, 10 Apr 2013 00:23:09 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0361B21F845E; Wed, 10 Apr 2013 00:23:07 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id C89DD70000E8; Wed, 10 Apr 2013 09:23:06 +0200 (CEST)
Received: from [192.168.0.21] (unknown [78.193.136.169]) by msfrf2412.sfr.fr (SMTP Server) with ESMTP id 7A703700007F; Wed, 10 Apr 2013 09:23:06 +0200 (CEST)
X-SFR-UUID: 20130410072306501.7A703700007F@msfrf2412.sfr.fr
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Rémi Després <despres.remi@laposte.net>
In-Reply-To: <5164F579.4060404@ericsson.com>
Date: Wed, 10 Apr 2013 09:23:06 +0200
Message-Id: <1B297169-99E4-4763-A653-4C2E44F9EDE5@laposte.net>
References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net> <5164F579.4060404@ericsson.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
X-Mailer: Apple Mail (2.1503)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Softwires WG <softwires@ietf.org>, IETF Secretariat <ietf-ipr@ietf.org>, ipr-announce@ietf.org
Subject: Re: [Softwires] France Telecom's IPR Statement about 4rd
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 07:23:11 -0000

2013-04-10 à 07:15, Suresh Krishnan <suresh.krishnan@ericsson.com> :

> Hi Remi,
>  I just wanted to point out that the IETF will make no determination
> about the validity of any particular IPR claim as specified in RFC3979
> and derived from the principles established in Section 10 of RFC2026.
> Any RFC listed in an ipr disclosure will have a notice added (described
> in Section 5 of RFC3979) that will contain a disclaimer of validity.

Thanks, Suresh,

Actually, I am well aware of this.

In my understanding, this justifies that an IPR statement that doesn't concern an RFC (with due understanding of initiators of the statement), should be deleted by its initiators, in good faith, rather than inappropriately listed in the RFC itself.

In this context, whether a 4rd IPv6 address can contain, or not, an IPv4 address followed by a port number is, for example, a simple technical matter on which the WG, and in particular a knowledgeable contributor like Med, is well placed to conclude .


Regards,
RD



> Thanks
> Suresh
> 
> On 04/09/2013 11:58 AM, Rémi Després wrote:
>> Dear Med, dear all,
>> 
>> I carefully checked France Telecom's IPR statement we just received about 4rd.
>> For reasons detailed below, I found that none of the three listed patents applies to 4rd.
>> 
>> Could you please, Med, check the technical analysis and, if we reach common understanding, see to it that the IPR statement be either deleted or appropriately updated. 
>> 
>> Thanks,
>> RD
>> 
>> 
>> __________________
>> TECHNICAL ANALYSIS
>> 
>> 1. 4rd isn't concerned with patent EP 2294798 because uses of for port numbers for address sharing are radically different.
>> 
>> - In EP 2294798, deriving a destination "identifier" from an original address + port must include these two steps: (1) find which PORT RANGE is matched by the destination port among those that are recorded as relevant to this destination address; (2) take as destination identifier that which is recorded as associated with this address/port-range couple.
>> 
>> - In 4rd, deriving a destination IPv6 address from an IPv4 A+P includes these two steps: (1) find which IPV4 PREFIX is matched by the IPv4 address, among recorded Rule IPv4 prefixes; (2) take as prefix of the IPv6 destination the concatenation of three parts: the Rule IPv6 prefix of the mapping rule that has the found IPv4 prefix; all bits that, in the IPv4 address, follow this IPv4 prefix; some bits of the destination port. 
>> 
>> Looking for a match between an IPv4 address and an IPv4 PREFIX is radically different from looking for a PORT RANGE that contains a given port.
>> 
>> 
>> (Incidentally, the same analysis applies AFAIK to MAP-E and MAP-T.) 
>> 
>> 
>> 
>> 2. 4rd isn't concerned with patents EP 2297927 and/or EP 2297927 because address formats are beyond doubt incompatible. 
>> 
>> - In both EP 2297927 and EP 2297928, each IPv6 address constructed from an IPv4 A+P MUST CONTAIN the FULL IPv4 address FOLLOWED BY the port number.
>> 
>> - In 4rd, an IPv6 address derived from an IPv4 A+P NEVER contains the FULL IPv4 address FOLLOWED by a port number:
>> 
>> . The full IPv4 address is always embedded in bits 80-111 of IPv6 addresses, but always followed by a CNP field which has no relation to the port number (Figure 5).
>> 
>> . With a CE mapping rule, the first 64 bits of the IPv6 address may contain part of the IPv4 address but NEVER the full address. (A CE mapping rule has a Rule-IPv4-prefix length k > 0  because with k = 0 it couldn't be distinguished, by address longest match, from the BR mapping rule whose k must be 0. With k > 0, at most 32 - k bits of IPv4 addresses can be embedded in 4rd IPv6 prefixes.) 
>> 
>> . With the BR mapping rule, no IPv4-address bit is embedded in the first 80 bits of IPv6 addresses (Figure 5).
>> 
>> 
>> (Incidentally, the same reasoning doesn't apply to MAP-E and MAP-T because their PSIDs are repeated after embedded IPv4 addresses. Where PSID lengths are 16 bits, which is permitted, IPv6 addresses do contain IPv4 addresses followed by port numbers.)
>> __________________
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 2013-04-05 19:53, IETF Secretariat <ietf-ipr@ietf.org> :
>> 
>>> 
>>> Dear Remi Despres, Reinaldo Penno, Yiu Lee, Gang Chen, Sheng Jiang, Maoke Chen:
>>> 
>>> An IPR disclosure that pertains to your Internet-Draft entitled "IPv4 Residual
>>> Deployment via IPv6 - a Stateless Solution (4rd)" (draft-ietf-softwire-4rd) was
>>> submitted to the IETF Secretariat on 2013-03-20 and has been posted on the "IETF
>>> Page of Intellectual Property Rights Disclosures"
>>> (https://datatracker.ietf.org/ipr/2050/). The title of the IPR disclosure is
>>> "France Telecom's Statement about IPR related to draft-ietf-softwire-4rd-04."");
>>> 
>>> The IETF Secretariat
>>> 
>> _______________________________________________
>> Softwires mailing list
>> Softwires@ietf.org
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
>