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

Job Snijders <job@instituut.net> Wed, 09 November 2016 09:42 UTC

Return-Path: <job@instituut.net>
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 460501294EB for <regext@ietfa.amsl.com>; Wed, 9 Nov 2016 01:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.com
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 m21fY1piIcTn for <regext@ietfa.amsl.com>; Wed, 9 Nov 2016 01:42:50 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376CE12963D for <regext@ietf.org>; Wed, 9 Nov 2016 01:35:31 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id a197so295178016wmd.0 for <regext@ietf.org>; Wed, 09 Nov 2016 01:35:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=1hGOzqUCxRcUh5MJcItmtqpagur7rWy00o4uqnZ6grE=; b=bE59Onr8rXOnthxVRQoY89HuoXqNOJkuBfdZ9BnzvBOjtcPasgQYXumbG9h7Dhd32c aHWOKAvzYLZsRcUd2YTNBTItl1IX0qmZa0XZKp6UhPyo5miu8WuXJpag/vHMIAyIE919 PrP17KJESDTs2EEY1HA3bfyI4Zr+Cly2u/8U6Y1gJkCKmJ8gSJsgToNcuPZ3TUr6R5Ho alr5c+cuvpao58G+NTuIqId6w0IauS7JOLcvHhUo+EObaBYWGB/0eox1re4KHBBADdKc gBJjwuOqbIlmYzxNbIjn1Yix276ljk0iSiTXQm8z0jVCcTL1WtI2a56a7F7Oigg5VWsU u3Iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=1hGOzqUCxRcUh5MJcItmtqpagur7rWy00o4uqnZ6grE=; b=bJ+3TIRLQVL0q0pCksbQ7rsPZCbkX+Ih7OkcqsmEIgOUmQHyA2TdDj3z2gyGtT3mDt 5L+a0+9eUnZFqMjGcry1uqrTS4ofRnCjP9QAYrfXUrUPG2JgS0ng5kAjOzonrl8oMwaF 9F2+j27YyFfrwFBP+wplwkmKM8dD5nFPdgVD/oobXR6HkUZqfcfnNH67eQMwo/O7m4qM hQpn63RKELdWZnogNvQszwxmy5UfhDas0fEIvRGB1fMMgn7okwYhsXpZ7HGUur+gu1Hi s3k2spR2E7OlSjYTb40p/1fI9CwS2fbxAna1MFBHioRJ9yuqY8PM3IoeiQ+XRUfcWtnG yVRQ==
X-Gm-Message-State: ABUngvcm0S7lrfTlWmIRvj5Zav1v+QQGjkPMsGXFbw4dOGq/j2Pd37esIGhvpjxiHMsYpg==
X-Received: by 10.194.222.105 with SMTP id ql9mr16786672wjc.63.1478684129648; Wed, 09 Nov 2016 01:35:29 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:c470:18ea:5374:cfde]) by smtp.gmail.com with ESMTPSA id i15sm27745224wjs.16.2016.11.09.01.35.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Nov 2016 01:35:28 -0800 (PST)
Date: Wed, 09 Nov 2016 10:35:24 +0100
From: Job Snijders <job@instituut.net>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20161109093524.GC89276@Vurt.local>
References: <20161108144742.GH2473@Hanna.local> <831693C2CDA2E849A7D7A712B24E257F4A4BC33E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4A4BC33E@BRN1WNEXMBX01.vcorp.ad.vrsn.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/vYQdB9XSYNi_SbO9rODkK3xFUTk>
Cc: "draft-ietf-eppext-keyrelay.all@ietf.org" <draft-ietf-eppext-keyrelay.all@ietf.org>, "Livesay, Paul" <plivesay@verisign.com>, "regext@ietf.org" <regext@ietf.org>
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 09:42:52 -0000

On Tue, Nov 08, 2016 at 07:40:19PM +0000, Hollenbeck, Scott wrote:
> (Removing the IETF list)
> 
> > -----Original Message-----
> > From: Job Snijders [mailto:job@instituut.net]
> > Subject: draft-ietf-eppext-keyrelay unreasonably stuck on IPR?
> > 
> >     """Licensing Declaration to be Provided Later (implies a
> >     willingness to commit to the provisions of a), b), or c) above
> >     to all implementers; otherwise, the next option 'Unwilling to
> >     Commit to the Provisions of a), b), or c) Above'. - must be
> >     selected)"""
> > 
> > The IPR statement was submitted on July 21, 2014.  I am not sure what
> > the capitalisation of the words "Provided Later" signifies - but surely
> > the purpose of this process is not to stall and leave a document in
> > limbo forever. 
> > 
> > A promise such as "soon" is appreciated, but not sufficient:
> > https://mailarchive.ietf.org/arch/msg/regext/SbwMA57ebzMjKwaphz6AZzliMM
> 
> This is the latest information I (I am the IETF participant whose
> belief triggered the disclosure) have as of right now: the patent has
> not been issued, and so Verisign does not know which, if any, claims
> will be allowed. The disclosure will be updated when the application
> process has been completed by the patent office.

Dear Scott,

There can be any number of years between filing and issuance, there is
no assurance that USPTO will be able to progress the application in the
immediate or distant future.

How does the Internet community benefit from not having a standardized
way to securely transfer domainnames?

I have to ask: is VeriSign purposefully obstructing the publication of
the draft-ietf-eppext-keyrelay document?

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. 

Regards,

Job