[ncc-services-wg] (no subject)

[Daniel Karrenberg <daniel.karrenberg@localhost]

Subject Excursion to NSD history. Was: Allow DNSMON services to monitor ENUM domains
Reply-To: 
In-Reply-To: <3678E9F7-3B2E-44EC-83B8-F0A5BAA5845F@localhost>


On 08.10 14:33, Jim Reid wrote:
> ... And as a former employee of an LIR who saw their  
> membership fees being used by the NCC to nurture DNS software that  
> undermined that company's products. ...

Jim, 

I assume you mean NSD.  I'll react to the dnsmon side of this
separately.  The intention of this message is to put the record straight
and voice some opinions on the NSD side. 


Full disclosure:

I am a long standing member of the (European) Internet community and
speak as such.  But be informed of these other things:

My personal view is that the RIPE NCC needs to be much more than a
number "factory".  I am on record with this view consistently over time
and from far before the NCC was actually established. 
[Ref: RIPE meeting minutes, ripe-019, ...]

I am the founding CEO of the RIPE NCC and currently serve as is in the
role of Chief Scientist. 

I am one of the instigators of what became NSD; some have said I am
*the* instigator but I feel that is not quite right.  The gestation 
of ideas like this is always very hard to pin down.  John Crain, Ted
Lindgreen and Alexis Yushin and possibly others instigated as much as 
I did. 


Facts:

NSD was developed by NLnet Labs http://www.nlnetlabs.nl/ and 
not the RIPE NCC. 

When development of NSD started we were not aware of anyone developing
something similar, neither proprietary nor open source.  If someone
had offered a realistic alternative at the time the RIPE NCC would have taken
it and I doubt if NLnet labs had undertaken to develop a "me too".

Development of NSD was above board from before it started.  Both NLnet
Labs and RIPE NCC told the community what we were up to;  we actively
solicited feedback about our plans and received nothing but
encouragement and good suggestions. 

The NCC resources that went into NSD were at the *very most* 3 months of
my time.  It is very difficult to account for that since I do not work
on a single thing at a time; neither do I work 9-5 and creative work
does mostly happen outside these hours anyway.  I was the only NCC staff
involved with the project. 

I fully participated in the design of NSD 1 as part of my NCC duties. 
Since NSD 2 my involvment is reduced to very sporadic advice. 

I developed the DISTEL test lab and performed regression and
performance testing of NSD 1 as part of my NCC duties.  See
http://www.ripe.net/ripe/meetings/ripe-42/presentations/ripe42-dns-distel/index.html
After the first versions of NSD 1 were released I have done no furhter
work on this.  NLnet Labs is operating a test lab now that is built on
the foundations of DISTEL. 


Opinions:

The main reason for the creation of NSD were massive concerns that
erupted (post 9/11) about the lack of diversity in major widely deployed
DNS software.  These concerns came from both the technical community but
more importantly from layer 9 and above.  Those who are not sympathetic
to industry self regulation in general and to organisations like ICANN
and the RIPE NCC in particular were creating all sorts of FUD in this
area with the intention to harm us.  Something needed to be done. 

Any mishaps with the operation of k.root-servers.net are a considerable
danger for the RIPE NCC's reputation as a professional organisation, and
more importantly in the light of the "Internet Governance" discussions. 
So hardening this operation is necessary and in the interest of the RIPE
NCC. The use NSD has indeed hardened this operation in more than one way.

Any performance increase of DNS software on RIPE NCC operated
authoritative DNS name servers saves money for additional hardware that
would otherwise be required. 

One could easily defend the level of our involvment in the development
of NSD by direct RIPE NCC operational needs: direct involvement in the
design made sure that our requirements were met by the product. 
Thorough regression testing was a prerequisite for us to deploy the
software on k.root-servers.net anyway; doing it as part of the NSD
effort rather than post-factum product testing was a much more
efficient. 

I believe strongly that the RIPE NCC should help along open source
efforts that meet its operational needs and that also meet operational
needs of the RIPE community.  So even without the very valid defense
above it would have been fully appropriate to participate.  The NCC
should not just be a number factory but also be a place where the
membership can place activities that further their common goals and that
need a professional and neutral organisation to do them.  This is our
strength. Letting the RIPE NCC degenerate to a number factory would
very likely weaken it to the point where it could be taken over by
others, such as governments.

We actively communicated to the RIPE community and beyond what we were
planning and doing at all times.  As far as I remember noone objected at
the time.  Certainly there were no significant objections from either
the RIPE community or the RIPE NCC membership.  I find it aggrevating to
be critisised about this *long* after the fact when indeed the channels
were wide open at the time, as they always are. 

Daniel