Date:        Tue, 24 Feb 1998 02:33:31 +1100 (EST)
    From:        Deus Ex Machina <vicc&#167;cia.com.au>
    Message-ID:  <199802231533.CAA22720&#167;cia.com.au>

  | pr.au and tm.au is just a bandaid solution to rectify a problem which
  | is more easily fixed by proper competition.

I personally tend to agree, though perhaps not for the reasons you do.
I don't believe that products, trade marks, and such, belong in the DNS
at all, putting them there is indeed a bandaid, until a directory in
which they can be better placed comes along.

  | I would suggest incoming details should be pending-locked for a certain
  | number of hours for the registry who first got the update,

That's perhaps part of a solution, it actually turns out to not be at
all easy when you start looking at all the border cases - I know, I see
these things happening now, and basically resolve them using human
intelligence (ie: ask people...)   There are so many cases which look
identical when all you see is the request, but actually are quite different
that it is very hard to automate any kind of distinction.

Eg: the simple case, a client switches from one registry to another, clearly
the info from the new registry should be preferred over the info from the
old one.    Then, client has two service providers (typically this is one for
their WWW pages, and the other for e-mail and general IP connectivity).  One
is there first, and has registered the domain with one registry.  The
client then gets the second service from the other ISP, which registers their
domain name with their preferred registry (and their servers of course).
To the zone file maker this looks just like the first case, but actually
is totally different.   Then there's the case where the first example has
happened, but someone in the client organisation accidentally pays an
invoice from the first registry, which then re-instates their information
(and looks to the zone keeper as if the client has switched back).

Now depending upon how the zone file is actually being built there
are various problems - either the zone file builder maintains the data,
the registries send uin updates - that causes bad updates to be made in
some of those cases.  Or the registries send in their sets of information
as they want it (complete) every time a new zone file is to be built,
in which case the above cases cause conflicting information, and the zone
file has to pick one, or simply omit the domain completely.   That probably
means "pick one" applies, and the sane one to pick would seem to be the
status quo (whatever applied previously)(.  Of course, that makes it real
hard to change registries in the face of a registry that won't delete its
old information (like: we have been paid until the end of the year, you
want to switch because we're giving lousy service, tough, we've been paid,
we're contractually bouind to keep publishing the info until then...)

  | no. MIT cant uniformely enforce its own rules, how do you expect X
  | separate companies to enforce them.

It is necessary.

  | forcing other registries to
  | have the same rules defeats the purpose of competition.

No, competition is so you can get the best service (timely processing,
assistance when things aren't working etc) at the lowest price.

  | there are no good justifications for the current rules,

I think we can disagree about that.

kre