[alac] [fwd] [council] Status of registrar constituency statement on the approval process for new gtld services (from: Bruce.Tonkin@melbourneit.com.au)

[Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>]

FYI
-- 
Thomas Roessler  <roessler@xxxxxxxxxxxxxxxxxx>
At-Large Advisory Committee: http://alac.info/




----- Forwarded message from Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx> 
-----

From: Bruce Tonkin <Bruce.Tonkin@xxxxxxxxxxxxxxxxxx>
To: council@xxxxxxxxxxxxxx
Cc: roseman@xxxxxxxxx
Date: Thu, 22 Jan 2004 12:27:07 +1100
Subject: [council] Status of registrar constituency statement on the approval 
process for new gtld services
X-Spam-Level: 

Hello All,

I have attached a current draft of the registrars constituency statement
on new gtld services.  The draft has been endorsed by 5 registrars and
has been submitted for voting by the whole constituency.

A copy of the draft is attached in Microsoft word format, and a plain
text version is included below.

Regards,
Bruce Tonkin

DRAFT3  21 Jan 04
Registrar Constituency Statement

This registrar constituency statement relates to the GNSO Policy
Development Process on a Procedure for use by ICANN in considering
requests for consent and related contractual amendments to allow changes
in the architecture or operation of a gTLD registry, in accordance with
Section 7(d) (1) of the GNSO Policy Development Process.

(1) A vote on this statement was held on <insert date>, with the
following result <insert results>.

(2) The registrar constituency carried out discussions on the topic via
its public mailing list at:
http://gnso.icann.org/mailing-lists/archives/registrars/ and via the
following meetings or teleconferences:
-       Registrars constituency meeting in Carthage, Tunisia - Tuesday
28 Oct 2003
-       Teleconference - 11 Dec 2003
-       Following the teleconference a draft statement was submitted to
the registrars mailing list on 17 Dec 2003 (see
http://www.gnso.icann.org/mailing-lists/archives/registrars/msg01039.htm
l )
-       A first draft of a constituency statement was submitted to the
registrars mailing list on 9 Jan 2004 (see
http://www.gnso.icann.org/mailing-lists/archives/registrars/msg01122.htm
l )
-       A second draft of a constituency statement was submitted to the
registrars mailing list on 16 Jan 2004 (see
http://www.gnso.icann.org/mailing-lists/archives/registrars/msg01169.htm
l )


(3) Analysis of how the registrars constituency is affected by the issue

Changes in the architecture or operation of a gTLD registry can affect
members of the registrars constituency in the following ways:
-       a change may affect the commercial viability of many registrars
with the result of an overall reduction in the level of competition and
consumer choice
-       a change may affect a registrar's customers (which may be
individuals, organisations, or intermediaries that provide domain name
services), which often results in higher customer support costs,
particularly in regard to sudden unexpected changes in operation
-       a change may require changes in a registrar's business
processes, which typically requires additional software development work
and thus additional expense.  Additional software development work that
does not either reduce a registrar's costs, or increase a registrar's
revenue will ultimately result in higher prices for its customers.

As a separate issue, the registrars' constituency recommends that ICANN
review its funding model, and consider how to levy its fees more broadly
across different registry services rather than the present model which
is based on the number of domains under management.


Addressing the terms of reference for the policy development process,
the registrars' constituency notes the purpose of the policy development
is to create a policy concerning the essential characteristics of the
process by which ICANN considers registry operator or sponsor requests
for consent or related contractual amendments to allow changes in the
architecture or operation of a gtld registry.

The registrar constituency addresses each of the tasks of the PDP below.


(1)     Develop guidelines for when approval is required to make a
change based on the existing registry agreements.

It would assist the industry to have a simple set of guidelines for when
it is necessary for a registry operator (particularly unsponsored) to
seek approval from ICANN.  The following is a simplified list of areas
where approval is required based on the unsponsored registry agreement.

(a)     Changes to reports provided to ICANN
(b)     Changes to schedule, content, format and procedures for data
escrow
(c)     Changes to the specification for the publication of data or
changes to query based access or bulk access concerning domain name and
name server registrations (ie WHOIS service)
(d)     Changes to the Registry-Registrar agreement
(e)     Material changes and additions in the functional specifications
for "Registry Services"
(f)     Changes in the performance specifications for "Registry
Services"
(g)     Changes to the zone file access agreement
(h)     Changes in the maximum price for "Registry Services"
(i)     Changes in the Registry Operator's Code of Conduct
(j)     Changes in the registration of domain names for a registry
operator's own use

With regard to unsponsored gtlds, the registrars constituency notes that
although portions of the policy-development authority for each sTLD are
delegated to the designated sTLD sponsor, there are some situations in
which an sTLD's sponsor will request amendments to, or approvals under,
the sponsorship agreement it has with ICANN. Although approval and
amendment requests are much more common in the case of unsponsored TLDs
than for sTLDs, the overall goals (e.g., predictability, timeliness,
transparency) of the procedures for handling gTLD and sTLD requests are
similar, even though there are differences in the provisions of the
underlying agreements that must be observed.

