RE: [registrars] .BIZ Queue - some interesting observations

["Michael D. Palage" <michael@palage.com>]

I would like to offer the following comments with regard to Bhavin's
previous posting.

The issues that Bhavin raised in his email are likely being discussed by
registrars with the counsel, however, such discussions are privileged and
therefore not subject to discovery.  As I have reminded people in the past,
the registrar mailing list archives are publicly available, and can be read
by plaintiff's attorneys. In light of the ongoing litigation it is prudent
to minimize discussions which could potentially be used as an adverse party
admission.

I would also like to point out that the new language in the
registry-registrar agreement states: "Registrar will not charge any domain
name applicant a fee for the application for a .BIZ domain name through the
Round Robin Selection Process".

Therefore, I question the prudence of entering into a legal contract which
one would knowingly violate by charging an application fee.

I share the collective concerns of the constituency regarding the Smiley
litigation. I have had extensive discussions with a number of the registrars
about the issue. However, I believe that it is prudent to limit certain
public discussion of the issues at this time without the consultation of
legal counsel.

To update the registrars on the Smiley litigation, there was a status
conference last week. A summary of the proceeding can be found on Bret
Fausett's Blog: http://www.lextext.com/icann. The plaintiff's indicated that
they are in the process of serving all North American registrars in
connection with this litigation.

Best regards,

Michael D. Palage





> -----Original Message-----
> From: owner-registrars@dnso.org [mailto:owner-registrars@dnso.org]On
> Behalf Of Bhavin Turakhia
> Sent: Monday, January 14, 2002 2:25 AM
> To: Registrars@Dnso. Org
> Subject: [registrars] .BIZ Queue - some interesting observations
>
>
> We are still investigating various models possible in the .BIZ Queue and
> have come up with some intertesting observations -
>
> ==========
> Parameters
> ==========
>
> ~~~~~~~~~~~~~~~~~~
> Fixed queue length
> ~~~~~~~~~~~~~~~~~~
> This refers to Registrars who will fix their queue length as opposed to
> having a variable queue size. A fixed queue length lends confidence to the
> applicant about the chances of his getting a particular name.
>
> Issues:
> * A short fixed queue length may not be possible for larger registrars who
> have a large number of customers
>
> ~~~~~~~~~~~~~~~~~~~~~
> Variable queue length
> ~~~~~~~~~~~~~~~~~~~~~
> This refers to Registrars who have a variable queue size.
>
> Issues:
> * A variable queue length does not lend confidence to the
> customers and does
> not give them an idea on their chances.
>
> * For smaller registrars who are anyways unable to sell more than
> a certain
> number of spots it maybe better to fix the number of spots from the
> beginning in order to allow customers to make an informed decision
>
> * A variable queue length cannot be used with success-based charging as
> discussed below.
>
>
> ~~~~~~~~~~~~~~~~~~~~~~
> Success based charging
> ~~~~~~~~~~~~~~~~~~~~~~
> This refers to Registrars who will collect money from all applicants, but
> refund money of those applicants who do not get their names. In .BIZ
> Neulevel themselves advise for a success-based pricing model only
> (though it
> remains to be seen if Registrars are willing to bear the entire cost of
> accepting and refunding money to a large customer base)
>
> Issues:
> * If a large number of Registrars choose this model, then all applicants
> will apply for their domain names with ALL these registrars
> considering that
> they have to ONLY BEAR A COST if the domain name gets registered.
> Therefore
> if they apply with 10 Registrars, they would get a refund from 9 of them
> eventually.
>
> * All Registrars who opt for this ONLY success based model will most
> probably end up getting all 39000 applications (unless they have a fixed
> queue length). Just to give an example, if all 75 Registrars subscribe to
> this model, then all applicants will apply to all 75 Registrars. Each
> Registrar will have 39000 appliations in their queue. Each Registrar will
> manage to register 520 names and will have to refund money taken for 38480
> applications.
>
> * Infact if I see other registrars working on this model, I will myself go
> and apply for names in my queue in their queue too as an
> insurance, since I
> would have to pay them only if my domain got registered thru them
> and would
> get a refund if it did not. Registrars who are intelligent will
> realise that
> they themselves can put their customers names across several of
> these queues
> and offer a higher success rate at a zero cost
>
> * This model would not work with the MULTIPLE APPLICATIONS parameter as
> discussed below
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Non-success based pricing
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> This refers to Registrars who will collect money from all applicants
> irrespective of whether the, domain name of the applicant gets
> registered or
> not.
>
> Issues:
> * Neulevel currently advises against it (though a large number of
> Registrars
> did follow this model in the .INFO Landrush without any
> complications then)
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Multiple applications in same queue
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> This refers to Registrars who will allow multiple applications
> for the same
> name in their queue
>
> Issues:
> * This model canot work if the Registrar is following a Success based
> charging model. For instance I am wondering with this model how a
> Registrar
> would prevent multiple applciations from the same registrant. For instance
> if A wants to register a domain abcd.biz. A would register this
> domain name
> with a registrar and pay for 1000 applications for it under
> different names
> thus increasing his chances by 999, at a ZERO cost since he would obtain a
> refund for 999 applications if one of them goes thru.
>
> * each multiple application reduces the chances of the registrar getting
> another domain in the queue by 75 domains (since 75 other domains will get
> processed before this registrars turn comes again)
>
> * Customers are not comfrotable with multiple applications
> considering that
> they apply for a domain name with a Registrar and another
> applciant applies
> for the same domain name with the same Registrar and therefore creates
> internal competition
>
> Based on the above parameters I believe the best model would be to charge
> irrespective of success. This would allow larger Registrars to have a
> variable queue with multiple applications. Smaller Registrars
> meanwhile can
> have short fixed queues at a higher value to end customers.
>
> Best Regards
> Bhavin Turakhia
> CEO
> Directi
> ----------------------------
> Tel: 91-22-6370256 (4 lines)
> Fax: 91-22-6370255
> http://www.directi.com
> ----------------------------
>