On 9 November 2016 at 09:03, Antoin Verschuren <i...@antoin.nl> 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.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