The areas of particular concern for registrars relate to changes in the
Registry-Registrar agreement and changes in the performance,
specification and prices of "Registry Services".  The registrars
constituency recommends that ICANN adopt a consistent definition of
registry services to guide the industry in determining when ICANN
approval is required.  The registrars constituency favours the
definition used in the .biz agreement ie 

"Registry Services" means services provided as an integral part of the
operation of the Registry TLD, including all subdomains in which
Registered Names are registered. 

In determining whether a service is integral to the operation of the
Registry TLD, consideration will be given to the extent to which the
Registry Operator has been materially advantaged in providing the
service by its designation as such under this Agreement.   (this
consideration should be added to any registry agreements that do not
currently have it.)

The development of technology, expertise, systems, efficient operations,
reputation (including identification as Registry Operator), financial
strength, or relationships with registrars and third parties shall not
be deemed an advantage arising from the designation. 

Registry Services include: 
-       receipt of data concerning registration of domain names and
nameservers from registrars, 
-       provision to registrars of status information relating to the
Registry TLD, 
-       dissemination of TLD zone files, 
-       operation of the Registry TLD zone servers, 
-       dissemination of contact and other information concerning
domain-name and nameserver registrations in the Registry TLD, and 
-       such other services required by ICANN.

Registry Services shall not include the provision of nameservice for a
domain used by a single entity under a Registered Name registered
through an ICANN-Accredited Registrar.


(2)     Develop a check list of issues to consider when approving a
change


ICANN should refer to its mission and its core values taken from the
ICANN bylaws in formulating the check list of issues to consider when
approving a change.

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

Three of the core values of particular relevance are:

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

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

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

The challenge for ICANN is allowing registry operators to innovate and
evolve their services while ensuring that the operational stability,
reliability, security, interoperability of the Internet is preserved,
and ensuring that there is a healthy competitive market in the provision
of domain name registration services by registrars.

When approving a change ICANN must determine whether:

(a)     The change requires ICANN approval.   Where there is a change
related to the functional, performance or prices of a service, ICANN
will need to first determine if the service fits under the definition of
"Registry Service".   

(b)     Whether to use a fast track or a more time-consuming approval
process.  In general changes that do not relate to the
registry-registrar agreement or Registry Services could be subject to
the fast track process. 


(c)     The change is likely to affect operational stability,
reliability, security and global inter-operability of the Internet.  The
fact that an effect is likely should not be a bar to the new service;
rather these factors and a registry's ability to minimize risks must be
weighed in considering whether, and under what conditions, to approve a
service. This should be fairly straight forward for most of the proposed
changes, however a proposed change in the functional and performance
specifications of a "Registry Service" should include impartial external
advice from one or more technical experts.   Where there is a
possibility of an issue associated with operational stability,
reliability, security and global inter-operability of the Internet,
ICANN staff should use a more comprehensive approval process.    The
terms "operational stability", "reliability", "security" and "global
interoperability" should be more clearly defined in the context of
domain name registries, with examples of changes that could cause
problems.  The ICANN Security and Stability Advisory Committee could
assist in providing clarification of these terms.   The following is
some suggestions for clarifying these terms:

a.      Operational stability  - The three main components of registry
operation relate to the provisioning system whereby registrars provide
instructions to the registry via the registry-registrar protocol to
register and maintain domain name records,  the DNS nameservice provided
to Internet users via the DNS protocol, and the domain name holder
information provided to Itnernt users via an interactive web page and
the port 43 Whois protocol.   Sudden changes to the behaviour of any of
these systems can impact the stability of applications that make use of
these systems.  For example a change to the registry-registrar protocol
could result in accidental deletion of domain name records, or incorrect
configuration of nameserver information associated with a domain name
record.  A change in the behaviour of the DNS nameservice such as the
introduction of wildcard behaviour, may result in failure of some
applications that rely on that behaviour.     The general approaches to
maintaining operational stability are :
i.      ensure that changes are backward compatible, 
ii.     ensure that the old and new environments are supported in
parallel for a suitable period
iii.    and ensure that sufficient notice period is provided.   
The length of time for operating parallel environments or providing a
notice period should be proportional to the significance of the change.
A registry operator should also provide a test environment prior to
putting a change into production to ensure that users can check that
there software will continue to operate.  This should apply to the
provisioning environment, the DNS nameserver environment, and the WHOIS
service.

b.      Reliability - reliability typically relates to the availability
of the registry operator systems, but it also related to the reliability
of the applications that use the service.  For example a change in the
behaviour of the DNS nameservice may reduce the reliability of other
important applications such as email that use the Internet.

c.      Security - again security relates both to the security of the
information maintained by the registry operator, as well as the security
of applications that use the registry systems.  For example, digital
certificates may be used based on the information available in the WHOIS
service.  If this information is either no longer available, or is
incorrect, then it can affect the security of applications that use the
digital certificate.

