DNS: An answer to this from Melbourne IT?

DNS: An answer to this from Melbourne IT?

From: Simon Hackett <simon§internode.com.au>
Date: Mon, 02 Dec 1996 07:50:13 +1000
I would appreciate an answer to the following suggestion of mine (and
subsequent words of support from Boz Cappie as below). I think it is the
fairest way to address the renewal situation - fairest for all concerned. I
have discussed this with others who also agree that the logical thing to do
with existing com.au registrations is to simply leave them alone until (any)
defined event which causes them to be re-registered, but to otherwise take
no action to change (or remove) existing com.au names prior to any
re-registration of same.

A reply on this topic would be most welcome from Melbourne IT as it has now
been over a week since this mail was sent and the issue is quite, quite
important and very timely.

Regards,
Simon Hackett

>Return-path: <owner-dns&#167;magna.com.au>
>Date: Thu, 21 Nov 1996 18:52:39 +1000
>From: bcappie&#167;hum.uts.edu.au (Boz Cappie)
>Subject: Re: DNS: COM.AU DNA's Progress Report after Week 2
>Sender: owner-dns&#167;magna.com.au
>X-Sender: bcappie&#167;mailbox.hum.uts.edu.au
>To: dns&#167;intiaa.asn.au
>Reply-to: dns&#167;intiaa.asn.au
>
>In reply to previous discussions with Melbourne IT, Simon Hackett wrote;
>
>>In fact, here's the easy policy answer. Please consider it:
>>
>>Set your policy to be that you will not make a *change* to any existing DN
>>delegations without the domain being registered up and paid for, but that
>>for all existing DN delegations, you will explicitly LEAVE THEM ALONE (and
>>not delete them - which would require labour and actions on your part that
>>will cost you money, as opposed to leave them alone!) until one of the
>>following events occurs:
>>
>>        - either someone owns up to that domain and offers you both updated
>>contact information *and* money, and defines the anniversary, by
>>implication, to be the date of this request, or:
>>
>>        - twelve months have elapsed from 01-Nov-1996 (when you started
>>operations), at which point you explictly purge all COM.AU names which are
>>not, at that time, paid up and registered properly.
>>
>>The point here: the incremental cost to you of existing entries in the DNS
>>is damn near ZERO. So **LEAVE THEM THERE** until either someone claims it
>>(with money to back up the claim) or we reach the end of 1997.  Let elapsed
>>time do the work. Then you will
>>
>>(a) alienate NOBODY
>>
>>(b) cost yourself no work at all for domains you don't need to care about.
>>They've been incorrect or broken for years, don't worry about it, *LEAVE
>>THEM ALONE* and just purge un-claimed domains after 12 months.
>>
>>Surely that's simple enough, and fair enough, for us all to accept? Please?
>>
>[...]
>>
>>Think of the benefit - that huge labour intensive task you're about to start
>>to get everything current - just *DON"T BOTHER*. Wait for your customer base
>>to do your work for you.
>>
>[...]
>>Simon Hackett, Technical Director, Internode Systems Pty Ltd
>>31 York St [PO Box 284, Rundle Mall], Adelaide, SA 5000 Australia
>>Email: simon&#167;internode.com.au  Web: http://www.on.net
>>Phone: +61-8-8223-2999          Fax: +61-8-8223-1777
>
>I agree completely. This is by far the fairest AND most logical solution to
>the anniversary date problem. This would make the anniversary date process
>completely transparent for all stakeholders and save M.IT a lot of hassle,
>both from the customer relations aspect as well as their labour resource
>allocation.
>
>In planning effective allocation of resources, it is far better for M.IT to
>spread the re-registration load out over a period of time such as 12
>months, than to have to attempt to deal with a huge peak load over a period
>of two months. After all, we know that, inevitably, most people and
>organisations are going to leave their re-registrations until the last
>minute, as human nature is inclined to do.
>
>A basic strategic plan, which would have included a market analysis as well
>as a full SWOT analysis, should have indicated to M.IT that this would be
>the most effective strategy in terms of effective and efficient resource
>allocation, as well as maintaining good stakeholder relations (bearing in
>mind that stakeholders, particulary customers, ARE a major resource for any
>organisation). Unless, of course, the strategy of M.IT is to monopolise the
>market - in which case, the ineffective and wasteful allocation of
>resources AS WELL AS the construction of bad stakeholder/customer relations
>would not really matter to them.
>
>
>Regards,
>Boz
>
>Boz Cappie
>Dept of Social Communication and Journalism
>Faculty of Humanities & Social Sciences
>University of Technology
>Sydney
>Australia
>ph: + 61 2 9514 1955
>e-mail: B.Cappie&#167;hum.uts.edu.au
>--- reality is what you can get away with ---
>
>
>
---
Simon Hackett, Technical Director, Internode Systems Pty Ltd
31 York St [PO Box 284, Rundle Mall], Adelaide, SA 5000 Australia
Email: simon&#167;internode.com.au  Web: http://www.on.net
Phone: +61-8-8223-2999          Fax: +61-8-8223-1777
Received on Mon Dec 02 1996 - 08:41:29 UTC

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