RE: [gnso-irtp-pdp-jun08] For review - Draft Request for Issues Report for IRTP Part B (deadline Wednesday 7 April at 20.00 UTC)
- To: "Diaz, Paul" <pdiaz@xxxxxxxxxxxxxxxxxxxx>, "Gnso-irtp-pdp-jun08@xxxxxxxxx" <gnso-irtp-pdp-jun08@xxxxxxxxx>
- Subject: RE: [gnso-irtp-pdp-jun08] For review - Draft Request for Issues Report for IRTP Part B (deadline Wednesday 7 April at 20.00 UTC)
- From: "Mike O'Connor" <mike@xxxxxxxxxx>
- Date: Tue, 07 Apr 2009 17:03:33 -0500
i share Paul's view. i was a strong advocate of the position that we
have a lot of overhead (time out for comments, tweaking final
nuances, etc.) in our process and thought at the time that we could
perhaps handle more questions at the same time.
but i, like many of the work-team members, am now subscribed to 2
other working teams and agree that we're probably taking on too much
in the next round. i like Paul's idea of adding questions #5 and #9.
one nuance. i *wouldn't* renumber the questions. i know it looks
weird in reports, but it's a lot easier to keep track of the
questions across multiple PDPs if the questions have the same
identifiers. not a big deal, but we've had a fair amount of
confusion in some earlier PDPs when we did that.
At 04:32 PM 4/7/2009, Diaz, Paul wrote:
We really need your input on this proposed request for an Issues
Report for the next IRTP PDP. Is everyone comfortable with taking
on all of these issues at once?
In my opinion, I think combining all of these issues will be a lot
work and take a long time. I recommend the next PDP just include
issues # 2, 7 and 9 (the original proposals for PDP B, renumbered in
Marika's PDF as 1, 2 & 3) plus the additional lock status questions
(original PDP C proposal #5 and the added question listed as #9 in the PDF).
We need to hear your thoughts ASAP. Without some input, we can't
claim any group consensus and make a proposal to the Council.
[mailto:owner-gnso-irtp-pdp-jun08@xxxxxxxxx] On Behalf Of Marika Konings
Sent: Monday, April 06, 2009 8:51 AM
Subject: [gnso-irtp-pdp-jun08] For review - Draft Request for Issues
Report for IRTP Part B (deadline Wednesday 7 April at 20.00 UTC)
As no further feedback has been received in relation to the email
below, I have prepared a draft request for an issues report for IRTP
Part B (see attached) incorporating all the issues currently
contained in PDP B, PDP C and the three issues that were added to
PDP C from the denial clarifications WG (2 issues) and the
post-expiration domain name recovery issues report (1 issue). In
order for the GNSO Council to consider this at its next meeting on
16 April, the request will need to be submitted by Thursday 9 April
at the latest. Please share your comments and/or suggestions at the
latest by Wednesday 7 April at 20.00 UTC on the mailing list. If no
further comments are received, the request will be submitted on 9
April to the GNSO Council.
With best regards,
On 3/24/09 8:57 PM, "Marika Konings" <marika.konings@xxxxxxxxx> wrote:
Following the discussion today on our call in which those present
proposed to group IRTP PDP B and C together in order to be more
efficient, please find below an overview of the issues listed in the
Inter-Registrar Transfer Policy Issues - PDP Recommendations
document of 19 Mar 2008. It should be noted that as a result of
other policy activities, one other issue has been added and another
is likely to be added to PDP C notably:
* That the work on denial reason #5 in which the current text reads:
No payment for previous registration period (including credit-card
chargebacks) if the domain name is past its expiration date or for
previous or current registration periods if the domain name has not
yet expired. In all such cases, however, the domain name must be put
into "Registrar Hold" status by the Registrar of Record prior to the
denial of transfer. Be suspended until such time as PDP C of the
IRTP Issues PDP is initiated. The results of work done by the Draft
Teams should be included in the initial report to be done by the
Staff for this potential PDP.
* That the work on denial reason #7 in which the current text reads:
A domain name was already in "lock status" provided that the
Registrar provides a readily accessible and reasonable means for the
Registered Name Holder to remove the lock status. Be suspended until
such time as PDP C of the IRTP Issues PDP is initiated. The results
of work done by the Draft Teams should be included in the initial
report to be done by the Staff for this potential PDP.' (from the
motion on the Inter-Registrar Transfer Policy (IRTP) Denial
Definitions Policy Development Process (PDP) adopted in September 2008)
* The issue of logistics of possible registrar transfer during the
RGP shall be incorporated into the charter of the IRTP Part C
charter' (from the motion on the initiation of a PDP on
Post-Expiration Domain Name Recovery which will normally be voted
upon on the GNSO Council meeting coming Thursday). It has been
proposed that the actual consideration of whether to allow the
transfer of a domain name during the RGP should be done within a
Post-Expiration Domain Name Recovery PDP, provided the motion is
adopted by the Council.
In addition, there is the recommendation made by this WG to 'to
include in future IRTP working groups the issue of the
appropriateness of a policy change that would prevent a registrant
from reversing a transfer after it has been completed and authorized
by the admin contact' which has not received a specific designation yet.
I consulted with the GNSO Chair and Vice-Chair and they confirmed
that the request for an issues report, which would be the starting
point for the next IRTP PDP would need to be approved by the GNSO
Council as part of the normal PDP procedure. However, a request
would need to be submitted as soon as possible in order to be
considered at the next GNSO Council meeting coming Thursday 26 March.
Please share your comments / suggestions with the list.
PDP B - Undoing IRTP Transfers
2. Whether a process for urgent return/resolution of a domain name
should be developed, as discussed within the SSAC hijacking report
see also http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm).
7. Whether additional provisions on undoing inappropriate transfers
are needed, especially with regard to disputes between a Registrant
and Admin Contact. The policy is clear that the Registrant can
overrule the AC, but how this is implemented is currently at the
discretion of the registrar.
9. Whether special provisions are needed for a change of registrant
near a change of registrar. The policy does not currently deal with
change of registrant, which often figures in hijacking cases. [Note
that this issue was previously worded as follows: "Whether special
provisions are needed for a change of registrant simultaneous to
transfer or within a period after transfer. The policy does not
currently deal with change of registrant, which often figures in
hijacking cases. (CR 10.0)" It is believed by the working group members
that the revised wording is more appropriate because it is highly
unlikely if not impossible for a registrar change and a registrant
change to happen simultaneously
and because the dispute resolution problems associated with a
registrant change after a registrar change can continue for some
time after the registrar change.]
PDP C - IRTP Operational Rule Enhancements
5. 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).
6. Whether provisions on time-limiting FOAs should be implemented to
avoid fraudulent transfers out. For example, if a Gaining Registrar
sends and receives an FOA back from a transfer contact, but the name
is locked, the registrar may hold the FOA pending adjustment to the
domain name status, during which time the registrant or other
registration information may have changed.
15. "Whether requirements should be in place for Registrars of
Record to send an FOA to the Registrant or Admin Contact". [Notes:
The first part of this issue is retained, although rephrased as
noted above; the original wording was "Whether requirements should
be in place for Registrars of Record to send an FOA". The second
part of 15 (reading: "and/or receive the FOA back from Transfer
Contact before acking a transfer") is recommended for deletion
because of past debates when this was deemed to make it easier for
uncooperative Registrars of Record to delay or block a transfer
desired by the registrant..]
18. Whether the process could be streamlined by a requirement that
registries use IANA IDs for registrars rather than proprietary IDs.