Re: [registrars] RE: Principles

["Ross Wm. Rader" <ross@tucows.com>]

Tucows continues to support a resolution of this issue that is
implementable, customer-friendly and supported by key industry players. We
also lend our support to this set of principles insofar as these
requirements continue to be fulfilled.


                       -rwr




"There's a fine line between fishing and standing on the shore like an
idiot."
- Steven Wright

Got Blog? http://www.byte.org/blog

----- Original Message -----
From: "Beckwith, Bruce" <bbeckwith@verisign.com>
To: <registrars@dnso.org>
Cc: "Gomes, Chuck" <cgomes@verisign.com>
Sent: Wednesday, December 04, 2002 5:52 PM
Subject: RE: [registrars] RE: Principles


>
> The VeriSign Registrar supports the principles that have been presented as
a
> customer and industry friendly approach, which lends itself to be
> commercially viable.
>
> There is no question that the Transfers Task Force has labored intensively
> on their review and Report recommendations, and there are unquestionably
> some very good points that have been put forth by the TTF Report.
>
> The key to an industry acceptance on how to handle transfers will be not
to
> choose one option over the other, but to blend the best features of each.
> Perhaps the Names Council can determine how best to accomplish this.
>
> Regards,
>
> Bruce Beckwith
> VeriSign Registrar
>
> -----Original Message-----
> From: Elana Broitman [mailto:ebroitman@register.com]
> Sent: Tuesday, December 03, 2002 2:19 PM
> To: registrars@dnso.org
> Cc: Gomes, Chuck
> Subject: RE: [registrars] RE: Principles
>
>
> 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
>