ICANN/DNSO
DNSO Mailling lists archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] New Straw Poll


Can't believe I did that...sometimes even one's most emphatic "Yes" turns
into a "No"

Mike - can you please change our vote on the following question to [Yes]
affirming that there are ambiguities with the current policy?

> > Q1: The current xfer policy in exhibit B of the registrar/registry
> contract
> > is currently written from the perspective of what a gaining registrar
must
> > do. The policy is silent on what affirmative actions a losing registrar
> may
> > take aside from requesting verification from the gaining registrar.
> Because
> > the current policy does not prohibit a losing registrar from imposing
> > additional safeguards in the transfer policy, a growing number of losing
> > registrars are imposing safeguards that conflict with the policies and
> > standard operating procedures that a majority of registrars have
employed
> > since the beginning of the test bed period. Given this difference of
> > opinion, can be stated that there are ambiguities in the current xfer
> > policy?
> >
> > [ ]Yes
> > [X]No

Thanks,

-rwr



Tucows Inc.
t. 416.538.5492
----- Original Message -----
From: "Ross Wm. Rader" <ross@tucows.com>
To: "Michael D. Palage" <michael@palage.com>; <registrars@dnso.org>
Sent: Tuesday, June 19, 2001 7:03 AM
Subject: Re: [registrars] New Straw Poll


> > Q1: The current xfer policy in exhibit B of the registrar/registry
> contract
> > is currently written from the perspective of what a gaining registrar
must
> > do. The policy is silent on what affirmative actions a losing registrar
> may
> > take aside from requesting verification from the gaining registrar.
> Because
> > the current policy does not prohibit a losing registrar from imposing
> > additional safeguards in the transfer policy, a growing number of losing
> > registrars are imposing safeguards that conflict with the policies and
> > standard operating procedures that a majority of registrars have
employed
> > since the beginning of the test bed period. Given this difference of
> > opinion, can be stated that there are ambiguities in the current xfer
> > policy?
> >
> > [ ]Yes
> > [X]No
> >
> > Q2: The registrars support a xfer policy that protects consumer's best
> > interest?
> >
> > [X]Yes
> > [ ]No
> >
> > Q3: Registrars believe that the best way to protect a consumer's best
> > interest when: (1) a gaining registrar has obtained authorization from
an
> > entity with legal authority to act on behalf of the registrant; and (2)
a
> > losing registrar sends an email notification to the registrant; and (3)
> the
> > registrant fails to affirmatively respond to the losing registrar's
> inquiry
> > is for the losing registrar to:
> >
> > [X]autoACK the transfer, except in special circumstances (i.e. rouge
> > registrar, special instructions from a registrant, etc.)
> > [ ]autoNAC the transfer
> >
> > Q4: Do the registrars favor a longer transfer period at the registry?
> >
> > [ ]Yes
> > [XNo
> >
> Both statistically and historically speaking, the current five day window
> has proven to be more than sufficient in cases where there is no
> interference from the losing registrar. It is only when the losing
registrar
> interjects superfluous process that the five days becomes too short. The
> primary reason being that when a registrant undertakes a transfer, they
> expect to undertake a verification process with the gaining registrar (as
> the gaining registrar will have educated them about the process by which a
> transfer occurs).
>
> > Q.5. Do the registrars favor a standard multi-lingual template that all
> > losing registrars should send to a registrant when requesting
verification
> > on a transfer request?
> >
> > [ ] Yes
> > [X] No
>
> ...but only if AutoACK is not the default policy.
>
> >
> > Q.6. To date the following recommendations have been put forward on
behalf
> > of certain registrars as methods for minimizing the current xfer
problem:
> > (1) single notification by losing registrar in bulk transaction (greater
> > than 5 domain names); (2) simultaneous email notification sent to
gaining
> > registrar; (3) uniform email template (multi-languages) sent by losing
> > registrar; and (4) a longer time window at the registry to allow for
> > transfers. If all of these recommendations were implemented would this
in
> > your opinion eliminate the majority of the current xfer problems that
have
> > been discussed to date and eliminate the need to change the current
> > agreements?
> >
> > [ ] Yes - these proposals would eliminate the need for contractual
change
> > [X] No - these proposals do not go far enough, contractual change still
> > needed
> >
> > Q.7: Since there are concerns on the part of requesting registrars that
> some
> > losing registrars may not be allowing transfers to occur and concerns on
> the
> > part of losing registrars that registrants are getting slammed or some
> > requesting registrars are not getting the appropriate authorization from
> an
> > authorized representative, should the registrar constituency explore an
> > independent verification model?
> >
> > [ ] Yes
> > [X] No
> >
> >
> ...The current audit functions of Exhibit B do not currently preclude this
> type of action. Registrars that do not have sufficient comfort with the
> majority of policy in place are urged to implement an audit of
verification
> that provides them with the comfort they require as opposed to
implementing
> obstructive policy.
>
> > Q.8 Because of the alleged ambiguities in the current registrar/registry
> > contract and the lack of any governing contract with ICANN on this
> specific
> > issue, a policy change in accordance with Section 4 of the
> > registrar/registry contract is the only option to legally enforce any
new
> > xfer policy an all ICANN accredited registrars. Do the registrars
support
> > putting forth the xfer policy before the names counsel to begin the
policy
> > implementation guidelines as set forth in Section 4.
> >
> > [X] Yes
> > [ ] No
> >
> >
> >
>



<<< Chronological Index >>>    <<< Thread Index >>>