[council] PEDNR Motion

[Gomes, Chuck]

Wouldn't we be better off avoiding confusing the PEDNR motion with RAA issues and instead focus on the motion without reference to the RAA?

Chuck 

> -----Original Message-----
> From: owner-council at gnso.icann.org 
> [mailto:owner-council at gnso.icann.org] On Behalf Of Tim Ruiz
> Sent: Thursday, April 02, 2009 12:03 PM
> To: GNSO Council
> Subject: RE: [council] PEDNR Motion
> 
> 
> Alan,
> 
> That makes no sense whatsoever. What RAA changes could they 
> recommend that would be out of scope that would solve an in 
> scope issue they are considering? And why would they do that 
> if the issue is in scope? Why not just put it in terms of a 
> consensus policy? And how could a change to the RAA be less 
> invasive than a consensus policy, for all practical purposes 
> they have the same effect? 
> 
> What this runs the risk of is the TF or WG skewing off. Any 
> situation where an out of scope change to the RAA would 
> resolve an in scope issue would be so extremely rare (and I 
> assert impossible) that it is not worth running this risk.
> 
> Tim 
>   
>   -------- Original Message --------
> Subject: RE: [council] PEDNR Motion
> From: Alan Greenberg <alan.greenberg at mcgill.ca>
> Date: Thu, April 02, 2009 10:41 am
> To: "GNSO Council" <council at gnso.icann.org>
> 
> 
> Tim, two issues:
> 
> First, just because we say that the group can make 
> RECOMMENDATION on ways the PEDNR issues could best e 
> addressed through a future RAA (non-picket fence) change does 
> NOT give them the latitude to address non-PEDNR issues. 
> Although it is certainly jumping the gun to consider PDP 
> outcomes, one could imagine that a possible outcome is a 
> recommendation that a PEDNR issue would best be addressed by 
> some specific contractual term of the RAA. Not within the 
> picket fence, not binding, but a bit of advice that could 
> then not be lost, but used as per the (hopefully existent) 
> process of RAA amendment.
> 
> I am not really expecting such "RAA-suggestion" 
> outcomes. But if it becomes obvious to the WG that this is 
> the least invasive away of addressing a problem, they should 
> be allowed to suggest it without them being accused of 
> broadening their scope. That is all it was meant to do.
> 
> I understand that there are some people who want to use a 
> "thin edge of the wedge" to address every RAA issue under the 
> sun, but I think that Staff have crafted a pretty narrow 
> definition here.
> 
> Alan
> 
> At 02/04/2009 11:24 AM, Tim Ruiz wrote:
> 
> >It's unfortunate that Staff supported such a concept, and I 
> personally 
> >believe it is seriously flawed. If we don't form WGs with specific 
> >focus we run the risk of them running on and on - getting 
> sidetracked 
> >in multiple directions.
> >
> >Clearly, a PDP WG could come back and say: "We do not recommend any 
> >policy at this time, but suggest that the following be 
> considered as a 
> >best practice..." That's much different than the WG spending time 
> >hashing out potential changes to the RAA. For one thing, if 
> the issue 
> >is in scope they don't have to. A consensus policy IS a 
> change to the RAA.
> >If they conclude there is not a need for a policy, then why 
> would they 
> >consider RAA changes? That is either a contradiction, or it 
> gets them 
> >off looking at things they were not chartered to consider.
> >
> >For the PEDNR PDP being contemplated, Staff Council deemed 
> it in scope.
> >So if the PDP WG is formed it will look at possible new policy or 
> >policy changes (both of which are in effect changes to the RAA), and 
> >perhaps they will also consider best practices. But what is 
> the point 
> >of looking at other RAA changes? The issue they are chartered for is 
> >deemed in scope so they don't need to - they can recommend a 
> policy. If 
> >they are looking at RAA changes for something else, why?
> >
> >
> >Tim
> >
> > -------- Original Message --------
> >Subject: RE: [council] PEDNR Motion
> >From: Alan Greenberg <alan.greenberg at mcgill.ca>
> >Date: Thu, April 02, 2009 10:02 am
> >To: "GNSO Council" <council at gnso.icann.org>
> >
> >
> >I slept in a bit today, and apparently I missed the start of 
> the party!
> >
> >Let me try to clarify things. First, there are two variants of PDPs, 
> >both of which can be "in scope for GNSO consideration". I must admit 
> >that I was not clear on some of this when the discussions 
> started, but 
> >I think/hope that what I have below reflect the opinions of 
> both Marika 
> >and ICANN Counsel.
> >
> >1. Those that formulate a consensus policy for adoption by 
> the Board. 
> >Clearly the resultant policy must also be with the scope of the 
> >definition of consensus policy within the applicable 
> contract (within 
> >the "picket fence").
> >
> >2. Those that give advice to the Board. They may be completely 
> >off-topic from contract allowed consensus policies. The new 
> gTLD policy 
> >is such an example. It is not binding on contracted parties. 
> Such PDPs 
> >can even be deemed out of scope for the GNSO. The Contractual Terms 
> >PDP06 was an example - it required a higher threshold to start.
> >
> >During the discussions that led to where we are today (both 
> in the DT 
> >and before), and as indicated in the Issues Report. The 
> problems that 
> >we are discussing may be addressed through a variety of mechanisms. 
> >Council has been very leery of WGs that enlarge their charters while 
> >operating, so it was felt important to make it clear that 
> all forms of 
> >output are allowed in this case. The Motion was an attempt at saying 
> >that there is no reason to limit a PDP to just one type of output if 
> >its deliberations lead it to belive that several are needed 
> to address 
> >the problem properly.
> >
> >a) those which are within the picket fence in the RAA could 
> result in a 
> >consensus policy recommendation to the Board.
> >b) those that would require changes to the RAA but are 
> outside of the 
> >picket fence and would have no more import than other input from the 
> >community into future revisions. But importantly, they would not be 
> >lost as they would be if they could not be one aspect of the 
> output of 
> >the PDP.
> >We have too much work to do to analyze problems and then 
> simply discard 
> >the results.
> >c) there could be recommendation for changes in compliance 
> made to the 
> >Board for implementation by ICANN compliance staff.
> >d) there could be recommendations for best practices for Registrars, 
> >which would be no more than just that - recommendations not 
> binding on 
> >anyone unless Registrars choose to follow them.
> >
> >The entire intent to be able to address the problem that 
> users see from 
> >a holistic point of view and look for the best way to 
> address it, with 
> >the least amount of "thou shalt do".
> >
> >We always have the worry about a PDP being hijacked and 
> discuss issues 
> >which were not included in the Issues Report or the Charter. In this 
> >case, Staff has written the recommendation which were quoted in the 
> >motion pretty restrictively. As the submitter of the request 
> for Issues 
> >Report, I actually wish they had given more latitude. But that *IS* 
> >what they said, and the DT decided to not attempt to change them.
> >
> >Alan
> >
> >
> >At 02/04/2009 09:40 AM, Tim Ruiz wrote:
> > >Marika,
> > >
> > >You're not getting the point. A PDP charter should, in my opinion, 
> > >either directly or indirectly be directed NOT to get 
> sidetracked with 
> > >consideration of *other* RAA changes. Otherwise it implies 
> > >considering issues that the PDP was not formed to 
> consider. If a PDP 
> > >is engaged on an *in scope* issue that could result in a consensus 
> > >policy then it should focus on that issue. We cannot have working 
> > >groups going off in any direction desired, and that's exactly what 
> > >will happen if we don't keep them focused on the issue 
> they were formed to consider.
> > >
> > >Tim
> > >
> > > -------- Original Message --------
> > >Subject: Re: [council] PEDNR Motion
> > >From: Marika Konings <marika.konings at icann.org>
> > >Date: Thu, April 02, 2009 8:15 am
> > >To: Tim Ruiz <tim at godaddy.com>
> > >Cc: Alan Greenberg <alan.greenberg at mcgill.ca>, GNSO Council 
> > ><council at gnso.icann.org>
> > >
> > >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.
> > >
> > >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.
> > >
> > >Again, apologies for the confusion.
> > >
> > >Best regards,
> > >
> > >Marika
> > >
> > >On 4/2/09 2:42 PM, "Tim Ruiz"
> > ><https://email.secureserver.net/tim@godaddy.com> wrote:
> > >
> > > Marika,
> > >
> > >Thanks for the explanation. But why is Staff encouraging PDPs to 
> > >include possible RAA changes? A consensus policy IS an enforceable 
> > >change to the RAA. The only other reason would be to 
> change something 
> > >not within the scope of the RAA picket fence. Such things 
> should NOT 
> > >be part of a PDP.
> > >
> > >A PDP should be specifically for *policy* development. If the GNSO 
> > >wants to consider things not within scope of the picket fence it 
> > >should not initiate a PDP. It can very well form a group 
> to consider 
> > >such things if it chooses with the understanding that the outcome 
> > >will not be a mandate but only a suggestion or possibly a 
> recommended 
> > >(but not enforceable) best practice. Mixing these things 
> together is 
> > >NOT a productive way to approach our work.
> > >
> > >In fact, we are forming such a group to discuss further changes to 
> > >the RAA. That group will no doubt discuss things not 
> within the RAA's 
> > >picket fence as well as some things that are. For me, if 
> this PDP is 
> > >going to proceed with the understanding that it will include 
> > >dicussion/examination of changes to the RAA, then I see no 
> point in 
> > >purusing any other discussion of the RAA.
> > >
> > >That all said, I would like to ask for the following, intended 
> > >friendly ammendment to the PEDNR motion:
> > >
> > >Replace the main paragraph of the RESOLVE portion with this:
> > >
> > >to initiate a Policy Development Process (PDP) to address 
> the issues 
> > >identified in the Post-Expiration Domain Name Recovery 
> Issues Report. 
> > >The charter for this PDP should instruct the Working Group:
> > >(i) that it should consider recommendations for best practices as 
> > >well as or instead of recommendations for Consensus 
> Policy; (ii) that 
> > >to inform its work it should pursue the availability of further 
> > >information
> > >
> > >from ICANN compliance staff to understand how current RAA 
> provisions 
> > >and consensus policies regarding deletion, auto-renewal, 
> and recovery 
> > >of domain names during the RGP are enforced; and (iii) 
> that it should 
> > >specifically consider the following questions:
> > >
> > >Also, I would suggest that the last bullet/question be 
> deleted since 
> > >the last paragraph really covers it. So to be clear, if my 
> proposed 
> > >amendment is accepted as friendly the RESOLVE portion of 
> the motion 
> > >would read:
> > >
> > >GNSO Council RESOLVES:
> > >
> > >to initiate a Policy Development Process (PDP) to address 
> the issues 
> > >identified in the Post-Expiration Domain Name Recovery 
> Issues Report. 
> > >The charter for this PDP should instruct the Working Group:
> > >(i) that it should consider recommendations for best practices as 
> > >well as or instead of recommendations for Consensus 
> Policy; (ii) that 
> > >to inform its work it should pursue the availability of further 
> > >information
> > >
> > >from ICANN compliance staff to understand how current RAA 
> provisions 
> > >and consensus policies regarding deletion, auto-renewal, 
> and recovery 
> > >of domain names during the RGP are enforced; and (iii) 
> that it should 
> > >specifically consider the following questions:
> > >
> > >-- Whether adequate opportunity exists for registrants to redeem 
> > >their expired domain names;
> > >-- Whether expiration-related provisions in typical registration 
> > >agreements are clear and conspicuous enough;
> > >-- Whether adequate notice exists to alert registrants of upcoming 
> > >expirations;
> > >-- Whether additional measures need to be implemented to indicate 
> > >that once a domain name enters the Auto-Renew Grace Period, it has 
> > >expired (e.g. hold status, a notice on the site with a link to 
> > >information on how to renew or other options to be determined).
> > >
> > >The GNSO Council further resolves that the issue of logistics of 
> > >possible registrar transfer during the RGP shall be 
> incorporated into 
> > >the charter of the IRTP Part C charter.
> > >
> > >
> > >Tim
> > >
> > > -------- Original Message --------
> > >Subject: Re: [council] PEDNR Motion
> > >From: Marika Konings
> > ><https://email.secureserver.net/marika.konings@icann.org>
> > >Date: Thu, April 02, 2009 4:20 am
> > >To: Alan Greenberg
> > ><https://email.secureserver.net/alan.greenberg@mcgill.ca>, GNSO 
> > >Council <https://email.secureserver.net/council@gnso.icann.org>
> > >
> > >Tim, please note that the recommendation you quoted from 
> the Issues 
> > >Report specifically relates to ‘the desired outcomes 
> stated by 
> > >ALAC in its request’, some of which go beyond the issues 
> > >recommended for a PDP. As noted by Alan, the drafting team 
> and staff 
> > >did discuss whether a pre-PDP WG would be appropriate, but agreed 
> > >that further research and consultation could be done as 
> part of a PDP 
> > >as the issues recommended for inclusion in a PDP have been 
> narrowly 
> > >defined. As stated in the motion, the drafting team does 
> believe it 
> > >is important to highlight in the charter that the outcomes 
> of a PDP 
> > >are not limited to recommended changes to consensus 
> policy, but could 
> > >also include recommendations regarding e.g. best practices, 
> > >compliance, possible RAA changes or further dialogue.
> > >
> > >On a different note, but related to the Post-Expiration 
> Domain Name 
> > >Recovery Issues Report, I would like to draw your attention to a 
> > >deletion and renewal consensus policy audit in relation to the 
> > >Expired Domain Deletion Consensus Policy that was carried 
> out by the 
> > >ICANN’s compliance team recently (see further details 
> attached). 
> > >Follow-up audit activity is being carried out as a result of the 
> > >non-compliance identified in the audit. As a result of this 
> > >follow-up, the compliance team estimates that the number of 
> > >non-compliant registrars is about 30-40% less today then 
> when the report was published.
> > >
> > >With best regards,
> > >
> > >Marika
> > >
> > >On 4/2/09 5:11 AM, "Alan Greenberg"
> > ><https://email.secureserver.net/alan.greenberg@mcgill.ca> wrote:
> > >
> > >
> > >
> > >The drafting team did discuss this. The conclusion was (and staff 
> > >concurred if I remember correctly) that any further consultation 
> > >could reasonably be done as part of the PDP. We also 
> talked about a 
> > >public forum in Sydney, the exact contents of which would 
> depend on 
> > >how far along the WG (presuming we use a WG) had gotten.
> > >
> > >I guess the question came down to whether we felt that some policy 
> > >development and non-policy recommendations were required 
> regardless, 
> > >and whether the outcomes of pre-PDP consultation would change the 
> > >details of the recommendations to be put in a PDP charter. 
> The answer 
> > >to the first question was yes, we did feel that PDP action was 
> > >required, and we did not think that the specific recommendations 
> > >would change. How a WG addresses the issues may well change, but 
> > >since it did not appear that the results of such 
> consultation would 
> > >alter the PDP charter, there did not seem to be any reason 
> to delay.
> > >
> > >Although not discussed, I would envision a call for input on some 
> > >targeted questins as an early part of the process.
> > >
> > >Alan
> > >
> > >At 01/04/2009 06:09 PM, you wrote:
> > >
> > > >I was re-reading the issues report and was reminded of this Staff
> > > >recommendation:
> > > >
> > > >"In relation to the desired outcomes stated by ALAC in 
> its request, 
> > > >ICANN staff notes that while most, if not all, outcomes might be 
> > > >achieved by the recommendations identified by the ALAC, 
> it would be 
> > > >helpful for all parties concerned to engage in a more fulsome 
> > > >dialogue on the extent and detailed nature of the concerns to 
> > > >determine whether these are shared desired outcomes and 
> if so, how 
> > > >these could best be addressed in policy work going forward, 
> > > >including a more robust discussion of the merits and 
> drawbacks of 
> > > >various solutions to address agreed concerns. The GNSO Council 
> > > >might consider such an activity, which could take the 
> form of one 
> > > >or more public workshops at an upcoming ICANN meeting, 
> for example, 
> > > >as a precursor for the launch of a PDP as it would help 
> to define 
> > > >and focus the policy development process on one or more specific 
> > > >proposed changes.
> > > >While this could
> > > >also be explored by a working group following the launch 
> of a PDP, 
> > > >staff recommends further fact finding first to figure out what 
> > > >policy options might exist, and then conduct a PDP to assess the 
> > > >impact of those policy options and confirm community 
> support for a 
> > > >preferred policy choice."
> > > >
> > > >I don't recall that we discussed whether we should follow this 
> > > >advice or not. Alan, is there a reason why your motion 
> initiates a 
> > > >PDP instead of the fact finding that the Staff suggests be done 
> > > >first?
> > > >
> > > >
> > > >Tim
> 
> 
>