<HTML>
<HEAD>
<TITLE>Re: [council] PEDNR Motion</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Apologies Tim, but I did not mean to imply that staff is encouraging PDPs to include possible RAA changes. I understood the reason as to why the drafting team decided to include examples of other possible outcomes of a PDP, such as a recommendation for RAA changes, to be that the drafting team wanted to emphasize that consensus policy or consensus policy changes are not the the only possible outcomes of a PDP. <BR>
<BR>
In reviewing some of the issues, a WG might decide that changes to a consensus policy are not appropriate but instead a recommendation for a best practice or RAA change might be more suitable. You are absolutely right that anything but consensus policy changes, are recommendations and therefore not enforceable. This is how I interpreted the reference to possible RAA changes. If this WG were to make a recommendation for changes to the RAA, and the GNSO would support this recommendation, it is my understanding that it would be passed on to the appropriate parties, WG and/or ICANN body to consider this recommendation and follow the applicable procedures which might result in changes to the RAA, or not. <BR>
<BR>
Again, apologies for the confusion.<BR>
<BR>
Best regards,<BR>
<BR>
Marika<BR>
<BR>
On 4/2/09 2:42 PM, "Tim Ruiz" <<a href="tim@godaddy.com">tim@godaddy.com</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Marika,<BR>
<BR>
Thanks for the explanation. But why is Staff encouraging PDPs to<BR>
include possible RAA changes? A consensus policy IS an enforceable<BR>
change to the RAA. The only other reason would be to change<BR>
something not within the scope of the RAA picket fence. Such things<BR>
should NOT be part of a PDP.<BR>
<BR>
A PDP should be specifically for *policy* development. If the GNSO<BR>
wants to consider things not within scope of the picket fence it<BR>
should not initiate a PDP. It can very well form a group to consider<BR>
such things if it chooses with the understanding that the outcome<BR>
will not be a mandate but only a suggestion or possibly a recommended<BR>
(but not enforceable) best practice. Mixing these things together is<BR>
NOT a productive way to approach our work.<BR>
<BR>
In fact, we are forming such a group to discuss further changes to<BR>
the RAA. That group will no doubt discuss things not within the RAA's<BR>
picket fence as well as some things that are. For me, if this PDP is<BR>
going to proceed with the understanding that it will include<BR>
dicussion/examination of changes to the RAA, then I see no point in<BR>
purusing any other discussion of the RAA.<BR>
<BR>
That all said, I would like to ask for the following, intended<BR>
friendly ammendment to the PEDNR motion:<BR>
<BR>
Replace the main paragraph of the RESOLVE portion with this:<BR>
<BR>
to initiate a Policy Development Process (PDP) to address the issues<BR>
identified in the Post-Expiration Domain Name Recovery Issues<BR>
Report. The charter for this PDP should instruct the Working Group:<BR>
(i) that it should consider recommendations for best practices as well<BR>
as or instead of recommendations for Consensus Policy; (ii) that to<BR>
inform its work it should pursue the availability of further information<BR>
<BR>
from ICANN compliance staff to understand how current RAA provisions<BR>
and consensus policies regarding deletion, auto-renewal, and recovery<BR>
of domain names during the RGP are enforced; and (iii) that it should<BR>
specifically consider the following questions:<BR>
<BR>
Also, I would suggest that the last bullet/question be deleted since<BR>
the last paragraph really covers it. So to be clear, if my proposed<BR>
amendment is accepted as friendly the RESOLVE portion of the motion<BR>
would read:<BR>
<BR>
GNSO Council RESOLVES:<BR>
<BR>
to initiate a Policy Development Process (PDP) to address the issues<BR>
identified in the Post-Expiration Domain Name Recovery Issues<BR>
Report. The charter for this PDP should instruct the Working Group:<BR>
(i) that it should consider recommendations for best practices as well<BR>
as or instead of recommendations for Consensus Policy; (ii) that to<BR>
inform its work it should pursue the availability of further information<BR>
<BR>
from ICANN compliance staff to understand how current RAA provisions<BR>
and consensus policies regarding deletion, auto-renewal, and recovery<BR>
of domain names during the RGP are enforced; and (iii) that it should<BR>
specifically consider the following questions:<BR>
<BR>
-- Whether adequate opportunity exists for registrants to redeem their<BR>
expired domain names;<BR>
-- Whether expiration-related provisions in typical registration<BR>
agreements are clear and conspicuous enough;<BR>
-- Whether adequate notice exists to alert registrants of upcoming<BR>
expirations;<BR>
-- Whether additional measures need to be implemented to indicate that<BR>
once a domain name enters the Auto-Renew Grace Period, it has expired<BR>
(e.g. hold status, a notice on the site with a link to information on<BR>
how to renew or other options to be determined).<BR>
<BR>
The GNSO Council further resolves that the issue of logistics of<BR>
possible registrar transfer during the RGP shall be incorporated into<BR>
the charter of the IRTP Part C charter.<BR>
<BR>
<BR>
Tim<BR>
<BR>
-------- Original Message --------<BR>
Subject: Re: [council] PEDNR Motion<BR>
From: Marika Konings <<a href="marika.konings@icann.org">marika.konings@icann.org</a>><BR>
Date: Thu, April 02, 2009 4:20 am<BR>
To: Alan Greenberg <<a href="alan.greenberg@mcgill.ca">alan.greenberg@mcgill.ca</a>>, GNSO Council<BR>
<<a href="council@gnso.icann.org">council@gnso.icann.org</a>><BR>
<BR>
Tim, please note that the recommendation you quoted from the Issues<BR>
Report specifically relates to ‘the desired outcomes stated by ALAC in<BR>
its request’, some of which go beyond the issues recommended for a<BR>
PDP. As noted by Alan, the drafting team and staff did discuss whether a<BR>
pre-PDP WG would be appropriate, but agreed that further research and<BR>
consultation could be done as part of a PDP as the issues recommended<BR>
for inclusion in a PDP have been narrowly defined. As stated in the<BR>
motion, the drafting team does believe it is important to highlight in<BR>
the charter that the outcomes of a PDP are not limited to recommended<BR>
changes to consensus policy, but could also include recommendations<BR>
regarding e.g. best practices, compliance, possible RAA changes or<BR>
further dialogue.<BR>
<BR>
On a different note, but related to the Post-Expiration Domain Name<BR>
Recovery Issues Report, I would like to draw your attention to a<BR>
deletion and renewal consensus policy audit in relation to the Expired<BR>
Domain Deletion Consensus Policy that was carried out by the ICANN’s<BR>
compliance team recently (see further details attached). Follow-up audit<BR>
activity is being carried out as a result of the non-compliance<BR>
identified in the audit. As a result of this follow-up, the compliance<BR>
team estimates that the number of non-compliant registrars is about<BR>
30-40% less today then when the report was published.<BR>
<BR>
With best regards,<BR>
<BR>
Marika<BR>
<BR>
On 4/2/09 5:11 AM, "Alan Greenberg"<BR>
<<a href="https://email.secureserver.net/alan.greenberg@mcgill.ca">https://email.secureserver.net/alan.greenberg@mcgill.ca</a>> wrote:<BR>
<BR>
<BR>
<BR>
The drafting team did discuss this. The conclusion was (and staff<BR>
concurred if I remember correctly) that any further consultation<BR>
could reasonably be done as part of the PDP. We also talked about a<BR>
public forum in Sydney, the exact contents of which would depend on<BR>
how far along the WG (presuming we use a WG) had gotten.<BR>
<BR>
I guess the question came down to whether we felt that some policy<BR>
development and non-policy recommendations were required regardless,<BR>
and whether the outcomes of pre-PDP consultation would change the<BR>
details of the recommendations to be put in a PDP charter. The answer<BR>
to the first question was yes, we did feel that PDP action was<BR>
required, and we did not think that the specific recommendations<BR>
would change. How a WG addresses the issues may well change, but<BR>
since it did not appear that the results of such consultation would<BR>
alter the PDP charter, there did not seem to be any reason to delay.<BR>
<BR>
Although not discussed, I would envision a call for input on some<BR>
targeted questins as an early part of the process.<BR>
<BR>
Alan<BR>
<BR>
At 01/04/2009 06:09 PM, you wrote:<BR>
<BR>
>I was re-reading the issues report and was reminded of this Staff<BR>
>recommendation:<BR>
><BR>
>"In relation to the desired outcomes stated by ALAC in its request,<BR>
>ICANN staff notes that<BR>
>while most, if not all, outcomes might be achieved by the<BR>
>recommendations identified by the<BR>
>ALAC, it would be helpful for all parties concerned to engage in a more<BR>
>fulsome dialogue on<BR>
>the extent and detailed nature of the concerns to determine whether<BR>
>these are shared<BR>
>desired outcomes and if so, how these could best be addressed in policy<BR>
>work going<BR>
>forward, including a more robust discussion of the merits and drawbacks<BR>
>of various solutions<BR>
>to address agreed concerns. The GNSO Council might consider such an<BR>
>activity, which<BR>
>could take the form of one or more public workshops at an upcoming ICANN<BR>
>meeting, for<BR>
>example, as a precursor for the launch of a PDP as it would help to<BR>
>define and focus the<BR>
>policy development process on one or more specific proposed changes.<BR>
>While this could<BR>
>also be explored by a working group following the launch of a PDP, staff<BR>
>recommends<BR>
>further fact finding first to figure out what policy options might<BR>
>exist, and then conduct a PDP<BR>
>to assess the impact of those policy options and confirm community<BR>
>support for a preferred<BR>
>policy choice."<BR>
><BR>
>I don't recall that we discussed whether we should follow this advice or<BR>
>not. Alan, is there<BR>
>a reason why your motion initiates a PDP instead of the fact finding<BR>
>that the Staff suggests<BR>
>be done first?<BR>
><BR>
><BR>
>Tim<BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>