Re: [wg-c] about the consensus call

["Mark C. Langston" <skritch@home.com>]

On Tue, Mar 14, 2000 at 10:57:15PM -0800, Dave Crocker wrote:

> 1. It will require ICANN to be strictly reactive rather than 
> proactive.  You are confusing this with procedural regularity.  Regularity 
> can be achieved in either mode.
> 
> 2.  The idea that anything at all will make ICANN feel more obligations 
> than it already does, given the intensely politicized tone of its context, 
> is wrong to the level of being silly.
> 
> 3.  Coupling authorization of a TLD with authorization of an organization 
> to administer that TLD greatly increases the tendency to view that 
> organization as "owning" the TLD.  The simple act of separating name 
> creation from name administration ensures that such a view of ownership is 
> utterly without merit.
> 
> 4.  In a difficult debate it is inappropriate, and frankly dangerous, for 
> the person responsible for assuring fair process to take on an advocacy 
> role.  There is a difference between assessing which view dominates, versus 
> personally advocating one.
> 
> 5.  Existing gTLDs were created by IANA, not by the registry running 
> them.  Given the difficulty of making progress in this realm, it makes 
> sense to do as few "new" things as possible.  Stick with the established 
> framework, for now, and consider modifying it after the rest of the 
> necessary mechanisms are established and running smoothly.


It's not often Dave and I agree on anything, but I have to say he's
100% on the mark here, particularly as regards the separation of 
TLD v. registry authorization.

This actually raises an interesting point.  I was considering
advocating a manatory review every X months for each approved registry
to ensure compliance/fitness.  Once I started thinking along these
lines, I realized that there was a technical nightmare looming -- what
procedure do we create in the event that a registry becomes unfit?
How do we transfer the function of that registry to another?  What if
there is no registry to which to transfer these functions even on a
temporary basis?

These are all excellent counters to the argument for review.  However,
they are equally appropriate when we ask the question about any
potential withdrawl of a registry.  Is a registry, once approved, the
registry for that TLD in perpetuity?  What if the registry goes out of
business?  Changes hands?  Goes rogue?

Each of these situations is one in which it may be necessary to transfer
all functions of a given registry to another registry.  And unless there's
a quick, tested, and reliable manner in which this can be accomplished,
I think there may be a huge risk of potential instability here.  And
politicking aside, this would be bad.  

I suppose I see Dave's/Kent's/others' point about the inherent stability
of such a system;  I was thinking in terms of a shared registry system,
and it never crossed my mind that they may have been arguing a case
in which a given registry has sole control over a TLD, and that 
registry is offline for more than the occasional technical glitch.
In the instances I described above, they're right. 

The questions above need to be answered, I believe.  And I'm not aware
of any existing framework for doing so.  This does not change my 
position on the rollout of new gTLDs, nor does it change my enthusiasm
for doing so.  It does highlight an area in which we need to work
before this can happen, however.

If I may, I'd like to propose a potential technical solution:  We
have in place a working SRS (for various values of 'working';  joke
if you must).  Currently, that SRS is a blanket system, covering
.com, .net, .org, and such.  I am not deeply familiar with the SRS
code, but I think the following might be possible:

* Create 'micro-SRS' systems, in which there is a primary registry,
and a secondary, or backup, registry.  Each approved registry would
have a designated secondary, to which their data would be mirrored.
Preferably, this secondary would not be chosen by the primary, to
avoid the situations we sometimes see now with primary and secondary
nameservers.

If and when the funtionality of the registry needs to be migrated for
political, technical, or other reasons, there exists a functional,
fresh copy of the registry in another system not controlled by the
owner of the primary.


I'd appreciate it if those who have had a look at the SRS code, or
who are at least more familiar with its internals than I am, could
comment on the feasibility of this idea.


-- 
Mark C. Langston
mark@bitshift.org
Systems & Network Admin
San Jose, CA