Re: DNS: URGENT - We must take a stand against Melbourne IT

Re: DNS: URGENT - We must take a stand against Melbourne IT

From: David Keegel <djk§>
Date: Sun, 17 Nov 1996 19:45:41 +1100 (EST)
I'm reducing address list back down to dns&#167; since the purpose
of this list is to discuss exactly these issues, whereas aussie-isp is
for different things.  The way some mail lists set the Reply-To: header
means that there is the potential for cross-posting to lead to dns disc-
ussions taking place only in aussie-isp or inet-issues etc, and not dns.

In future can people wanting to comment on Melbourne IT and PLEASE
send their comments only to dns&#167; (or xxx§

Richard Archer wrote:
] Some policies which MelbourneIT could improve upon:
] The need to fax your credit card details or post a cheque before the
] request is put into the queue.
] The requirement for a personal/company cheque to have cleared before the
] request is put into the queue.

I thought I explained why this should not be a problem once most ISPs 
become PISPs.  Then the end-user can let the PISP deal with that stuff
with Melbourne IT and end-user only has to deal with their chosen PISP's
payment terms.

I am pleased to see the Melbourne IT has made a list of PISPs available
on their Web page.  Has any thought been put into compiling a list of
PISPs who will forward DNS registrations from the general population
(rather than just customers the PISP sells Internet Services to)?

Once there is at least one well-known PISP who will forward registrations
from anyone, funded from a margin on registrations rather than being cross-
subsidised by an ISP business, then the whole issue of Melbourne IT's
payment terms has very little importance.

In a sense this is as if Melbourne IT had out-sourced most of their
Accounts Department for the bureau.

] Requiring renewal of domain names in such a short time frame.

I'm more concerned about the ratio of renewal price to initial rego price.
I would have thought the renewal price should be significantly less than
the initial registration (which includes 2 years renewal).
] Three-tiered pricing structure... this can only be designed to increase
] revenues. If it is possible to perform registrations in 24 hours, why not
] do so as standard, guaranteeing registrations in 10 days.

I think Melbourne IT having a tiered pricing structure is quite reasonable.
As long as it doesn't generate too much accounting overhead within the Bureau
-- because in the end it is we domain holders who pay for Melbourne
IT's overheads in the Bureau. 

Presumably Melbourne IT have allocated more staff per registration for the
higher priority requests.  To handle a much higher number of requests in
24 hours would require more staff, and therefore be more expensive.

] Charging a 100% surcharge to expedite processing, then another 100% to
] expedite processing again.

If a company really needs it fast, they should be prepared to pay.
] Charging a regular fee for maintenance of the domain name, then charging
] an extra maintenance fee if manual work is required. Surely one fee or
] the other is appropriate, but not both.

This seems to have changed since your mail.
Personally I would have thought a scheme where the maintenance fee includes
N free changes (say 1<N<5) and excess changes attract an additional fee,
would be a reasonable one.

] Requiring a minimum of $1000 to start a PISP account.

The point of PISP accounts is that transactions are in bulk. 

For small ISPs who would get less than 10 registrations per year and
don't have enough cash flow to become PISPs themselves can set up a
scenario like this :-
	customer -> ISP -> PISP -> Melbourne IT
where the PISP might be the ISP's upstream ISP, or might even be a
Basically, the ISP makes sure the forms are filled in correctly, and
the PISP handles the financial interaction with Melbourne IT.

] It would appear that the MelbourneIT pricing structure has been developed
] with the assumption of having a monopoly over the domain. If there was some
] competition for this business, I am sure the pricing structure and billing
] policies would have been quite different.

I seem to remember the words "non-exclusive delegation", but I'm not sure
what this means in practice.  It seems pretty exclusive so far, but maybe
we haven't seen the whole picture.
David Keegel <djk&#167;>  +61 3 9642-5997
Cybersource P/L: Unix Systems Administration and TCP/IP network management
Received on Sun Nov 17 1996 - 20:31:26 UTC

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