RE: Statements against new.net?

["Mathias Koerber" <mathias () koerber org>]

> Well DUH!  I totally agree that conflicting roots break things.  
> But I don't
> think that conflicting roots is an inevitable consequence of 
> having multiple
> roots, or even multiple root zones.

Please outlines what advantages multiple root 'zones' have over
a single root 'zone' if they are not conflicting?

To me the only reason to have multiple roots can be so that each can
make different decisions of what TLDs are to be included or excluded
in it, or where a certain TLD is delegated to. But that constitutes conflicting
which you yourself above stipulated as bad.

Multiple 'coordinated' roots effectively are a single root with added overhead
(generating agreement on what to include etc). A single master with replication
(as currently exists in the public root will do the same with less engineering
overhead and headaches.

Several 'independent' root systems have in the past claimed that they would
'coordinate' with each other. Apart from the fact that that would again create
a single root again, this leaves the following questions:
        - will all 'independent' root systems be accorded equal voice, opportunity
           in the efforts for 'coordination'
        - who guarantees that 'coordination' wil not break down once disagreement
           ensues between some of the players
        - will newcomers (independent roots that start up later) be accorded the same 'rights'
           in the coordination efforts as incumbents? 
                If yes, how can that be guaranteed w/o excessive regulation and overhead.

                If no, how different would that situation then be from the existing one? Will there
                be roots that rebel and become 'independent' from the 'idependent roots'?
                (and so on ad nauseam)?

Technically, any coordination effort among 'independent roots' simply create a single root, and
thus would be no different from the current ICANN/IANA root (one body of whatever composition
deciding the contents of the root). The question simply is how that body is organized. I don't
see the RFC2826 going into that at all.

If there are no guarantees or even attempts to coordinate the roots, they are bound to end
up conflicting (unless they remain static), which would break things.

And BTW: The problem is *not* distributing the glue for the root-servers (hints!) to the end-users,
there are different ways to do outside the DNS itself that already (including ftp).
The 'problem' is the actual content of that root zone.

Mathias