> 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 do you say this?

Compare

	http://www.aunic.net/tdcom-1.html
	http://www.west.net.au/asn.au

In each case, we're both using AUNIC's database at the back
end, but have full control over what goes on the "shop front".


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

Sure.  I don't see the point, but obviously its a
trivial extension.

So the "NIC" Software is reduced to a three stage form handler
that does:

	Part A - Submission

	; Check for Required Fields

	; Check required format of some fields (eg: ACN for com.au)

	; Confirm this domain is not already approved/pending

	; Add to "pending" queue

	; Prepare for required delivery to DNA


	Part B - Rejection

	; Confirm we have a pending domain for this rejection

	; Confirm the source is legitimate

	; Remove from pending queue

	; Notify DNA of success

	; Notify submitter of rejection


	Part C - Approval

	; Confirm we have a pending domain for this rejection

	; Confirm the source is legitimate

	; Add to Approved database

	; Notify zone file maintainer of request for addition (if != DNA)

	; Notify DNA of success

	; Notify submitter of approval


The zone file maintainer will presumably have some semi automated
or fully automated software to insert new additions.  Minimal 
example: 2LD NIC places domains for approval in a directory.  Zone
maintainer scp/ftp/http's the info in and processes it.

This is a fairly simple form handler.  It leaves database
selection, future searches of the databases, and some way
of uniformly allowing one search of .AU as future exercises.

MM