ICANN/DNSO
DNSO Mailling lists archives

[ga]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [ga] Date: Wed, 9 Jan 2002 15:53:53 -0500


Elliot,

I, for one, appreciate your presentation of an objective view on, and
a potential resolution for, this issue. Much of the recent traffic on
this list has sunk to the personal level, which destroys the focus on
the issue and equally diminishes the opportunity for consensus and a
resolution.

The theory behind the WLS proposal, as I read it, was that it
addressed technical issues which could not otherwise be addressed on a
technical level. Your comments say, in contrast, that there is no
immediate technical problem with dropping deletions or, IOW that the
problem has been solved.

Since it is no longer broken and, therefore, does not demand a fix,
then I summize that the only motivation for a change in the business
model is for the Registry and certain Registrars to make additional
revenue from the secondary market, but in a structured and regulated
way.

Personally, I am not against anyone making a buck and I support free
enterprise, democracy and the entrepreneurial spirit. The premise is
that free enterprise spurs healthy competition, fosters R&D and
technological advances, drives down the price to the consumer and
expands the power and capabilities of humankind.  I support those
ideals and I believe in them.

Therefore, with all due respect to you and your noble intentions, with
respect to a workable resolution for this issue, I disagree with your
proposal for a least two reasons:

1. There is no compelling reason to change anything, since, in
contrast to the premise behind the WLS proposal, there is nothing to
fix.

2. There are already Registrars and others participating, in one
fashion or another, in the after-market.  The proposal would,
essentially, thwart healthy competition, since it regulates the price
and, therefore, service and innovation.

I do not mean the foregoing to convey the notion that I am resistive
to change.  In contrast, I remember when RAM was called CORE and I had
a PC before anyone ever called them by that name.  I am in favor of
"healthy" change, but I don't view any change with respect to the
after-market to be either healthy or warranted at this time.

There are several more elementary challenges which need to be solved
before a "moving forward" mind-set is warranted, in my view.  Some,
are, as follows:

1. At least one Registrar admitted to a back room deal concerning the
registration of expired domain names during the 45 day period. I won't
mention the name out of respect, but it does tell me that there is the
potential for abuse currently in the system. I am told, but have
not read it for myself, that the ICANN contract is not clear on this
particular issue, since it speaks to ICANN's pertinent
regulations/procedures, but no such regulations/procedures currently
exist.

2. There seems to be an abundance of complaints, which I have read on
other lists, about the Registry's (or it's brother/sister the Registrar)
concerning the hoarding of expired domain names.

3. There are issues with respect to domain name transfers.  It seems
that some Registrars have departed from the main-stream and introduced
there own policies and procedures which depart from the ICANN
agreement.

So, with all due respect to you, Elliot, and the other poor souls who
have labored through this long post, I think we should fix the current
problems with the system first -- making those a priority over new
ventures (or adventures) into different markets.  IOW, I favor putting
the after-market on the "back-burner" for now and doing some much
needed house cleaning and maintenance.

Thanks,



Wednesday, January 09, 2002, 3:26:44 PM, Elliot Noss <enoss@tucows.com> wrote:

EN> I wanted to take a bit of a "clean-sheet" approach to this discussion as the
EN> points I wish to communicate cut across a number of different threads on a
EN> number of different lists.

EN> There are really four topics I wish to raise as follows:

EN> - Who has the "right" to deal with expired/expiring names?
EN> - The mixing in this discussion of two seperate issues, registry load and
EN> the allocation of expired/expiring names;
EN> - The inefficiency that results from any flat-price solution;
EN> - A way forward.

