[ncc-services-wg] Off topic: Excursion to NSD history.

[Daniel Karrenberg <daniel.karrenberg@localhost]

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