Op 12 nov. 2016, om 03:14 heeft Matthew Pounsett <m...@conundrum.com> het volgende geschreven:
Hi Matt, > I don't actually see the overlap. Although perhaps I'm just missing > something. > > 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. Ok, I do see the differences now, and the overlap. draft-koch-dnsop-dnssec-operator-change describes the proces of synchronizing the minimum number of records needed between a gaining and lozing DNS-operator in order for the DNSSEC chain of trust to remain intact during a zone transition without exchanging private keys. It considers all other records that need to be synchronized for services to remain intact out of scope, as there is no difference in synchronizing them when the transition were to be done without DNSSEC. And in practice most of the time the purpose of a transition is because those records will change after the transition anyway. So it only describes the minimum that needs to be done so either zone data will not become insecure before, during or just after a transition, and how this process can be automated for every domain transition independent if other records change or not. It only prevents the domain from becoming unavailable due to validation errors. Your solution describes the process of keeping a maximum number of records synchronized, -including those records needed for the chain of trust to remain intact-, but also not exchanging private keys, assuming that the services for the domain do not change after the transition. Some records like SOA, NS, signatures and private keys always change during a transition though. So draft-koch-dnsop-dnssec-operator-change is a subset of your draft, only dealing with DNSSEC records, but includes text on how to automate the registration process for those minimum number of records to make it a common practice, and what to do when DNS operators are not cooperating to bail out of that process with as little damage as possible. > 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. Verisign claim that they have IPR on the process of changing a dns operator (called Hosting provider in the patent) for a DNSSEC zone while keeping the chain of trust intact. That includes your and our solution as well as any process that describes a transition under DNSSEC including supporting provisioning processes like EPP. They claim in their patent application (so not yet approved): -That they invented this process for the first time in 2011. -That this process is a novelty and not common sense. Since there is prior art from before 2011, and there is sufficient doubt that the process is more common sense for people that understand DNSSEC in stead of a novelty, the patent application has been rejected twice by the European Patent Office. But a patent application is a long-lasting process, and allows for appeal processes to rejections that can take years. During this appeal process it is unclear which (if any) of the claims is ever to be granted, and so no license terms are yet given by Verisign. As RFC 3979 says, it’s hard to give guidance to best current practices if no license terms are known for an IPR claim. That’s why there was hardly support for draft-koch-dnsop-dnssec-operator-change to be adopted by DNSOP 4 years ago, and why there is hesitation in REGEXT to making statements on why the standards track document draft-ietf-eppext-keyrelay should ignore the IPR claim. RFC6781 was already a DNSOP document before the IPR claim was submitted. - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