EN> Who has the "right" to expired/expiring names?
EN> -----------------------------------------------
EN> This is an issue that creates an interesting sub-text to this entire
EN> discussion, yet has not been fully examined. There are three potential
EN> claimants for this right and three possible states for these names.
EN> Claimants include registrants, registry and registrars. States include
EN> unexpired, expired in the grace period and expired o/s the grace period.
EN> There are two things that are clear. First, that no one party is clearly
EN> entitled to stake a claim. Registrars are limited by the terms of 3.7.5 of
EN> the RAA which require that names be put back in the pool if not renewed. The
EN> registry is limited by its role as monopoly technical supplier and by the
EN> Registry agreement which entitles it to a fee for the services it is
EN> contracted to perform and confers upon it no property rights beyond that.
EN> Registrants are limited by a number of practical issues including their
EN> limited rights in a name and their diffuse nature.

EN> What is clear to me is that this IS NOT a function of a registrars terms of
EN> service, nor is it an inherent right contained in the registry agreement.

EN> At the same time we must keep our eye on the fact that the role of
EN> registrars and registry is, most purely, to efficiently administer the
EN> allocation and provisioning of domain names. This means that the best
EN> approach is the one that puts names into the hands of those who would put
EN> them to the most use. Names in the hands of those who most desire them will
EN> lead to a fuller utilization of the Internet, more value for users and more
EN> revenue for registrars and registries.

EN> This point should not be seen as at odds with an egalitarian (as opposed to
EN> equitable) view of domain names and first-come-first-served ("FCFS"), but I
EN> realize this is a point that would be the subject of much debate. What is
EN> interesting today is that we are at a unique time and place in the history
EN> of the DNS which makes this less contentious. We have one extremely mature
EN> namespace in .com/.net/.org. It is almost certain to be the largest
EN> namespace throughout the lifecycle of the current DNS. It also has a
EN> secondary market that is more evolved than any other will ever be. We also
EN> have the recent introduction of new gTLDs that provide a fresh supply of
EN> names. This means any solution effected can be tailored to the current
EN> circumstance.

EN> We must also remember that there are two groups of registrants that we must
EN> consider, current registrants and potential registrants. They have distinct
EN> interests. Current registrants have rights around their existing names, both
EN> in terms of security from losing a name through inadvertance and in excess
EN> economic value. Potential registrants benefit from being able to efficiently
EN> obtain names that are currently owned. With the introduction of new gTLDs
EN> potential registrants have, and will continue to have more and better
EN> alternatives. The maximum value in the secondary market exists right now,
EN> today.

EN> At the end of the day the competing claims of registries and registrars are
EN> likely subordinate to those of registrants. Accordingly, any solution should
EN> start with this underpinning.

EN> Registry load and the allocation of expired/expiring names
EN> -----------------------------------------------------------
EN> It has been noted by a number of people in this debate, and has been my
EN> position for many months, that the issues of registry load and the the
EN> allocation of expired/expiring names are being mixed together unnecessarily.

EN> I wish to add my voice to the chorus saying that these issues are related
EN> only remotely, almost accidentally. There have been a number of very good
EN> suggestions as to simple steps the registry could take to lessen the load.
EN> There are a couple additional points worth noting here. First, the current
EN> solution is no longer broken. While I am not a fan of the status quo, the
EN> registry has weathered the storm and there seems to currently be no
EN> appreciable impact on our day-to-day business (which was not the case a
EN> short time ago). An additional measure or two (a modified check command,
EN> additional, transparent compliance, all names dropping in real time and a
EN> published drop list are the easiest and most effective IMHO) would make this
EN> a non-issue.

EN> It is worth noting my personal dealings with the registry on the question of
EN> load have been positive and I was impressed with their genuine desire to
EN> solve the issues at hand.

EN> This last point leads me to feel comfortable that these issues are not being
EN> presented as being directly connected and can be dealt with seperately. I
EN> would, of course, love to hear Chuck confirm this.


EN> The Inefficiency of flat pricing
EN> ---------------------------------
EN> The current market for domain names is characterized by flat-priced supply
EN> and variable-priced demand. I do not take a politial position on this, I
EN> merely note it as observation. This market inefficiency (again observation
EN> not position) has lead to the existance of a robust secondary market. It has
EN> also lead to a significant amount of the current CNO namespace sitting
EN> unused.

