I got various private questions about NSD history. While it is off topic here is some more for those interestd. Others: ignore. Other Instigators: Jaap Akkerhuis is certainly also one of the instigators. He was with SIDN (.nl) at the time and wanted code iversity too. Jaap contributed quite some ideas in the initial design and continued to comment on requirements and design throghout. Why did the RIPE NCC provide a coder to the project? Well Olaf was not really a coder as such but rather our "Keeper of Requirements". NSDs reason for being is code diversity. This meant that two key requirements were independence of bind and implementing the DNS RFCs. We all woved not to look at bind code at all while this was going on; implementing on the other hand the RFCs was not that easily done: at that time DNS was specified by a lot of separate RFCs, more than a dozen if I remember correctly. And the DNSSEC RFCs were still being (constantly re-) written and yet we anted NSD to be "DNSSEC Ready".;-) Because of his DNSSEC work, Olaf was, and probably still is, one of the greatest living authorities about all things DNS standard. So it was quite logical to make him the editor of our requirements doc. I recall that we often asked specific questions about how this or that response of NSD needed to look like and Olaf would either know the answer right away citing chapter and verse, or dive into a number of interrelated standards and provide us with his interpretation of the gospel. This was invaluable to the project. I do not beleive in the myth that requirements, specification and implementation ever happen in strictly that order in any (successful) software project; I do not think any of the NSD team beleived in that. We did not need specs because the team was small and we did not really farm out stuff to independent groups. So we needed solid requirements to work to and we also needed them to document exactly what NSD does; after all this was a new product intended for critical applications. In order to make that requirement document solid and to test feasibility of some design decisions early on, I asked Olaf to turn the reuqirements into a prototype (perl) implementation of the zone compiler. In the nsd design this piece encodes the vast majority of the requirements but is not critical to query answering performance. So there was a chance that this prototype would actually make its way to production, but the main purpose was to test, refine and clarify the requirements. In the end I believe that the perl zonec did not even ship with NSD. So Olaf's coding work was really a part of his role as "Keeper of Requirements"; a very important role in the project. This was also a role that the RIPE NCC was extremely interested in because we were planning to be one of the first users of NSD for very critical applications. I can hardly imagine a better role for us to take than to actually maintain the requirements for such a critical product during the design and implementation phase. When NSD shipped we really knew that what it was supposed to do met *our*, the NCC's, requirements. We also knew that it did what it was supposed to do since we provided the testing. Synergy! Eough recollection. I Hope I answered the questions that one of you asked and that some of you may have had. Daniel