RE: [DNS] Searcher twists name rules

RE: [DNS] Searcher twists name rules

From: Larry Bloch <larry.bloch§>
Date: Fri, 25 Mar 2005 10:32:36 +1100
> -----Original Message-----
> From: Kim Davies [mailto:kim&#167;] 
> Sent: Friday, 25 March 2005 1:56
> To: Larry Bloch
> Cc: dns&#167;
> Subject: Re: [DNS] Searcher twists name rules
> Hi Larry,
> Quoting Larry Bloch on Friday March 25, 2005:
> | 
> | What I think Vic is articulating (and if so I agree) is 
> that we have 
> | to ensure policy serves the customer, not what armchair enthusiasts 
> | think customers want. From the front line, what we see is that:
> | 
> |  - registrants don't understand the restrictions placed on 
> them by the 
> | policy
> |  - they see the policy as useless red tape for no practical benefit
> |  - they want to be able to sell their names
> |  - they want names to be registered in real time
> I think you are missing a few things, most notably:
> - they want to get the name they want for the least expense

Yes - quite right

> All of the 4 points above you mentioned I absolutely agree 
> with from a consumer point of view, but there is a trade-off 
> involved which involves balancing these wants. Not everyone 
> will agree with these trade-offs, after all the "perfect" 
> consumer wants everything for nothing, but that is why we 
> have these discussions.

True enough
> | Certainly requiring a business registration to identify a 
> registrant 
> | is useful. But beyond that, if .au has acceptable use 
> policies, and if 
> | registrants warrant that they have a close and substantial 
> connection 
> | to a domain name, I fail to see how it is the regulators role to 
> | decide in particular instances or via policy in general if a 
> | registration infringes the rights of another party. That's 
> ultimately 
> | a matter for intellectual property law and dispute resolution 
> | mechanisms.
> As touched on by others, DRP mechanisms create a barrier to 
> entry - only large players usually fight those battles. It is 
> a tricky one, because if DRP mechanisms are too accessible, 
> they can become problematic in other ways.

Again a fair point - a balance is needed including an effective DRP process.
In fact the same applies to the law and courts in general (ie: stacked in
favour of those with money).
> | Much of the current restrictive policy is a response to the 
> scammers 
> | and cyber squatters. Those issues are largely resolved, and a 
> | loosening of policy to meet the expectations of the market is 
> | appropriate.
> I'm not sure I entirely agree with the analysis that because 
> the problems have largely abated, that is a reason to throw 
> things open. On the surface it seems like deciding to stop 
> locking doors because the crime rate is down. It is quite 
> possible that would invite the problem to (re)surface.

Yes - I'm advocating a progressive relaxation. A loosening of screws over
time with a close watch on the effect. A bit like how the reserve bank
manages rates.
> | .AU is undervalued because normal market behaviour that maximises 
> | value from the assets in the market is absent.
> Undervalued for whom?

General average overall value and utility for all average market
participants. Our capatalistinc economic system ascribes value as a concept
to dollar value. Within that value system, .Au is undervalued, I meant. Now
some may prefer other economic systems...

> | We have thrown the baby out with the bath water. In our efforts to 
> | prevent cyber squatting, we have destroyed value and missed 
> _part_ of 
> | the opportunity to create a vibrant and meaningful .AU.
> It's all about finding a balance. You destroy value and 
> opportunity in other ways if you make .au a completely free 
> market. The domain space is a finite resource that needs to 
> last, for all intents and purposes, in perpetuity - without 
> overly penalising people based on how late or early they 
> entered the so-called "market". Pure capitalism favours 
> driving resource exhaustion. Finding a perfect balance is a tough ask.


> kim
Received on Fri Oct 03 2003 - 00:00:00 UTC

This archive was generated by hypermail 2.3.0 : Sat Sep 09 2017 - 22:00:08 UTC