EN> I have strong reservations about any solution geared at the expiring market
EN> that magnifies that inefficiency. By definition it leaves money on the table
EN> and leaves demand unfulfilled at the same time. The worst of both worlds.
EN> Ideally we could find a solution that was able to create a robust, efficient
EN> secondary market which would benefit registrars and the registry, but if
EN> done properly would most benefit registrants.

EN> A suggested way forward
EN> ------------------------
EN> Unfortunately, for me, the existing WLS proposal is not acceptable. The
EN> inefficiencies are large and the economics are miles away from either fair
EN> or realistic. With significantly re-worked economics it could be an
EN> acceptable interim step, but I am not sure we need an interim step,
EN> especially given the decoupling of the registry load issue.

EN> It seems to me there is a way forward that addresses all of the above
EN> issues. I would suggest two important modifications to the existing Peter
EN> Girard proposal. An unlimited bidding period and the bulk of the fees going
EN> to existing registrants rather than registrars.

EN> All names should be available to "bid" on at any time. A "bid" by a
EN> prospective registrant would require an administrative fee collected by a
EN> registrar, shared with registry and would be available for acceptance by the
EN> existing registrant at any time. A sucessful transaction would lead to a fee
EN> to both registry and registrars. An example:

EN> - Potential registrant places a bid of $150 on abcd.com and for doing so
EN> pays a non-refundable administrative fee to registrar x of $10 and in turn
EN> registrar pays registry $5;
EN> - Original registrant is made aware of his ability to "transfer" the name
EN> and any unexpired term to a potential registrant for $120;
EN> - If original registrant decides to accept he contacts the existing
EN> registrar of record and informs him of his desire;
EN> - If the registrars are different the $30 transaction fee is split 1/3 each,
EN> if the same than the split is equal between registrar and registry;
EN> - The fee would be a % of bid, capped at a relatively low number ($30?).

EN> To be clear, this is described in very brief terms and would need
EN> significant rounding out as well as a champion so please work the principals
EN> not the specifics.

EN> This solution would provide significant benefits to everyone involved in
EN> both an equitable and palatable fashion. It would also keep both registrars
EN> and registries in their role of market makers not market participants and
EN> would create a level of efficiency that would lead to increased revenues,
EN> increased registrant satisfaction and, perhaps most importantly, maximized
EN> use of the namespace.

EN> The original administrative fee would/should act so as to deter nearly all
EN> wasteful behaviour. Technically, it need be no more complicated than an
EN> interface between the SRS and EBay's open APIs (full credit here to Joyce
EN> Lin in Montevideo, if only we would have listened to you then!). It could be
EN> completely done by the registry, by the registry with technical partners,
EN> Peter could do it, or it could be put out to a completely new tender
EN> process. I know we would love to build it (but to be clear we are not
EN> throwing our hat in the ring whatsoever). I know perhaps fifty people
EN> reading this message would love to build it. That kind of excites me,
EN> thinking of all of the extremely capable people who could nail this
EN> technically. Innovation would abound if we let it.

EN> The single largest beneficiary would be the registry. Ok by me. The largest
EN> cumulative benefit would accrue to registrants. Again, that works for me. I
EN> think this would be an absolutely elegant outcome for everyone.

EN> Regards

EN> Elliot Noss
EN> Tucows inc.
EN> 416-538-5494

EN> --
EN> This message was passed to you via the ga@dnso.org list.
EN> Send mail to majordomo@dnso.org to unsubscribe
EN> ("unsubscribe ga" in the body of the message).
EN> Archives at http://www.dnso.org/archives.html




----
Don Brown - Dallas, Texas USA     Internet Concepts, Inc.
donbrown_l@inetconcepts.net         http://www.inetconcepts.net
PGP Key ID: 04C99A55              (972) 788-2364  Fax: (972) 788-5049
Providing Internet Solutions Worldwide - An eDataWeb Affiliate
----

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html



<<< Chronological Index >>>    <<< Thread Index >>>