Perhaps by way of explanation I should enlarge on my previous
comments:

>* we were attempting to remove any ambiguity in the rules (else
>  competition cannot work)

Removing ambiguity is possible if an external objective definition
is used.  Lets use as an example the existing .com.au policy of not
approving names which are generic industries such as
'banking.com.au'.  My personal opinion is that this adds some value
to the .com.au 2LD by minimising 'passing off';  in the same way
that the .uk rules for .plc.uk are restricted to UK public limited
companies.

There are so many commercial scams & frauds happening on the
internet already that I kinda like the idea of a structure that
minimises things like Dodgy Brothers registering and using
.banking.com.au as a front.  As long as the solution is simple and
workable of course, - but it doesn't seem too difficult to me.

All the commercial sector panel needs to do is agree on the list of
what generic names are not allowable; that could include generic
industry names and generic place names for example.  Then as part of
the technical solution that enables multiple DNAs to operate in one
DNA, we include the list which can be automatically checked as part
of the name registration process by all DNAs (and can also be
checked by organisations considering applying for a name, btw).

Then we have a solution that is unambiguous, is easily automated,
and also addresses my second point:

>* there would be nothing that required licensing from Melbourne IT

since its just a list of values agreed upon by the commercial sector
community and publicly available.  I believe any rules for domain
name approval should not be the property of a DNA - their role is to
use those rules in approving requested domain names.

If there is any technical or business reason why this is not easily
achievable, someone please say so.

My other comment:
>* that the rules must be capable of being automated simply (else
>  competition cannot work)

requires perhaps some more complex logical reasoning.  Let me try
and support my comment :)

Firstly, I agree with kre's comments that things don't have to be
automated to have competition, and also:

>the aim of the policies has to be what is good for the domain, not
>what will make life easy for the registrars, even less for ISPs.

But in the commercial 2LDs (those designed for us for-profit guys to
get domain names) I'm not sure how it can be effectively managed
without automation - there are two problems that I can see:

1.  The volume of applications and associated costs.  We're just at
the start of commercial use of the internet - and already its
booming.  There are somewhere around one million businesses in Oz -
and if we include other commercial concepts that could be candidates
for domain names - trademarks as a possible example, then the
numbers are much higher.  While it could all be done manually,
automating the domain name approval process will minimise costs.

I guess my point is that if it absolutely has to be manual, then so
be it.  But where the volume is high, it would be nice if we can
design an automated solution.

2.  The consistency problem.  Flexibility is an asset in people,
consistency is an asset in computers.  If we accept that there will
be multiple DNAs in the commercial 2LDs, the only way to ensure
consistent application of the rules is to automate them.  Even with
the best will in the world and clear guidelines and lists, twenty
individuals at twenty DNAs will not apply the rules consistently.
The end result with be some DNAs approving names that others reject.
A lawyers picnic.

My belief is that we want public trust in the domain name system  -
that it is consistent, fair, equitable and reliable, - and public
disputes, although never one hundred percent unavoidable, will be
unhelpful.

Regards, Mark


 * * * * * * * * * * * * * * * * * * * *
*  Message From : HUGHES, MARK          *
*  Location     : AUSTRALIA-CCA HDQ     *
*  KOMAIL ID    : N17503  (CCAMCQN1)    *
*  Date and Time: 09/03/97  12:10:15    *
 * * * * * * * * * * * * * * * * * * * *