Re: [council] PEDNR Motion

Chuck, RAA 4.1.2 (http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.1.2) provides that registrars have to comply with new or revised policies if the topic is within the picket fence OR if the agreement "expressly provides for compliance" such as in subsections 3.3.4, 3.3.8, 3.7.5, 3.7.8, and 3.7.9. For further details, please see http://gnso.icann.org/mailing-lists/archives/council/msg06359.html.

With best regards,

Marika


On 4/9/09 2:26 AM, "Chuck Gomes" <cgomes@verisign.com> wrote:

Thanks Marika.

I am curious as to why the word 'generally' was used in the following sentence: "However, if a PDP recommends binding new obligations on registries or registrars, these generally would need to be on topics that are inside the picket-fence in order to be enforceable."?

Chuck



________________________________
From: Marika Konings  [mailto:marika.konings@icann.org]
Sent: Wednesday, April 08, 2009  3:49 PM
To: Gomes, Chuck; Alan Greenberg; GNSO  Council
Subject: Re: [council] PEDNR Motion


As some of you requested feedback from staff, I would  like to let you know that ICANN Legal Counsel has confirmed that the question  of within scope /outside of scope relating to the initiation of a PDP relates  to whether an issue is within scope of GNSO policy-making (i.e. within ICANN’s  mission and linked to gTLDs). In the case of PEDNR, the issues fall within  ICANN’s mission and are related to gTLDS, so no higher threshold is required  for the initiation of a PDP. However, if a PDP recommends binding new  obligations on registries or registrars, these generally would need to be on  topics that are inside the picket-fence in order to be enforceable.

A  working group charter should outline narrowly defined issues to be addressed  by a WG that should not be broadened without the explicit agreement of the  GNSO Council. However, in examining these narrowly defined issues and  exploring potential solutions, it is appropriate for a WG to explore the best  solution possible whether it is a proposed new registry or registrar  obligation or some other sort of recommendation/solution.

Apologies for  the delay in responding.

Best regards,

Marika


On  4/2/09 11:55 PM, "Chuck Gomes" <cgomes@verisign.com>  wrote:




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
> > >
> > >
> > >
>  >  >
>
>
>
>