On Mon, 31 Jan 2000, Bill Gerrard wrote:
> Hello,
>
[snip]
> > I've found NIC-Handles to have many pros, but there are also many cons to
> > it as well. I find them to be a messy implementation to a needed
> > solution.
>
> Most of the problems are caused by the policies implemented by NSI.
>
I have to agree on this one. I have had nothing but horrors changing
things around with netsol, but this is due to the rediculous email
proceedures they use, rather than the nic handle situation. On the other
hand, NIC HANDLES were made for a situation where there is a single entity
(network solutions) handling all domain modifications. There are a whole
bunch of complications which arise when you have multiple resellers each
handling modifications, especially when you consider transfers between
those entities. That having been said, I think the basic opensrs system
is going to be the best scenario for controlling a domain, and the NIC
HANDLE system the best for assigning contact information:
Each domain has a reseller and password associated. Only using
that domain name, password, and reseller password may contacts be
assigned/changed and subusers created. Each contact (org, admin, billing,
tech) is given a NIC HANDLE. This is unique throughout the entire opensrs
system. This lists a users name, address, phone number, etc. There is an
associated password with this, in order to change that information. THE
CONTACT SYSTEM HAS NOTHING TO DO WITH MANAGEMENT OF A DOMAIN. A subuser
(or multiple) may be created to change the nameservers and/or add/delete
glue records. These can also be done using the password associated with
the domain. We also manage nameservers through a NIC HANDLE system,
global throughout opensrs, and basically the same as network solutions
(except managed through the web instantly, not email hope and
pray). Transfers between resellers simply change the reseller associated
with the domain. Nothing else has to change, since it's all
global. Management can only be done through the reseller (except a
reseller transfer), you need the reseller password to manage the
domain. Contact and hostname information is global and can be changed
through any reseller. In fact, multiple resellers domains may point to
the same contact and/or hostname information. End-users should be warned
that changing this information through another reseller may expose their
password to that reseller.
This describes the server backend. Simplifications can certainly be made
at the client end, and that's really the whole point of doing it this
way. You give the flexibility for the clients to do what they need to do,
and if they choose to be more restrictive, they have the flexibility to do
that.
Please, someone try to put some holes in this. What problems would this
cause? What would it help? How can we change it? It's my opinion that
we have to get this right, as soon as possible, and that any disruption to
the old system is worth it. I came up with this pretty much on the fly,
so I'm sure there are holes, but I'm fairly sure they can be fixed. In
any case consider this a request for comments, if you will.
This archive was generated by hypermail 2.1.3 : Tue Oct 19 2004 - 23:35:19 EDT