Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?

Antoin Verschuren <ietf@antoin.nl> Wed, 09 November 2016 18:47 UTC

Return-Path: <ietf@antoin.nl>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00C4129559 for <regext@ietfa.amsl.com>; Wed, 9 Nov 2016 10:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.498
X-Spam-Level:
X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=antoin.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYFxdA6NMZMT for <regext@ietfa.amsl.com>; Wed, 9 Nov 2016 10:47:57 -0800 (PST)
Received: from walhalla.antoin.nl (walhalla.antoin.nl [IPv6:2a01:670:6aa4:da00::6]) (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 34531129643 for <regext@ietf.org>; Wed, 9 Nov 2016 10:47:57 -0800 (PST)
Received: from [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2] (unknown [IPv6:2a01:670:6aa4:da00:462a:60ff:fef4:e7f2]) by walhalla.antoin.nl (Postfix) with ESMTPSA id E2A5828043A; Wed, 9 Nov 2016 19:47:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antoin.nl; s=walhalla; t=1478717275; bh=vwmTgU4S5Y7g8CrJKul1WxSjksIa7lwnvr3wc/8CRhk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=RYU/iFJtgN5CrBhc3GZvazdaJhG6Rcr8BfYgy4IKFq7SfeTCuQI9xaDOmHhpIzTvq sCFbL2JkpdckAz2+nT73SaQASRZ+7g2TFu1da4xWrjQKI2J5188dk3mWYU74Fx5jz1 PTTtc7S7hwZxa2CcFEircJI42d2BWz1JU6tmGZ/k=
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_C1093EDC-0D1E-40B9-A62A-52B88FA48B65"; protocol="application/pgp-signature"; micalg="pgp-sha256"
X-Pgp-Agent: GPGMail
From: Antoin Verschuren <ietf@antoin.nl>
In-Reply-To: <20161109134114.GK2473@Hanna.local>
Date: Wed, 09 Nov 2016 19:47:49 +0100
Message-Id: <C851A2CF-B946-4E3E-8799-585851CDEB77@antoin.nl>
References: <20161108144742.GH2473@Hanna.local> <831693C2CDA2E849A7D7A712B24E257F4A4BC33E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20161109093524.GC89276@Vurt.local> <831693C2CDA2E849A7D7A712B24E257F4A4BCC19@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20161109134114.GK2473@Hanna.local>
To: "regext@ietf.org" <regext@ietf.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/5XyA8Z8BG3YP8bmkNAeyq15mH3U>
Cc: Job Snijders <job@instituut.net>, "Livesay, Paul" <plivesay@verisign.com>, alissa@cooperw.in, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [regext] draft-ietf-eppext-keyrelay unreasonably stuck on IPR?
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2016 18:47:59 -0000

[Personal statement: Chair hat off]

Just so that everyone has the same information regarding the IPR we are discussing, the patent application and it’s EPO process can be found here:
https://register.epo.org/ipfwretrieve?apn=US.201113078643.A&lng=en

The patent application has been officially rejected by the patent office twice now in the past 5 years due to prior art.
This is without me as the original inventor of the secure dns-operator change method submitting any personal prior art that stems back to 2008 when I first thought of the idea during a DNSSEC workshop for operations staff while working for SIDN.
I have discussed this method in an IETF, DNS-OARC, CENTR and ICANN context with fellow IETFers including Verisign staff, and gave presentations about it, which led to the prior art before the first version of draft-koch-dnsop-dnssec-operator-change was published by the IETF in March 2011 and the Verisign patent application a month later.
This and the fact that I’m a co-author of both draft-ietf-eppext-keyrelay and draft-koch-dnsop-dnssec-operator-change is why my co-chair Jim is leading the process on draft-ietf-eppext-keyrelay and I attempt to state no personal opinions in this process or judgement of the opinions of others in this process.

[/Chair hat off]

Like most of you, I am no patent expert or lawyer.
Verisign is following the IETF IPR process as defined by the IETF, and it has every right to do so.
So please don’t blame Verisign or Scott personally.
The Patent office procedures are what they are, and we cannot change them or speed them up either.
Verisign can do the latter, but is not obliged to do so by any IETF rule, only by willingness.

That being said, we as a working group need to decide what we want to do.

I agree with Job that it is unfortunate that the IETF IPR process allows a pending patent application that has no licensing terms yet to stall the IETF process.
If this needs to change, I think we need to discuss this in a broader IETF context, but I think it will be very hard, if it is even possible legally to mandate licensing terms on IPR statements submitted to the IETF.

If we think Verisign has breached the IETF Note Well by patenting solutions after they were discussed during IETF meetings, that discussion also needs a broader IETF context than this working group. This will also mean a long legal battle which few individual IETF participants would be able to afford, and would require broader IETF consulting and guidance from the IESG.


So as a working group, we basically have only 2 options left:
1. We could kindly convince Verisign with arguments that stallment of this IPR claim is negatively impacting Internet security like Job has done, and ask them to withdraw or quickly proceed with their application. In this case, if Verisign is not willing to state licensing terms beforehand, we are still dependent on the Patent office procedures and timelines, and we will just have to wait for that.
2. We could jointly state that we took notice of the IPR claim, and that no matter what the licensing terms or outcome of the application is, we would like to standardize the solution in our Internet draft since it is the only best solution.

I would be hesitant to choose for option 2 on the argument that many believe the application will be rejected by the patent office in the end as there is sufficient prior art, since I am not a Lawyer, nor do I have the funds to pay for one in the small chance the patent office will make the wrong decision in approving the application to get it off their plate.
If we choose for option 2, we need to state why we think the patent application or it’s licensing terms don’t matter to us.

Jim has asked for this before, with little to no response to call consensus to have this draft proceed, so I would like to ask you again to state your opinion on this mailinglist so Jim can summarize them in a response to the IESG.


- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392






Op 9 nov. 2016, om 14:41 heeft Job Snijders <job@instituut.net> het volgende geschreven:

> On Wed, Nov 09, 2016 at 12:19:44PM +0000, Hollenbeck, Scott wrote:
>>> Because Verisign still has the option to provide a more detailed
>>> Licensing Declaration ahead of the issuance, covering whatever claims
>>> (if any) will be allowed.
>>> 
>>> Why has Versign choosen not to provide a Licensing Declaration such as
>>> option A ('no license'), B ('Free RAND'), C ('RAND') or E ('NOPE')?
>>> 
>>> In failing to provide clarity to the internet engineering community,
>>> Verisign is arguably obstructing much needed internet security
>>> mechanisms.
>> 
>> In my last note I explained why the decision was made to not update
>> the disclosure: we do not know if the patent will be granted, and we
>> do not know which, if any, of the claims will be allowed. We cannot
>> provide a definitive licensing declaration for something that remains
>> unknown.
> 
> No. Verisign has submitted a patent and is fully aware what the contents
> of that submission are. Verisign is also in a position to decide what
> the licensing will look like depending on the possible outcomes for the
> USPTO process.
> 
> Verisign chooses not to do so, and thus frustrates the process.
> 
> Kind regards,
> 
> Job