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

bert hubert <bert.hubert@powerdns.com> Thu, 10 November 2016 21:45 UTC

Return-Path: <bert.hubert@powerdns.com>
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 D4DC6129793 for <regext@ietfa.amsl.com>; Thu, 10 Nov 2016 13:45:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.397
X-Spam-Level:
X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no
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 cXbm_RXZbAaY for <regext@ietfa.amsl.com>; Thu, 10 Nov 2016 13:45:15 -0800 (PST)
Received: from tmpmail.powerdns.com (tmpmail.powerdns.com [128.199.32.142]) by ietfa.amsl.com (Postfix) with ESMTP id A630F1296ED for <regext@ietf.org>; Thu, 10 Nov 2016 13:45:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tmpmail.powerdns.com (Postfix) with ESMTP id 447556803E; Thu, 10 Nov 2016 16:44:30 -0500 (EST)
Received: from tmpmail.powerdns.com ([127.0.0.1]) by localhost (tmpmail.powerdns.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 009WZ_pDlxqI; Thu, 10 Nov 2016 16:44:26 -0500 (EST)
Received: from server.ds9a.nl (unknown [IPv6:2001:470:1f15:bba::42]) by tmpmail.powerdns.com (Postfix) with ESMTP id 950296803D; Thu, 10 Nov 2016 16:44:26 -0500 (EST)
Received: by server.ds9a.nl (Postfix, from userid 1000) id ED853AC2B90; Thu, 10 Nov 2016 22:44:26 +0100 (CET)
Date: Thu, 10 Nov 2016 22:44:26 +0100
From: bert hubert <bert.hubert@powerdns.com>
To: Job Snijders <job@instituut.net>
Message-ID: <20161110214426.GA11719@server.ds9a.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> <C851A2CF-B946-4E3E-8799-585851CDEB77@antoin.nl> <20161110103304.GL89276@Vurt.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20161110103304.GL89276@Vurt.local>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/xb7fEsuiaR0n1kSAkWnzLaAkgIU>
Cc: "Livesay, Paul" <plivesay@verisign.com>, Antoin Verschuren <ietf@antoin.nl>, alissa@cooperw.in, "regext@ietf.org" <regext@ietf.org>, 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: Thu, 10 Nov 2016 21:45:17 -0000

On Thu, Nov 10, 2016 at 11:33:04AM +0100, Job Snijders wrote:
> On Wed, Nov 09, 2016 at 07:47:49PM +0100, Antoin Verschuren wrote:
> > 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.
> > 
> > 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.
> 
> Given that Verisign demonstrated an unwillingness to amend their License
> Declaration, I'd like to support option 2.
> 
> I have a few supporting notes to share regarding option 2:

So do I, but I'd like to add a few things.

>     1) Any draft or any mechanism that defines howto securely
> transfer a domainname without breaking the DNSSEC chain of trust, will
> inevitably be contaminated by Verisigns IPR disclosure for WO2012135492:

+1 - this point effectively means that there is no alternative to going
ahead.

>     2) Verisign's motivation for their unforthcoming attitude is
> irrelevant. Whether Verisign believe they can employ patent applications
> as a strategic device to delay drafts or whether it is mere organisational
> incompetence doesn't matter, the outcome is the same. Antoin is right
> that this anti-social behaviour needs to be addressed in a broader
> context, 'keyrelay' delay will serve as an excellent example of
> collateral damage due to poorly choosen IPR License Declarations.

I agree change is needed, but we need this standard. If in fact you want to
make the best show of how bad things are, we should not proceed and drop the
standardisation and wail loudly.

>     3) Verisign's patent application and licensing terms for the rights
> they might be able to claim (if any), are likely to be confined to a
> narrow geographic, while on the other hand, the IETF standards serve a
> global audience. An RFC that is contested in one region can still be
> perfectly fine and usable in another region.

I'd put this differently. While the US may not be able to benefit from this
standard, at least let pure non-American entities enjoy it. In practice this
'narrow demographic' impacts most of the domain industry: anyone with a US
entitity - because that is the (practical) reach of IPR lawsuits.

But let's indeed do this for the rest of the world.

>     5) Based on Antoin's write-up, I have good reason to believe prior
> art exists and the patent application will be shredded after careful
> scrutinization, just as EPO demonstrated by rejecting the patent twice
> already.

+1 - this is a followup really to '3'. We might be doing the standard for a
post-invalidated USA, plus the rest of the world.

> In addition to the above, I encourage people to discuss and reevaluate
> their collaborations with Verisign at a later date.

I think we treat them way too kindly. They receive hundreds of millions for
maintaining COM and NET. 

	Bert