RE: [council] PEDNR Motion

Thanks Alan.  I forgot about that.

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 5:46 PM
> To: GNSO Council 
> Subject: RE: [council] PEDNR Motion
> 
> 
> I am referring to the voting threshold needed to INITIATE a 
> PDP.  According to the Bylaws Annex A 3.c
> 
> "A vote of more than 33% of the Council members present in 
> favor of initiating the PDP will suffice to initiate the PDP; 
> unless the Staff Recommendation stated that the issue is not 
> properly within the scope of the ICANN policy process or the 
> GNSO, in which case a Supermajority Vote of the Council 
> members present in favor of initiating the PDP will be 
> required to initiate the PDP."
> 
> Although the start of it was before my time, I was told that 
> PDP06 (gTLD Contractual Conditions) was deemed by ICANN Legal 
> Counsel to be outside of GNSO Scope and required the higher threshold.
> 
> In this present case, the Issues Report says and I have had 
> it confirmed that the issue is within scope of the GNSO.
> 
> Alan
> 
> 
> At 02/04/2009 05:16 PM, Gomes, Chuck wrote:
> >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 utcomes stated by ALAC in
> > > > > > > >its
> > > > 
> > 
> requestâÂÂÂÂÃ
> > ‚€ÃƒƒÃ‚‚™,
> >
> > > some of wh 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
> > > >ƒâ€šÃ‚â„¢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
> > >
> > >
> > >
> > >
> 
> 
> 
>