d.      Global Interoperability - where possible Internet user
application should be able to work with any of the gtld registry
systems.  For example, all the gtld registries should aim to use the
same core registry-registrar protocols, WHOIS and DNS protocols.   A
recent innovation that requires coordination is the introduction of
internationalised domain names.  The IETF has recently converged on a
standard for encoding characters used in different languages into ASCII
text (Punycode).   Before giving permission to change a core protocol or
data format, ICANN should seek to facilitate cooperation amongst
registries and registrars to agree on a common protocol or data format.

(d)      The change is likely to reduce the competition in the
registration of domain names.  This is often a controversial issue
because often changes will affect the business models of one or more
registrars, or their intermediaries.    For example, a change in the way
a registry operator allocates domain names that have been deleted will
directly affect those registrars that rely on registrations of
previously registered names as their main source of revenue.   Where
ICANN staff believe that a registrar business model could be affected by
a change in the registry systems, ICANN should seek impartial advice
from a competition expert with a strong understanding of the domain name
industry structure.  Where there is a possibility of an issue associated
with the overall competition (as distinct from an individual competitor)
in the domain name industry, ICANN staff should use a more comprehensive
approval process.     The issue should be considered from the point of
view of the "long term" interests of end users.  In general the long
term interests are best serviced by a healthy competitive industry
amongst domain name registrars because every registry is a natural
monopoly in a particular TLD.  A registry has a substantial degree of
market power for registrants within that tld, as the switching costs for
a registrant are often high to move to another tld.  Therefore, vigorous
competition among registrars is the only way that the market can be
certain of providing the best prices and services.  Registrars need to
be able to differentiate their product offerings and add value,
otherwise the value of a domain name will mostly reside with the
registry operator and there will be little incentive to operate as a
registrar.    This will result in a return to a single provider for a
particular domain name space.   Where a new "Registry Service" is
proposed, ICANN should consider whether the same service can be
effectively provided by registrars or their intermediaries.  For
example, if a registry operator chose to limit the nameservers available
to be associated with a domain name to only nameservers operated by the
registry operator this would constrain competition.  Another example
could be the provision of an email service that was only available from
the registry operator (e.g name@gtldname).   Where possible registrars
should have access to unbundled service offerings.

If registrars cannot provide the service effectively, ICANN staff should
not deny the registry operator the right to launch the service, although
they may place certain conditions on the service in order to safeguard
competitive offerings by the registrar sector.  

If registrars can effectively provide the service, ICANN staff should
not allow the registry operator to provide the service as a bundled
product, at a price point that takes advantage of the registry
operator's monopoly position, or in a manner that claims a better offer
by the registry operator by virtue of being the registry operator.

(3)     Develop a process and timeline for responding to a request
including "quick-check" phase, and more comprehensive phase.



The essential characteristics of a process to consider registry operator
or sponsor requests for consent or related contractual amendments to
allow changes in the architecture or operation of a gTLD registry are
the following:

(a)     Confirm that the change needs ICANN approval.  This should
include legal and/or technical advice in the case of determining with a
service is a "Registry Service"

(b)     Determine whether the change is likely to likely to affect
operational stability, reliability, security and global
inter-operability of the Internet, or competition in the registration of
domain names.    This should include impartial technical expert advice
or competition expert advice.  If there is no possibility of any issue,
then proceed to approve within 14 days.  If there is clearly a problem
than deny approval within 14 days.  This is the fast track process.

(c)     If there is uncertainty about the impact of the change on
operational stability, reliability, security and global
inter-operability of the Internet, or competition in the registration of
domains names, notify the applicant within 14 days that a more extensive
public process will be used and allow the option for the applicant to
withdraw the request. 

(d)     The more comprehensive process should consist of a 30 day
consultation period consisting of 
a.      collecting public comments facilitated by the ICANN Manager of
Public Participation
b.      facilitating briefings for major affected stakeholders (e.g
registrars when a change is proposed to provisioning system, or ISPs if
a change is proposed to the DNS nameservice)
c.      collecting constituency statements from each GNSO constituency
d.      collecting statements from the ALAC, GAC, SECSAC as appropriate

(e)     At the end of the 30 day consultation period, ICANN staff would
have 14 days to prepare a report and provide a decision to the
applicant.   In cases where the change is rejected, the ICANN report
should provide guidance on what alterations to the proposal could be
made to allow ICANN to approve the change.  For example ICANN staff may
recommend safeguards to preserve competition in the registration of
domain names, or safeguards such as longer notice periods to preserve
the operational stability of the Internet.

(4)     Develop a process and timeline for an appeals procedure for use
by registry operators

Access to the appeals procedure should be available to all members of
the ICANN community rather than just registry operators.    There is an
existing procedure for reconsideration under section 2 of Article IV of
the ICANN bylaws which is open to any person or entity that is
materially affected by an action by ICANN.     The timeline for the
procedure in the ICANN bylaws is:
(a)     A request for reconsideration must be submitted within 30 days
of the decisions
(b)     The reconsideration committee has 30 days to announce whether it
will proceed to consider the request
(c)     The reconsideration committee has a total of 90 days to make a
final recommendation.







----- End forwarded message -----