Re: [registrars] RE: Principles

["dmcgehee" <dmcgehee@bulkregister.com>]

BulkRegister supports the principles that have been presented as a working
solution to the transfer issue.   The principles offer an improvement for
both Registrars and Registrants over the current transfers process.

The Transfers Task Force has developed many valid points, and we feel that
between the two efforts we will be able to arrive at a compromise which will
be acceptable to all Registrars and most importantly user friendly for the
end user.

Donna McGehee
BulkRegister.

>
>
> -----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
>