Hi Brenden,

comments below ...

>> Indeed, but I have the impression that it was not as clear for some people
>> that
>> the studies/analysis are not yet complete/conclusive and there is
>> still work to do.
>>
>
> Yes this became obvious as questions were asked.  E.g., one question pointed
> out the problem with big jump in root scaling report graph.  It seems to
> assume all TLDs are signed and publishing DS records at same time (that's
> the big jump), it's far more likely it will be a gradual take up of DNSSEC
> by TLDs (and some may never deploy it), therefore the growth in size and
> rate of change will be slower, not immediate as the graph suggested.  The
> other point raised was what exactly are the assumptions that determined the
> root server capacity curve (the blue line), change the assumptions and the
> capacity curve could start from a much higher point on the x axis.

I believe that both the graphs shown by Lars and the "100" comment
(I believe somebody said by Thomas ?) created some confusion.

It is not clear that any actual or valid simulation metrics were used to create
the graphs and as far as I remember I've not seen in any of the reports any
clear definition of what Root Server Operator Headroom or Capacity actually
means and how and from where a quantitative number is assigned to it so you
can create a graph.

I believe Lars intention was to explain how big of an impact it could be, using
the root DNSSEC signing as an example of a sudden change, if we sign it
now that the root zone is relatively small or if we do it later with
thousands or
hundred of thousands TLDs.

I don't think that even the shape of the graph is correct, but really depends of
how "capacity" is defined. If we assume as "capacity" the ability of the root
zone operators and the root zone infrastructure to absorb and manage a
given number of total TLDs, Resource Records, database changes, etc,
the blue line should look more like a staircase.

To use a simple analogy it is like the capacity of the hard disk in
your computer,
if you have a 100GB disk you know what your limit is, if you upgrade or add
more disk, lets say 500GB, then the graph will show now a new step with your
total capacity as 600GB.

The thing is that we don't know really well what's the "capacity" of the root
zone and how easy/fast we can use more of it, without taking in account the
ripple effects on the rest of the system.

I'd not focus or make any arguments or statements based on the graphs.

I've heard several times the "100" number, and I believe that came from an
hypothetical question where somebody asked how many and at what pace
we could be able to add new TLDs with the current infrastructure, and the
response was actually "I guess 100/yr should be ok", but some people
took it as factual information when it is not, it's just a guess.

> IMO, it would be very imprudent to draw any recommendations from the
> existing report.

Absolutely, take in account that this was just a series of presentations of
the preliminary findings and results of the study, the model by TNO is not
100% complete and it has not been validated and we still need to feed
real data to it to be able to get some reasonable output from the simulations.

As I said before none of the reports are conclusive, this was not a
presentation of the SSAC with specific conclusions and recommendations,
but it's clear that there is not an easy and concrete answer yet to the
question "does the root zone as it is today scale?".

There is a lot of more work to do, and I'm particularly concerned that most
of the study and analysis so far is focused only on the root zone and not
much on what are the side effects on the rest of the system.

I believe the last question by the "small business" lady was a good one,
DNSSEC, the growth of the root zone, the change of behavior of DNS as
a system (TCP vs UDP for example) will have a noticeable impact in those
areas were infrastructure is not very good or easy to upgrade. As I mentioned
in a previous message we are starting to see an increase in server load
and network traffic with the changes produced by DNSSEC and IPv6,
without the root signed or DNSSEC widely deployed.

If we care about end users and developing parts of the world we should
keep a close eye on this.

>> Another thing and the model from TNO includes something of it, the issue
>> of creating additional capacity is not only related to hardware/software/pipes
>> upgrade, some of the processes (given that the root zone has been stable
>> and growing at a very low pace) do not scale, particularly at IANA, where many
>> task are still being done almost manually.
>
> Yes,  I agree.

Producing changes on the root zone requires a lot of coordination and
verification,
and since it's an area that have been stable for many years it didn't
require more
than just a quasi formal process to get things done. There is still
lot of communication
between NTIA, IANA, VeriSign that is handled by email or over the phone.

My take is that qualified human resources and tools development will be far more
hard to scale than the servers.

>> As I said before, big mistake from ICANN is that we should have done all
>> these studies and preparatory work before starting with the DAG.
>>
>> Imagine having almost 10 years headroom to have the infrastructure ready.
>>
>> But now the recurrent question I've seen and heard several times, is how
>> ICANN will select the first 100 new TLDs.
>
> This raises another critique of the argument to sequence DNSSEC first, then
> addt'l TLDs, IPv6, etc.  If we're only doing a 100 TLDs/year then the "big
> jump" becomes a non-factor for a while - so we shouldn't rush signing the
> root.

There has been (and I still believe there it is) a big disconnect on
many fronts,
to be frank and I don't intend to generalize but across the technical community
is very common to hear "why the heck we need the new gTLDs for?", and
there are a lot of valid arguments out there.

DNSSEC is a necessity and without the root signed and just relying on
trust anchors is a nightmare of coordination and puts a lot of burden on
system/network administrators (with all due respect but many not highly
trained or qualified) making the overall system unstable.

I don't foresee any huge issues in a gradual addition of TLDs and I guess
everybody is taking in account that IDN ccTLDs will be the first ones to
show up soon.

Biggest problem with or without DNSSEC is that as I said before while the
infrastructure could be able to digest them, the people that are today
part of the system do not.

Take in account that adding TLDs is not just adding the records to the
root zone and distribute the file, it brings an incremental rate of requests
for changes/updates and the root zone should be able to operate in a more
dynamic fashion as a TLD does.

Regards
Jorge