[core] IPR/3241 (Re: Upcoming virtual interim meetings (Re: CoRE@IETF102: Summary))

Carsten Bormann <cabo@tzi.org> Thu, 09 August 2018 13:41 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 04561130E68 for <core@ietfa.amsl.com>; Thu, 9 Aug 2018 06:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nOfRz7nvy3ZZ for <core@ietfa.amsl.com>; Thu, 9 Aug 2018 06:41:34 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4E8127598 for <core@ietf.org>; Thu, 9 Aug 2018 06:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de []) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w79DfU9l022782; Thu, 9 Aug 2018 15:41:31 +0200 (CEST)
Received: from [] (p54A6C84F.dip0.t-ipconnect.de []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 41mTtf4hDczDXR3; Thu, 9 Aug 2018 15:41:30 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAAzbHvZJCNM_PUdpOUcLZyqU3e0a+afzKuVMWR8can9agOpB3Q@mail.gmail.com>
Date: Thu, 9 Aug 2018 15:41:30 +0200
Cc: Core <core@ietf.org>
X-Mao-Original-Outgoing-Id: 555514888.40469-f3f9d8c3030d82815a0acd464a96a690
Content-Transfer-Encoding: quoted-printable
Message-Id: <DBCDEB6F-C6FD-44B9-80EA-562740CC52D4@tzi.org>
References: <D9C33C35-5F27-44B8-9431-B68F0BD029B0@tzi.org> <9B5EC459-15BC-45F0-BC6B-0F4C4994AB15@tzi.org> <CAAzbHvaQVHKkFzr=ivPwegVn=AWPKB9+iD-DhuTMaTHz96fmQQ@mail.gmail.com> <CAAzbHvZJCNM_PUdpOUcLZyqU3e0a+afzKuVMWR8can9agOpB3Q@mail.gmail.com>
To: Klaus Hartke <hartke@projectcool.de>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/W_B2PpXpQ-nAr1ZG5nBJjT_4LKc>
Subject: [core] IPR/3241 (Re: Upcoming virtual interim meetings (Re: CoRE@IETF102: Summary))
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Aug 2018 13:41:37 -0000

On Aug 9, 2018, at 14:50, Klaus Hartke <hartke@projectcool.de> wrote:
> https://datatracker.ietf.org/ipr/3241/

Right.  Not sure that we need to spend time on this in the interim.

At the next main meeting, the chairs plan to have a short segment on timely patent claim (“IPR”) disclosures.

{“chair-hat”: “off”, “discussion”: “

(Warning: The following lines are not legal advice, I’m not a lawyer.
Please stop reading here if you don’t want to be encumbered by the discussion; yes: in some jurisdictions what you know can be used against you.
As a general piece of advice that I’m not going to further detail, it is usually counterproductive to discuss validity of patent claims on an open mailing list.  I’m making an exception here for a reason.)

I don’t read patent claims, but made an exception here because of the surprise moment.

The priority date on this patent is March 2011, which is when we discussed having a way to communicate the total size of the representation of a resource that is accessed via the Block protocol.  At the time, one of the inventors listed on the patent had a draft describing a Size option for this(*).  These morphed into Size1, Size2, and eventually became a separate, independent part of the overall block-wise transfer protocol.

I personally don’t see a need for the WG to act here, for the following reasons:

— the licensing conditions seem fine to this non-lawyer (defensive/reciprocal only, no charge).
— the part of the block-wise protocol that could be affected (the Size1/Size2 options) are optimizations one can live without (and, as far as I am aware, are not widely implemented).
— frankly, if my hypothesis that there was no patent claim disclosure (“IPR disclosure”) at the time, and for seven more years, is true, that might weaken any claims.
— both a bug and a feature: This is a Chinese patent, so for many people any juridical handling of this may be harder to predict than for patent claims closer to home.  But then, this seems to be relevant for the Chinese market only.

All that said, of course, the patent claim is one more little thing someone might have to look at who wants to productize a full-function implementation of the block-wise transfer protocol, increasing transaction costs.

“}.  WG chair hat back on: 

I applaud Huawei for making this disclosure; late is better than never.
In the unlikely event that WG members do see a need for the WG to act on this disclosure, please converse in private with the chairs first: core-chairs@ietf.org

Grüße, Carsten

(*) I cannot find a patent claim (“IPR”) disclosure on this: https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-li-core-coap-size-option — but maybe I’m not looking at the right place.