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

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

From: Simon Hackett <simon§internode.com.au>
Date: Mon, 21 Jul 1997 14:03:31 +0900
Steve,

thanks for responding - nice to feel like there's someone else out there :)

I appreciate that you may not be the person who is specifically chartered
with updating the document based on public comment - or are you? 

>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. 

>
>> 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?

>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).

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? 

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).

>Some of the members of ADNA have agreed to write the softwore to
>facilitate the multiple DNA problem to get around all the nasties it might
>introduce. 
>The money from the ADNA startup fee was seen to be able to fund :
>
>ADNA startup
>Software development costs
>The other aim of ADNA to monitor the .au name space
>

You were raising before the prospect of potential conflicts of interest
with IAP's being the owners of DNA's. What about the conflict of interest
inherent in IAP's being contracted to write DNA arbitration software, being
paid from the dues from a non-profit (ADNA) to do it? Cant the successfuly
DNA's simply mutually agree to fund *by themselves* the creation of any
needed software to arbitrate requests? Why put the onus of paying for that
development on the financial contributors to ADNA?

All this takes is for the selection criteria document to contain a
statement requiring all successful DNA's to contribute equally to the
development costs of any arbitration or management software which is
mutually agreed to be a requirement for successful operation? This just
needs a bullet point in an MOU, not money from ADNA (esp. since we're lead
to believe that ADNA is already oweing more money than it currently has -
why ask ADNA to fund a cent of this?)

Oh, in addition, just write in that any software so developed must be made
available at no cost to any other DNA's appointed by ADNA in any domain.
Then ADNA gets to give it away once it gets developed - it gets to be
altrustic at no cost to itself!

>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). 

Note also that the DNA's just have to agree, mutually, to co-fund a server
or two in a well connected spot for their domain (e.g. com.au) and their
own links don't actually have to be that flash after all. 

I guess we know what is being intended here - that a DNA has a
reasonable-to-good internet link at worst, but that defining this is hard.
I hesitate to suggest it, but what about saying a min of 512K into at least
one national internet backbone? Or just saying 512K min - which is probably
not a bad spot to insist on?

[about company business plans]:
>.  This is seen as being able to give ADNA an firm idea of what
>the new DNA is about:
>
>Are they cold blooded capitalists ?
>
>Are they doing this for the good of all men ?
>
>Do they have any idea what they are in for ?
>
>Do they have an upgrade path for staff recruitment ?
>Do they have an administrative framework that can handle the work load
>that they perceive they will get ?
>
>Proving people are seroius by asking them to write cheques is one thing
>but asking them to detail in a 'business plan' how they exactly intend to
>pull off this DNA thing is better.
>

You really really can't expect a selection criteria document to work if the
selection critera are not stated clearly as boolean (yes/no) things to check.

Evaluating an org against the above list of questions doesn't actually
achieve a single thing - you have to define criteria which are concrete,
and which are boolean yes/no issues with respect to whether a DNA gets to
operate or not. I really suggest checking the critera for the gTLD-mou
operators out again in this regard - while I don't happen to agree with
some of their criteria, they are very simple critera, each of which gets a
yes/no answer, each of which is therefore arguable only as to whether it is
yes or no. 

When it comes to "Do they have any idea of what they are in for?" or "Are
they cold blooded capitalists?" - which answer are you looking for, that's
the question. Which answer will cause ADNA to reject the applicant, and why?

More specifically, asking for a business plan is not the same thing as
stating whether that business plan will be used as a basis for acceptance
or rejection. Is ADNA prepared to be sued by a company who forms to become
a DNA and is rejected because someone in ADNA doesn't like the sound of
their business plan? The criteria and the *reason* for the criteria must be
clearly stated.  

I think the best you can actually ask for is a declaration by the applicant
that they are applying in good faith and intend to operate as a DNA with
dillegence and leave it at that.

>
>Perhaps 'business plan' is a poor choice of words where 'DNA plan' or
>'Domain Plan' would be better.
>

That would be a good starting change, yes - the "for the business as a
whole' bit is just silly. Are you really expecting (say) Telstra Internet
to submit the entire business plan for Telstra corporate just to become a
DNA (assuming they wanted to - this is entirely hypothetical!). Again, if
not, then the point is the make clear just what is needed to sufficiently
separate the prospective DNA from any other business interests that might
be related to some of the same people.

>I prefer this method - make being a DNA possible only if you chose to
>cooperative in the total management of the domains you are involved with.

