Re: [ga] Transfers and the Policy-Development Process

[Thomas Roessler <roessler@does-not-exist.org>]

On 2002-08-17 16:04:15 -0400, DannyYounger@cs.com wrote:

>Keep it simple, and get the job done.  Focus on policy  
>development, and on that alone.  That is all you were chartered to 
>do.

That's a good idea in theory - just doing high-level policy  
(narrowly defined) and leaving implementation (not so narrow) to  
technical experts.  But theory and practice are the same thing 
_only_ in theory.

In practice, when all the implementation details have been sorted  
out by "technical experts", you may wake up and find yourself  
confronted in an unpleasant way with the practical consequences of 
Lawrence Lessig's notion of architecture: Code is law.   
Implementation _is_ policy.  (Not always, but frequently enough.)

One very instructive example was given by Lessig during the Berkman  
Center's ILAW conference; I wasn't there, but you can find excellent 
notes on the net, see, for instance, 
<http://www.corante.com/copyfight/20020701.shtml#2205>:

	Architecture in cyberspace is a regulator. Think about it 
	first in real space.

	Robert Moses was a public administrator in New York. He 
	wanted to keep society segregated. The law changed; 
	segregation was outlawed.  But he found a way to keep 
	beaches segregated. Build some roads with low bridges across 
	them; buses can't drive on them. Those who use public 
	transportation were effectively kept away: "naturally." It  
	achieves its effect non-transparently. 

To give an example in the ICANN context, I suggest that you compare  
the suggested implementation of WHOIS services in GNR's original  
.name proposal to the agreement which came out of the  
"implementation" process, and spend some thoughts on the question  
who benefitted from the outcome in question.  Hint: There's a 
trivial and a non-trivial part to this.

Applied to what you wrote about transfers, "implementation" of your  
"policy" could come out with about anything between "just transfer"  
and "require notarized [by US consulate or embassy] confirmation 
 from registrant".  The _actual_ policy would be found in the 
implementation.

In more practical terms, the transfers policy we are going to see at 
some point in the future has to strike a balance between denying  
the transfer (when there is insufficient evidence that the request  
is genuine) and allowing it (when the evidence is sufficient).  The  
current policy contains one possible balance.  It seems to be based  
on the assumption that registrars are competing in a fair manner.

Obviously, that assumption was extremely naive.

So there are two problems to be solved: 1. Find the right balance.   
2. Make sure it's enforceable and, if possible, verifiable even when 
registrars don't compete in a fair manner.

That's actually a tough job, and I wouldn't be surprised if some of  
the more powerful players wouldn't have an interest in actually  
arriving at such a policy.  The most interesting question becomes,  
for this reason, whether or not the transfers problem can even be  
solved with the current framework.
-- 
Thomas Roessler                        http://log.does-not-exist.org/
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html