Re: DNS: Draft selection criteria for new DNAs and 2LDs

Re: DNS: Draft selection criteria for new DNAs and 2LDs

From: Stephen Baxter <steve§senet.com.au>
Date: Mon, 21 Jul 1997 16:30:32 +0930 (CST)
> 
> I appreciate that you may not be the person who is specifically chartered
> with updating the document based on public comment - or are you? 

No, actually I am the person that is supposed to be finding a greater
audience for ADNA to sell itself to and ,with MM, and contributing some
staff time to the software side.


> >I asked the same question at the ADNA board meeting and Peter gave me some
> >insight into the staff load at Melb IT for processing requests. To
> >roughly quote Peter - to be able to run a ".com.au" sized DNA he
> >considered five staff a minimum considering the policy constrainsts of
> >".com.au".
> 
> Sure, but in a world where there are (say) 10 com.au DNA's operational,
> would that still be true? One could argue that this would then only need
> 0.2 people-hours per week per operator, or one could argue that it would
> actually get worse than Peter's existing level due to growth rates and
> inter-DNA issues.
> 
> Why try to guess this - why specify it at all, because reality just won't
> match that number very well. 

This sort of leaves it to ADNA to take the DNA's word for it that they
will do a good job. I suppose this comes down to the market force thing
again, if the X DNA promises a certain quality level then the customers
should be able to vote with their feet if they do not meet that level.

One way around alot of issues here would be to have DNA publish their
performance on domain approval/rejection times etc :

          % < 48 hours     % < 5 days     % > 5 days
DNA A     50               46             4
DNA B     80               17             3

That is a fairly basic example but it may be a way to solve the problem of
ensuring a DNA has a service level that fits their market.
This way if a competing DNA was not keeping up with demmand then other
IAPs would not send business to them.

> >> Could a potential DNA simply nominate a company that they would contract
> >> staff in from if successful? 
> >
> >I see that as a usefull way to get around startup DNA staffing problems
> >in the cost model
> >
> 
> Cool. Now, do you edit the document to say that, or does someone else? Who
> is maintaining it?

Kevin, I think - sorry to dob you in here. Is it you ?

> 
> >There is also the point of having ISPs as DNAs - something Robert Elz has
> >been contributing to the DNASEL list. From the point of view of total
> >transparency of DNA duties having an IAP/ISP dispense this function could
> >be seen as a conflict of interest. The point was also made that certain
> >DNA's now are I[AS]Ps !
> 
> In practical terms, the fact that the employers of several of the
> Australian subdomains of .AU happen to be IAP's doesn't seem to be causing
> any harm in the community (e.g. edu.au, net.au, asn.au for instance).
> 

This was not lost on the conversation.
No accusation or aother was made against any party but the general
impression was that to have total transparency it was better not to have
this happen.

> Is creating a new, subsidiary company of an IAP parent enough to 'separate'
> the two entities for the purpose of being able to be appointed as a DNA? If
> not, how far removed is necessary exactly, and exactly why? 

I think the present system works because the poeple who are delegated the
domains are actually responsible enough not to allow otherwise but in a
'deregulated' situation it may be different.

> 
> The selection criteria really can only define how much separation from
> other existing business operations is "enough'. It's not fair to make a
> judgement that being an IAP is "bad" and (for instance) being the owner of
> a newspaper or a radio station or a telco is "good" (or at least "not bad").
> 
> The notion that an IAP owning a DNA is bad needs to be either justified,
> proven, or ignored. If it's deemed "bad" then 'sufficient separation' needs
> to be defined clearly. Then you need to figure out what to do about the
> existing domain spaces where the existing operator is employed by an IAP
> (the majority of them).

I would regard the demarcation as being a separate ACN although I do not
really know the exact legal implications of this situation in regard to
directors responsibilities etc.

Any bush lawyers available ?
Real lawyers even - Pattrick ?

[snip]
> 
> >The 64k value was a why not 64k. I agree that the conectivity of any
> >propestive DNA should be high but what how do we really measure.
> >Is that 2Mb through Telstra, Connect.com, OGN (!), Access-One or can it be
> >2Mb through a tier 9 resller !
> 
> Good point - so why actually mandate this in the application at all then -
> either you're going to require a serious level of connectivity (e.g. 2
> mb/sec at a maximum of (say) 500 milliseconds from munnari.oz.au, or
> whatever, or don't bother at all). 
> 

Something like the QoS in the TIS schedule is not bad. The DNA must be
able to demonstate suitable Internet connectivity from munnari.oz.au with
a packet return time not exceeding 300 milliseconds. 
Simple ping stats could be used as evidence of the above.


> 
> Steve, thanks very much for commenting on my original message, I appreciate
> it, and I don't mean any of the above as an attack on anyone - I'm simply
> trying to be a devil's advocate to help these criteria be useful and
> unambiguous, and I feel that the existing draft is very very ambiguous
> indeed  in terms of precisely what might be rejected in a DNA's business
> plan, and why. 

I actually spent many days compiling that reply due to the length of your
original post and was only spurred into further action by your point about
the lack of 'noise' on the channel !



Stephen Baxter                            SE Network Access
SE Network Access                         http://www.senet.com.au
Direct Internet Access                    222 Grote Street
phone : +61 8 8221 5221                   Adelaide 5000
fax   : +61 8 8221 5220

<http://www.senet.com.au/~steve/pgp.html for Public Key>
Received on Mon Jul 21 1997 - 17:16:31 UTC

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