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

Suresh Krishnan <suresh.krishnan@ericsson.com> Wed, 10 April 2013 05:18 UTC

Return-Path: <suresh.krishnan@ericsson.com>
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 4310421F9138; Tue, 9 Apr 2013 22:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level:
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
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 FSG9A3XpQO8v; Tue, 9 Apr 2013 22:18:15 -0700 (PDT)
Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 685B321F9130; Tue, 9 Apr 2013 22:18:15 -0700 (PDT)
X-AuditID: c618062d-b7f0d6d00000097e-ac-5164f6169be4
Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.0B.02430.616F4615; Wed, 10 Apr 2013 07:18:14 +0200 (CEST)
Received: from eusaamw0712.eamcs.ericsson.se (147.117.20.181) by EUSAAHC007.ericsson.se (147.117.188.93) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 10 Apr 2013 01:18:14 -0400
Received: from [164.48.125.41] (147.117.20.214) by smtps-am.internal.ericsson.com (147.117.20.181) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 10 Apr 2013 01:18:13 -0400
Message-ID: <5164F579.4060404@ericsson.com>
Date: Wed, 10 Apr 2013 01:15:37 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: Rémi Després <despres.remi@laposte.net>
References: <20130405175307.17053.57704.idtracker@ietfa.amsl.com> <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net>
In-Reply-To: <86BE1CED-B837-4BC5-B7DD-CEFF338845BC@laposte.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUyuXRPrK7Yt5RAgzdTrSxO3nrIZNG+7T6L xdnuGewWh98+BRLLtjI5sHosWfKTyePc+8lMHi3PTrIFMEdx2aSk5mSWpRbp2yVwZcw585G1 4LBixeIzfYwNjJ+kuhg5OSQETCT+3djEDmGLSVy4t56ti5GLQ0jgKKPE87bnLBDOHkaJq3u/ soBUCQlsZZSYt9UXxOYV0Jb482gfI4jNIqAq8XfpfFYQmw1o6oadn5lAbFGBMIm9F6axQdQL Spyc+QRsjoiAg8Tjq5uZQBYwC8xilJjx5hbYIGEBR4nWRUuhlpVIbNgzBWwQp4C9xPEbO9gg TpWU2PKiHexsZgE9iSlXWxghbHmJ5q2zmSF6NSW2rvnOOoFReBaS3bOQtMxC0rKAkXkVI0dp cWpZbrqRwSZGYMAfk2DT3cG456XlIUZpDhYlcd4g1wsBQgLpiSWp2ampBalF8UWlOanFhxiZ ODilGhgX7pG/VHJxxatVPxQ9L03uSDq2/88aDbFwnjPP3D6dfyCTpsF613DlpYyaEyHtWn2F LifOylg5/ytm+nRjdumTvpd/Ch9eE/VOdNv2w8N9R8aXTeVOHxsSOHd3LPH/lrXY98idG3Nr 1p1qbIo+eEH/5be8zjtrpzjIzuaQ/rWnWNNV9VvcjCglJZbijERDLeai4kQAO/badEYCAAA=
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 05:18:16 -0000

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

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
>