draft-ietf-eppext-keyrelay unreasonably stuck on IPR?

Job Snijders <job@instituut.net> Tue, 08 November 2016 14:47 UTC

Return-Path: <job@instituut.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 44478129CD2 for <ietf@ietfa.amsl.com>; Tue, 8 Nov 2016 06:47:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
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=ham 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xSPxMaH9wmZM for <ietf@ietfa.amsl.com>; Tue, 8 Nov 2016 06:47:45 -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 31B3E129CDB for <ietf@ietf.org>; Tue, 8 Nov 2016 06:47:45 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id f82so185470085wmf.1 for <ietf@ietf.org>; Tue, 08 Nov 2016 06:47:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=V9Q2AJsWWmmePkhymgYIG8yvpelNW1zPKCA2DbtGyE8=; b=odaecSqJ1qYqcg6cZ7NziHsV1aqKFOdoAmNCFBV+iO5xS1tBdy/k0WX+Mnr2OOBXd/ 5bIjAtMSpcgJCUBxf5Z3YJjzvprIqlNcQuW6iOnGQAt+LXJrI9SafXCc6XRUwCGSqYBr FD6f/lr+ibzhf34JKy5JSyUCR8pJNXeFUYYzlptlA8zat8vfreAVKkfsCLekgbiRrrB0 DuS/fCB549i8vdE1MUw2NTdHazbjGKAMTPWQwx91NZKa+JXFUIh6efAJDQMTPtEQZ3HN gS2ORgfiMLKhztqJltiUv511yEHP3HALRmFbU66OBn3x6M11qg002FL2JwW9+fSbpnW0 LJtA==
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:subject:message-id:mime-version :content-disposition:user-agent; bh=V9Q2AJsWWmmePkhymgYIG8yvpelNW1zPKCA2DbtGyE8=; b=M9LQ3Z26zcXlIEYmLR1ZPMljqdhswQMoU2mAJ7LS4wwPVYPWuMAT4xhjyCJTH4324M 0DpkDW5fU1nq9IuMNEtpuYn8p2AjxMAsKxAn81KT3XYPjmyNBj5LhVNNf5u7Z5SkShsu 3LfZ9iMPhj8E6i481UlRvz2A9XZ2vy/kwMr470iLQAjHgsogkRQQwzOKwE5e3yEEYGMP esXjzuai3QzgMtJxx8ZPSETvoQ5T7vQ0t/a8cL3vi4Uej9+LX+mwer+kugAP/wKm7Nih AtIEbv4vu+pmwEIegSNECa3oGzExmolO3CkYSNxuH1SdOd1pL+HrLI4vHBJ3O76HWvQe QTKw==
X-Gm-Message-State: ABUngvfmRmYS/s5foWTKlqVBRKiNeYGe5O6h4vcoyjQGdmsFCjM1t9vRjlgrYtMOXFQSog==
X-Received: by with SMTP id d69mr12068163wmh.119.1478616463543; Tue, 08 Nov 2016 06:47:43 -0800 (PST)
Received: from localhost ([2001:67c:208c:10:319f:c386:86c3:ad6a]) by smtp.gmail.com with ESMTPSA id w66sm1425986wme.4.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Nov 2016 06:47:42 -0800 (PST)
Date: Tue, 08 Nov 2016 15:47:42 +0100
From: Job Snijders <job@instituut.net>
To: ietf@ietf.org, regext@ietf.org, plivesay@verisign.com, shollenbeck@verisign.com, draft-ietf-eppext-keyrelay.all@ietf.org
Subject: draft-ietf-eppext-keyrelay unreasonably stuck on IPR?
Message-ID: <20161108144742.GH2473@Hanna.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7vxA8fK6Z5MYSXj4A7OoA_llpws>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Nov 2016 14:47:47 -0000

Dear IETF,

Since the EPPEXT Working Group has been concluded and evolved into
regext, I'm reaching out to the bigger group about a document that
somehow is stuck.

The keyrelay specification describes how one can change the DNS operator
of a domain while keeping the DNSSEC chain of trust intact. Obviously
this beats the current "not-the-best" practise of going insecure,
transferring and then securing the domain again.

Background info on secure domain transfers:


Draft-ietf-eppext-keyrelay can't progress due to a DISCUSS from Stephen
Farrell. Farrel raised because the IPR situation is not succinctly
clear: https://datatracker.ietf.org/doc/draft-ietf-eppext-keyrelay/ballot/

>From the IPR details here listed at
https://datatracker.ietf.org/ipr/2393/ I quote:

    """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. I appreciate that IPR related work can take time, but
this long? A convenient counter is provided here: https://rikribbers.nl/keyrelay/

I've asked the keyrelay authors what attempts have been undertaken to
resolve the situation, and according to them attempts to communicate
with the (presumably a legal department) contact persons listed at
https://datatracker.ietf.org/ipr/2393/ have gone unanswered, and the
IETF participant whose belief triggered the disclosure has not been able
to progress the issue either. A promise such as "soon" is appreciated,
but not sufficient: https://mailarchive.ietf.org/arch/msg/regext/SbwMA57ebzMjKwaphz6AZzliMM0

For those that wonder what the impact of stonewalling this document is:
the SIDN (the .nl registry) has put their current deployment on hold.
The SIDN had implemented keyrelay in their Shared Registry System to
verify if a domain transfer can be done while keeping the DNSSEC chain
of trust intact. However registrars are waiting for keyrelay to be
published as a real standard, in absence of that:

Should you wonder why the Dutch are growing impatient... The Dutch
registry is globally a leader in terms of DNSSEC deployment. With over
2.5 million DNSSEC secured domain registrations, the ability to securely
transfer is critical! There are ~ 22,000 .nl-domainname transfers per

Adoption of secure transfers should have been in place before DNSSEC
validating resolvers became the norm.

Aside from the 'keyrelay'-specific concerns I described above, I worry
that IPR disclosures can be used as an obstructionist attack vector to
indefinitely stall a document's publication. File a patent, file a
disclosure, never provide licensing information! That doesn't seem right.

Kind regards,