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

[Job Snijders <[e-mail]>]

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:

    http://www.internetsociety.org/deploy360/blog/2013/09/how-to-securely-transfer-a-dnssec-signed-domain-between-dns-operators-sidns-epp-keyrelay/
    https://www.sidnlabs.nl/downloads/wp_2013_EPP-keyrelay_v1.en.pdf

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:
secure->insecure->transfer->secure.

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
month.

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,

Job