In message <8c184518-2a56-42b6-bd63-3e50f8126...@hopcount.ca>, Joe Abley writes : > > On 7 Mar 2014, at 10:49, Tony Finch <d...@dotat.at> wrote: > > > Joe Abley <jab...@hopcount.ca> wrote: > > > >> https://xkcd.com/927/ > > > > So from the standards development point of view, I think what this is > > saying is that success is more likely to come from building on what > people > > are already doing and nudging more of them to do it more similarly. > > Sure, maybe. > > I think we have to consider our target audience. Part of that is to > consider the existing menagerie and understanding the shape of the > expected solutions space. > > While we in this group might find comfort in arcane binary protocols > using UDP port 53, the habits of people who frequent the dyndns zoo seem > to be far more tilted towards throwing JSON documents around over HTTP. > It's hard to imagine unifying a pile of RESTish APIs with something that > looks foreign and different. > > I'll +1 Andrew and say that I have my doubts (a) that the underscore > scaffolding will ever appear in the top-most labels and (b) that anybody > would use them if they did. > > My poorly-informed doubt is hardly a reason not to document the idea. But > I think it's a stretch to expect anything more than an XKCD-927 result. > > > Joe
Our audience should be the CPE developer with the one "turn on DNSSEC" button which generates the keys, signs the zone, pushes keys upstream at the right time. It has a username/password field for zones where it is not automatically installing KEY records as part of the automatic delegation process. The second audience is the DNSSEC Key management tool developer which has a policy file which says "roll the key for this zone monthly/yearly" and just ensures it happens. nsupdate is how one does it today because the other bits of software that will use the method have not yet been written because we (the IETF) haven't provided them with a full standardised solution which works everywhere. nsupdate is the proof of concept tool. It is the fill the gap tool until the others are written. It is the fix it tool. However in all cases we have RRR and non-RRR managed zone and the tools need to work with all of them. There are lots of tools today which use nsupdate as the backend to update the DNS after putting addresses into a IPAM. We also have nameservers that are being renumbered that need to push new glue records for themselves to the parent zones. This will happen with both signed and unsigned zones and their is no "scraping" solution that works for this senario. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop