Melbourne IT comments on the .net criteria

["Bruce Tonkin" <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>]

Melbourne IT comments on the .net criteria submitted to the GNSO Council
9 July 2004
========================================================================
=============
========================================================================
==============

Clarification
=============
These comments are submitted by Bruce Tonkin in his role as Chief
Technology Officer of Melbourne IT, and are the views from a single
registrar.  

Declaration of Conflict of Interest
===================================
Melbourne IT is a 10% shareholder in Neulevel, the operator of the .biz
registry.


(0) Executive summary
=====================

This is a brief summary of the suggested changes to the criteria
described in detail below.

- recommend the .net subcommittee reference its particular
recommendations against the mission and core values of ICANN as listed
in the bylaws.

- recommend the .net subcommittee consider and include a reference to
the criteria used in the first round of new TLDs:
http://www.icann.org/tlds/tld-criteria-15aug00.htm 

- provide tighter minimum criteria for performance specifications for
the .net registry.  Use the definitions of the .biz agreement as a
guide, and also review the actual performance of the .net registry
operator averaged over the past 12 months as detailed in the public
monthly reports as a benchmark.  The objective should be to enhance the
current service.  The current criteria in the .net registry agreement
are well below that acceptable for a registrar.   Melbourne IT would
prefer to see a reliability figure of 99.95% for the registry/registrar
provisioning system.

- add "migration strategy" as a selection criteria.  The objective
should be to minimise the overall .net service cost for existing
registrars (ie the migration cost should be outweighed by savings
elsewhere), and also maximise the choice available for registrars (e.g
choice of thin versus thick registry on a per registrar basis).

- remove "maximisation of consumer choice" as a criteria.  This is
meaningless, as .net is already available to consumers.  ICANN is
exercising its choice in a competitive registry operator market to
choose a registry operator for .net that best meets the needs of its
registrar customers.  

- add a new criteria: "maximise the service provided to registrars".
Registrars have no individual choice of registry operator.  The service
a registrar can provide to a consumer or reseller, will ultimately be
determined by the quality and level of service provided by the monopoly
.net registry operator.  If a registry operator can lower a registrars
costs through new and improved services, this will be able to passed
onto consumers in the competitive registrar market.

- remove the section on "pricing".  Pricing is a term best used in the
context of consumers, and the price a consumer pays is determined by
registrars or their resellers. 

- add a new criteria "impact on registrar cost".  Registrar cost is
defined as the impact on a registrar's costs of the .net registry
service.  The cost consists of migration costs, the registry fees
charged to the registrar, ICANN's fee, and may be influenced by any cost
savings possible from improved registry service.   Applicants should
describe how their proposal would reduce a registrars overall costs."

- request ICANN to review the registry licence fee for .net, and include
it as a condition of the tender.  An increase in the .net registry
operator fee may allow a reduction in the fees paid to ICANN by
registrars, and potentially may lead to a reduction in the retail prices
paid by consumers.

- under the innovation and value criteria, require applicants to
specifically describe how they will enhance three main services:
registrar transfers, WHOIS, and allocation of deleted names.  These
three areas have been the most discussed issues in the GNSO over the
past several years, and the tender process is an opportunity for ICANN
to seek, on behalf of registrars, innovative solutions that provide a
benefit for registrars and their customers.  These three areas are
significant contributors to registrars costs.

- generalize the relative criteria to improve the existing stability,
reliability, and security of the registry.  Applicants should indicate
how their proposed solution compares against the current service as
reporting in the current .net operator's monthly reports over the past
12 months, and indicate how they could enhance the service.   For
example an applicant should provide the mean time to resolution for
additions or changes to the .net zone file.

- improve the wording regarding suppliers and vendors to avoid the
impression that this is targeted at registry operators as suppliers.
Here is some suggested wording:
"Applicants should indicate how they will implement the registry
solution to maximise stability, security and reliability.  It is
preferable for the .net registry operator to use a diversity of computer
hardware vendors, software vendors, telecommunications vendors, Internet
service providers, and also locate services across a geographically
diverse area."












(1) General comments
====================


I recommend that the GNSO report specifically reference its
recommendations against ICANN's mission and relevant core values.

ICANN's basic mission is:
"to coordinate, at the overall level, the global Internet's systems of
unique identifiers, and in particular to ensure the stable and secure
operation of the Internet's unique identifier systems."

The core values relevant to the .net tender are:

1. Preserving and enhancing the operational stability, reliability,
security, and global interoperability of the Internet.

- this is a core requirement

2. Respecting the creativity, innovation, and flow of information made
possible by the Internet by limiting ICANN's activities to those matters
within ICANN's mission requiring or significantly benefiting from global
coordination.

- should encourage creativity and innovation


4. Seeking and supporting broad, informed participation reflecting the
functional, geographic, and cultural diversity of the Internet at all
levels of policy development and decision-making.

- ensure broad participation in deciding on changes in the .net registry
operation.

5. Where feasible and appropriate, depending on market mechanisms to
promote and sustain a competitive environment.

- putting out the operation of the .net registry for tender is itself a
market mechanism to get the best result.

6. Introducing and promoting competition in the registration of domain
names where practicable and beneficial in the public interest.

The GNSO .net subcommitteee may also wish to review aspects of the
criteria used in the first round of new TLDs:
http://www.icann.org/tlds/tld-criteria-15aug00.htm


As a registrar, Melbourne IT is a customer of the .net registry
operator.  We believe that ICANN is now taking advantage of the
competitive registry operator market to operate a tender process to
select a registry operator that can provide the best result to its
customers (registrars), and also ensure that the new registry operator
ENHANCES the operational stability, reliability, security, and global
interoperability of .net in accordance with ICANN's mission.   As the
.net registry operator is in a monopoly position with respect to .net,
it is necessary for ICANN to operate the process on behalf of all the
registrars, as registrars can't independently select their own registry
operator.   Melbourne IT would like to see a better service provided as
an outcome of the tender process, and thus ICANN needs to properly
benchmark the current performance provided by the existing .net
operator.




(2) Absolute criteria related to stability, security, technical and
financial competence
========================================================================
==============

The performance specifications in the current .net registry agreement
are below what Melbourne IT would like to receive as a registrar.  For
example the performance specifications in the .biz agreement are both at
a higher standard (e.g 99.9% uptime for the provisioning system) and
more specific.

A registrar is very dependent on the uptime available from the registry
provisioning system.  Although a registry may queue transactions when a
registry is done, there is a diminished service offered to customers
(for example the availability of a name or the success of registration
cannot be guaranteed).  The current .net agreement allows for 4 hours
unplanned outage per month.

A review of the current .net registry operator's actual performance for
2003, shows that most months there was zero unplanned outage.  To ensure
that registrars do not receive a lower level of service from the .net
operator in future, I recommend ICANN establish the average performance
measured over a 12 month period, and set this as a benchmark to be met
in the tender.  Remember it is ICANN's responsibility to ENHANCE the
current reliability of Internet services.

I would like to see a minimum reliability figure of above 99.95% for the
registry provisioning systems (excluding planned outages).   The growth
in collective industry experience and improvements in technology should
be reflected in an improvement in the service levels available with
.net.   There should also be financial penalty clauses to ensure that
registrars are compensated when a registry operator fails its service
level agreement.  This ensures that there is an economic motivation for
the registry operator to operate at the highest levels.



(3) Migration issues
====================

When a company considers changing supplier, a key component of the
consideration is the cost of migration to the new supplier.   Any
benefits in a lower price of service need to take into account the
migration cost.

In the case of the recent .org migration, registrars received no benefit
in terms of a lower per transaction cost, and they were forced to accept
a high migration cost.  Thus the .org process actually led to a net
increase in expenses for registrars.  It is notable that the number of
.org names as a proportion of .com names has slightly dropped since the
change in registry operator.

Ideally as a registrar, I would like to see the new operator continue to
support the RRP protocol and thin registry model, as well as offer the
option for registrars to migrate to the EPP protocol (especially useful
for new registrars entering the market), and the option to elect to
operate with a thick registry model.

I would recommend that the "migration strategy" be considered a key
criteria (under the relative criteria section) in the selection of the
new .net operator, and ensure that the cost of migration for existing
registrar customers is properly evaluated (perhaps using a subcommittee
of registrars that are not associated with any of the tenders).


(4) Competition
===============

I see little impact on consumer choice with respect to the .net tender.
The .net TLD already exists, and consumers already can choose .net over
other TLDs.  The recent experience with the change in the .org operator,
showed that a change in registry operator has almost no influence on the
market (ie the proportion of .org names compared to .com names is
slightly below (as of the most recent monthly report on the ICANN
website) the proportion prior to the change in operator).

Once a company is operating a particular TLD, it is in a monopoly
position and there is often little incentive to significantly improve
the service for registrars (and their customers).  The recent focus of
the current .net operator has been on finding new services (e.g WLS) for
which it can charge registrars, rather than improving the current
services (e.g improving the implementation of the transfers function).

Instead I see the tender process itself, if run at regular intervals,
giving registrars (and ultimately consumers) the best chance of getting
an improved service at an improved cost.

I recommend removing the "maximisation of consumer choice" as one of the
criteria.

It would be better to say: "maximise the service provided to
registrars".   Registrars have no choice of .net registry operator, but
ICANN does have the opportunity as part of the tender process to choose
the operator most likely to provide better service.


(5) Pricing
===========

The prices charged to consumers are determined by registrars and their
resellers.  The monopoly cost components of a registrars price for .net
names, consist of the fees charged by the .net registry operator, and
the fee charged by ICANN.   

Every year ICANN has increased the fees charged to registrars, but has
not increased the fees charged to registry operators.   Even if ICANN
did increase the registry operator fee, the registry operator has a
contractual right to pass on this increase to registrars.   As the
market has grown the monopoly registry operators (which have not lowered
their registrar fees in proportion to the growth in domain name volumes)
have benefited far more than the registrars (that have generally lowered
their prices in an increasingly competitive market).

I would like to see ICANN establish as part of the tender process an
increase in the fee paid by the registry operator to ICANN for the .net
registry licence.  Thus ICANN could reduce the fees it charges
registrars.   The registry operator would need to announce the service
fee it will charge registrars, and this may have a net effect of a lower
overall cost to registrars.   

Note that a registry operator should not be constrained in the model it
proposes to charge registrars (e.g  a registry operator could reduce the
costs of registration to encourage growth in the market, or charge for
other transactions such as creating name server records).

The other cost considerations that are relevant to a registrar, are the
cost of migration to a new .net operator, and also the cost savings
possible through improved registry services.  The three main areas where
a registry operator could potentially decrease registrar costs are:
- transfers (currently a customer service nightmare)
- WHOIS (registrars are being requested to improve accuracy at their
cost - potentially a registry could provide services in this area)
- Deleted names (the current mechanisms for obtaining desirable recently
deleted domain names are inefficient and ultimately expensive for the
consumer)

The current criteria under the heading "pricing" in the GNSO criteria is
too narrow, and implies that this narrow criteria should be considered
above other criteria which all have a bearing on cost.  The word
"pricing" is often confused with the price paid by consumers.

Thus I recommend that the section on "pricing" be restated as:

"- registrar cost.  Registrar cost is defined as the impact on a
registrar's costs of the .net registry service.  The cost consists of
migration costs, the registry fees to the registrar, ICANN's fee, and
may be influenced by any cost savings possible from improved registry
service.   Applicants should describe how their proposal would reduce a
registrars overall costs."


(6) Innovation and value
========================

The service areas that have attracted the most policy development time
in the GNSO in the past few years are:
- transfers
- WHOIS
- delete processes

I recommend that the GNSO specifically include these three areas in the
criteria related to innovation and value.   Each applicant should be
required to explain how they would improve the services offered to
registrars (and hence ultimately to consumers) in these three areas.

