RE: [council] PEDNR Motion

Alan,

Please see my comments inserted below.

Chuck 

> -----Original Message-----
> From: owner-council@gnso.icann.org 
> [mailto:owner-council@gnso.icann.org] On Behalf Of Alan Greenberg
> Sent: Thursday, April 02, 2009 3:40 PM
> To: Tim Ruiz; GNSO Council 
> Subject: RE: [council] PEDNR Motion
> 
> 
> Tim, I will let Marika definitively address that. 
> But here is my understanding.
> 
> There are two types of "out-of-scope":
> 
> - Those that are deemed by legal council to be out of the 
> GNSO scope, and those require a higher threshold to initiate a PDP.

Chuck: I do not know to what you are referring regarding the latter, 'those require a higher threshold to initiate a PDP'.  Please explain.
 
> 
> - Those that are out-of-scope of the picket fence. If deemed 
> to be within Council scope as above, they do not require the 
> higher threshold, but of course cannot be used to set a 
> consensus policy.

Chuck: Again, where does the 'higher threshold' concept come from.  In the case of possible consensus policies, if the Council recommends a consensus policy with a supermajority vote, then the threshold for the Board rejecting it is higher than it is if the Council recommends it with a simple majority vote.  Is that what you are referring to?

> 
> I was told that the entire PEDNR issue is within GNSO scope, 
> and it was worded as such based on that advice. But clearly 
> only parts are within the picket fence of the RAA.
> 
> All of this is not what I understood going into this process, 
> but *IF* I got it right, that is the current interpretation 
> according to staff.
> 
> Alan
> 
> At 02/04/2009 02:43 PM, Tim Ruiz wrote:
> 
> >If that's the type of thing we want this group to look at then it 
> >requires a different threshold of approval, correct? It's not 
> >appropriate to try and include out of scope things with in 
> scope things 
> >because the latter has a lower threshold of approval to get started.
> >
> >So perhaps that's the fundamental question. But I suggest 
> this motion 
> >stick with what's in scope.
> >
> >Tim
> >
> >   -------- Original Message --------
> >Subject: RE: [council] PEDNR Motion
> >From: Alan Greenberg <alan.greenberg@mcgill.ca>
> >Date: Thu, April 02, 2009 1:14 pm
> >To: GNSO Council <council@gnso.icann.org>
> >
> >
> >Tim, We are talking to different ends. I am talking about changes to 
> >how compliance is measured or enforced.
> >
> >I will give a specific and current example. The February 2009 
> >Contractual Compliance Semi-Annual Report. One of the measures was 
> >whether Registrars were honoring the Deletion and Renewal Consensus 
> >Policy. This was carried out by reviewing Registrar web sites.
> >
> >ICANN Counsel has confirmed the a Registrar cannot avoid their 
> >contractual obligations by simply sub-contracting the 
> responsibilities 
> >to others. This is explicitly reinforced in the recently 
> approved RAA 
> >Amendments. The Registrar is responsible if their 
> subcontractor is not 
> >adhering to the agreement.
> >
> >However, compliance staff have routinely said that they 
> cannot consider 
> >reseller issues, because ICANN does not have a contract with these 
> >resellers. However, if one is to try to audit a registrar who has 
> >sub-contracted obligations to a reseller, one must look at whether 
> >their resellers are doing the job properly - there is no 
> other way for 
> >ICANN to independently conduct such an audit. Requiring that 
> ICANN at 
> >least sample resellers for those Registrars who use them should be 
> >mandatory.
> >
> >To this end, I may be mistaken, but I don't believe that the 
> RAA (old 
> >or new) requires that Registrars disclose to ICANN who their 
> resellers 
> >are. Yet without this information, how can ICANN even 
> pretend that they 
> >are auditing their contracts. Adding such a requirement is 
> exactly the 
> >kind of issue that could only be addressed under the "advice 
> for future 
> >RAA amendments" type of PDP output.
> >
> >Alan
> >
> >At 02/04/2009 01:44 PM, Tim Ruiz wrote:
> > >Alan,
> > >
> > >My amendment uses the verbiage right out of the issues 
> report. But to 
> > >answer you question directly, I don't see any reason to include it.
> > >
> > >As Staff suggests in the issues report, the TF or WG 
> should consider 
> > >information from compliance Staff about how related 
> current policy is 
> > >enforced (related RAA provisions and related consensus policies). 
> > >This information could be used by the group to craft 
> consensus policy 
> > >or consensus policy changes that complaince Staff could 
> actually enforce.
> > >That's an expected consideration in any policy 
> developement work and 
> > >doesn't really need to be spelled out.
> > >
> > >Tim
> > >
> > > -------- Original Message --------
> > >Subject: RE: [council] PEDNR Motion
> > >From: Alan Greenberg <alan.greenberg@mcgill.ca>
> > >Date: Thu, April 02, 2009 12:06 pm
> > >To: "GNSO Council" <council@gnso.icann.org>
> > >
> > >
> > >Tim, we may agree to differ on this.
> > >
> > >In your proposed replacement motion, you also dropped and 
> reference 
> > >to the PDP process making recommendations to ICANN 
> compliance staff. 
> > >Do you have a reason for excluding this as well?
> > >
> > >Alan
> > >
> > >At 02/04/2009 12:03 PM, Tim Ruiz wrote:
> > >
> > > >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@mcgill.ca>
> > > >Date: Thu, April 02, 2009 10:41 am
> > > >To: "GNSO Council" <council@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@mcgill.ca>
> > > > >Date: Thu, April 02, 2009 10:02 am
> > > > >To: "GNSO Council" <council@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@icann.org>
> > > > > >Date: Thu, April 02, 2009 8:15 am
> > > > > >To: Tim Ruiz <tim@godaddy.com>
> > > > > >Cc: Alan Greenberg <alan.greenberg@mcgill.ca>, GNSO Council 
> > > > > ><council@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.gree
> > nberg@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
> 
> 
> 
>