ICANN/DNSO
DNSO Mailling lists archives

[registrars]


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

[registrars] New Straw Poll


Listed below is the revised straw poll. I apologize for the delay but I have
tried to run these questions by several people to make them as objective as
possible. I have even included several questions that a registrar employing
an autoNAC policy asked to be included. Thanks for those that responded to
the original straw poll. As I previously stated in last week's
teleconference, the next Names Counsel meeting is June 29th. There will be a
seven day voting window on this ballot.

Mike


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
[ ]No

Q2: The registrars support a xfer policy that protects consumer's best
interest?

[ ]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:

[ ]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
[ ]No

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
[ ] No

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
[ ] 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
[ ] No


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.

[ ] Yes
[ ] No





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