RE: [registrars] RE: Principles

[Elana Broitman <ebroitman@register.com>]

Register.com also supports the transfer principles below.  These principles
stem from Chuck's work with registrars, including in Amsterdam and Shanghai,
and Elliot's proposal made in Shanghai.  The principles offer an improvement
on the current transfers process.  Most significantly, they make the
transfer process more transparent, and therefore, easier to use, for
registrants.  The principles also clarify the roles and responsibilities of
registrars, so that registrars can help their customers through the process.

As Bruce notes below, the principles are aligned with some of the sections
of the Transfers Task Force Report and Recommendations.  But, there are also
some fundamental differences.  The principles, we believe, offer an
improvement upon the Task Force Report.  The principles are a solution that
can be adopted by more, various registrars, and therefore offer a practical
solution for registrars to adopt in the nearer term.  

Therefore, Register.com wants to voice its support for the principles and
encourage the Names Council to consider the Task Force Report together with
the Principles and endorse to the Board a report or process that
incorporates the principles.  

Elana Broitman

-----Original Message-----
From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au]
Sent: Monday, December 02, 2002 8:02 PM
To: registrars@dnso.org
Cc: Gomes, Chuck
Subject: [registrars] RE: Principles


Hello All,

In response to Chuck's principles - Melbourne IT supports these principles
as we believe they can be used to drive a solution that:
(a) Can be efficiently implemented
(b) Provides certainty and predictable behaviour for registrars and
registrants
(c) Cannot be easily gamed by either gaining or losing registrar, or
unauthorised third parties working against the wishes of the registrant.

The present process fails checks (b) and (c) above.

Note Melbourne IT also supports the transfers task force report for the same
reasons.
We are keen to take the next steps to move from principles to an
implementation (which may include changes to existing agreements or a fresh
legal agreement) that we can all agree on.

We encourage all registrars to support the transfers task force work as an
important step forward.  However more steps must follow to reach
implementation, and Melbourne IT appreciates the efforts of Chuck Gomes to
continue to work with registrars to define a solution to the problem.

Note there are many areas of common agreement in the principles below and
the transfers task force report.

Specific comments on the principles are included below.

Regards,
Bruce Tonkin


> 
> 1.                  Registrars should provide a unique and 
> private email
> address for use only by other registrars and the registry.

Agreed.  This is a useful feature regardless of implementation - as it is
useful to first work between registrars to resolve any implementation issues
or special cases without having to resort to external dispute resolution.


> 2.                  Admin contact is the default authority.

Agreed.

> 3.                  Registrant may overrule admin contact authority.

Agreed.

> 4.                  All transfer process communications to 
> registrants from
> losing and gaining registrars should be standardized.

Strongly agree.  Again this should apply regardless of whether the
implementation is based on EPP or RRP.  This helps provide certainty and
predictability for registrants.

> 5.                  Registrars should provide special, 
> standardized Whois
> access, which may be separate from public Whois access, to 
> other registrars
> and the registry solely for the purpose of transacting transfers.

Agreed.  I see this is a way to handle some of the privacy issues.  A
registrar may choose to limit some information for public access for privacy
reasons, but gaining registrars must be able to access the information for
authentication purposes.  I think in the longer term, public WHOIS access
will be more restricted, and thus this provision will be required.
Presently Melbourne IT does not put any limits on public WHOIS access for
gtld information.

In Australia, the public WHOIS access is heavily restricted.
A gaining registrar may use the EPP info command using the auth-info code to
retrieve the full registry record.  If a gaining registrar uses the EPP info
command on a domain without the auth-info code - they only get the publicly
restricted information.   (Note: the current registrar of record may use the
EPP info command without the auth-info code to retrieve the full record.)
 
> 6.                  If the gaining registrar is responsible 
> for transfer
> authentication and the losing registrar's special Whois is 
> not accessible
> for a to-be-specified time; this can be grounds to allow the 
> transfer to
> occur in case of a dispute.

Agreed.  I am assuming the idea is that the transfer would only go ahead
after dispute resolution.  The gaining registrar would still need to prove
to the satisfaction of the dispute resolution provider that they had valid
authority.  The default action being that the transfer is denied.

> 7.                  Minimum, standardized documentation 
> should be required
> of registrars for all transfer procedure steps for use in dispute
> resolution.

Agreed.


> 8.                  English is the mandatory default language for all
> registrar, registry and registrant transfer communications.  
> Additionally,
> registrars may communicate with registrants in other 
> languages provided that
> the principle of standardization in principle 5 above is satisfied.

Agreed.  The method of handling multiple languages should be taken into
account in the development of the standardised communication.  e.g the first
line of the standardised email may include simple instructions in multiple
languages (e.g "Click here if you speak German")with a link to more detailed
instructions in those languages.  Often the front page of websites have a
graphic picture of the flag of a country representing different languages
(e.g English, French, Spanish, German, Chinese, Japanese etc).

> 9.                  Only registrars may initiate disputes.  
> If registrants
> want to initiate a dispute, it must be done through a registrar.

Agreed.  This allows the registrar to first attempt to resolve the problem
directly with 
the registrant or the other registrar before escalating to dispute
resolution.

> 10.              The registry is responsible for first level dispute
> resolution.

Agreed.  I assume this will be on the basis that any costs for this first
level dispute resolution would be cheaper than other commercial dispute
resolution providers.  This will become clearer once Verisign announces
potential costs for dispute resolution.  I guess Verisign could outsource
the dispute resolution to another provider via open competitive tender if
necessary.  From a Melbourne IT perspective we are hoping that the savings
in manual administration time dealing with the existing process will far
outweigh any costs we may incur from dispute resolution (ie we are expecting
a net saving in costs from the new transfers implementation).



> 11.              There will be a non-judicial second-level dispute
> resolution process for appeals.

Agreed.  Again I assume this will be cheaper than going to a court of law.

> 12.              Losing and gaining registrars should be required to
> complete specific transfer process steps within to-be-determined and
> specifically defined time periods.

Agreed.

> 13.              Only losing or gaining registrar should 
> authenticate the
> transfer request, not both.

Agreed.  Our preference is for the gaining registrar to do authentication as
for the current transfers process and the transfers task force report, but
we can agree to this if it means solving the larger problem.  I expect the
new process will result in the default case being losing registrar does
authentication.  In which case Melbourne IT will change its procedures to
match the industry norm.  It seems that several large registrars have
already made this change anyway in contravention of the spirit of the
existing agreements - I admit that the current legal agreements allow this
by exploiting loopholes.

> 14.              If some form of auth code is used, the same 
> auth code must
> be used for the same domain name and the same gaining registrar.

Agreed.  Ideally the same auth-code would be used regardless of registrar.

> 15.              If a new transfer process is adopted, the new process
> replaces the old process (i.e., a registrar can't use the new 
> process and
> the old process as a follow up to restrict a transfer).

Agreed.


> 16.              Reasons for a losing registrar to deny a transfer:
> ·        Evidence of fraud
> ·        UDRP action
> ·        Court order
> ·        Non-payment for previous registration period if transfer is
> requested after the expiration date or non-payment for the current
> registration period if transfer is requested before the 
> expiration date.

Agreed.

Regards,
Bruce