Yep - and interestingly, in the obvious domain of initial interest, com.au,
this means that the criteria for that domain must arguably be set by either
ADNA or by a committee of all DNA"s operating in com.au - no longer can it
be set just by Melbourne IT. See the iahc.org web pages here -the aim there
is to have all operators sign a mutual MOU which does set down what
operators will agree to do collectively. THe body which the IAHC will wind
up creating to do this (CORE) will act just as a policy oversight entity,
but will NOT do any of the actual legwork. We can learn from this.

>A lot of this was put in to stop the worries about people who may want to
>generally drive down the price of domains while subsidising the
>operation from other quarters of their business. This is very much wrapped
>up with the ISP/DNA argument - should an ISP be allowed to package domians
>with products and give preferential treatment to people buying their
>other network products.

I don't think you can expect these critera to protect the community from
such a potential conflict of interest (if it actually IS one). You need to
just define the separation required in legal terms between a DNA and any
other business interests of a larger group that the DNA might be owned by
(e.g. "must be a separate legal company or partnership") or you stay out of
the argument completely.

What needs to be defined is what level of separation is enough. For
instance, Melbourne IT operate other business enterprises from the same
comapny that acts as a DNA for com.au. How are you going to evaluate
whether any of them conflict with their role as a DNA - or are you just
going to say that the DNA has to be a separate company? Does Melbourne IT
have to set up a new company and roll its employees over into it? If so,
why? If not, why not?

>
>I agree with letting market forces rule but if there are not some balances
>put in place some ugly situations could appear. 
>
>

Be careful of mandating things that put ADNA in conflict with trade
practices legislation. That legislation is quite powerful and would
presumably apply here - and I suspect would be both necessary and
sufficient without us inventing our own custom modifications to it. 

>> ok I guess, but why can't anyone else propose a new 2LD and see if anyone
>> of the existing DNA"s wants to offer to handle it? 
>
>That is really interesting - some sort of public submission process where
>anybody can 'petition' ADNA to make a new domain available. 
>

Yes, exactly - since in principle this whole process is being run by a
nonprofit to achieve improvements in community service, not to make DNA's
money (or is that true - are they just there for 'Cold Blooded Capitalists"
to make a heap of money from?). Why should they nominate the new namespaces
at all?

>You could also go see a present DNA if you really wanted wanted that
>domain badly.
>What if the proposed domain name was fairly awfull and no DNA could be
>found to take it - I guess it dies a early death.
>

Exactly :)

>I would have thought that this would not be possible (to change the naming
>policy).
>What makes an official domain description policy - surely this is done at
>boot time for the domain and cannot be changed unless the DNA has consent
>from the sub level domain operaters.

Urr, the activities of sub-level domain operators aren't relevant here
(e.g. people operating subdomains of COMPANYNAME.com.au for instance). It
just doesn't matter once the delegation has happened, what that company
does inside their sandpit.

Official domain name allocation policy is a sensitive and important issue,
especially if a domain is being operated with a non-trivial policy designed
to encourage sensible population of the namespace under that area (e.g. the
existing com.au policy). 

Melbourne IT have made changes to the policy in com.au since becoming
operational in that domain, and I expect they'll want to do so again in the
future. When they have company, I submit that they can no longer drive that
process on their own, and that just how it IS driven isn't a trivial issue.
Perhaps policy for the domain should be set and driven entirely by ADNA,
with no DNA able to do anything but agree or cease to operate in that
domain? Hmm, even that would be dangerous (what if ADNA made a poor call
and exposed the DNA"s to legal action due to a silly new policy?)

>> I don't think that's entirely fair. Insisting on a minimum of two years'
>> operation sounds great. 
>
>I think two years should be minimum.

Then just say that and leave it at that.

>In other words you are resposible for your domain and the domain
>alphabetically ahead of yours when sorted. This way the "church.au" guys
>would also have to have in their "domain plan" the way they would
>coordinate with the "hospital.au" (as they are next in the sort order) on
>the general running of the domain space for both domains.

Is the above a part of the actual intent or just a suggestion? Why don't
you simply have all DNA"s in a given name space agreeing to back each
others' data up in its entirety on a mutually reciprocal basis and leave it
at that? Why ask (for instance) a (hyopthetically) nonprofit operator of
(say) id.au to agree to back up com.au just because he's next in the sort
order?

Who is actually editing the DNA selection criteria document? Why (if
anyone) takes notice of comments made in this forum, and how are they
incorporated into the document in  a fair manner?

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. 

Simon
---
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 Jul 21 1997 - 15:07:29 UTC

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