ICANN ICANN Email List Archives

[gnso-trans-pdp]


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

RE: [gnso-trans-pdp] Suggestions for Reasons 5 and 7

  • To: "Tim Ruiz" <tim@xxxxxxxxxxx>, <gnso-trans-pdp@xxxxxxxxx>
  • Subject: RE: [gnso-trans-pdp] Suggestions for Reasons 5 and 7
  • From: "Steele, Barbara" <BSteele@xxxxxxxxxxxx>
  • Date: Mon, 2 Jun 2008 09:26:32 -0400

I agree that there are a fair number of inquiries, complaints and
disputes that arise as a result of the losing registrar denying
transfers for this reason.  In this particular case it would be up to
the the gaining registrar to file the dispute on the grounds that the
losing registrar inappropriately denied the transfer, specifically
citing the provision from the IRTP that has been violated (which I am
hopeful that they would be willing to do since they stand to gain a
customer with at least one, but possibly many, domain names).  

I feel that PDP D, IRTP Dispute Policy Enhancements, is best left to
address the items relating only to the TDRP, including the need for
registrant education relating to transfer dispute options (issue #19)
and whether or not registrants should be able to raise a dispute
themselves (issue #16). 


-------------------------------------------------------
Barbara Steele
Compliance Officer
VeriSign Information Services
bsteele@xxxxxxxxxxxx
Direct: 703.948.3343
Mobile: 703.622.1071
Fax:  703.421.4873

 
21345 Ridgetop Circle
Dulles, VA  20166


Notice to Recipient:  This e-mail contains confidential, proprietary
and/or Registry Sensitive information intended solely for the recipient
and, thus may not be retransmitted, reproduced or disclosed without the
prior written consent of VeriSign Naming and Directory Services.  If you
have received this e-mail message in error, please notify the sender
immediately by telephone or reply e-mail and destroy the original
message without making a copy.  Thank you.


-----Original Message-----
From: owner-gnso-trans-pdp@xxxxxxxxx
[mailto:owner-gnso-trans-pdp@xxxxxxxxx] On Behalf Of Tim Ruiz
Sent: Friday, May 30, 2008 11:14 AM
To: gnso-trans-pdp@xxxxxxxxx
Subject: RE: [gnso-trans-pdp] Suggestions for Reasons 5 and 7


Barbara,

The association with PDP D 16 and 19 is due to the fact that disputes
over payment between the registrant and the registrar are a common
problem and the reason a lot of transfers don't succeed. Of course, a
lot of that has to do with the way the policy is interpreted by
registrars (and is why reason #5 is under review). These payment
disputes that are a big reason why the issue of registrants initiating
the Transfer Dispute Resolution Process (TDRP) has been raised.

When there is a dispute over payment the current registrar is not likely
to offer to initiate a TDRP and may not even inform the registrant that
the TDRP exists. So the registrant must rely on the gaining or intended
registrar who has no window into this particular kind of problem. As a
result, the gaining registrar may hesitate to start a TDRP and often
tells the registrant they have to resolve the problem with their current
registrar first

At any rate, I'm fine with recommending PDP C.
 
 
Tim 

-------- Original Message --------
Subject: RE: [gnso-trans-pdp] Suggestions for Reasons 5 and 7
From: "Steele, Barbara" <BSteele@xxxxxxxxxxxx>
Date: Fri, May 30, 2008 7:26 am
To: "Tim Ruiz" <tim@xxxxxxxxxxx>, <gnso-trans-pdp@xxxxxxxxx>


Tim,
Thanks for pulling this together. I had tried to send a brief note to
the group yesterday to make some recommendations but I am apparently
having operator errors - I don't believe that the last two e-mails that
I have sent have made it to the group. In any event, I agree completely
with your suggested updates and recommendations for denial reason #7 as
it does track very closely with Issue #5 in the PDP C - IRTP Operational
Rule Enhancements. 

With regard to denial reason #5, the additional background and
information that you have drafted under the concerns section are very
good. I also agree with the information that you have included under the
recommendations with the exception of which PDP to fold it into.
Since PDP D includes issues that are all related specifically to the
Transfer Dispute Resolution Policy, I don't believe that PDP D is a good
fit for this denial reason. Instead, I would suggest that we recommend
that it also be included in PDP C since how transfer requests are
handled when there are issues relating to payment for prior registration
periods could be deemed operational. I don't see the connection to issue
16 (Whether dispute options for registrants should be developed and
implemented as part of the policy (registrants currently depend on
registrars to initiate a dispute on their behalf) or issue 19 (Whether
requirements or best practices should be put into place for registrars
to make information on transfer dispute resolution options available to
registrants) which are included in PDP D.


-------------------------------------------------------
Barbara Steele
Compliance Officer
VeriSign Information Services
bsteele@xxxxxxxxxxxx
Direct: 703.948.3343
Mobile: 703.622.1071
Fax: 703.421.4873


21345 Ridgetop Circle
Dulles, VA 20166


Notice to Recipient: This e-mail contains confidential, proprietary
and/or Registry Sensitive information intended solely for the recipient
and, thus may not be retransmitted, reproduced or disclosed without the
prior written consent of VeriSign Naming and Directory Services. If you
have received this e-mail message in error, please notify the sender
immediately by telephone or reply e-mail and destroy the original
message without making a copy. Thank you.


-----Original Message-----
From: owner-gnso-trans-pdp@xxxxxxxxx
[mailto:owner-gnso-trans-pdp@xxxxxxxxx] On Behalf Of Tim Ruiz
Sent: Thursday, May 29, 2008 5:48 PM
To: gnso-trans-pdp@xxxxxxxxx
Subject: [gnso-trans-pdp] Suggestions for Reasons 5 and 7

In text below and in the Word doc attached. It includes suggested
revisions to the Concerns and Recommendations sections for #5, and to
the Recommendations section for #7.

Denial Reason #5

Concerns

In addition to the text of denial reason #5, the IRTP policy also states
a transfer may not be denied for nonpayment for a pending or future
registration period, and then further states that denying transfers
should not be used as a way to resolve disputes over payment with two
exceptions: (i) In the case of non-payment for previous registration
period(s) if the transfer is requested after the expiration date, or
(ii) In the case of non-payment of the current registration period, if
transfer is requested before the expiration date. 

Any attempt to clarify or modify reason #5 would necessarily require a
review of the meaning and intent of these other provisions in the policy
as they could be seen to be contradictory in some aspects, and have been
interpreted in various ways. This was also pointed out in the final
report of 9 April 2008 in sections 4.2.2, 4.2.3, and 4.2.4.

Other concerns are:

* The proposed texts, or clarifications, raise deeper issues and more
complexity than we are prepared to deal with within the scope and
timeframe allotted to this drafting group.
* "Registration period" is not clearly linked to the Registration
Agreement at present -- a change in this relationship is a policy issue,
not a clarification of existing policy.
* There is no reference to the Auto Renew Grace Period within the IRTP
policy. However, the recent ICANN Staff advisory states that there is a
clear association between the Auto Renew Grace Period and the intent of
denial reason #5.
* Many of the conversations and interpretations of this part of the IRTP
have taken place over a long period of time -- community input issues.

Recommendation

There appears to be general agreement on what this denial reason was
trying to accomplish, but we should allow an appropriate amount of time
for formulating revisions that will effectively resolve the ambiguity.
More time is needed to fully understand the existing and various IRTP
provisions on this subject, the recent ICANN Staff advisory, and the
comments in the constituency statements in order to adequately address
the questions raised in the final report.

It is recommended that the Council either:

1. Include clarification of denial reason #5 in PDP D (IRTP Dispute
Policy Enhancements) of the final report of 19 March 2008. At the core
of this reason for denial is dispute over payment between the registrant
and the registrar and could impact the resolution of issues 16 and 19 of
PDP D; or

2. Immediately extend the charter and scope of this Drafting Team to
become a Working Group and seek additional participation of interested
stakeholders to address this issue more thoroughly, and prior to the
initiation of PDP D.

Denial Reason #7

Recommendation

Issue 5 under PDP C of the IRTP Issues PDP Recommendations of 19 March
2008 and the reason for wanting to clarify reason for denial number 7
are very closely related.

Issue 5 of PDP C on IRTP Operational Rule Enhancements states: "Whether
standards or best practices should be implemented regarding use of
Registrar Lock status (e.g., when it may/may not, should/should not be
applied). (CR 8.0)"

The IRTP Policy Clarification of Reasons for Denial final report of 9
April 2008 says in the first sentence of the second paragraph on page 5:
"Regarding "lock status", there is support for clarification, with a
clear focus on the meaning of "readily accessible and reasonable means"
for removing the lock."

The result of the pending PDP that will include Issue 5 of PDP C could
have an impact on "readily accessible and reasonable means" for removing
a registrar lock. Given the close relationship of these two issues it is
recommended that they be combined as a single issue. It could then be
left as Issue 5 of PDP C, or it could be moved to its own PDP. If the
latter, the Council could also decide to immediately extend the charter
and scope of this Drafting Team to become a Working Group and seek
additional participation of interested stakeholders. The Council may
first need to decide if a new issues report would be necessary to
include Issue 5 of PDP C.


Tim 







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