The current .net operator has not implemented any improvements in the
transfer process.   There is a new transfers policy, but it has not been
implemented by ICANN or registry operators.  Areas where a registry
operator could improve service are: authentication techniques (such as
the EPP auth-code), dispute resolution processes (establishing a dispute
resolution process between registrars and agreeing to implement the
outcome of the dispute resolution), transfer undo processes (ensure that
a transfer made in error can be completely rolled back).

With respect to WHOIS, there are issues associated with data mining and
accuracy.  A registry operator could propose solutions to improve the
WHOIS service in both of these areas.  For example, a registry operator
could run scans on registrar addresses (with the consent of the
registrar) to identify addresses that do not seem real (e.g a street,
suburb or country that does not seem to match).  Obtaining address
information on a global basis is expensive - and very expensive if each
registrar is required to obtain such databases.  A registry operator
could make a significant contribution by obtaining address information
for at least part of the world.   This information would not stop a
registrant from deliberately using false information, but may help
improve the accuracy of information provided by registrants that supply
bad data by mistake.

The current process for re-registering deleted names for the .com and
.net domain names is very inefficient.   The first-come, first-served
allocation method has been very effective for registration of new names
where there is little contention between registrars for the same name at
the same time.  With deleted names, several registrars may wish to
acquire the name on behalf of their customer.  This is done by
saturating the registry with as many add requests as possible at the
time the name is scheduled to be deleted.  As the more requests that are
submitted, the higher the chance just one will succeed, some registrars
collude with other smaller registrars (as each registrar is given the
same number of registry connections regardless of size) to attempt to
pool their connections together and share the proceeds from any names
acquired (ie they agree not to compete against each other).  This then
disadvantages a registrar that does not participate in a pool of
registrars.  The overall cost of this process is high, and these costs
are then passed onto the consumer that eventually receives the recently
deleted name.    Perhaps the best model in these circumstances, where
there is contention amongst consumers for a single name, is an auction
model.  A registry operator may be able to propose an auction model, as
part of the tender process.  The model could include how the proceeds of
an auction could be distributed (e.g between the original registrant,
the original registrar, the registry operator, ICANN, and the new
registrar).   Note the present .net registry operator has proposed the
WLS solution, but it is only a partial solution to the problem, and
there is also likely to be contention for WLS entries.   The .net
registry tender is an opportunity for applicants to offer alternative
solutions.


(7) Relative criteria relating to stability, security, technical and
financial competence
========================================================================
================

The minimum criteria discussed in section (2) above with respect to
stability and reliability could be considered to be the basic criteria
necessary to be accredited by ICANN to be a TLD operator.  With respect
to the .net registry tender, ICANN should be giving weight to those
applications that ENHANCE the existing stability, reliability and
security of the .net service.  The current .net operator has published
in its public monthly reports its performance, and applicants should be
required to state how their service would match or exceed the current
service provided as part of the relative criteria.

Thus I recommend adding a relative criteria:
- applicants should be required to how their proposed solution compares
against the current service as reported in the current .net operator's
monthly reports over the past 12 months, and indicate how they could
enhance the service.   The existing point in the criteria related to the
zonefile is put one performance measure.  It would be better to state
this as an example under a more general point.

Here is some proposed text:
"- applicants should indicate how their proposed solution compares
against the current service as reporting current .net operator's monthly
reports over the past 12 months, and indicate how they could enhance the
service.   For example an applicant should provide the mean time to
resolution for additions or changes to the .net zone file."

With respect to the text about multiple suppliers and vendors.  It is
not clear whether this is intended to mean that it is preferable for
.net to with a different registry operator compared to .com.  This would
tend to create a bias against one of the existing registry operators.
It may be better to restate as follows:

"- Applicants should indicate how they will implement the registry
solution to maximise stability, security and reliability.  It is
preferable for operators to use a diversity of computer hardware
vendors, software vendors, telecommunications vendors, Internet service
providers, and also locate services across a geographically diverse
area."

Registry operators should also be required to state whether they plan to
support IPv6, and their plans for improving the security of the .net
registry solution (e.g trials of DNSSEC).