[DNS] Acceptable levels of service (Was [DNS] ENOUGH is ENOUGH)

[DNS] Acceptable levels of service (Was [DNS] ENOUGH is ENOUGH)

From: John Kidston <j.kidston§citec.qld.gov.au>
Date: Wed, 22 Jul 1998 11:07:54 +1000
Puuling us back on track, Geoff Newton was kind enough to contribute:
> 
> Sadly this topic seems to be degenerating into a flame war.
> 
What we have witnessed is that there is some frustration with the
process, especially the lack of predictability in timeframes.

> Could I propose that we cast our considerable efforts into the process
> rather than the individual(s).
>
The individual(s) are not the issue, the scope of their workload is -
regardless of whether they are the volunteer heroes who are desperately
holding the whole thing together, or the ISPs and others who are masking
the complexities from the end consumers.

> Perhaps this group (or another even!) should be considering what are
> acceptable levels of service for dns administration in .org.au. It
> could
> be that clients just need to be reminded of the typical turnaround
> time
> in such requests. Possibly a web form could be developed to give
> people
> an idea of the position of their request in the queue, and the number
> of
> requests processed per day.
>
 The AUNIC web site currently contains the disclaimer: "The time to
complete processing of an application is not undertaken with any stated
period."  However, since this is in the policy document
http://www.aunic.net/policies.html it is probably rarely read.

The idea of an indicator to show position in queue and rate of
processing is a good one.  However, it would be worth noting that this
issue was raised in relation to "org.au", and I suspect that the
processing time required for applications in domains like org.au,
asn.au, id.au, and info.au is considerably more variable than for
com.au, edu.au, net.au, and gov.au.  Applicants would need to be made
aware of this variability.

Another issue which arises is how "challenging" applications are dealt
with.  If the registry has to seek further information from the
applicant, or refer issues to other bodies, what happens to the
application?  Does it go into a holding area and receive priority
immediately the relevant information arrives at the registry?  Or does
it simply return to the end of the queue?

> Would anybody be interested in jotting down some of the administrative
> operations and "proposed" turnaround times?
>
I'll open by suggesting that 14 days should be an acceptable turnaround
time.  Domain names are required when an entity effects an Internet
presence, and the planning and implementation of this would take at
least that long.  Of course, this requires domain name registration to
be in the early stages of implementation, not right at the end as is
often the case.  (It's amazing how many organisations spend three months
developing a web site, and then expect instant turnaround on
registration/delegation of a domain name.)
 
> I'd council against a knee-jerk reaction to dissolve the existing
> process and replace it with another using the same articles. I think
> the
> Australian Internet community should be better defining the
> requirements
> first. That then gives a mechanism to evaluate whether the existing
> systems works, needs refinement, or needs replacing.
> 
> Much has been done on the free time of individuals for the greater
> good
> of the Internet in Oz. I appreciate and commend the efforts of those
> people (both recognised and not). However, the net is getting bigger,
> and the issues trickier. Perhaps we (on this list) should be
> contributing something constructive to do our bit on this.
> 
Yes indeed.  Simply moving the difficulties from dedicated, experienced
people to enthusiastic novices will not solve the issues which confront
us.  Perhaps enlarging the team may help.

> Just my $0.02
>
And most appreciated :-)
 
John Kidston
CITEC  - A business of the Queensland Government
Ph +61 7 32222356    Fx +61 7 32247327  E-mail
j.kidston&#167;citec.qld.gov.au
Received on Wed Jul 22 1998 - 09:09:19 UTC

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