Michael, the model you suggest doesn't seem to support different web shop-fronts for DNAs, which is essential to allow customers a choice in price+service. Why not just a standard "front-end on a database" client/server model: DNA Web shop front + customer front-end Client approval/rejection of application Submits application to 2LD NIC. 2LD NIC Central repository with FCFS operation Server applications only accepted from DNAs Very reliable operation. The race condition problem seems identical to your proposal in that the customer isn't sure they have the name until approval. The exact mode of communication between the NIC and the DNA shouldn't be specified as e-mail either. It should support e-mail, but also a protocol like ftp or http that's not a store-and-forward service. Leni. Michael Malone wrote: > Authoritive name servers probably hosted by very large > ISPs, backbone providers or > universities > > Domain Name Admins The people who say "ok, you can > have that domain". > > 2LD "NIC" A Central machine where the > applications are submitted. The > submitter will select a DNA that > they wish to pay, and it will be > emailed to that DNA. The DNA will > approve or reject the applicant, and > if approved, it will be merged into > the database at this 2LD NIC. > > This is exactly what the situation is right now with COM.AU. The > name servers are provided by a number of large well connected > networks. The DNA is Melbourne IT. AUNIC is the 2LD NIC. > I like this model. It works well, avoids race conditions at the > database end of things, and means you really don't give a toss > about the link speed of the DNA. > > By the way, I'd suspect the 2LD NIC will be a tendered position, > and probably charge the DNA's. I'd suspect the Authoritive name > servers would do their part for free and would line up to do it. > > MMReceived on Tue Jul 22 1997 - 23:54:36 UTC
This archive was generated by hypermail 2.3.0 : Sat Sep 09 2017 - 22:00:02 UTC