Re: [DNSOP] New Version Notification for draft-pounsett-transferring-automated-dnssec-zones-02.txt

[Matthew Pounsett <[e-mail]>]

On 9 November 2016 at 09:03, Antoin Verschuren <[e-mail]> wrote:

> Hi Matt,
>
> I cannot help noticing that draft-pounsett-transferring-automated-dnssec-zones
> is providing the same solution as an earlier draft draft-koch-dnsop-dnssec-
> operator-change.
> This draft has already gone through a review process, and is considered to
> be done content wise by the authors.
>
> The reason why draft-koch-dnsop-dnssec-operator-change has never made it
> to WG adoption in DNSOPS is because of IPR that is now also targeting your
> draft.
> There is currently discussion on this IPR on the REGEXT mailinglist
> because draft-ietf-eppext-keyrelay, which is the standardization of the
> provisioning parameters for this secure operator change concept is stalled
> for a long time as well because of this IPR.
>
> Can I ask you how your draft is different from draft-koch-dnsop-dnssec-operator-change
> to justify a new attempt?
> Wouldn’t the IPR pose the same adoption issues as draft-koch-dnsop-dnssec-
> operator-change?
>

I don't actually see the overlap.  Although perhaps I'm just missing
something.

Suzanne pointed draft-koch-dnsop-dnssec-operator-change out to me right
after my talk at the OARC meeting last month.. my first quick scan of it
and my more recent (this morning) closer look suggest to me that it is
dealing with the problem of moving a signed zones between non-cooperating
registrars.   One of the assumptions of the documented procedure is that
the DNS operators are not sharing DNS zone data, for example.

draft-pounsett-transferring-automated-dnssec-zones's basic assumptions are
that the DNS operators are cooperating, and that the principle requirement
for using the procedure is that they must publish the same zone throughout
the procedure, which implies an active zone transfer (or an analogue) at
every stage.

It seems to be that these two drafts are attempting to solve different
problems.


>
> The authors of draft-koch-dnsop-dnssec-operator-change are willing to
> revive the draft and ask for WG adoption by DNSOPS as well.
> As co-author of that draft and the original inventor of the secure
> dns-operator change method, I’m open to see how that draft can be improved
> by your attempt, and see if we could work together to get this concept
> described in an Informational RFC.
>

I'll defer on answering this until we resolve whether the documents
actually overlap. :)    If they do I have no problem dropping my draft and
contributing to draft-koch-dnsop-dnssec-operator-change instead.. but if
they are actually solving unrelated problems then I'm not sure I see the
value in a merge.


>
> draft-ietf-eppext-keyrelay is stalled in IESG review for 328 days now, and
> I wouldn’t want the DNSOPS WG to waste the same time while the IPR issue is
> not resolved.
> Instead, I think it would be wise to jointly address both the
> Informational concept description and provisioning solution and if members
> of DNSOPS have any input to the IPR discussion on the REGEXT mailinglist, I
> would invite them to contribute.
>

I'm brand new to the IPR issue, so these comments probably aren't well
thought out.  I noted when the IPR claim first appeared on my draft that
the same patent application is used in a claim against RFC6781.  I had
thought that the RFC had gone ahead despite the claim, and therefore it
wouldn't be a big problem for my draft, but having a closer look makes me
think that IPR claim may have appeared after publication.

I've seen the discussion in REGEXT and the comments from Scott about the
holdup in attaching a licensing intention to the IPR claims.  It seems to
me that it shouldn't be hard for Verisign to declare their intention should
their patent(s) be awarded.  If they aren't awarded then those licensing
intentions become irrelevant, and if they are awarded then.. well.. we know
in advance what Verisign's intentions are.   I don't understand why this is
a problem, but I Am Not A (Patent) Lawyer.